How To Set Up Floodlight and Test OpenFlow Rules

Posted by Brent Salisbury
April 09, 2013

You 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.

Related Reading