© Sergey Kuznetsov, 123RF

Open-Flow-basierte Netzwerke existieren meist rein in Software und nutzen zum Beispiel Open Vswitch. Nun landet mit dem Zodiac WX ein kostengünstiger, WLAN-fähiger Accesspoint der australischen Firma Northbound Networks auf dem Netzwerk-Markt, der SDN mit Open Flow unterstützt.

Bereits 2016 stellte das Linux-Magazin die erschwingliche Hardware Zodiac FX vor, einen SDN-fähigen Switch [1], der im Zuge einer Kickstarter-Kampagne das Licht der Welt erblickte. Später lud Northbound Networks den Autor zu einem Betatest für ein neues Produkt ein: Zodiac WX [2], einen WLAN-fähigen Accesspoint.

Dessen Besonderheit ist der Support für das Open-Flow-Protokoll [3]. Damit regelt ein Admin den Verkehr zwischen den mobilen Clients und dem Festnetz wesentlich flexibler, als es klassisches Routing und Firewallregeln erlauben.

Die Basics

Der jüngst veröffentlichte Accesspoint kommt als stabiles Gerät im Ufo-Design (Abbildungen 1 und 2) daher und lässt sich wahlweise über Power over Ethernet (PoE) oder ein Netzteil betreiben. Als Betriebssystem läuft auf dem Zodiac Lede, ein temporärer Fork des Open-WRT-Projekts. Temporär, weil sich die beiden Projekte Lede und Open WRT inzwischen wieder unter dem Namen Open WRT vereint haben [4].

Abbildung 1: Der Accesspoint Zodiac WX ähnelt in seinem Äußeren einem Ufo.

Abbildung 2: Auf der Rückseite sind die verfügbaren Anschlussmöglichkeiten zu sehen.

Als CPU des Zodiac WX kommt eine Mips 74Kc zum Einsatz. Das System verfügt über 128 MByte Arbeitsspeicher. Zugleich bringt es zwei Anschlüsse für Gigabit-Ethernet mit, von denen sich einer auch zur Stromversorgung verwenden lässt. Die WLAN-Schnittstelle folgt dem schnellen 802.11ac-Standard (und den langsameren Varianten b, g und n) mit 2,4 beziehungsweise 5 GHz.

Die Administration des Geräts erledigt der Admin über eine Weboberfläche (Abbildung 3), SSH oder ein REST-API.

Abbildung 3: Unter anderem lässt sich der Zodiac WX per Weboberfläche steuern.

Den SSH-Zugang muss der Admin erst über die Weboberfläche freischalten. Danach darf er über den Admin-Account zugreifen. Für privilegierte Zugriffe, wie es zum Beispiel das »nnofagent«-Kommando zum Auflisten der installierten Flows und Gruppen braucht (siehe Abschnitt weiter unten), ist der Benutzer »admin« in der »sudoers«-Datei eingetragen. Und »sudo -s« funktioniert auch für die vollwertige Rootshell.

API ans Steuer

Als wichtige Leistungskennzahl für Open Flow Devices gilt die Menge an Flows, Tabellen und Gruppen, die so ein Gerät verwalten kann. Der Zodiac WX unterstützt insgesamt acht Gruppen, 16 Tabellen und 512 Flow-Einträge.

Das REST-API erweist sich gerade im SDN-Kontext als besonders wichtig, weil der Clou ja darin besteht, dass ein SDN-Controller die Flow-Regeln steuert. Da wäre es umständlich, wenn der Administrator die Grundkonfiguration des Netzwerks manuell vornehmen müsste – vor allem wenn mehrere Accesspoints zum Einsatz kommen. Stattdessen kann der SDN-Controller über ein vorhandenes API so auch solche Dinge anpassen, die Open Flow nicht abdeckt.

Übrigens: Aktiviert der Admin den SDN-Controller nicht, arbeitet das Gerät wie ein normaler Accesspoint.

Go with the Flow

Das Open-Flow-Protokoll erlaubt es, die Daten-Verkehrsflüsse anhand von Regeln zu steuern. Diese Regeln bestehen, vereinfacht gesagt, aus einem Block von Filtern, gefolgt von einer Menge an Aktionen, die bestimmen, was mit einem Paket passieren soll. Über die Aktionen lassen sich zum Beispiel auch Felder im Paket umschreiben.

Filter und Aktionen decken dabei nach Bedarf die ISO-Schichten 1 bis 4 ab, also die Felder der Ethernet-Schicht bis hin zu den TCP-, UDP- und SCTP-Ports. Im Open-Flow-Filter repräsentiert der Eingangsport des Pakets und in der Aktion dessen Ausgangsport Schicht 1.

Bei physikalischen Switchen ist meist offensichtlich, wie diese zusammenpassen, auch wenn die Open-Flow-Nummerierung nicht zwingend zu den Portnummern des Geräts passt. Ports heißen in diesem Fall die Steckplätze, in denen die Netzwerkkabel stecken. Bei WLAN-Clients fehlen solche Ports naturgemäß, und somit fehlt auch beim Festlegen des Ziels für ein Paket eigentlich ein Open-Flow-Element.

Der WX löst dieses Problem, indem er dem Open-Flow-Port 65 den kabelgebundenen Port zuordnet, den Open-Flow-Ports 1 bis 32 die Clients im 5-GHz-Bereich und den Open-Flow-Ports 33 bis 64 die Clients im 2,4-GHz-Bereich. Das erledigt der SDN-Controller anhand der MAC-Adressen der Pakete.

Ungewollt dynamisch

Das Port-Problem der WLAN-Clients bringt eine ganz unfreiwillige Dynamik in die Open-Flow-Anwendungsentwicklung. Wollen Admins einen dynamischen Flow generieren, der Pakete an Port 5 und den damit verbundenen WLAN-Client schickt, erzeugt das mitunter Komplikationen: Geht dann ein WLAN-Client in den Stromsparmodus, taucht er beim nächsten Check-in womöglich als sechster Client auf und hängt in der Open-Flow-Logik am WX-Port 6. Dies müssen Entwickler für den WX besonders beachten.

Im Gegensatz zu Open Vswitch [5] kann der Administrator auf dem Zodiac WX die Flow-Regeln nicht lokal verwalten, sondern ist auf einen Open-Flow-Controller angewiesen. Im Test hat der Autor Floodlight [6] und Open Daylight [7] verwendet. In seinen frühen Versionen arbeitete der WX nicht mit Open Daylight zusammen, das hat Northbound allerdings behoben.

Die Konfiguration des SDN-Controllers erfolgt über die Weboberfläche unter »Control | Settings«. Abbildung 4 zeigt die Einstellungen.

Abbildung 4: Die Konfiguration des SDN-Controllers gelingt ebenfalls über eine Weboberfläche.

Die Einstellung »Auth Bypass« sorgt dafür, dass der Accesspoint Pakete, die nur zur Anmeldung am WLAN dienen (sie bilden einen eigenen Ethertype), von der weiteren Flow-Verarbeitung ausnimmt. Alternativ muss der Administrator manuell einen Flow einrichten, der diese Pakete durchreicht.

Selbst ist der Admin

Wie bei Open-Flow-kontrollierten Geräten üblich, ist der Admin des Geräts zugleich dessen Programmierer und muss sich um alles selbst kümmern. Für den Betrieb eines WLAN-Clients bedeutet dies bei aktiviertem »Auth Bypass«, er muss Flows für ARP und DHCP einrichten. Die Open-Daylight-Version der Flow-Beschreibung zeigt Listing 1.

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 ]

Als Ausgangsport wird hier »FLOOD« verwendet, das Open-Flow-Gegenstück zu einem Broadcast. Hat der Controller gelernt, welcher Client zu welchem Port gehört, kann er höher priorisierte Flows dazu bringen, die ARP- oder DHCP-Pakete für einen bestimmten Client nur auf seinem Port auszugeben.

Der Zodiac WX ist ein hybrider Open-Flow-Switch. Das bedeutet, dass er die »NORMAL«-Ausgabe-Aktion unterstützt. Die folgt sinngemäß dem Motto: Schick das Paket dorthin, wo es aufgrund der Forwarding-Tabelle hingehört. Bei Switchen wäre das die Ziel-MAC-Adresse – das gilt auch hier.

Da die WLAN-Clients aber keine physikalischen Ports verwenden, ergibt sich an dieser Stelle noch eine Besonderheit, die bei anderen Open-Flow-Geräten so nicht auftritt: Die MAC-Zieladresse und der Port müssen zusammenpassen oder passend gemacht werden.

Der Hintergrund ist, dass die Zuordnung, wie weiter oben schon beschrieben, der Reihenfolge beim Anmelden folgt. Open Flow ordnet also Port 1 dem zuerst angemeldeten 5-GHz-Client zu. Dabei merkt es sich auch die MAC-Adresse des Clients. Das führt dazu, dass die Open-Flow-Aktion »output:1« die Ziel-MAC-Adresse überschreiben muss, damit das Paket auf dem passenden Funkkanal ankommt.

Das bereits erwähnte Programm »nnofagent« listet mit der Option »-f« die vom Controller installierten Flows auf. Das entspricht auch dem Output in der Weboberfläche. Der Accesspoint unterstützt daneben auch die Open-Flow-Eigenschaften »Group« und »Meter«, wobei die erste Aktionen zusammenfasst und die zweite zur Durchsatzsteuerung beiträgt. Um diese Parameter aufzulisten, kommen der Logik folgend »-g« (für die Gruppen) und »-m« (für die Meter) zum Einsatz.

Das REST-API

Zur Konfiguration jedes Netzwerkgeräts gehört auch die Konfiguration der IP-Adressen und gegebenenfalls von VLANs. Dies unterstützt das Open-Flow-Protokoll allerdings nicht. Stattdessen stellt die letzte Firmware-Release (1.10 zum Zeitpunkt des Tests) ein REST-API bereit, das es erlaubt, diese Basiskonfigurationen vorzunehmen.

Dies ermöglicht es einem SDN-Controller, mit dem entsprechenden (noch zu entwickelnden) Treiber, die gesamte Konfiguration des Geräts unter seiner Kontrolle zu halten. Damit kann eine Applikation auf diesem Controller durchgängig ganze Netze aufspannen und nicht nur die Verkehrsflüsse kontrollieren.

Fazit

Das Gerät eignet sich gut zur Entwicklung von SDN-Applikationen auf echter Hardware. Im Vergleich zum Zodiac FX, der lediglich drei Wirkports mitbrachte, ist die Möglichkeit des WX, bis zu 64 Clients anzuschließen, für Netzwerk-Admins sehr attraktiv.

Es gibt durch die konzeptionellen Unterschiede der Hardware allerdings ein paar im Text erwähnte Einschränkungen, auf die frischgebackene SDN-Entwickler achten müssen. Aber im Vergleich zu den vier- bis fünfstelligen Kosten für größere SDN-Switche bietet der WX mit rund 215 US-Dollar ein sehr gutes Preis-Leistungs-Verhältnis.

Hinzu kommt, dass die WLAN-Anbindung auch das Koppeln von IoT-Geräten erlaubt, denen nicht selten ein Ethernet-Anschluss fehlt. Verglichen mit einem “normalen” Open-WRT-Accesspoint mit der vollen Funktion eines Linux-Kernels im Rücken, lassen sich Pakete mit Open Flow zu einem höheren Grad manipulieren und filtern.