How To Set Up Floodlight and Test OpenFlow Rules

The following tutorial demonstrates how to set up the Floodlight open source controller for controlling an OpenFlow-enabled switch. Once installed and running, I use the RESTful API to send an OpenFlow flow modification (flowmod) to instantiate a flow rule.

Using the "OpenFlow normal" rule as the default action allows for integration of OpenFlow/SDN islands to be connected into the native network. This provides a blank slate for network engineers to install custom flow rules to forward, rewrite or drop traffic.

There are many potential uses. For instance, firewalling policies could be implemented to drop any L2-L4 traffic to specific ports, MAC addresses or IP addresses. Rules can be installed for forwarding flows to multiple ports for selective traffic monitoring. As new users plug into the network, their packets could be redirected to a server for authentication, which could then add a security policy based on identity. Traffic can be forwarded down particular links based on price of bandwidth, time of day, controller-to-switch latency, or any other constraint.

A key concept of this tutorial is how to take an OpenFlow switch and instantiate a "table miss" flow policy. Flow tables are required to support table miss functionality. A table miss is when a packet does not match an entry in a flow table. The table miss fields in the following flow rule have wildcards that will match any value. A "table miss" looks like any other rule, but is intended to catch all traffic that is not matched in the flow lookup by wildcarding all of the fields.

The table miss action in this tutorial matches all ingress packets with the lowest priority and sends that matched traffic to the normal forwarding L2/L3 pipeline.

This example uses the Java-based Floodlight open source controller from Big Switch on a virtual machine running Ubuntu Linux. Floodlight can just as easily be ported to other Linux flavors or to Windows or Mac, because the Java Virtual Machine is platform-agnostic.

The instructions assumes you have an OpenFlow switching element pointing at the Floodlight controller's IP address on port 6633. By default, Floodlight instructs the switch to be a normal L2/L3 learning switch. That is disabled in step #5, which instructs the switch to forward proactively, using only pre-installed rules. Removing the "Forwarding" module prevents any packet-in latency from switch to controller for reactive instruction requests.

[ Join us at Interop Las Vegas for access to 125+ IT sessions and 300+ exhibiting companies. Register today! ]

The example table-miss policy uses the normal forwarding pipeline, rather than having unmatched traffic sent to the controller to request forwarding instructions. If you are brand new to FloodLight, running it as a L2 learning switch is a good place to start. The only difference is to not remove the forwarding module from loading in step 5.

For Ubuntu Linux Builds, install the following pre-requisites:

1. 'sudo apt-get install build-essential ant python-dev eclipse default-jdk git curl'

2. 'git clone git://github.com/floodlight/floodlight.git'

3. cd floodlight

4. Next edit the file src/main/resources/floodlightdefault.properties

5. Remove the line "net.floodlightcontroller.forwarding.Forwarding, \". This tells FloodLight to only perform proactive forwarding meaning the switch will only send packets to the controller if there is an explicit match + action instructing it to do so. All unmatched packets in a table-miss will be dropped.

6. Run ant to build a jar. It will be in the ~/floodlight/target directory.

7. 'ant'

8. java -jar target/floodlight.jar

By default, Floodlight will bind to port 6633 and start as a learning switch. Attach your OpenFlow switches (hardware or software) at the controller.

Next page: Adding Match-Plus-Actions