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

Figure 1: The Zodiac WX access point.

Figure 2: The available connection options can be seen on the rear panel.

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.

Figure 3: The Zodiac WX is controlled from a web interface.

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.