OpenFlow-capable Zodiac WX access point
Controlled Landing
Zodiac FX is an affordable software-defined network (SDN)-enabled hardware switch [1] that was launched by Northbound Networks of Australia in a Kickstarter campaign. The company invited me to join a beta test for a new product: Zodiac WX [2], a wireless-enabled access point.
A special feature of the Zodiac WX is support for the OpenFlow protocol [3]. OpenFlow-based networks usually exist purely in software and use a protocol like Open vSwitch [4], for example, which lets you to control traffic between mobile clients and a fixed network much more flexibly than traditional routing and firewall rules allow.
Basics
The recently released access point is a stable device (Figures 1 and 2) that can be operated either with Power over Ethernet (PoE) or a power supply unit. The operating system runs on Zodiac LEDE, a temporary fork of the OpenWrt project – temporary because the two projects, LEDE and OpenWrt, have reunited under the name OpenWrt [5].
The CPU of the Zodiac WX is a MIPS 74Kc. The system has 128MB of RAM and two connections for Gigabit Ethernet, one of which can also be used for the power supply. The wireless interface supports the fast 802.11ac standard (and the slower variants b, g, and n) at 2.4GHz and 5GHz, respectively. The device is managed from a web interface (Figure 3), SSH, or a REST API.
You need to enable SSH access in the web interface; afterward, you can gain access using the admin account. For privileged accesses, such as the nnofagent command for listing installed flows and groups (see below), the admin user needs to be added to the sudoers file; sudo -s also works for the full-fledged root shell.
API at the Wheel
One important performance metric for OpenFlow devices is the number of flows, tables, and groups that a device can manage. The Zodiac WX supports a total of eight groups, 16 tables, and 512 flow entries.
The REST API is especially important in the SDN context, because an SDN controller controls the flow rules. It would be a slow process if the administrator had to configure the network manually – especially if several access points are used. Instead, the SDN controller can use an existing API to customize anything that OpenFlow does not cover.
Incidentally, if the admin does not enable the SDN controller, the device works like a normal access point.
Go with the Flow
The OpenFlow protocol lets you manage traffic flows according to rules. Simply put, these rules comprise a block of filters followed by a set of actions that determine what should happen to a packet. The actions can also be used to rewrite fields in the package, for example.
Filters and actions cover ISO Layers 1 to 4 (i.e., the fields of the Ethernet layer up to the TCP, UDP, and SCTP ports). In the OpenFlow filter, the input port of the packet and, in the action, its output port represent Layer 1.
With physical switches, it is usually obvious how they fit together, even if the OpenFlow numbering does not necessarily match the device's port numbers. Ports in this case are the slots where the network cables are plugged in. Of course, such ports are missing from wireless clients, so even when setting the target for a packet, one OpenFlow element is missing.
The WX solves this problem by assigning the wired port to OpenFlow port 65, 5GHz clients to OpenFlow ports 1-32, and 2.4GHz clients to OpenFlow ports 33-64. The SDN controller does this using the packets' MAC addresses.
Unintentionally Dynamic
The port problem of wireless clients adds an involuntary dynamic to OpenFlow application development. Generating a dynamic flow that sends packets to port 5 and the connected wireless client can cause complications: If a wireless client then switches to power-saving mode, it might reappear as the sixth client when it logs back in and be connected to WX port 6 in the OpenFlow logic. Developers for the WX have to pay special attention to this possibility.
The administrator of the Zodiac WX cannot manage the flow rules locally but relies on an OpenFlow controller. In the test, I used Floodlight [6] and OpenDaylight [7]. In its early versions, the WX did not work with OpenDaylight, but Northbound fixed that.
The SDN controller configuration is managed in the web interface under Control | Settings (Figure 4). The Auth Bypass setting ensures that the access point excludes packets that are only used to log on wirelessly (they form their own EtherType) from further flow processing. Alternatively, you need to set up a flow manually that passes these packages through.
Do It Yourself
As usual with OpenFlow-controlled devices, the admin of the device is also its programmer and has to take care of everything personally. To operate a wireless client with activated Auth Bypass, you need to set up flows for ARP and DHCP. The OpenDaylight version of the flow description is shown in Listing 1.
Listing 1: Flow Definitions for Wireless Clients
001 [
002 {
003 "flow" : [
004 {
005 "instructions" : {
006 "instruction" : [
007 {
008 "apply-actions" : {
009 "action" : [
010 {
011 "output-action" : {
012 "output-node-connector" : "FLOOD"
013 },
014 "order" : 0
015 }
016 ]
017 },
018 "order" : 0
019 }
020 ]
021 },
022 "priority" : "5",
023 "match" : {
024 "ethernet-match" : {
025 "ethernet-type" : {
026 "type" : "0x806"
027 }
028 }
029 },
030 "table_id" : 0,
031 "id" : "f1"
032 }
033 ]
034 },
035 {
036 "flow" : [
037 {
038 "match" : {
039 "ip-match" : {
040 "ip-protocol" : "17"
041 },
042 "ethernet-match" : {
043 "ethernet-type" : {
044 "type" : "0x800"
045 }
046 },
047 "udp-destination-port" : "67"
048 },
049 "table_id" : 0,
050 "id" : "DHCP1",
051 "instructions" : {
052 "instruction" : [
053 {
054 "order" : 0,
055 "apply-actions" : {
056 "action" : [
057 {
058 "order" : 0,
059 "output-action" : {
060 "output-node-connector" : "FLOOD"
061 }
062 }
063 ]
064 }
065 }
066 ]
067 },
068 "priority" : "10"
069 }
070 ]
071 },
072 {
073 "flow" : [
074 {
075 "match" : {
076 "ip-match" : {
077 "ip-protocol" : "17"
078 },
079 "ethernet-match" : {
080 "ethernet-type" : {
081 "type" : "0x800"
082 }
083 },
084 "in-port" : "65",
085 "udp-destination-port" : "68"
086 },
087 "table_id" : 0,
088 "id" : "DHCP2",
089 "priority" : "10",
090 "instructions" : {
091 "instruction" : [
092 {
093 "order" : 0,
094 "apply-actions" : {
095 "action" : [
096 {
097 "order" : 0,
098 "output-action" : {
099 "output-node-connector" : "NORMAL"
100 }
101 }
102 ]
103 }
104 }
105 ]
106 }
107 }
108 ]
109 }
110 ]
The output port used here is FLOOD, the OpenFlow counterpart to a broadcast. Once the controller has learned which client belongs to which port, it can cause higher priority flows to output the ARP or DHCP packets for a particular client only on its port.
The Zodiac WX is a hybrid OpenFlow switch, which means it supports the NORMAL output action. This follows the saying: Send the package where it belongs according to the forwarding table. For switches, this would be the destination MAC address and applies here.
Because the wireless clients do not use physical ports, another special feature appears that is not seen with other OpenFlow devices: The MAC destination address and the port must match or be made to match.
The assignment follows the order when logging in, as described above. OpenFlow assigns port 1 to the 5GHz client that is logged on first. It also remembers the MAC address of the client. This means that the OpenFlow action output:1 must overwrite the target MAC address for the packet to arrive on the appropriate radio channel.
The already mentioned nnofagent program lists the flows installed by the controller with the -f option and corresponds to the output in the web interface. The access point also supports the OpenFlow Group and Meter properties, with the first action summarizing and the second contributing to throughput control. To list these parameters, use -g (for groups) and -m (for meters).
REST API
The configuration of each network device also includes the configuration of IP addresses and, if applicable, virtual LANs (VLANs), which, however, are not supported by the OpenFlow protocol. Instead, the latest firmware release (1.10 at the time of the test) provides a REST API that allows you to perform these basic configurations.
Therefore, you can develop an SDN controller with the appropriate driver to control the entire configuration of the device, which means that an application on this controller can span entire networks and not just control traffic flows.
Conclusions
The Zodiac WX device is well suited for developing SDN applications on physical hardware. Compared with the Zodiac FX, which only had three active ports, the ability of the WX to connect up to 64 clients is very attractive for network admins.
However, because of the conceptual differences in the hardware, newcomers to SDN development have to pay attention to a few limitations mentioned in the text. Compared with the four- to five-figure cost for larger SDN switches, though, the WX offers a very good price-performance ratio at around $180 dollars.
Additionally, the wireless connection allows the coupling of Internet of Things devices, which often lack an Ethernet connection. Compared with a "normal" OpenWrt access point with the full functionality of a Linux kernel behind it, OpenFlow packages can be manipulated and filtered to a higher degree. The latest version of Zodiac wx, which appeared after this article was written, provides additional integration with Open vSwitch.