What is a Software Defined Network?

Software Defined Network (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 the information in the routing table, it uses the FIB and LFIB, as well as managing things like QoS, filtering and the encapsulation of packets.

Enter the Software Defined Network

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 to make the network more programmable. Cisco has their toolkit called onePK.

The basic concept of SDN is shown below:

Software Defined Network overview

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:

Floodlight for SDN main interface

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

The software defined network needs to be able to do some networking. 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 don’t 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 netmask 
route add net netmask br-int

Now our switch shows up on our dashboard:

Floodlight controlling OpenFlow switch for SDN

We also have a nice Topology to look at:

Floodlight topology map

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

Getting DPID from Floodlight

We can see lots of hosts on the network now:

Floodlight and OpenFlow for SDN, host table

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"}'
{"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

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 its 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 the world of the Software Defined Network is not either expensive nor hard to start looking into.

We’ll talk about onePK next.