Example 3 - Programming Networks with OpenFlow

Note: This example references many topics which were discussed in example 1 and example 2, which act as sufficient prerequisites.

The full “what and why” of OpenFlow is discussed in the core documentation, but the reason you would want to use OpenFlow is to program how exactly your network behaves. For example, maybe you want to write a custom protocol and segment traffic in your network. Maybe you simply want to play around with a programmable switch.

OpenFlow is the leading architecture of Software Defined Networking (SDN), which is shaping up to be the future of deeply programmable networks.

In this experiment, we’re going to get a software OpenFlow switch up and running on a single machine on GENI. Our node will act as an OpenFlow switch and it will be networked with two additional machines. We’re going to send ping packets through our switch from one node to another, and then program the switch to drop any packets headed from one node to another.

Our virtual topology will look like this:

../_images/ex3-topology.png

The node on the left will be the node we send packets to, and the node on the right will be the receiver of the packets. The node in the middle will be our software switch.

Tutorial

Step 1 - Set Up Our Network

Open up Flack as we did in the previous example, and create a new slice, giving it a unique name:

../_images/ex3-new-slice.png

When you’ve submitted the new slice request, and the slice is created, click into it so you have a blank pane in front of you:

../_images/ex3-blank-pane.png

Drag three PC nodes from utahemulab.cm on the pane:

Before:

../_images/ex3-topo-before.png

After:

../_images/ex3-topo-after.png

Important: The node in the middle will be our network switch.

The next thing we’ll want to do is network our three machines together. For this, we’ll drag two LAN components onto the pane. We want to have two distinct networks, so we’ll network the switch and the node on the left first, and secondly, the node on the right and the switch.

Firstly:

../_images/ex3-network-step-1.png

Secondly:

../_images/ex3-network-step-2.png

Now we’re ready to configure out individual boxes.

Step 2 - Specify Ubuntu As the Operating System and Submit

Let’s configure all three nodes so that they have Ubuntu installed. For the node on the left, click on the information icon:

../_images/ex3-os-setup-i.png

In the pane that appears, head to the “Disk Image” field, and find the option for “Ubuntu 12.04 LTS with KVM installed”. Select that:

../_images/ex3-os-setup-select.png

Click “Apply” at the bottom, and do the same for the other two nodes in our network. When you’re done, each node should be marked as having the Ubuntu OS configured:

../_images/ex3-os-setup-final.png

We’ve got our network set up! We’re ready to submit our request to provision these nodes. Click “Submit” on the bottom of the screen. If you hit any errors while provisioning, you can submit again.

Step 3 - Install Open vSwitch

The node in the middle is going to be our switch. A this point, that node should have an address next to it, such as pcXXX.emulab.net, possibly with a port number. SSH into that back in a new terminal. In the example above, we’ll do:

$ ssh pc209.emulab.net
$ sudo bash

We executed sudo bash since we’re going to be doing a lot of heavy lifting that requires root. Now we need to install Open vSwitch. This is actually very easy, and only requires that we install a few packages with the apt package manager and do some housework. First, run these commands and confirm ‘Yes’ any prompts.:

$ apt-get update
$ apt-get install openvswitch-datapath-source bridge-utils
$ module-assistant auto-install openvswitch-datapath
$ apt-get install openvswitch-brcompat openvswitch-common
$ apt-get install curl traceroute

Now, we’ll do a little editing. Execute:

$ nano /etc/default/openvswitch-switch

And change the line that says:

# BRCOMPAT=no

To:

# BRCOMPAT=yes

And finally, restart Open vSwitch:

$ /etc/init.d/openvswitch-switch restart

Step 4 - Configure Open vSwitch to Use our Ethernet Interfaces

This next step truly depends on the box that you’re working on. You need to know which interfaces you’re going to be working with for the next steps. To do that, run:

$ ifconfig

In the output, you’ll see a few different interfaces. The ones you need are prefixed by ‘eth’, and end with anything between 1 and 5. In the example, below, the two interfaces relevant to us are eth2 and eth4. Take note of your interfaces, and apply them to the instructions below, along with the appropriate IP addresses.

../_images/ex3-interfaces.png

So we have interfaces eth2 and eth4. We want to configure Open vSwitch to use those interfaces as if they were the interfaces of a switch. We do this by setting up a virtual bridge interface. Type, or copy and paste these lines into your terminal:

ovs-vsctl add-br br-int
ovs-vsctl add-port br-int eth2
ifconfig eth2 0
ifconfig br-int 10.10.1.2 netmask 255.255.255.0
route add -net 10.10.1.0 netmask 255.255.255.0 dev br-int

ovs-vsctl add-br br-int2
ovs-vsctl add-port br-int2 eth4
ifconfig eth4 0
ifconfig br-int2 10.10.2.1 netmask 255.255.255.0
route add -net 10.10.2.0 netmask 255.255.255.0 dev br-int2

At this point, running another:

$ ifconfig

Should show your new bridge interfaces:

../_images/ex3-interfaces-final.png

Your switch is ready to go! Now you just need an OpenFlow controller.

Step 5 - Set Up Floodlight, an OpenFlow Controller

Your OpenFlow switch is controlled by an OpenFlow controller. An OpenFlow Controller is just a software package that interfaces with the switch via the OpenFlow API, and pushes routing rules.

In a situation where you had a hardware-based openflow switch, the controller would reside on a separate host. We’re using a software based switch in the example, and for convenience, we’re going to install the controller on the same box as our software switch.

Again, we’ll install a package and run a series of commands:

$ apt-get install build-essential default-jdk ant python-dev uml-utilities git
$ git clone git://github.com/floodlight/floodlight.git
$ cd floodlight
$ make
$ java -jar target/floodlight.jar

We’ve just started our Floodlight controller. This controller will act as our interface to the switch. Since we just started the controller, we’ll see log messages appearing on the screen:

../_images/ex3-floodlight-log.png

Step 6 - Test Our Switch

Because Floodlight is running in our terminal, we’re going to open up another terminal window and ssh into our switch so we can keep working. We’ll also tell the switch to listen to the Floodlight controller while we’re at it:

$ ssh pc209.emulab.net
$ sudo bash
$ ovs-vsctl set-controller br-int tcp:127.0.0.1:6633

Additionally, we’re going to open up a connection to the machine in our topology labeled PC. Your address will be different. Check your topology pane for the correct address:

$ ssh pc536.emulab.net
$ sudo bash

Now let’s install a package of utilities we can use to test switch connectivity:

$ apt-get install uml-utilities traceroute

Next, From PC, let’s ping PC-0 to make the boxes on both ends of the switch can talk to each other:

$ ping pc-1

This should yield something similar too:

../_images/ex3-switch-connectivity-before.png

Great! Right now let’s test the route our packets are taking from PC to PC-0. We want to make sure our packets are flowing through the switch we set up. We can double-check by running:

$ route -n

Which would yield:

../_images/ex3-route-n.png

In the output above, you can see that our route from PC to PC-1 is indeed through the switch we set up. If you would like, you can also test with traceroute, in the manner of:

$ traceroute pc-1

Step 7 - See Floodlight’s Web Interface

Floodlight has a simple web interface built in. It allows you to see which nodes are connected to the switch, and which rules are currently active. Access it by opening a browser window to:

http://pcXXX.emulab.net:8080/ui/index.html

Of course, replace your switch’s hostname with the one above.

Additionally, take note of the DPID of the switch that you created:

.. image:: ../assets/images/ex3-floodlight-ui.png

Step 8 - Put Some Routing Rules!

Now for the programmable networks part of our openflow experiment. Let’s get back in the terminal window that is connected to our switch. We’ll now add a rule to our switch through Floodlight that will drop any packets coming from PC (10.10.2.2). Be sure to adjust your IPs below if they don’t match up. Also, replace [DPID] with the DPID you found above:

$ curl -d '{"switch": "[DPID]", "name":"drop-flow", "src-ip": "10.10.2.2", "dst-ip":"10.10.1.1","active":"true"}' http://127.0.0.1:8080/wm/staticflowentrypusher/json

Let’s make sure that rule was pushed correctly, by issuing:

$ curl http://127.0.0.1:8080/wm/staticflowentrypusher/list/[DPID]/json | json_pp -t dumper

And you’ll see something similar to:

../_images/ex3-floodlight-rules.png

Step 9 - Retest That Switch

Go back to step 6 where we were on PC, and try to ping PC-1. How did that work? Did it fail?

Congratulations! You programmed your first switch with a simple JSON packet. If you want to remove the rule and try once more, you’ll find that your packets are free to flow again:

$ curl -X DELETE -d '{"name":"drop-flow"}' http://127.0.0.1:8080/wm/staticflowentrypusher/json

Step 10 - Think About The Applications

For the purposes of this example, we manually pushed all the required JSON rules to demonstrate the programmability of the switch.

But imagine that instead of pushing the rules manually, you wrote a web application to push those rules instead. Since the switch is now controllable with something like JSON, you can truly define the behavior of your network with software. That’s the essence of software-defined networking!

Additional Resources

This tutorial was adapted from this blog post for GENI: http://networkstatic.net/2012/06/openflow-openvswitch-lab/

For more on the Floodlight REST API, and what methods are available: http://www.openflowhub.org/display/floodlightcontroller/REST+API