Review: SDN and OpenFlow for Beginners with Hands on Labs

I have just finished reading SDN and OpenFlow for beginners with Hands on Labs by Vivek Tiwari, and I can honestly say that I was really impressed. If you have read a few of my posts before then you probably know that I am not a fan of overly expensive books - and this is really good value for money. It's not a long book, and is priced very reasonably at $7.99.

Vivek is a double CCIE (Routing and Switching and Service Provider) and his experience within the field and as a mentor definitely comes through. His writing style is friendly and anecdotal making what could be a very dry topic come across as interesting and fun.

SDN and OpenFlow for Beginners

The book is split into two parts.

An introduction to OpenFlow and SDN

Part one covers "What is SDN?" where we get a very good technical and also non-technical breakdown of what SDN actually does and a history of SDN and OpenFlow. He then goes into greater depth explaining CAM and TCAM functions, and why these are important to understand in order to benefit from what SDN has to offer.

With a good understanding of CAM and TCAM he then explains the concepts behind flows and actions, before going into the OpenFlow protocol, and then into the advantages of OpenFlow, and how it can benefit the different areas of the business from both a financial standpoint and from an engineering view.

Lastly in part one we have the future of SDN.

Hands on Labs on SDN using OpenFlow

Part two is where the real fun starts. Vivek walks us through setting up our own little lab using freely available tools, and a great example of using OpenFlow to manage our network. He walks us through installing OpenDaylight, mininet, VMWare player, and some other tools, such as Putty, we well as a quick pointer in how to snoop on OpenFlow conversations in Wireshark.

The examples may not be extensive, but this is not meant to be an extensive book, it's meant to get you up and running. That said the example he gives, of using OpenDaylight to set the default gateway for our switches is a very good and relevant one that shows the power of the SDN tools at our command.

Overall thoughts

This is a really good book. It's priced really nicely and it won't take long to read. The formatting for kindle is well done, which for a technical book is not the easiest thing in the world, and it is very easy to read.

If you have any interest in SDN, and really you should as it's going to take off massively over the next couple of years then you should definitely buy this book.

Getting started with Cisco onePK

Following on from the previous post on Software-Defined Networks (SDN), we are going to have a quick look at Cisco's onePK.

onePK and the Software Defined Network

onePK stands for One Platform Kit, its what gets us started with programming for the Cisco Open Network Environment. It is basically a set of APIs for programming your network devices (IOS, IOS-XE, IOS-XR and NX-OS) in C (well C64 to be more exact), Java and Python.

From Cisco's website (you'll need a CCO login for this) you can download the onePK all-in-one image for Ubuntu, which can run very nicely in VirtualBox. It is a 2.61Gb image that contains everything you'll need to get started, including 3 IOSv routers and the Eclipse IDE.

I downloaded the all-in-one VM and fired it up, but learned that before you do this you need to make sure that the second adapter is set to a host-only adapter. If you get an error that one cannot be found then go to preferences (of VirtualBox - not of the VM), select Network, click on Host-only Networks, and click add to create one:

The VM settings should look a bit like this now, the first adapter is set to bridged (so that I have ssh access to the VM):

Once it's installed into VirtualBox login in as "cisco" with a password of "cisco123" and change the password when prompted. Set the Network Simulator Credentials (I used 802101 for both), which is the username and password needed to communicate with the virtual routers.

Double click on Start 3node - if you get an error here then its probably due to lack of a host-only network - so make sure it's there and connected.

Once it's done you get a confirmation:

After you have clicked OK to the above message your routers start up:

After a short time we are launched into IOSv (VIOS-ADVENTERPRISEK9-M) Version 15.4(1.24)T0.9.

At this point it should be pointed out that the onePK vm gets a little funny about switching back and forth in order to take screenshots. I stopped the VM, added a DVD drive and installed the Guest Additions. Once done I needed to use the Stop 3node icon and then use Start 3node to get my routers back again.

With the Guest Additions making life much easier we can have a quick look at the config of our router, nothing hugely out of the ordinary here, we have a bunch of interfaces:

The only real thing of note is the onep settings:

Enabling a supported device for onep is as simple as entering "onep" at the configuration prompt, then from the sub-prompt enabling the tls transport:

router(config)#onep
router(config-onep)#transport tls

Let's try and actually do something now though.

From the desktop doubleclick on the CreateCA icon. This generates the certificate needed for communication between the nodes and the controller. At the moment I am following the instructions from the Cisco website, which follow the rule that any introduction to anything even vaguely programming orientated starts with a "Hello" example, so from the Terminal prompt on the desktop change directory (cd) to /home/cisco/onePK-sdk-1.2.0.173/c/sample-apps/HelloNetwork and run the "make" command. Once thats run through run the following:

cisco@onepk:~/onePK-sdk-1.2.0.173/c/sample-apps/HelloNetwork$ ./bin/HelloNetwork -a router1.3node.example.com -R ~/ca.pem
Enter username: 802101
Enter password: 
Connecting with onep transport type TLS. 

Router1 says: Hello Network!

cisco@onepk:~/onePK-sdk-1.2.0.173/c/sample-apps/HelloNetwork$ 

I can tell you are impressed!

To prove that the application is actually doing something we can see the router's log for the connection:

We can change the routers name:

And we can run the command again and see the reflected change:

cisco@onepk:~/onePK-sdk-1.2.0.173/c/sample-apps/HelloNetwork$ ./bin/HelloNetwork -a router1.3node.example.com -R ~/ca.pem
Enter username: 802101
Enter password: 
Connecting with onep transport type TLS. 

MyFirstRouter says: Hello Network!

cisco@onepk:~/onePK-sdk-1.2.0.173/c/sample-apps/HelloNetwork$ 

I havn't touched C programming since my university days, but onePK also supports Java and Python, so it should suit most developers in one language or another. Running a python script follows the same syntax, here is one that will get the contents of the RIB:

cisco@onepk:~/onePK-sdk-1.2.0.173/python/tutorials/routing$ ./RIBTutorial.py -a router1.3node.example.com -R ~/ca.pem
INFO:onep:RIBTutorial:Reading arguments...
Enter Username : 802101
Enter Password : 
INFO:onep:RIBTutorial:Connecting to Network Element...
INFO:onep:BaseTutorial:We have a NetworkElement : 
NetworkElement [ router1.3node.example.com ]

INFO:onep:BaseTutorial:Successful connection to NetworkElement - 
INFO:onep:RIBTutorial:Done
INFO:onep:RIBTutorial:Getting a Routing Instance...
INFO:onep:RIBTutorial:Getting a RIB...
INFO:onep:RIBTutorial:adding RIB listener...
INFO:onep:RIBTutorial:1001
INFO:onep:RIBTutorial:Routes are : 
INFO:onep:RIBTutorial:L3UnicastRoute[address:10.10.10.0/24,ownerType:CONNECTED,ownerTag:,adminDistance:0,metric:0,errorCode:0]
INFO:onep:RIBTutorial:L3UnicastRoute[address:10.10.10.110/32,ownerType:LOCAL,ownerTag:,adminDistance:0,metric:0,errorCode:0]
INFO:onep:RIBTutorial:L3UnicastRoute[address:10.10.20.0/24,ownerType:CONNECTED,ownerTag:,adminDistance:0,metric:0,errorCode:0]
INFO:onep:RIBTutorial:L3UnicastRoute[address:10.10.20.110/32,ownerType:LOCAL,ownerTag:,adminDistance:0,metric:0,errorCode:0]
INFO:onep:RIBTutorial:L3UnicastRoute[address:10.10.30.0/24,ownerType:CONNECTED,ownerTag:,adminDistance:0,metric:0,errorCode:0]
INFO:onep:RIBTutorial:L3UnicastRoute[address:10.10.30.110/32,ownerType:LOCAL,ownerTag:,adminDistance:0,metric:0,errorCode:0]
INFO:onep:RIBTutorial:L3UnicastRoute[address:192.168.56.0/24,ownerType:CONNECTED,ownerTag:,adminDistance:0,metric:0,errorCode:0]
INFO:onep:RIBTutorial:L3UnicastRoute[address:192.168.56.111/32,ownerType:LOCAL,ownerTag:,adminDistance:0,metric:0,errorCode:0]
cisco@onepk:~/onePK-sdk-1.2.0.173/python/tutorials/routing$ 

Anything that can be done on the router can be done through a script, which is great when making changes to multiple routers. Yes I know you can use cut and paste, but somethings require a certain level of out-of-band management, and onePK is just the ticket.

This has only been a really simple walk through, hopefully when I get some time I'll put together something on how to create a script with the onePK API, for now I encourage you to have a look to get a feel for the possibilities that this opens up.

What is a Software Defined Network?

Software-Defined Networking (SDN) is a huge buzz word at the moment, but what is it all about, and more importantly, how will it affect you as a network administrator?

To understand about SDN we must first understand some of the building blocks of our network hardware, and that are the different 'planes' that a switch has. These are the Control plane and the Forwarding (or data) plane.

Control Plane

The control plane looks after the configuration, management and exchange of routing table information, it keeps an eye of our neighbors and adjacencies and puts this into RIB or LIB for the forwarding plane. It also looks after things like stacking and ARP.

Forwarding Plane

The forwarding plane decides what to do with packets based on routing table, it uses the FIB and LFIB, as well as managing things like QoS, filtering and the encapsulation of packets.

Enter Software-Defined Networking

With Software-Defined Networking a controller sits between the Control Plane, and the Forwarding Plane, which should make it easier to optimize them independently of each other. This is done through an API (Application Programming Interface), and the most commonly talked about one at the moment is OpenFlow. through this API a network admin (or anyone with an understanding of the API and the right credentials) can change the network by changing port details, shaping traffic and adding or removing services in order to make the network more programmable. Cisco have their own toolkit called onePK.

The basic concept of SDN is shown below:

A programmer creates the necessary configuration in the API, which is then sent to the compatible devices via the controller.

You can run your own switch capable of OpenFlow in the form of Open vSwitch, which can turn an ordinary Linux machine into a fully fledged OpenFlow capable switch. This is not the same as an SDN controller, but you can use something like Floodlight to do this.

Using Floodlight as an SDN Controller

Floodlight can be installed from projectfloodlight.org, and I chose the ready made VM.

Once it's installed cd through to /opt/floodlight/floodlight and start the floodlight.jar file:

floodlight@localhost:/opt/floodlight/floodlight$ java -jar floodlight.jar 

You will then need to start a new ssh session as the console will start filling up with LLDP messages. If its starts properly then using your browser you should be able to navigate to http://<vm ip address>/ui/index.html:

You won't see much at the moment as we have nothing to play with. So let's get Open vSwitch installed in a VM.

Using Open vSwitch as an SDN client

I downloaded a ready built ubuntu virtualbox VM (12.10), and installed openvswitch:

sudo apt-get install openvswitch-controller openvswitch-brcompat openvswitch-switch open-vswitch-source

Next you need to edit the below file and change the line "# BRCOMPAT=no" to read "BRCOMPAT=yes"

sudo vi /etc/default/openvswitch-switch

It's a good idea to reboot at this stage. Once rebooted we can then try and start our open vswitch:

sudo service openvswitch-switch start
sudo service openvswitch-switch status

If you get errors at this stage then check to make sure that the brcom modules is loaded:

lsmod | grep brcom

If you dont get anything back then install it:

sudo module-assistant auto-install openvswitch-datapath

Then reboot and check it's loaded when they system boots up again:

sudo init 6
lsmod | grep brcom
sudo service openvswitch-switch status

At this stage everything should be running fine.

We can now set up our switch. First we create a bridge interface on the switch and then assign our network interface to it. Next we specify a controller that we want to talk to. Lastly we remove the IP address from our physical interface and assign one to our bridge interface:

sudo ovs-vsctl add-br br-int
sudo ovs-vsctl add-port br-int eth1
sudo ovs-vsctl set-controller br-int tcp:192.1678.0.13:6633
sudo ifconfig eth1 0
sudo ifconfig br-int 192.168.0.24 netmask 255.255.255.0
route add net 192.168.0.0 netmask 255.255.255.0 br-int

Now our switch shows up in our dashboard:

We also have a nice Topology to look at:

Make a note of the switch's DPID, we'll need that later for all our commands

We can see lots of hosts on the network now:

We can test the functionality out from the floodlight servers command line by using curl to send a command to a json flow pusher:

floodlight@localhost:~$ curl -d '{"switch": "00:00:08:00:27:5a:8c:d2", "name":"flow-mod-1", "priority":"32768", "ingress-port":"3","active":"true", "actions":"output=4"}' http://192.168.0.13:8080/wm/staticflowentrypusher/json
{"status" : "Entry pushed"}

The above command takes anything from port 3 and pushes it out of port 4. We can confirm that the command has been sent (along with previous commands) using the list command below:

floodlight@localhost:~$ curl http://192.168.0.13:8080/wm/staticflowentrypusher/list/00:00:08:00:27:5a:8c:d2/json
{"00:00:08:00:27:5a:8c:d2":{"flow-mod-1":{"actions":[{"port":4,"maxLength":32767,"length":8,"type":"OUTPUT","lengthU":8}],"priority":-32768,"bufferId":-1,"cookie":45035997351236006,"idleTimeout":0,"hardTimeout":0,"flags":0,"match":{"dataLayerDestination":"00:00:00:00:00:00","dataLayerSource":"00:00:00:00:00:00","dataLayerType":"0x0000","dataLayerVirtualLan":-1,"dataLayerVirtualLanPriorityCodePoint":0,"inputPort":3,"networkDestination":"0.0.0.0","networkDestinationMaskLen":0,"networkProtocol":0,"networkSource":"0.0.0.0","networkSourceMaskLen":0,"networkTypeOfService":0,"transportDestination":0,"transportSource":0,"wildcards":4194302},"command":0,"outPort":-1,"length":80,"type":"FLOW_MOD","version":1,"lengthU":80,"xid":0},"flow-=mod-1":{"actions":[{"port":4,"maxLength":32767,"length":8,"type":"OUTPUT","lengthU":8}],"priority":-32768,"bufferId":-1,"cookie":-66263411,"idleTimeout":0,"hardTimeout":0,"flags":0,"match":{"dataLayerDestination":"00:00:00:00:00:00","dataLayerSource":"00:00:00:00:00:00","dataLayerType":"0x0000","dataLayerVirtualLan":-1,"dataLayerVirtualLanPriorityCodePoint":0,"inputPort":3,"networkDestination":"0.0.0.0","networkDestinationMaskLen":0,"networkProtocol":0,"networkSource":"0.0.0.0","networkSourceMaskLen":0,"networkTypeOfService":0,"transportDestination":0,"transportSource":0,"wildcards":4194302},"command":0,"outPort":-1,"length":80,"type":"FLOW_MOD","version":1,"lengthU":80,"xid":0}}}floodlight@localhost:~$ 

This was my first foray into Open vSwitch, so I might be missing a trick or two here. It is easy enough to get set up, but without a suitably sized network to play with I kind of have to take "Entry pushed" at it's word. With a decent sized network to play with and a bit more time then things might have got a little bit more interesting. But this is meant to show that SDN is not either expensive, nor hard to start looking into.

We'll talk about onePK next.