You are currently browsing articles tagged OpenFlow.


After seeing that Brent had already tackled this on Ubuntu I thought I’d give it a whirl on CentOS.  It took me awhile to figure out the install, but I finally got it running.  Trust me, the time it takes to install this is worth it.  This it pretty cool stuff (If you don’t know what stuff, I’m referring to, check out their web site

I wouldn’t have been able to get this installed without the walkthrough that Brent posted on his blog.  A large chunk of this is VERY similar to what he’s done with the exception of the OS he used.  THANKS BRENT!

Disclaimer: I’ll openly admit that I’m not a ‘Linux guy’.  I hack pieces together and often refer to the googles to help me out.  That being said, this tutorial is what I (the Linux non-expert) did to get this running.  I’m not saying that it’s the ‘right way’ to do it, but I can tell you that it does work. 

I’m going to assume that you have a fresh Linux host available that you can SSH into to start the build.  You’ll need internet access on the host to download the required OpenDaylight components.  That being said, let’s get started!

Note: I’m going to walk through the install process using screenshots.  Due to the sizing of the images, it may be hard to read some of the commands that I’m executing.  If you’re having issues, skip to the end where I include the build script I use.

The first thing you need to do is sign up for an account as part of the OpenDaylight project.  You’ll need this account in order to download a GIT clone of the code.  Browse to this URL…

And click on the picture in the middle of the screen to load the sign up page…

On the next page, fill in the required information and then click submit…


If all goes well, you should see the ‘Success’ message…


Now browse to this URL and sign in with your credentials…,n,z


Once signed in, click on the ‘Settings’ hyperlink in the upper left hand corner of the screen next to your name and email…


Under settings, navigate to the ‘HTTP Password’ menu.  Under that menu, you should see your username listed with a blank password.  Click the ‘Generate Password’ button to generate a new random password…


You’ll need this account information for the GIT download so just write it down and save it for now.  Now let’s get into the actual Linux install…

As I mentioned earlier, I’m assuming that you have a fresh CentOS installation that we are using.  I’m using a CentOS 6.4 64 bit version of Linux for this example.  So let’s start with disabling the services that cause the most trouble.  SE Linux and ipTables. 

Note: Like I said, I’m not an expert and the end goal here is just to get this running.  Keep your own security best practices in mind when you configure your own host.

Disable SE Linux and ipTables firewall
The first step is to disable SE Linux.  This is done by editing the file /etc/selinux/config and changing the variable ‘SELINUX’ from ‘enforcing’ to ‘disabled’…

To save your changes, press the escape key, and then type the letters ‘wq’ followed by the enter key.  This will save the changes you made (write quit). 

The next thing we want to do is to disable the IP firewall.  We’ll stop the ipTables service as well as tell the service not to run at boot…


We technically need to reboot the server for the SE Linux change to take effect, but we’ll save that for later. 

Install the pre reqs
Centos uses YUM for package download and installation.  There are a couple of packages that we need to install before we are able to download and install OpenDaylight. First we’ll download and install the individual components…


Once you hit enter, YUM will launch the install process and do all kinds of checks and validations for the packages you requested.  Once that is completed, you should get a prompt asking you to approve the actual download and install…


Enter yes (y) and press enter.  YUM will kick off the download and install.  Be patient, this will take some time…


Once completed, we want want to install a YUM ‘group’.  Specifically, we want to install the ‘Development Tools’ group.  A YUM group is just a group of packages together…


Run that command, let it do it’s processing, then approve the install with a yes…


Once that’s completed, let’s run a ‘yum upgrade’ to make sure that all our software if up to date…


Same deal.  Let it do the processing and then approve the installs…


Once that completes, we are done with YUM.  However, we do still need to manually install the Maven software.  To do this, we download the maven package with the ‘wget’ command, unzip it to it’s install location, and then create a symbolic link (shortcut) for it to be instantiated with. 


Once the files are unpacked, we create the symbolic link for the ‘mvn’ command…


At this point, we’ve installed all of the pre reqs for OpenDaylight.  Before proceeding further, I like to reboot the machine to make sure that I don’t see any issues.  Quick reboot and then we’ll tackle the software build.

Download the code from the GIT repository
In this next step, we’ll actually download the required code from the GIT repository.  To do this, we need to use the login we generated in the first step of this post.  First, make sure you change to whatever directory you want to install OpenDaylight into.  I’ll just use the root directory.  Then, run the following GIT command, enter your password (from the site that you recorded earlier) and wait for the download to complete…


Use Maven to install the code
Now that the download is complete, we can use Maven to build the code.  To do so, navigate the specified directory, and then run the ‘mvn clean install’ command…


This will take awhile.  Probably right around 10 minutes to complete.  When it’s done, you’ll get some final output that should look like this…


Note: If the build errors out and doesn’t complete, make sure the system has enough memory. Brent recommended 1.5 gig in his post and I was having issues getting it to build with 2 gig in a VM.  I cranked it up to 4 and it worked just fine. 

At this point, the controller is ready to run.  However, there is one last setting we have to configure…

Configure the Java variables
OpenDaylight uses some system wide variables as part of it’s run script.  These are considered environmental variables and are what the system uses to find the path to specific files.  The environmental variable we are concerned with is called ‘JAVA_HOME’. Let’s check to see if it’s defined, and then define it ourselves…


As you can see, at first the system doesn’t know the variable. Then we use the ‘export’ command to define it. After defining it, the system now knows where it is. To make sure that it persists through reboots, we should also define it in the /etc/environment file…


Once the file opens for editing, hit the ‘i’ (insert) key and then type this line in…


Once again, hit escape, then type ‘wq’ followed by enter to save the file and exit. 

Fire up the controller
At this point, we are set to fire up the controller.  To do that, browse to the following directory and execute the run script…


You should see the application load, and at this point, you should be able to browse to the web app through the URL http://<Server’s IP address>:8080…


The default login is admin/admin…


We’ll leave it there for now.  I just wanted to get the controller up and running in this post.  Here’s the actual build script I used for the full install…

#Disable SE Linux
Edit the /etc/selinux/config file and restart the server

#Disable the firewall
service iptables stop
chkconfig iptables off

#Install Pre Reqs
yum install  wget vim java ant python eclipse-platform git
yum groupinstall “Development tools”
yum upgrade

#Install Maven
unzip -d /usr/share/
ln -s /usr/share/apache-maven-3.0.5/bin/mvn /usr/bin/mvn

#Get GIT code
cd /
git clone

#Build with maven
cd controller/opendaylight/distribution/opendaylight/ 
mvn clean install

#Configure Java Env variables
export JAVA_HOME=/usr/lib/jvm/java-1.6.0-openjdk.x86_64
edit /etc/environment and add…

#Load the controller
cd /controller/opendaylight/distribution/opendaylight/target/distribution.opendaylight-0.1.0-SNAPSHOT-osgipackage/opendaylight

Or if you prefer to see the build script in text file format (no word wrap) just send me a quick email and I’ll send it your way.  In the next post, we’ll talk about connecting the controller to a Brocade MLX switch.  The fun begins!!

Tags: ,

Defining OpenFlow

I want to draw the line in the sand right off the bat and tell you that OpenFlow != SDN.  OpenFlow is an open API that allows some intelligent device (an OpenFlow controller) to program the data plane of an OpenFlow enabled device.  That’s it.   SDN on the other hand, at least to me, stands for something entirely different.  SDN means a revolution in how we manage networks as a whole.  A Software Defined Network would provide programmatic interfaces to the networking infrastructure that would allow for a very high degree of automation and management.  In addition these software defined networks would be more easily aligned with other infrastructure.  From a provisioning perspective, this is a natural progression in the network joining other silos (think storage and compute) to become what I like to call ‘common infrastructure’.  In the end, we want one platform that can manage all of the common infrastructure. 

Arguably, this is going to require many building blocks to accomplish.  For instance, let’s take a brief look at OpenStack so I can clarify the difference.  OpenStack is being advertised as a CMS or Cloud Management System.  CMS systems are designed largely to deliver on the promise of IaaS (Infrastructure As A Service).  That being said, to truly deliver IaaS, you’d need to manage all of the pieces of the ‘common infrastructure’ as one logical unit.  This being said, OpenStack provides different components for each application.  The Nova component handles compute, the Swift component handles storage, and the Quantum component to handle the network.  The natural progression of thought here might lead you to believe that Quantum would use OpenFlow to program the network layer.  This assumption would be wrong and the OpenStack example provides an excellent example of the difference between SDN and OpenFlow.  For instance…


While admittedly, this is a VERY basic model I think it makes my point rather clear (also, keep in mind there are other pieces of OpenStack that I’m not showing like the Glance component).  The Quantum component of OpenStack itself leans on what is referred to as a OpenFlow plug-in to talk directly to a OpenFlow controller.  This communication is NOT OpenFlow.  In other words, the OpenFlow plug-in provides an API to an existing OpenFlow controller.  The OpenFlow controller is what talks OpenFlow (depicted with red lines) to any capable OpenFlow switch.  This could be a physical device which I would still consider to be part of the Quantum stack or a Open vSwitch that lives on the compute hardware.  This solidifies my initial statement, OpenFlow is not SDN.  Rather, OpenFlow is a building block of a SDN solution that facilitates the programming of a switching devices data plane.  So without going to much further off course, let’s dive into what OpenFlow is…

A common definition of OpenFlow found on the internet will read something like this…  “OpenFlow separates a switches control and data plane”.

But let’s be clear about that definition.  OpenFlow does not imply that the device’s control plane is now non-existent.  Rather, it means that the source of information which the control plane uses to program the forwarding plane has changed, or been added to.  Traditional (non-OpenFlow) switches rely on control plane processes (BGP, OSPF, etc) to build the switches IP routing table.  From the routing table, the control plane then builds the forwarding table.  The forwarding table is then sent to the data plane so it knows how to forward the frames and packets it is processing. 

In the case of a OpenFlow, the switch get’s it’s information from an external source commonly referred to as an OpenFlow controller.  This device sends flow information to the OpenFlow switch and populates what is referred to as a flow table.  Much like the IP routing routing table on traditional switches, the flow table on OpenFlow switches is then used by the devices control plane to program the forwarding table.  This being said, the data plane doesn’t really change between a standard switch and an OpenFlow switch.  Regardless of where the data comes from (local control plane or OpenFlow controller) the switch still needs to build and maintain a forwarding plane to be able to forward packets and frames. 

This being said a more accurate definition might read “An OpenFlow switch uses a remote source (OpenFlow Controller) to build it’s local FIB”.  More wordy, but also more accurate. 

To understand OpenFlow, we need to understand it’s goal in regards to forwarding.  OpenFlow builds a new data structure on a router called a flow table.  These flow tables can either be proactively or reactively programmed.  That is, they can be pre-populated by a controller or packets can be sent to the controller in order for a forwarding decision to be made reactively.  Both scenarios have their own merits in certain situations but we won’t dwell on that too much in this post.   Just know that the flow table exists and it’s programmed in one of those two fashions for now.

Note: In this post we are focusing on OpenFlow v1.0 since the hardware I’m using currently supports only that version.

Version 1.0 of OpenFlow supports what’s called 12 tuple matching.  A tuple is a fancy computer science term which can really be boiled down to “an ordered list of 12 items”.  The 12 items that the 1.0 spec can match on are…

Ingress Port
Ethernet Source (Layer 2 source)
Ethernet Destination (Layer 2 Destination)
Ether Type
VLAN Priority
IP Source
IP Destination
IP Protocol
TCP/UDP Source Port
TCP/UDP Destination Port

These 12 items, can be separated into layer 2 specific criteria (blue) and layer 3 specific criteria (green).  I make the distinction here since the particular gear I’m testing on requires that an OpenFlow enabled port either be configured in either layer 2 or layer 3 mode.  That is, it currently only supports matching on one or the other.  This doesn’t truly meet the OpenFlow spec, but it’s a start and I understand the next gen of code (coming this month I believe) will support full 12 tuple matching.  Knowing the limitations that I have, let’s look at an example flow table entry for a layer2 port…


Here you can see a flow entry that’s using the layer 2 information I outline above.  This rule would read like this…

“If a frame enters port 1/4 with no dot1q header, a source MAC of 0024.38a8.a603, and a destination MAC of 0024.38a7.5d01, forward it out port 1/2.”

Pretty simple isn’t it?  As you can imagine, these flow rules can get pretty specific, or be rather generic.  Much like routes to prefixes, the more specific matches will be used first.  

We’ll take a look at some more complex examples in my next set of posts where I cover configuring the Brocade MLX for OpenFlow.  For now, I just wanted to plant the seed as to what OpenFlow is.

Tags: ,

Here’s a copy of the presentation that Kyle and Steve gave at the OpenStack meetup at the end of March.  Great presentation with lots of good info for people new to both concepts. 

Tags: ,