Software-Defined Networking with Raspberry Pi, OpenFlow and Zodiac FX
Getting hands-on with real SDN hardware and software for minimal outlay.
In the post, we take a look at how you can gain experience with Software-Defined Networking (SDN) technology that is usually the reserve of high-end datacentre equipment, with only a modest outlay courtesy of Zodiac FX, Raspberry Pi and an open source OpenFlow controller.
What is SDN?
SDN Architecture Overview (source: Wikimedia/Open Networking Foundation)
In traditional networking solutions the control plane, which is responsible for deciding where packets must be forwarded, is tightly integrated with the forwarding plane, which does the actual forwarding. Integration is at the level of the network hardware and means complexity is distributed across the network, and in order to modify flows, you may have to configure many devices.
While equipment vendors do provide network management tools, these will offer different levels of flexibility, tend to assume a fairly static network configuration and there is limited interoperability. Furthermore, the control plane intelligence is still deeply embedded in equipment, with its capabilities and any bugs etc. varying across vendors, products and firmware versions.
What software-defined networking does is to split out the control and forwarding planes, allowing the former to be centralised and built using a common platform. There are now proprietary architectures that enable this, but SDN is most commonly associated with open standards, which in also facilitating interoperability and reducing vendor lock-in, present a far greater opportunity.
The OpenFlow protocol is developed by the Open Networking Foundation (ONF) and gives remote access to the control plane in switches and routers, which connect to a controller on TCP port 6653 — or with earlier versions, port 6633. The controller is then able to add, modify and remove packet matching rules and actions, which are executed on the network equipment at “wire speed”.
Image source: ONOS project.
There are also OpenFlow compatible software implementations of network functions, such as Lagopus, which is a software-based switch and router that can be run directly on Intel systems and on a virtual machine. While filling a server full of network interface cards might not make sense for an office switch, network function virtualisation (NFV) is a powerful solution when used together with server virtualisation, and will prove useful in many other highly dynamic environments.
A 48x 10GbE + 6x 40GbE SDN switch from FS.COM.
It may come as no surprise to learn that Facebook and Google, amongst numerous other heavyweights, are driving forces behind OpenFlow. Indeed, together with Deutsche Telekom, Microsoft, Verizon, and Yahoo! they founded ONF back in 2011.
In turn, it may come as little surprise to learn that equipment tends to be designed around the needs of such “Internet scale” organisations, with vendors offering, for example, switch chassis with 48x 10Gb Ethernet + 6x 40Gb Ethernet ports! Impressive, but clearly out of the reach of most experimenters and those wishing to get hands-on with SDN.
Zodiac FX is a 4-port 10/100M Ethernet switch that was driven by the need for a low-cost option for SDN experimentation and home use and was brought to life via a Kickstarter campaign. This combines a Microchip KSZ8795CLX Managed Ethernet Switch and a SAM4E8CA Processor, together with open source firmware, to create a compact and eminently hackable solution.
In addition to 4x Ethernet ports, Zodiac FX has a Micro USB connector for power and serial port access for the command line interface, a JTAG header for recovering from a bad firmware upload, and an SPI header for expansion.
Zodiac FX needs to have a “native” port configured for OpenFlow communications, which by default is port 4. The switch IP address, netmask and gateway were configured as appropriate.
Both the Zodiac FX port 4 and Pi Ethernet were connected to another switch so that they could be administered via a laptop connected to the existing network.
Switch ports 1-3 were configured as type OpenFlow and nothing will be passed between them until flows are configured. So now we have the hardware set up, next we need an OpenFlow controller.
There are plenty of open source OpenFlow controllers to choose from, such as OpenDayLight, which provides this functionality and much more, and is a collaborative project developed under the Linux Foundation, with founding contributors including HP, IBM, Intel and others.
However, for initial exploration, something like Ryu, an SDN framework that is written in Python, is a good choice and will be easier to get up and running.
Assuming Pi network interfaces have been configured and with the customary,
apt-get update followed by,
apt-get dist-upgrade we can then proceed to install the O/S dependencies with:
$ sudo apt-get install gcc python-dev libffi-dev libssl-dev libxml2-dev libxslt1-dev zlib1g-dev python-pip
With Python’s package manager installed we can now install Ryu:
$ sudo pip install ryu
So what we have now have is a software development framework and a set of examples. To run up a simple layer 2 learning switch configuration which uses OpenFlow v1.3, we simply type:
$ ryu-manager --verbose /usr/local/lib/python2.7/dist-packages/ryu/app/simple_switch_13.py
Following which the OpenFlow controller starts and we can power up the Zodiac FX.
If we go to the Flows section on the web interface we now see that a flow has been installed.
And if we connect a device to one of ports 1-3 we will see the controller reporting packet in events.
All we’ve done so far is to create an L2 learning switch, which clearly you could buy off-the-shelf. However, the intelligence is being provided by a Python application running on the Raspberry Pi and its behaviour can be very easily changed. For a detailed exploration of how the simple switch application works, see a post over on the Inside OpenFlow website.
With Zodiac FX currently supporting up to OpenFlow v1.3, this means that flows can be configured where actions are set at levels including, for example:
- Switch port
- Ethernet source/destination MAC, and VLAN priority
- MPLS label and other parameters
- IPv4 and IPv6 source/destination address
- UDP/TCP/SCTP source/destination port
As such it’s easy to see how applications could be created for firewalling, prioritising traffic and a great deal more. Not only this but applications that could be far more easily integrated with other tools and management systems — with, importantly, all the complexity centralised.
CommentsAdd a comment
Hello Andrew, there is any way to use openwrt in raspberry pi 3 to operate with openflow?