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.

OpenFlow Table Miss

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-ActionsYou can point your browser at http://127.0.0.1:8080/ui/index.html to view real-time information from the controller. This can also be used to determine the Data Path ID (DPID) value of your switch for REST API calls. The DPID is the unique identifier for the bridge in the forwarding element. Multiple DPIDs can exist in a forwarding element.

Finally, add the "match plus action" instructions, which should be installed in the flow table on the switch. This will match all fields for incoming packets ("actions":") and send them to the normal forwarding pipeline ("actions":"output=normal"). Install the rule using the northbound REST API using cURL from the same Linux machine running the controller to the IP 127.0.0.1 (localhost).

Replace the DPID (00:01:00:9c:02:b1:ff:c0") with the ID from your OpenFlow switch. This REST API call will instantiate a flow matching all fields and have an associated action of "normal" for anything matching the rule in the flow table within the switch. It is being set with a priority of 0, meaning any packet that matches a field with a priority greater than zero will take precedence over the rule being added.

curl -d '{"switch": "00:01:00:9c:02:b1:ff:c0", "name":"normal-drain", "cookie":"0", "priority":"0", "active":"true", "actions":"output=normal"}' http://127.0.0.1:8080/wm/staticflowentrypusher/json

Now you can add more flow rules as shown in the flow table diagram. If a packet does not match on the more specific rules, the catch-all table miss rule will provide the default action.

In this case, the table miss is normal L2/L3 forwarding. More specific (fine/micro) rules can instruct and re-write flows by hand or custom homegrown applications or emerging vendor applications. Just as importantly, the network has the ability to function normally while you test whether OpenFlow will fit in your environment.

To delete all flow rules on the switch, you can send the following API call. Remember to replace the DPID value with your switches value:

curl http://127.0.0.1:8080/wm/staticflowentrypusher/clear/00:01:00:9c:02:b1:ff:c0/json

Flow entries in the switch flow tables will remain there until a controller removes them, or the switch reboots. This means the controller can fail or lose the network connection between the controller and switch (control channel) and still continue to function, because all rules have been proactively installed.

For more details on the static flow pusher module and usage, check out the Floodlight Wiki.

If you do not have access to OpenFlow enabled hardware, there are open source projects such as Open vSwitch and Mininet that can be used for both learning OpenFlow and developing for it.

A screencast of this tutorial, with commentary, can be found here.

Final Thoughts

There are some other key components to keep in mind with early OpenFlow deployments. The spanning-tree protocol is a consideration with regard to blocking links to avoid bridging loops. This is because OpenFlow "normal" uses Ethernet flooding and learning found in current generation networks. Flow table capacity and performance is limited with current hardware. Silicon foundries will continue to add innovative capabilities to solve current constraints.

The more abundant L2 CAM is beginning to be used for L2 binary lookup processing for more efficient use of existing silicon by network hardware. Flow policies using limited fine (micro) flow matching for specific traffic for SDN applications and Coarse (macro) flows matching the majority of traffic, will fit into today's hardware.

Brent Salisbury, CCIE#11972, is a network architect at a state university, and also served in the U.S. Marine Corps. Follow him on Twitter at @networkstatic and read his blog at www.networkstatic.net.