© Olena Bilion, 123RF

Linux fühlt sich auf jeder Hardware wohl und übernimmt viele Aufgaben. Nur beim Transport – also bei den Netzwerkgeräten – schien die klassische Firmware bislang noch wettbewerbsfähig. In letzter Zeit gibt es aber vielversprechende Ansätze, um Linux auch hier einzusetzen. Das Projekt Open Switch ist einer davon.

Open Switch[1] betrat im Herbst 2015 die Bühne [2]. Hewlett-Packard kündigte das neue quelloffene Netzwerk-Betriebssystem (Network Operating System, NOS) in Kooperation mit Accton Technology Corporation, Arista, Broadcom, Intel und VMware an. Die Switche der Altoline-Serie [3] von HP Enterprise (HPE), wie der Konzern heute heißt, wurden von der ersten Stunde an unterstützt. Knapp ein Jahr später fanden sich weitere Fürsprecher wie Mellanox, Cavium Extreme Networks oder auch LinkedIn beziehungsweise Microsoft. Seit Anfang Juni 2016 ist Open Switch ein offizielles Projekt unter der Schirmherrschaft der Linux Foundation ([4], [5]).

Aller Anfang ist einfach

Open Switch lässt sich aus zwei Perspektiven betrachten: der des Anwenders oder der des Entwicklers. Für eine Erkundung als Anwender ist kompatible Hardware nötig, etwa ein entsprechender Switch. Für den Entwickler ist der Einstiegspunkt die Open-Switch-Gerrit-Seite [6]. Für die Entwicklung braucht der Interessent einen Github-Account und die Werkzeuge Git [7] und Gerrit [8]. Die einzelnen Schritte erläutert die Projekt-Seite [9]. Wer sich in der Vergangenheit mit Yocto [10] beschäftigt hat, sollte sich schnell zurechtfinden. Diese Linux-Distribution für kleine Systeme ist das Fundament für Open Switch (Abbildung 1).

Abbildung 1: Open Switch basiert auf Yocto – die aktuelle Variante kommt mit einem 3.18er Kernel.

Dieser Artikel nähert sich Open Switch aus der Anwenderperspektive, weil der Einstieg in die Entwicklung ohne Anwendererfahrungen als zu schwierig erscheint. Nun hat nicht jeder Zugriff auf die nötige kompatible Hardware. Glücklicherweise stellt das Projekt jedoch eine Variante für virtuelle Server zur Verfügung. Das Abbild ist im Format Open Virtualization Appliance (OVA) erhältlich ([11], [12], [13]). Das Tar-Archive enthält neben einem fertigen Abbild im VMDK-Format [14] die Beschreibung der zugehörigen virtuellen Maschine (siehe Listing 1). Falls die vorhandene Infrastruktur keine automatische Einbindung von OVA-Abbildern erlaubt, bleibt nur der Weg zu Fuß.

01 $ tar tf openswitch-appliance-image-appliance-ops-0.4.0-master+2016080600.ova
02 OpenSwitch.ovf
03 OpenSwitch.vmdk
04 $ tar xf openswitch-appliance-image-appliance-ops-0.4.0-master+2016080600.ova
05 $ ls OpenSwitch.*
06 OpenSwitch.ovf OpenSwitch.vmdk
07 $ qemu-img convert -f vmdk -O raw OpenSwitch.vmdk OpenSwitch.img
08 $ ls OpenSwitch.*
09 OpenSwitch.img OpenSwitch.ovf OpenSwitch.vmdk

Für den vorliegenden Artikel kam KVM als Hypervisor zum Einsatz. Die Spezifikation der virtuellen Maschine entnahm der Autor aus der OVF-Datei: zwei CPUs, 768 MByte RAM und acht Netzwerkschnittstellen. Die Konvertierung des Festplattenabbilds ist Geschmackssache, da KVM auch mit VMDK-Dateien umgehen kann. Die erste Netzwerkschnittstelle dient übrigens der Verwaltung von Open Switch beziehungsweise der darunterliegenden Hardware selbst. Um über das Netz erreichbar zu sein, muss diese Schnittstelle also eine IP-Adresse besitzen. Ob die Zuweisung statisch oder über DHCP erfolgt, spielt keine Rolle.

Egal ob manuell oder automatisiert, die Installation der virtuellen Open-Switch-Instanz geht ausgesprochen schmerzfrei und unspektakulär über die Bühne. Schon wenige Sekunden nach dem Start steht das System zur Verfügung (siehe Abbildung 2).

Abbildung 2: Die virtuelle Open-Switch-Instanz steht schon nach wenigen Augenblicken zum Einsatz bereit.

Drei Benutzer sind vordefiniert: »root« , »admin« und »netop« . Nur die beiden letzteren sind durch ein Passwort geschützt, das identisch mit dem Login-Namen ist. Der Zugriff auf den allmächtigen Wurzelbenutzer geschieht ohne zusätzliche Authentifizierung. Für interaktive Sitzungen kann der Anwender SSH als HTTP beziehungsweise HTTPS über die Standardports benutzen. Beim Zugriff über den Browser ist das Root-Login nicht erlaubt. So oder so ist es ratsam, die Passwörter zu ändern, um sich vor einem unbefugten Zugriff zu schützen.

Wie wäre Open Switch nun auf echter Hardware zu installieren? Das Projekt greift auf die Unterstützung von ONIE (Open Network Installation Environment, [15]) zurück. Das stellt Methoden und Konzepte für die Installation eigener Firmware auf Netzwerkgeräten zur Verfügung. Der Begriff Firmware kann hier etwas irreführend klingen, da es sich in den meisten Fällen um Linux-ähnliche Systeme handelt, die sich üblicherweise selbst NOS (Network Operating System) nennen. Interessanterweise basiert ONIE ebenfalls auf Linux.

Die NOS-Installation erfolgt über die üblichen Linux-Bootloader-Mechanismen. Die weiteren Informationen liefert der Kasten “Ein Installer für alles”.

Ein Installer für alles

Ziel von ONIE (Open Network Installation Environment) ist die Bereitstellung einer einheitlichen und einfachen Möglichkeit, Netzwerkgeräte mit Firmware/NOS der eigenen Wahl auszustatten. Im Hintergrund werkeln dabei ein moderner Linux-Kernel und Busybox [16]. Der Anspruch des Projekts geht so weit, dass es Installationen in großen Umgebungen möglichst parallel unterstützen möchte. Mit Puppet [17], Chef [18] oder Ansible [19] stehen ausreichend viele und bewährte Werkzeuge zur Verfügung. Verhält sich der Switch analog zu einem Linux-Server ist die Erweiterung der Verwaltungswerkzeuge recht einfach.

ONIE ist eine Initiative des Open Compute Projekts ([20], [21]). Zu dessen Gründungsmitgliedern gehörten unter anderem: Accton, Agema, Big Switch Networks, Broadcomm, Cumulus Networks und Dell. Eine Überlappung mit den Open-Switch-Mitstreitern der ersten Stunde ist nicht zufällig. Treibende Kraft war dabei Cumulus Networks [22], das ebenfalls im NOS-Markt tätig ist. ONIE möchte einzelne Endanwender, Verwalter großer Netzwerk-Umgebungen und auch Switch-Hersteller und -Verkäufer gleichermaßen gut bedienen.

Der Arbeitsablauf der NOS-Installation ist recht einfach (Abbildung 3). Der so genannte Low Level Bootloader des Switch initiiert eine Erstinitialisierung der Hardware und lädt schließlich ONIE, quasi einen Linux-Kernel mit Busybox, oben drauf. Dieser konfiguriert die Verwaltungsschnittstelle, lädt den NOS-Installer und führt ihn aus. Für das Finden und Laden des Installationsprogramms kann ONIE auf verschiedene Methoden und Konfigurationsmöglichkeiten zurückgreifen [23].

Abbildung 3: Die Installation eines NOS über ONIE (links) und ein normaler Bootprozess (rechts).

Die Information über die Lage des NOS-Installers kann direkt in ONIE konfiguriert sein. Alternativ ist die Bereitstellung der Daten über DHCP, Multicast DNS und ähnliche Zeroconf-Methoden möglich, der aus der Serverinstallation bekannte PXE-Boot-Mechanismus ebenfalls. Für den Transport der Binärdaten ist sowohl TFTP als auch HTTP verwendbar. Es ist auch möglich, das Installationsprogramm auf einem lokal angeschlossenen USB-Stick abzulegen. Dort sucht ONIE danach sogar zuerst.

Tiefer im Kaninchenbau

Wie erwähnt sollte der erste Schritt nach der Installation darin bestehen, neue Passwörter für die Benutzer »root« , »admin« und »netop« zu setzen. Das Anlegen eigener Benutzer über das Kommando »useradd« ist ebenfalls eine gute Idee. Danach verschaffen die üblichen Linux-Kommandos wie »ps« , »top« oder »ifconfig« einen ersten Überblick. Den Systemstart übernimmt Systemd.

Schaut man auf die Liste der Standardprozesse, zeigt sich eine ganze Menge Dienste, deren Name mit »ops« beginnt. Jeder ist dabei für eine ganz bestimmte Funktion von Open Switch zuständig. Um die VLAN-Verwaltung kümmert sich beispielsweise »ops-vland« , während »ops-ospfd« die Geschehnisse um das Routingprotokoll OSPF (Open Shortest Path First) kontrolliert. Für jede Funktion gibt es auf der Projektseite eine ausführliche Dokumentation [24].

Für die eigentliche Verwaltung muss der Open-Switch-Admin aber zunächst einen speziellen Kommando-Interpreter starten (Listing 2). Dabei handelt es sich um die von der Routing-Software Quagga bekannte »vtysh« [25]. Damit gelangt der Anwender in den so genannten privilegierten Modus, der etwa das Auslesen der Konfigurationen erlaubt. Wer sie ändern will, muss in den Konfigurationsmodus wechseln. Dies geschieht durch die Eingabe von »configure« beziehungsweise »configure terminal« .

01 root@switch:~# vtysh
02 switch#
03 switch# show ntp status
04 NTP is enabled
05 NTP authentication is disabled
06 Uptime: 137 second(s)
07 switch#
08 switch# show ntp associations
09 ----------------------------------------------------------------------
10  ID NAME REMOTE VER KEYID REF-ID ST T LAST POLL REACH DELAY OFFSET JITTER
11 ----------------------------------------------------------------------
12 ----------------------------------------------------------------------
13 switch(config)# ntp server ntp.linux-magazin.de
14 switch(config)#
15 switch(config)# exit
16 switch#
17 switch# show ntp associations
18 ----------------------------------------------------------------------
19  ID NAME REMOTE VER KEYID REF-ID ST T LAST POLL REACH DELAY OFFSET JITTER
20 ----------------------------------------------------------------------
21  1 ntp.linux-magazin.de - 3 - - - - - - - - - -
22 ----------------------------------------------------------------------

Die so durchgeführten Änderungen überleben einen Reboot nicht. Für das Experimentierstadium ist das ganz nützlich, da ein Neustart das System wieder in einen jungfräulichen Zustand versetzt. Im Normalbetrieb wünscht sich der Admin aber in der Regel, dass die Modifikationen dauerhaft sind. Mit einem einfachen Kommando überträgt er die Laufzeit-Konfiguration in den nicht-flüchtigen Speicher: »copy running-config startup-config« . Dies geschieht übrigens direkt aus der »vtysh« heraus.

Bahn frei für Automaten

Die Konfiguration eines einzelnen Switch ist nur ein Puzzlestein gemessen an den eigentlichen Ambitionen des Open-Switch-Projekts. Die zielen auf Automation größerer Konfigurationen. Das Projekt bevorzugt Ansible [19] und liefert die Dokumentation für den Einstieg [26] mit. Ein Argument dafür ist, dass es keine Installation auf dem Zielsystem – dem Open-Switch-Gerät – erfordert.

Das oben gezeigte Beispiel für die NTP-Konfiguration eines einzelnen Switch erforderte das Anmelden, das Wechseln in die Routing-Shell, das Einschalten des Konfigurationsmodus und schließlich das Absetzen des Kommandos. Niemand möchte dies manuell auf vielen Geräten ausführen. Der kritische Leser mag argumentieren, dass die NTP-Konfiguration in den meisten Fällen statisch und nur bei der Ersteinrichtung eines neuen Geräts nötig ist. Der beschriebene Prozess – Login, »vtysh« , »configure« , »einKommando« – ist aber vergleichbar mit der Konfiguration eines neuen VLAN.

Diese Aufgabe ist Teil des Alltags eines Netzwerkadmin und in den meisten Fällen auf einer Reihe von Switches durchzuführen. Die manuelle Ausführung skaliert dann nicht. Mit Open Switch und Ansible lässt sich die neue VLAN-Konfiguration in Sekunden auf vielen System ausrollen – einfach, wiederholbar und auf der unterstützten Hardware sogar herstellerunabhängig. Mit dem Ansible-Modul »ops_template« ist zudem die komplette Neueinrichtung von vielen Switches in einem Schritt möglich.

Zum gegenwärtigen Zeitpunkt gehören vier Module zum Kernbereich von Ansible [27]. Tabelle 1 listet sie mit einer kurzen Beschreibung auf. Natürlich lassen sich auch andere Ansible-Module verwenden, schließlich basiert Open Switch auf Linux. Für die eigentlichen Switch-Kommandos müsste der Admin den Wechsel in die spezielle Shell »vtysh« über Konstrukte wie beispielsweise »echo ‘show version’|vtysh« einbauen.

HTTPS hat aber quasi eine Doppelfunktion: Es ist nämlich auch der Einstiegspunkt für eine REST-Schnittstelle [28]. Die entsprechende Infrastruktur vorausgesetzt, lässt sich die Open-Switch-Umgebung über »GET« , »POST« , »DELETE« und »PUT« verwalten.

Was am Ende übrig bleibt

Open Switch liegt gegenwärtig in der Version 0.4 vor. Seit seiner Veröffentlichung vor knapp einem Jahr ist viel passiert und nicht nur im technischen Bereich. Insbesondere die Schirmherrschaft der Linux Foundation garantiert Nachhaltigkeit und Weiterentwicklung. Mit HPE steht ein namhafter Hersteller von Switch-Hardware hinter dem Projekt.

Open Switch ist nicht der einzige Mitspieler im NOS-Markt. Dell beispielsweise kooperiert mit der bereits erwähnten Firma Cumulus Networks und hat ein Eigengewächs in petto: das auf Net BSD basierende DNOS9 (Dell NOS) [29]. Dann wäre da auch noch Vy OS [30] zu nennen, das eine Brocade-Vergangenheit hat.

Die Projekt-Dokumentation ist recht umfangreich, hat aber auch ein paar offene Baustellen. So sind einige Beispiele sogar irreführend, weil sie dringend erforderliche Parameter nicht erwähnen. An anderer Stelle gibt es Verweise auf veraltete Versionen.

Am Ende bleibt ein vollständig quelloffenes Betriebssystem für Switches, das auf bekannten Projekten wie Yocto oder ONIE aufbaut und dem Otto-Normal-Linux-Benutzer einen einfachen Einstieg erlaubt.