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.jarYou 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-sourceNext you need to edit the below file and change the line "# BRCOMPAT=no" to read "BRCOMPAT=yes"
sudo vi /etc/default/openvswitch-switchIt'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 statusIf you get errors at this stage then check to make sure that the brcom modules is loaded:
lsmod | grep brcomIf you dont get anything back then install it:
sudo module-assistant auto-install openvswitch-datapathThen reboot and check it's loaded when they system boots up again:
sudo init 6 lsmod | grep brcom sudo service openvswitch-switch statusAt 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-intNow our switch shows up in our dashboard:
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.