Welcome to weblogs.com.pk Sign in | Join | Help

Masood Ahmad Shah

This blog contains a summary of my research readings and thoughts in system and network engineering. View Masood Shah's profile on LinkedIn

Syndication

News


SDN Controllers Comparison with hands on labs

Author: Masood Ahmad Shah (Charles Sturt University)

Objective

SDN1 Controllers are the brain and decision maker in the SDN-based network infrastructure. A controller consist of a set of application components to act as an essential control point in the network infrastructure and make decisions to programs the forwarding behavior for the packets passing through routers/switches.There are a number of SDN controllers exist, and are still being developed and used at an ever-increasing pace and have the potential of being used for next generation networks.

The objective of this document is to provide a basis and rationale to indicate differences in between different controllers, by comparing how user-friendly they are and what sort of features they offer. In addition to that implement a SDN based network infrastructure by using at least two different SDN controllers and do a flow walk from switch to controller and vice versa.

Part (a) SDN controllers

As stated earlier a SDN controller is a control center of the SDN based network, talking with switches through south-bound link to program packet forwarding instructions and communicate with applications on it’s north-bound side. There are multiple SDN controllers available and they differ from each other in various aspects. In this section, we will compare the following four controllers from the perspective of feature set, integration, applicability and easiness of use.

  1. OpenDaylight
  2. Open Network Operating System (ONOS)
  3. Ryu
  4. Trema

1Software Defined Network

I’m summarising the comparison of above four controllers by looking at features, capability, applicability and supported networks. The following diagram shows the different characteristics that I would use for comparative analysis: 

The value of a SDN controller characteristics arises from the fact of its applicability, features set and easiness of use a controller support. For example, a controller must have features such as Neutron plugins, and port and flow configurability if a controller has to support openStack-based virtualization of a network.

On top of that, applications also require the services they want from the network. For example, an application that is very delay sensitive would expect from controller to provide an end-to-end path with minimum delay and jitter.

Let’s look at different aspects of multiple controllers, the result of the comparison is shown below in a tabular format. As a results, none of the controllers seem to be optimal but OpenDaylight looks more suitable for the majority of the use case and requirements. 

In summary the controller is selected by matching the requirements of a network. OpenDaylight is a clear winner based on the above comparison and could be one of the reasons for its his popularity among vendors. Ryu and ONOS have a similar number of use case supports, where Ryu having support for two important use cases: packets service insertion and chaining. Similarly, Trema has similar uses case supports but poor in supporting a whole bunch of features set.

Part (b) Hands on experience with SDN Controllers

The purpose of this section is to set up a SDN LAB and walkthrough how OpenFlow would work in a production SDN deployment.

OpenDaylight + Mininet

Software platform to build lab

  • Linux (Core operating system to run Virtual machines for OpenDaylight and Mininet)
  • OpenDaylight (SDN Controller)
  • Mininet (to create a realistic large scale virtual network running actual kernel, switch and software application code)

Step 1: Installation OpenDaylight and Mininet

OpenDaylight was installed by following a pretty straightforward process[2] that is well documented on OpenDaylight at wikihttps://wiki.opendaylight.org/view/Install_On_Ubuntu_14.04 

In a similar manner, Mininet pre-built VM image was downloaded/installed by following the Mininet documentation https://github.com/mininet/mininet/wiki/Mininet-VM-Images. Once installed then ssh to the VM instance listening on port 8022:

Step 2: Building network

A network was build using tree topology with Open vSwitch switches with the control of OpenDaylight as SDN controller making use of OpenFlow13 to talk to south bound switches. The following command is used:

sudo mn --topo tree,4 --mac --controller=remote,ip=100.102.132.52,port=6633 --switch ovs,protocols=OpenFlow13

And as a results, the following screenshot confirms I entered into Mininet’s CLI that allows to control, and manage the entire virtual network from a single console. For example, the CLI command:

Step 3: Controller communication with the switches

At the same time while tailing logs on the OpenDaylight controller I observed that all of the seven Open vSwitches can talk to controller that we set up during the creation of network via --controller=remote,ip=100.102.132.52,port=6633. Logs from the controller confirming that switches managed to establish a TCP connection:

2016-10-17 18:29:37,135 | INFO | ntLoopGroup-5-14 | RoleService                     | 303 - org.opendaylight.openflowplugin.impl - 0.3.0.Boron | submitRoleChange called for device:Uri [_value=openflow:3], role:BECOMEMASTER

2016-10-17 18:29:37,172 | INFO | ntLoopGroup-5-14 | RoleService                     | 303 - org.opendaylight.openflowplugin.impl - 0.3.0.Boron | submitRoleChange onSuccess for device:Uri [_value=openflow:3], role:BECOMEMASTER

2016-10-17 18:29:32,863 | INFO | entLoopGroup-5-9 | RoleService                     | 303 - org.opendaylight.openflowplugin.impl - 0.3.0.Boron | submitRoleChange called for device:Uri [_value=openflow:1], role:BECOMEMASTER

2016-10-17 18:29:33,000 | INFO | entLoopGroup-5-9 | RoleService                     | 303 - org.opendaylight.openflowplugin.impl - 0.3.0.Boron | submitRoleChange onSuccess for device:Uri [_value=openflow:1], role:BECOMEMASTER

2016-10-17 18:29:33,157 | INFO | ntLoopGroup-5-10 | RoleService                     | 303 - org.opendaylight.openflowplugin.impl - 0.3.0.Boron | submitRoleChange called for device:Uri [_value=openflow:7], role:BECOMEMASTER

2016-10-17 18:29:33,159 | INFO | ntLoopGroup-5-10 | RoleService                     | 303 - org.opendaylight.openflowplugin.impl - 0.3.0.Boron | submitRoleChange onSuccess for device:Uri [_value=openflow:7], role:BECOMEMASTER

2016-10-17 18:29:35,066 | INFO | ntLoopGroup-5-12 | RoleService                     | 303 - org.opendaylight.openflowplugin.impl - 0.3.0.Boron | submitRoleChange called for device:Uri [_value=openflow:2], role:BECOMEMASTER

2016-10-17 18:29:35,190 | INFO | ntLoopGroup-5-12 | RoleService                     | 303 - org.opendaylight.openflowplugin.impl - 0.3.0.Boron | submitRoleChange onSuccess for device:Uri [_value=openflow:2], role:BECOMEMASTER

2016-10-17 18:29:35,404 | INFO | ntLoopGroup-5-15 | RoleService                     | 303 - org.opendaylight.openflowplugin.impl - 0.3.0.Boron | submitRoleChange called for device:Uri [_value=openflow:6], role:BECOMEMASTER

2016-10-17 18:29:35,513 | INFO | ntLoopGroup-5-15 | RoleService                     | 303 - org.opendaylight.openflowplugin.impl - 0.3.0.Boron | submitRoleChange onSuccess for device:Uri [_value=openflow:6], role:BECOMEMASTER

2016-10-17 18:29:35,677 | INFO | ntLoopGroup-5-11 | RoleService                     | 303 - org.opendaylight.openflowplugin.impl - 0.3.0.Boron | submitRoleChange called for device:Uri [_value=openflow:5], role:BECOMEMASTER

2016-10-17 18:29:36,397 | INFO | ntLoopGroup-5-11 | RoleService                     | 303 - org.opendaylight.openflowplugin.impl - 0.3.0.Boron | submitRoleChange onSuccess for device:Uri [_value=openflow:5], role:BECOMEMASTER

2016-10-17 18:29:36,512 | INFO | ntLoopGroup-5-13 | RoleService                     | 303 - org.opendaylight.openflowplugin.impl - 0.3.0.Boron | submitRoleChange called for device:Uri [_value=openflow:4], role:BECOMEMASTER

2016-10-17 18:29:36,527 | INFO | ntLoopGroup-5-13 | RoleService                     | 303 - org.opendaylight.openflowplugin.impl - 0.3.0.Boron | submitRoleChange onSuccess for device:Uri [_value=openflow:4], role:BECOMEMASTER

OpenDaylight GUI (web interface) populated the topology as well, however not hosts yet. The reason of not discovering hosts is because we have not exchanged any frames yet. 

Step 4: Testing out connectivity and hosts discovery

Running pingall test to check connectivity between every pair of nodes to discover the hosts connected to switches: 

Since now we have run the pingall that passed the frames among all of the nodes. Given that, the hosts are (now) discovered and so we should be able to see all of the hosts on the controller:

The above snapshots and logs confirm that SDN network setup has now been completed successfully. Let’s dig into flow tables.

Step 5: Flow table

From Mininet CLI “ovs-ofctl” could be used to dump flow table for the switches. Say for example, we could use the following command in order to dump flow table for the switch named openflow:1

“sh ovs-ofctl dump-flows -O OpenFlow13 s1“ 

The other alternative command to dump the the flow table is “dpctl”. Say for example, if we want to dump all the flows on all switches “dpctl dump-flows -O OpenFlow13”

ONOS + Mininet

Software platform

  • Linux (Core operating system to run Virtual machines for ONOS and Mininet)
  • ONOS
  • SDN Controller
  • Mininet
  • To create a realistic large scale virtual network running actual kernel, switch and software application code.

Step 1: Installation ONOS and Mininet

ONOS was installed by following a straightforward process[3] that is well documented onhttps://wiki.onosproject.org/display/ONOS/Installing+and+Running+ONOS

Step 2: Building network

Since we have not connected any switch to the ONOS controller (yet) and so there is no topology, devices, hosts or flows.

Now since the mininet was/is already installed on the computer (during OpenDaylight + Mininet exercise) and all I needed to is that build a topology with Open vSwitch switches with the control of ORON as SDN controller to talk to south bound switches. The following command is used:

sudo mn --topo linear,5 --mac --controller=remote,ip=100.102.132.52,port=6633


Topology: Linear

ONOS Controller: 100.102.132.52 listening on port 6653

And as a results, the following screenshot confirms I entered into Mininet’s CLI that allows to control, and manage the entire virtual network from a single console. For example, the CLI command:

Step 3: Controller communication with the switches

While tailing logs on the ONOS controller we observed that all of the five Open vSwitches can talk to controller that we set up during the creation of network via --controller=remote,ip=100.102.132.52,port=6633. Logs from the controller confirming that switches managed to establish a TCP connection:

2016-10-18 13:45:42,277 | INFO | ew I/O worker #2 | DeviceManager                   | 76 - org.onosproject.onos-core-net - 1.8.0.SNAPSHOT | Local role is MASTER for of:0000000000000001

2016-10-18 13:45:42,277 | INFO | ew I/O worker #3 | DeviceManager                   | 76 - org.onosproject.onos-core-net - 1.8.0.SNAPSHOT | Local role is MASTER for of:0000000000000002

2016-10-18 13:45:42,316 | INFO | ew I/O worker #3 | ntrollerImpl$OpenFlowSwitchAgent | 168 - org.onosproject.onos-of-ctl - 1.8.0.SNAPSHOT | Transitioned switch 00:00:00:00:00:00:00:02 to MASTER

2016-10-18 13:45:42,318 | INFO | ew I/O worker #2 | ntrollerImpl$OpenFlowSwitchAgent | 168 - org.onosproject.onos-of-ctl - 1.8.0.SNAPSHOT | Transitioned switch 00:00:00:00:00:00:00:01 to MASTER

2016-10-18 13:45:42,322 | INFO | ew I/O worker #4 | DeviceManager                   | 76 - org.onosproject.onos-core-net - 1.8.0.SNAPSHOT | Local role is MASTER for of:0000000000000003

2016-10-18 13:45:42,325 | INFO | ew I/O worker #4 | ntrollerImpl$OpenFlowSwitchAgent | 168 - org.onosproject.onos-of-ctl - 1.8.0.SNAPSHOT | Transitioned switch 00:00:00:00:00:00:00:03 to MASTER

2016-10-18 13:45:42,407 | INFO | ew I/O worker #5 | DeviceManager                   | 76 - org.onosproject.onos-core-net - 1.8.0.SNAPSHOT | Local role is MASTER for of:0000000000000004

2016-10-18 13:45:42,417 | INFO | ew I/O worker #5 | ntrollerImpl$OpenFlowSwitchAgent | 168 - org.onosproject.onos-of-ctl - 1.8.0.SNAPSHOT | Transitioned switch 00:00:00:00:00:00:00:04 to MASTER

2016-10-18 13:45:42,450 | INFO | ew I/O worker #6 | DeviceManager                   | 76 - org.onosproject.onos-core-net - 1.8.0.SNAPSHOT | Local role is MASTER for of:0000000000000005

2016-10-18 13:45:42,452 | INFO | ew I/O worker #6 | ntrollerImpl$OpenFlowSwitchAgent | 168 - org.onosproject.onos-of-ctl - 1.8.0.SNAPSHOT | Transitioned switch 00:00:00:00:00:00:00:05 to MASTER

ONOS console has (now) populated the topology:

However it has not discovered hosts yet. The reason of not discovering hosts is because we have not exchanged any frames yet. 

Step 4: Testing out connectivity and hosts discovery

Running pingall test to check connectivity between every pair of nodes to discover the hosts connected to switches: 

Since now we have run the pingall that passed the frames among all of the nodes. Given that, the hosts are (now) discovered on the ONOS controller and so we should be able to see all of the hosts on it:

Step 5: Flow table

From Mininet CLI “ovs-ofctl” could be used to dump flow table for the switches. Say for example, we could use the following command in order to dump flow table for the switch named openflow:1

“sh ovs-ofctl dump-flows s1“ 

Flow table similarity can be seen on the ONOS controller as well: 


References

"Software Defined Networking (SDN): Anatomy of OpenFlow Volume I (Volume 1) by Doug Marschke (Author), Jeff Doyle (Contributor), Pete Moyer (Contributor)

Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud 1st Edition by William Stallings

OpenDaylight installation https://wiki.opendaylight.org/view/Install_On_Ubuntu_14.04 [2]

ONOS installation ://wiki.onosproject.org/display/ONOS/Installing+and+Running+ONOS [3]

Published Friday, May 19, 2017 4:03 PM by jahil

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

No Comments

Leave a Comment

(required) 
required 
(required)