© cylonphotoft, Fotolia

Als Facebook ankündigte, für seine Rechenzentren eigene Switches bauen zu wollen, sorgte dies für ein Raunen in der Branche. Neben F-Boss gibt es mittlerweile auch Linux-basierte Betriebssysteme für Switches. Der Artikel stellt die Kombination aus dem Boothelfer Onie und Cumulus Linux vor.

Bei Switches für Rechenzentren denken die meisten Administratoren an Produkte von Juniper, Cisco, HP oder Arista. Diese Geräte lassen sich über eigene Betriebssysteme konfigurieren, Pakete leitet die Hardware weiter. Die Asics (Application-specific integrated Circuit), die das Switchen übernehmen, unterscheiden sich oftmals gar nicht so sehr voneinander, die Hersteller grenzen sich vielmehr über die abbildbaren Konfigurationen voneinander ab. Wie diese aussehen, bestimmt wiederum die steuernde Software, und die kann auch ein Linux sein.

Abbildung 1: Das gängigste Szenario ist, dass ein DHCP-Server den Switch über die IP-Adressen des lokalen Webservers informiert, auf dem sich das Betriebssystem-Image befindet.

Linux läuft mittlerweile nicht nur auf praktisch jeder CPU-Architektur, sondern hat auch seinen Weg auf die Steuereinheiten von Switches gefunden. Fehlen nur noch Treiber und Werkzeuge, mit denen ein Admin die Switch-Hardware verwaltet. Das erledigt Cumulus Linux [1]. Die Distribution läuft auf den Geräten von Dell, Edgecore und einigen anderen Herstellern, ist allerdings nicht kostenlos (siehe Kasten “Lizenz zum Switchen”).

Onie

Damit das Betriebssystem auf dem Switch arbeitet, muss es kompatibel zu Onie [3] sein. Das Open Network Install Environment ist eine Mini-Linux-Distribution, die lediglich dazu dient, das eigentliche Betriebssystem zu installieren. Das Onie-Team bezeichnet sie als “Linux Kernel mit Busybox”. Onie stöbert das eigentliche Betriebssystem im Netzwerk oder auf einem angesteckten USB-Stick auf, stößt die Installation an und stellt Werkzeuge zur Reparatur bereit, falls bei Installation oder Upgrade was schiefläuft.

Die Bootreihenfolge für ein nacktes Onie-fähiges Gerät sieht so aus:

• Nach dem Anschalten startet der Minimal-Bootloader des Geräts (meist eine Version von U-Boot).
• Dieser wiederum initiiert den Linux-Kern des Onie-Installers.
• Onie sucht nach dem eigentlichen Betriebssystem und installiert es.

Der Onie-Installer [4] sucht dabei auf mehreren Wegen nach dem Betriebssystem. Findet Onie ein USB-Storage-Device und in dessen Rootverzeichnis eine Datei mit passendem Namen (die Regeln für die Namen liefert [5]), startet die Installation. Das ist alles.

Schließt der Admin hingegen einen PC mit einem Webserver per LAN-Kabel direkt an, dann sucht sich Onie über die Neighbor Discovery die IP-Adresse des Servers und probiert die eben genannten Namensregeln aus. Das Image muss dafür lediglich im Document-Root des Webservers liegen.

Der wohl häufigste Fall im Netzwerk funktioniert über DHCP (Abbildung1). Der Admin richtet für den Host die DHCP-Option 114 (»default-url« ) mit einem direkten Link zur Firmware ein. Ab da funktioniert alles ohne weitere Eingriffe. Dieses Vorgehen erlaubt es, den Switch aus dem Karton zu holen, einzubauen, das Management-Interface anzuschließen und ihn einzuschalten.

Für komplexere DHCP-Setups flicht Onie noch eine Vendor-ID in die DHCP-Anfragen, so kann der Admin die DHCP-Antworten trennen. Geht beim Installieren etwas schief, bietet Onie eine Kommandozeile im Busybox-Stil. Mit ihr kann der Admin nach dem Rechten sehen oder die Installation neu anstoßen.

Zurzeit unterstützt Onie die Betriebssysteme Switch Light [6] von Big Switch Networks, Cumulus Linux und MLNX-OS [7] von der Firma Melanox. Auch im Jahr 2015 ist es übrigens nicht selbstverständlich, dass der ganze Mechanismus auch über IPv6 funktioniert.

Cumulus Linux

Cumulus Linux ist eine Debian-basierte Distribution mit ein paar Extras, um die Hardware des Switch anzusteuern. Ehemalige Mitarbeiter von VMware und Cisco haben die dahinterstehende Firma 2010 gegründet, um ein “Netzwerk-Linux” zu entwickeln. Abbildung 2 zeigt das Zusammenspiel zwischen den üblichen Linux-Komponenten, den Erweiterungen von Cumulus und der Switch-Hardware.

Abbildung 2: Das Zusammenspiel der Komponenten auf einem Switch mit Cumulus Linux. Bei der rot markierten Switchd-Komponente handelt es sich um den Switch-Daemon, das “Herz von Cumulus Linux”.

Der für den Test benutzte Switch 4600-54T der Firma Edgecore besitzt neben dem Management-Interface 52 Ports zum Switchen. Über den Befehl »ifconfig -a« lassen sich diese anzeigen, aber nicht als »eth« , sondern als »swp« . Der in Abbildung 2 dargestellte Switchd-Daemon fängt alle Standard-Linux-Aufrufe ab und setzt sie auf der Switch-Hardware um. Die konfiguriert sich so wie ein Linux-Rechner mit 53 Interfaces.

Was für den Admin eines Cisco-Switch »no shutdown« ist, erledigt hier »ip link up« . Der Admin aktiviert das Switchen zwischen den Switchports mit »brctl« , dem Standardwerkzeug für Bridges. Damit die Konfiguration auch einen Reboot überlebt, sollte sie in »/etc/network/interfaces« liegen. Um die Ports 1 bis 5 untereinander switchen zu lassen, fügt der Admin die Zeilen aus Listing 1 in die »interfaces« -Datei ein.

01 auto br0
02 iface br0
03         bridge-ports swp1 swp2 swp3 swp4 swp5
04         bridge-stp on

Da die Liste bei 52 Ports etwas lang zu werden droht, ist es auch möglich

bridge-ports glob swp1-10

zu schreiben. Der Netzwerk-affine Admin sieht hier bereits, dass Cumulus die Syntax und die Möglichkeiten für Standard-Linux-Bridges erweitert. Es ist natürlich auch möglich, Ports VLANs zuzuordnen und Ports zu bündeln, um redundante Uplinks zu schaffen.

Neben der Konfiguration über »brctl« steht bei Bedarf auch Open V-Switch bereit. Die Konfiguration von Overlay-Netzen mit Virtual Extensible LAN (VXLAN) klappt dabei sogar Hardware-beschleunigt. Soll das Gerät auf Layer 3 arbeiten, kann der Admin die Bridge- oder SWP-Interfaces mit IP-Adressen versorgen. Um dynamische Routingprotokolle kümmert sich die Quagga-Suite [8].

Zu den Standardwerkzeugen bei einer Fehlersuche gehört Tcpdump. Dies fehlt üblicherweise auf Switches. Also muss der Admin erst einen Spiegelport konfigurieren und dort ein Tcpdump-fähiges Gerät anhängen. Cumulus erlaubt es hingegen, Traffic über »tcpdump -n -i br0« anzuzeigen.

Große Pcap-Dateien brauchen für Analysen dennoch einen Spiegelport, weil der Flashspeicher des Switch wenig Platz bietet und langsam arbeitet. Da auf ihm aber ein Linux mit Debians Software-Auswahl rennt, lassen sich noch andere Dinge drehen. So läuft Collectd [9] auf dem Switch und erlaubt das Monitoring mit dem entsprechenden Server.

Automation

Der Onie-Installer gibt sich viel Mühe, um eine unbeaufsichtigte Inbetriebnahme zu ermöglichen. Diese Bemühungen setzt er im Betrieb des Switch fort. Für Puppet und Chef stehen Clients im Repository bereit, auch Ansible wird unterstützt. Liegen Cookbooks oder Playbooks einsatzbereit vor, die »/etc/network/interfaces« anpassen, dann kann die Automatisierungssoftware der Wahl den Switch vollständig konfigurieren. Rollt der Admin einen Dienst aus, der eine bestimmte Netzwerkkonfiguration benötigt, setzt er Puppet ein, anstatt den betroffenen Switch anzufassen.

Fazit

Der klassische Netzwerk-Admin wird Cumulus und Onie auf Switches nicht unbedingt mögen oder sich umgewöhnen müssen – und sein CLI vermissen. Der klassische Linux-Server-Admin fühlt sich hingegen schnell zu Hause, sieht sich aber mit einigen neuen Abkürzungen und Technologien konfrontiert, wenn es um die fortgeschritteneren Features der Switchkonfiguration geht.

Zwischen beiden Welten steckend, gefällt es dem Autor des Artikels sehr gut, mit den bekannten Linux-Tools auf Fehlersuche im Netz zu gehen. Noch spannender ist aber sicherlich der Automatisierungsaspekt: Cumulus lässt sich sehr einfach in bestehende Standardlösungen integrieren und schränkt dabei den Admin in seinen Automatisierungsbemühungen nicht ein. Nicht zuletzt spielt auch der kommerzielle Aspekt eine Rolle, da einige der nackten Switches deutlich preisgünstiger sind als die Konkurrenz der großen Marken.