Control Center

Divide and Conquer

Another example of an advanced packet forwarding and manipulation application with OpenFlow is network-internal load distribution across multiple servers. Traditional server load balancers are typically individual systems that reside upstream of a server landscape and distribute the load to the available applications as a function of the service. One major drawback with this approach is that the classic load balancer is a significant and unavoidable bottleneck on the network.

In an SDN, however, this bottleneck can easily be avoided. Thanks to the extensive control options for data flows, the entire SDN, that is, every single switch, router, and network path, can act as a load balancer and forward data streams directly to different servers along distributed paths. This technique avoids overloading any single network appliance. Instead, server load balancing becomes a network service.

Floodlight already provides a rudimentary version of this approach. The Floodlight Load Balancer application is a simple application for the distribution of UDP, TCP, or ICMP flows to different servers. No single network component handles the task of load balancing; the task is instead distributed through the entire network.

The Floodlight load balancer can be managed via a REST API, which is based on the OpenStack Quantum Load Balancer as-a-service API (LBaaS). This means that virtual IP addresses can be created for the load balancer and flows directed to these addresses automatically redirected to physical servers on the network. Once configured, the OpenFlow switches automatically handle a large part of the work.

Like many other Floodlight applications, the load balancer is currently still in development and thus far offers only basic functionality. For example, flow distribution is based on a round-robin method and does not take into account the server load or the actual data traffic. Nevertheless, it is already possible to implement a simple but powerful server load balancer with the existing components if you adapt the existing software to meet your own needs.

More Security

SDN and OpenFlow are also breaking new ground in the field of security by simplifying traditional approaches. The congruent installation of Access Control Lists (ACLs) on a large number of network switches is quite complex, and, even in professional systems, discrepancies arise between requirements, documentation, and the actual configuration. Therefore, a system that automatically sets ACLs on all network components is desirable.

Again, Floodlight offers an elegant and standardized solution: The Floodlight stateless firewall application is a reactive Floodlight module that centrally stores network-wide ACL configurations for all OpenFlow switches. The firewall rules (ALLOW or DENY) can be configured relatively conveniently for arbitrary OpenFlow matches and sorted by priority thanks to a REST API.

Each packet-in event generated by the first packet in a new flow is compared with the existing firewall ruleset until either the set is empty or a matching rule is found. If matching rules are found, the highest priority rule determines whether the packet is forwarded or the flow is blocked. If no rule is found, or the rule states that the flow is allowed, the packet-in event passes through the firewall and is processed and forwarded by subsequent Floodlight modules. However, if a rule that blocks the flow is found, the firewall installs an OpenFlow rule on the OpenFlow input switch to discard all further packets in the same flow.

The Floodlight firewall thus allows centrally configured network-wide ACL rules that are automatically enforced at all (or selected) switches. The following simple example illustrates the configuration options. The rules exclusively allow connections in the subnet 192.168.1.0/24 to TCP port 80.

TCP | 192.168.1.0/24 | 80 | ALLOW | 1 TCP | 192.168.1.0/24 | * | DENY | 2

Initial Steps

As a Java application, Floodlight runs on a Java VM and is therefore available on virtually all operating systems. Many popular Linux distributions, including Ubuntu, actually have a release in their repositories. Additionally, a preconfigured virtual machine image is available from the project website.

Because of the rapid development of Floodlight, you should install the latest version from GitHub or nightly builds, which have proved to be extremely stable in the past. Floodlight is easiest to install on Linux (e.g., Ubuntu). For this purpose, a Git client, Python, and Apache Ant must be in place in addition to a Java environment. To load Floodlight Linux from GitHub and compile, you can do the following:

$ git clone git://github.com/floodlight/floodlight.git
$ cd floodlight
$ git checkout stable
$ ant

Floodlight can be configured via Java properties files. The directory

./src/main/resources/floodlightdefault.properties

contains the default settings, such as port settings, and the application modules, which are loaded automatically.

Before initial tests, it makes sense to replace the simple net.floodlightcontroller.forwarding.Forwarding module with the higher performance net.floodlightcontroller.learningswitch.LearningSwitch module. You can then launch Floodlight by typing

$ java -jar target/floodlight.jar

Floodlight will now wait for connections from OpenFlow switches. If you do not have any OpenFlow-enabled hardware right now, you can simulate an OpenFlow network with the free MiniNet software. Again, installing from GitHub is recommended:

$ git clone git://github.com/mininet/mininet
$ mininet/util/install.sh -a

The procedure takes about five minutes and installs all MiniNet components, including the Open vSwitch OpenFlow software switch, a Wireshark dissector for analyzing OpenFlow messages with Wireshark, and POX. (POX is another OpenFlow controller written in Python.)

The following command will start MiniNet with a minimal topology that connects two hosts over an OpenFlow Switch and establishes a connection to an external Floodlight controller:

$ sudo mn --topo=minimal --controller=remote \
          --ip=<controller ip> --port=<openFlowPort 6633 by default>

MiniNet immediately connects with Floodlight, giving you a miniature SDN for testing purposes.

For further help or information about Floodlight, take a look at the project website [2]. The Floodlight project has a mailing list, and you will find a great developer community that is always willing to help.