Ethernet-Verbünde mit Bonding betreiben, VLANs und Switches trotz Spanning Tree beherrschen und störende DHCP-Server aufstöbern: Admins halten ihre Netze meist nur dank gezielter Tricks und Kniffe unter Kontrolle. Dieser Herausforderung stellen sich unsere Profis mit Freude.

Netzwerke jenseits trivialer Fälle administrieren klappt nur mit einer guten Portion Theoriewissen und einem riesigen Erfahrungsschatz. Das Linux-Magazin wollte es genauer wissen und bat seinen Autor und Sysadmin-Guru Charly Kühnast um einschlägige Berichte aus dem Alltag. Doch der erklärte sich prompt für nicht zuständig und flüchtete auf den Flur. Zwei Türen später hielt er inne, klopfte und überredete seine Kollegen aus der Netzwerk-Abteilung dazu, Anekdoten aus ihrer täglichen Arbeit zu berichten. Da die Jungs ein recht stattliches, Niederrhein-weites Primär- und Sekundärnetz verantworten, schöpfen sie aus dem Vollen.

Der Spaß beim Vernetzen beginnt schon in den untersten Schichten: Wie viele Kabel zwischen einem Rechner und dem nächsten Switch liegen, ist gar nicht so selbstverständlich mit "eins" zu beantworten. Auch ob ein Switch die richtige Wahl ist oder doch ein Router her muss, klärt sich oft erst nach wochenlanger leidvoller Erfahrung mit der falschen Entscheidung. Selbst das altbekannte DHCP hat genügend Überraschungen in petto.

Fall 1: Bonding

Manchmal reicht ein einzelnes Ethernet-Interface nicht aus. Sei es, weil im Fehlerfall Failover-Mechanismen greifen sollen oder weil der Durchsatz bei nur einer NIC zu gering wäre (Abbildung 1). In diesen Fällen ist es sinnvoll, mehrere Karten per Bonding-Interface zusammenzufassen. Ausgangsdokumentation hierfür ist die Anleitung in »bonding.txt« für den jeweiligen Kernel. Sie steckt in den Linux-Quellen, etwa unter »/usr/src/linux-2.6.5-7.257/Documentation/networking/bonding.txt«.

Abbildung 1: Hat ein PC zwei Netzwerkanschlüsse, gibt es zwei Verkabelungsvarianten fürs LAN: an einen Switch (links, High Availability und Load Balancing) oder an zwei getrennte (rechts, nur HA).

Nach der Konfiguration eines virtuellen Master-Interface (beginnend bei »bond0«) und der Zuordnung der physikalischen Interfaces (etwa »eth0« und »eth1«) an das Master-Interface ist das Bondingmodul mit der entsprechenden Parametrisierung zu starten: Dabei sind Modus 0 oder 2 für Load Balancing zuständig und Modus 1 für Active Backup. Modus 0 verteilt die Last im Round-Robin-Verfahren, während Modus 2 einen XOR-Algorithmus anwendet.

Aus Netzwerksicht ist Modus 2 klar zu bevorzugen, da Modus 0 zwar die Pakete gleichmäßig über alle Links verteilt, hierbei aber prinzipiell die Gefahr besteht, dass sich Pakete einer Session auf unterschiedlichen Links gegenseitig überholen. Das wäre für manche UDP-Anwendungen tödlich und selbst TCP ist in schlimmen Fällen nicht mehr in der Lage, die originale Reihenfolge zu rekonstruieren. Im ungünstigsten Fall bricht dann die Session ab. Cisco-Switches kennen Round Robin nicht einmal.

Die XOR-Variante geht intelligenter vor und bildet aus Quell- und Ziel-MAC einen Hash, der darüber entscheidet, auf welchem verfügbaren Link die Verbindung landet. Solange sich Quell- und Ziel-MAC nicht ändern, bleibt die Entscheidung gleich. Der erwünschte Effekt: Alle Pakete einer Verbindung passieren die gleiche Leitung.

Wer bin ich

Spätestens wenn mehr als zwei Interfaces vorhanden sind, wird es für das Bonding wichtig, welches physikalische Interface welchem »ethx« entspricht. Weil der Kernel selbst entscheidet, wie er die Nummern vergibt, hilft das Werkzeug »ethtool« mit dem Parameter »-p«: Es lässt die Link-Diode des angesprochenen Interface rhythmisch blinken (siehe [1] und [2]).

Das erweist sich als besonders hilfreich, wenn jemand nachträglich Netzwerkkarten einbaut (Abbildung 3). Dann nämlich würfelt das Betriebssystem die Zuordnung zwischen Physik und »ethx« neu aus. Die hässliche Folge ist, dass sich plötzlich völlig andere Interfaces in einem Bond wiederfinden. Wer dann nicht feststellen kann, welches »ethx« welchem Port entspricht, darf sich stundenlang mit Probieren vergnügen.

Beim Einrichten von zwei oder mehr Bondings über Dualport-Interface-Karten (je zwei Ports pro Karte) ist wichtig, dass sich die zu einem Bond zusammengefassten Interfaces auf unterschiedlichen Karten befinden (Abbildung 2). Nur das stellt sicher, dass beim Ausfall einer Karte noch ein Link pro Bond am Leben bleibt. Ist nur Ausfallsicherheit gefordert und kein Load Balancing, wäre es sinnvoller die Links auf verschiedene Ethernet-Switches zu verteilen (Abbildung 1). Der Ausfall eines Switch würde den Betrieb dann weniger einschränken.

Abbildung 2: Bonding mit Dual-Port-Ethernet-Karten verwendet sinnvollerweise zwei virtuelle Master-Interfaces »bond0« und »bond1«, die über Kreuz physische Interfaces beider Karten vereinen. Fällt eine Karte aus, überleben dennoch beide Bonding-Interfaces.

Abbildung 3: Baut der Besitzer eine zusätzliche Netzwerkkarte in seinen Rechner, tüftelt das Betriebssystem die Zuordnung von physikalischem Gerät zur logischen Interface-Nummer neu aus. Wer Pech hat, findet unter »eth0« die neue Karte wieder und alle Nummern sind neu vergeben.

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

Ethernet-Verbünde mit Bonding betreiben, VLANs und Switches trotz Spanning Tree beherrschen und störende DHCP-Server aufstöbern: Admins halten ihre Netze meist nur dank gezielter Tricks und Kniffe unter Kontrolle. Dieser Herausforderung stellen sich unsere Profis mit Freude.