Basic SDN Construction/Testbed Setup

September 19, 2019 Leave a comment

Shaunak Mashalkar, Dillon Leigh, Chris Batula, Holden Gordon

Under the supervision of Dr. Behnam Dezfouli & Dr. Yuhong Liu

What is an SDN? A brief context: 

At the most basic level, an SDN, or software-defined network, consists of a control plane and a data plane directing traffic to and from hosts. The control plane may consist of one or more controllers; the data plane may include both SDN-capable switches and traffic-processing middleboxes; traffic may be between hosts on the network or external servers, as is often the case in IoT with remote management and data collection. At all levels, a variety of potential implementations and firmwares exist. In our decoupled testbed, we are currently opting to use OpenFlow as a unifying inter-component management protocol, with one OpenDaylight (ODL) instance as a controller and one Open vSwitch (OvS) instance for data plane implementation.

Controller configuration:

The testbed ODL instance runs on a Mac. The specs are as follows:

  • OS: macOS Mojave Version 10.14.5
  • Processor Name: Intel Core m5
  • Processor Speed: 1.2GHz
  • Number of Processors: 1
  • Total Number of Cores: 2
  • L2 Cache (per core): 256 KB
  • L3 Cache: 4 MB
  • Hyperthreading: Enabled
  • Memory: 8 GB

The program runs on Apache Karaf, an OSGi runtime environment that has inbuilt support for easy installation of extra ‘features’ from any project’s externally hosted libraries; in ODL’s case, features are utilized to add optional controller functionalities (read: virtually all of them). An attempt was made to run ODL on a Raspberry Pi (3 Model B, V1.2.) However, ODL is memory- and processing-intensive and as such, does not function well on the Pi. Within certain limits, the amount of memory allocated to the runtime environment can be adjusted from 4096 MB (as directed by the setenv.bat file found in the installation’s bin folder); the smallest purposefully observed runtime allocation so far is 1024 MB (search for JAVA_MAX_MEM in the file to adjust), but even that leads to errors when running on the Pi.
To launch ODL within a terminal, simply run the karaf script also within the bin folder.

As an open source project, ODL’s development cycle sees new versions released fairly frequently — the most recent version is Neon (0.10.1). However, much of its case-by-case functionality is implemented in the form of Karaf features instead of being inbuilt, and must be updated separately. At the time of writing, newer versions (0.9+) of ODL are not compatible with the current versions of features required for our project specifications. As such, the team uses the latest Oxygen (0.8.4) installation of ODL for the testbed. ODL 0.8.4 assumes a Java 8 environment, and will not run properly on later versions; you may need to install it manually. 

The documentation for ODL Oxygen can be found here: https://docs.opendaylight.org/en/stable-oxygen/

List of installed features:

  • OpenFlow Plugin (library): enables controller-switch communication and management through the OpenFlow SDN protocol — mainly includes interfaces/APIs (i.e. southbound (controller-switch) and REST) and network mapping/information (OpenFlow topology/statistics tools)
  • L2 Switch (library): “provides Layer2 switch functionality” managing flow creation and network topology based on typical SDN packet-in flow creation procedures; effectively directs flow table content, and traffic through that
  • DLUX (library): adds browser-based user interface for network visualization/infometrics and control; able to access remotely (so long as controller can be SSH’d)

Switch configuration:

Open vSwitch is an open source, multilayer virtual OpenFlow switch. It is licensed under the open source Apache 2.0 license. The OvS instance (ver. 2.5.2) used for the test-bed was run on a Raspberry Pi 3 Model B V1.2 with Raspbian 8.0 installed separate from the controller device, though it is possible to run both the controller and the switch on the same device. As a standard, most VMs and practical implementations utilize OvS.

The documentation for OvS can be found here: https://docs.openvswitch.org/en/latest/

To set up OvS, we followed the instructions at https://sumitrokgp.wordpress.com/2017/05/18/converting-a-raspberry-pi-to-a-openflow-switch/. In case the blog post is removed, here are the instructions:

  1. Download the Open vSwitch archive (wget http://openvswitch.org/releases/openvswitch-2.5.2.tar.gz) and unpack it in the root home directory. 
  2. Install OvS: 
    • apt-get install python-simplejson python-qt4 libssl-dev python-twisted-conch automake autoconf gcc uml-utilities libtool build-essential pkg-config
    • apt-get install linux-headers-3.10-3-rpi
  3.  In the Open vSwitch folder: ./configure –with-linux=/lib/modules/3.10-3-rpi/build
  4. Make and (make) install. 
  5.  Go to datapath/linux and turn on the module: modprobe openvswitch
  6. Create a script: ovs_script.sh with the following code: 
    • #!/bin/bashovsdb-server –remote=punix:/usr/local/var/run/openvswitch/db.sock \    –remote=db:Open_vSwitch,Open_vSwitch,manager_options \    –private-key=db:Open_vSwitch,SSL,private_key \    –certificate=db:Open_vSwitch,SSL,certificate \    –bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert \    –pidfile –detachovs-vsctl –no-wait initovs-vswitchd –pidfile –detachovs-vsctl show
  7. Create a file for the database which will contain important information about the switch: touch /usr/local/etc/ovs-vswitchd.conf
    mkdir -p /usr/local/etc/openvswitch
  8. Populate the database: ./openvswitch-2.5.2/ovsdb/ovsdb-tool create /usr/local/etc/openvswitch/conf.db /root/openvswitch-2.5.2/vswitchd/vswitch.ovsschema
  9. Run the script that was created earlier.

To connect the switch and the controller, we modified the switch’s network interface configuration file to set the Pi’s ethernet port to a static address that could then be hardwired to the controller. This is how the Pi’s interface configuration file was modified:

  1. As root: pico /etc/network/interfaces
  2. Add: 
    • auto eth0 //automatically brings up eth0 port on system start
    • iface eth0 inet static //denotes that eth0’s ip is being set to a static value
    • address [this machine’s address on the port; we used 10.0.1.7 arbitrarily] 
    • netmask 255.255.255.0
  3. Run: /etc/init.d/networking restart

Linking Components

When both the controller and switch are running, the controller passively listens on the OpenFlow port (6653 for version 1.3) for a switch instance. On the Ethernet connection, within the computer’s associated (high level) adapter settings, the controller’s ip was also set to a static 10.0.1.8 with a netmask of 255.255.255.0.

With the control channel set, an initial bridge instance can be created within OvS with ovs-vsctl add-br [bridgename], and ports can be added to its jurisdiction (from adapters or otherwise) with ovs-vsctl add-port [bridgename] [interfacename] (example: ovs-vsctl add-port br0 eth1). Keep in mind that the control port should not be added by this method; once encompassed by the switch, OvS considers interfaces for traffic routing rather than OpenFlow direction. Finally, to set the controller (assumedly still connected with the Karaf runtime active), use ovs-vsctl set-controller [bridgename] [tcp:controller-ip:6653]; upon success, the status message found in ovs-vsctl show should include is_connected:true. In our testbed with the 10.0.1.[] prefix, the command read ovs-vsctl set-controller br0 tcp:10.0.1.8:6653. Using compatible USB-Ethernet adapters (listed at https://elinux.org/RPi_USB_Ethernet_adapters ), any hosts or devices connected to the switch ports should now have their inbound and outbound flows configured automatically. Locally, the SDN has full functionality.

Leave a Reply

Your email address will not be published. Required fields are marked *