© Vladyslav-Zymovin, 123RFw

Ist die Internetanbindung unerlässlich, richtet der Netzwerkadmin sie besser mit Netz und doppeltem Boden ein. Dank dem Fault Tolerant Router steht dafür sogar eine recht preisgünstige Lösung für einen Linux-Server als Router zur Verfügung, wenn der Admin mit den Abstrichen leben kann.

Stabile Internetanbindungen sind vielerorts geschäftskritisch. Den Leitungen ist das natürlich egal, sie brechen häufiger zusammen, als es dem Admin lieb sein kann. Will er die Leitungen über zwei oder mehr Provider redundant anbinden, spielt er in der Regel mit dem Border Gateway Protocol (BGP).

Das ist ein recht kostspieliges Vergnügen, da es sich um Geschäftsanschlüsse handelt, die sich Provider gut bezahlen lassen. Mit leichten Einschränkungen, aber deutlich günstiger klappt es mit der Redundanz, wenn der Netzwerker Linux und den fehlertoleranten Router (Fault Tolerant Router [1]) einsetzt.

Üblicherweise versendet ein Linux-Host seine Pakete mit Unterstützung der Routingtabelle. Alle Pakete, die nicht zu einer spezifischen Route gehören, nehmen den Weg über die Standardroute (Default Route), die typischerweise ins Internet führt. Fällt diese Leitung aus, sind alle Teilnehmer diesseits vom Internet abgeschnitten. Die Ursachen für einen Ausfall erweisen sich als vielfältig. Zu ihnen gehören Bagger, die Leitungen durchtrennen, Softwarefehler in Layer 2 oder 3 sowie Router, die einen Hop weiter im Netz des Providers versagen.

Um Festplattenausfälle zu verhindern, setzen Admins schon lange Raids ein und verdoppeln ihre Platten im einfachsten Fall als Mirror-Raid [2]. Für Zugangsleitungen ist das nicht so einfach. Bei einem in diesem Bereich klassischen Setup sichern mindestens zwei Internetprovider das Netzwerk, verfügt der eigene Anschluss also über zwei Uplinks.

Dies teilt der Admin dem Rest der Welt über das Border Gateway Protocol (BGP) mit, bei internen Netzen darf es auch ein internes Routingprotokoll wie OSPF sein. Bricht ein Link weg, merken die Protokolle dies und hören auf, Pakete über die tote Leitung zu senden.

Die Protokolle erkennen Ausfälle automatisch. Macht das Internet Protocol (IP) die Grätsche, obwohl die Leitung auf unterster Ebene intakt ist, bemerkt das Routingprotokoll dies, weil es aktives Monitoring betreibt. Das kann zwar etwas dauern, trotzdem geschieht der Wechsel ohne Zutun und treibt den Admin nicht mitten in der Nacht aus dem Bett.

Während aber das “i” in Raid für “inexpensive” steht (Redundant Array of Inexpensive Disks), ist ein redundanter Netzwerkanschluss nicht für 19,99 Euro im Monat zu haben. Vielmehr wird ein dreistelliger Betrag fällig. Doch auch der weniger solvente Admin will sein redundantes Array of Links (RAL) gern in ein RAIL verwandeln.

Zum Glück bringt Linux fast alle Komponenten mit, um so ein RAIL zu realisieren. Der Netzwerk-Admin muss sie aber im Kernel aktivieren. Lediglich Linkausfälle erkennt Linux nicht automatisch. Stattdessen würde es alle Datenpakete über den ausgefallenen Link ins Nirwana schicken und der Benutzer erhielte nicht reproduzierbare Ladefehler. Bevor der Admin den Fault Tolerant Router aber in sein Setup integriert, sollte er die darunterliegende Software besser kennenlernen.

Wildes Routen mit “iproute2”

Das »ip« -Kommando des »iproute2« -Pakets kann eigentlich alles konfigurieren, was der Linux-Kernel netzwerktechnisch hergibt. Viele Funktionen lassen sich nur damit konfigurieren (etwa Routen in zusätzlichen Routingtabellen), in anderen Fällen ersetzt es Standardwerkzeuge wie »ifconfig« , »route« oder »vconfig« , das VLANs anlegt.

So kann »ip« zum Beispiel mehrpfadige Routen anlegen. Dazu gibt der Admin einer neuen Route den Parameter »table X« mit auf den Weg. Bei »X« handelt es sich um eine Zahl oder einen Namen, der in der Datei »/etc/iproute2/rt_tables« auf eine bestimmte Routingtabelle zeigt. Beispielsweise ordnet das Kommando

ip route add table 5 192.168.0.0/24 via  10.1.1.1

die Route für das Netz »192.168.0.0/24« der Routingtabelle Nummer 5 zu.

Policy Routing

Existieren mehrere Routingtabellen, will der Admin dem Kernel mitteilen, wann er welche Routingtabelle verwenden soll. Dabei hilft ihm das »ip rule« -Kommando. Damit stellt der Administrator Regeln für die Quell- oder Ziel-IP-Adressen auf, auch Netzblöcke sind erlaubt. Er kann das verwendete Netzwerkinterface festlegen sowie einen Wert für das Type-of-Service-Feld (TOS) des IP-Protokolls.

Will er die Regeln möglichst flexibel gestalten, setzt er zusätzlich auf das Argument »fwmark« . Mit diesem hexadezimalen Wert kann er eine von IPtables gesetzte Firewall-Markierung tracken, die IPtables zusammen mit dem »mangle« -Attribut benutzt, um nach Ports oder Protokollen zu routen (Listing 1). Detaillierte Informationen dazu liefert eine Suche nach “Policy Routing” [3].

01 iptables -t mangle -A PREROUTING -i Quellinterface -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
02 iptables -t mangle -A PREROUTING -i Quellinterface -j CONNMARK -p tcp --dport 80 -m conntrack --ctstate NEW --set-mark 0x10

Um etwa auf einem Linux-Router alle Pakete aus dem Subnetz »172.16.0.0/24« in die Routingtabelle 8 mit der Standardroute »10.2.2.1« zu leiten, helfen die zwei folgenden Kommandos:

ip route add table 8 default via 10.2.2.1
ip rule add from 172.16.0.0/24 lookup 8

Eine Kleinigkeit, die einem Admin klar sein muss, wenn er mehrere Routingtabellen verwendet: Ihm fehlen die Routingeinträge, die der Kernel beim Anlegen einer neuen IP-Adresse automatisch erzeugt. Die muss er händisch eintragen, wenn er sie, etwa beim Policy Routing, benutzen will. Ansonsten schickt Linux die Antwortpakete über die falsche Route zurück.

Will der Netzwerker nur den ausgehenden HTTP-Verkehr über eine andere Route leiten, legt er die beiden IPtables-Regeln aus Listing 1 an. Die erste löscht die Markierungen der ausgehenden Pakete, die zweite verpasst den Paketen mit dem Reiseziel Port 80 eine hexadezimale Markierung (»–set-mark 0x10« ). Auf sie soll die Routingregel fortan achten:

ip rule add fwmark 0x10 lookup 8

Auf diesem Weg leitet der Admin zwar Pakete um, doch der Kernel verteilt sie nicht auf verschiedene Routen.

Multipath Routing

Über das »ip route« -Kommando legt ein Admin mehrere Defaultrouten fest – sogar mit unterschiedlicher Gewichtung. Das setzt voraus, dass er den Kernel zuvor mit Multipath-Routing-Support übersetzt hat.

Üblicherweise verteilt Linux Datenpäckchen auf Paket- oder auf Verbindungsebene. Die Pakete einzeln zu verteilen lastet zwar beide Leitungen optimal aus, birgt aber in der Praxis ein paar Risiken. So muss das Gegenstück am anderen Ende der Leitung die Pakete wieder in ähnlicher Weise zuordnen, da sonst nur der Upstream lastverteilt wird.

Sind die Leitungen unterschiedlich schnell, kann es zudem passieren, dass der Absender Pakete in der richtigen Reihenfolge losschickt, diese aber in der falschen ankommen. Da TCP-Verbindungen Unterschiede aber nur bis zur Puffergröße ausgleichen, pendelt sich die Geschwindigkeit auf die langsamste Leitung ein. Außerdem ist auf diesem Weg eine Adressenumsetzung unmöglich.

Alternativ setzt der Admin jede neue Verbindung auf eine andere Leitung. Zwar sind die individuellen Streams dann maximal so schnell wie die schnellste einzelne Leitung, aber bei mehreren Benutzern führt dies dennoch zu einem verbesserten Datendurchsatz.

Zwei Standardrouten mit Load Balancing setzt der Admin folgendermaßen:

ip route add default nexthop via 10.1.1.1  dev eth1 nexthop via 10.2.1.1 dev eth2

Will er auf Paketebene arbeiten, gehört hinter das »add« -Kommando der Begriff »equalize« . Eine Gewichtung erreicht er, indem er ein »weight Gewicht« hinter die einzelnen Hops schreibt. Fällt jetzt eine Route aus, rennt jede zweite Verbindung in einen Timeout.

Damit sind alle Bausteine genannt, um Daten über mehrere Leitungen zu schicken, diese mit ein paar einfachen Kommandos zu überwachen und bei einem Ausfall eine Leitung aus dem Cluster zu entfernen. Nun kommt der Fault Tolerant Router ins Spiel.

Fehlertolerant

Alessandro Zarrilli hat das Projekt ins Leben gerufen, unter [4] lässt sich der Quellcode herunterladen, unter [1] wartet zudem eine recht ausführliche Dokumentation. Über den Befehl »gem install fault_tolerant_router« spielt der Admin die in Ruby geschriebene Software auf den Rechner (Abbildung 1). Nach ihrem Start überwacht ein Daemon die Leitungen und schaltet sie notfalls um.

Abbildung 1: Über »gem« lässt sich der in Ruby geschriebene Fault Tolerant Router recht einfach auf einem Linux installieren. Die Abbildung zeigt ein Ubuntu 14.04.

Mit der Option »generate_config« aufgerufen, erzeugt das Programm die Konfigurationsdatei »/etc/fault_tolerant_router.conf« , Listing 2 zeigt Ausschnitte. Die passt der Admin an seine Bedürfnisse an. Die Datei liegt im Yaml-Format [5] vor und beinhaltet die Konfigurationsgruppen »uplinks« , »downlinks« , »tests« , »log« und »email« .

01 uplinks:
02 - interface: eth2
03   ip: 10.1.1.1
04   gateway: 10.1.1.254
05   description: Example Provider 1
06   weight: 1
07   default_route: true
08   # weitere Interfaces
09 [...]
10 downlinks:
11   lan: eth1
12
13 tests:
14   ips:
15   - 192.168.254.254
16   required_successful: 1
17   ping_retries: 1
18   interval: 60
19
20 log:
21   file: "/var/log/fault_tolerant_router.log"
22   max_size: 1024000
23   old_files: 10
24 [...]

Eine »uplinks« -Definition besteht üblicherweise aus dem Namen des Interface, der zugehörigen IP-Adresse, der IP-Adresse eines Gateway für das Interface, einer Beschreibung, einem Flag sowie einer Gewichtung. Das Flag bestimmt, ob die Schnittstelle zu den Standardrouten gehört. Je höher die Gewichtung, desto häufiger kommt diese Leitung für neue Verbindungen zum Einsatz. Entsprechend setzt der Admin bei unterschiedlich schnellen Leitungen auf eine höhere Gewichtung (Abbildung 2).

Abbildung 2: Die Konfigurationsdatei des fehlertoleranten Routers lässt sich über die Option »generate_config« erzeugen. Sie bringt bereits mehrere Beispielinterfaces mit, die auf potenzielle Provider zeigen.

Im Bereich »downlinks« definiert der Admin ein internes Interface, auf Wunsch auch ein DMZ-Interface. Unter »tests« gehört eine Liste von IP-Adressen, die der Router im Rahmen von Funktionstests regelmäßig anpingen darf, in zufälliger Reihenfolge. Die Adressen sollten über das Internet erreichbar sein. Der Admin definiert zudem, nach wie vielen erfolgreichen Tests eine Leitung als funktionstüchtig gilt und wie oft der Router ein Ping sendet. Auch einen Timeout- und einen Retry-Parameter gibt er an.

Der »log« -Bereich der Konfigurationsdatei legt die maximale Größe der Logdateien und ihre Menge fest. Ändert sich sein Status, kann der Daemon E-Mails versenden. Die dazu nötigen Parameter gehören ebenfalls in die Konfigurationsdatei. Die letzten Parameter dienen als Startzähler für die Routingtabellen, Firewall-Marks und Prioritäten, die der Router automatisch festlegen soll.

Die notwendigen Mangle- und NAT-Regeln generiert das Skript ebenfalls auf Basis der Konfiguration. Die Installationsanleitung empfiehlt dem Softwareverwalter, diese mit einer bestehenden Konfiguration zusammenzuführen. Da der Router in der Infrastruktur meist auch die Rolle der Firewall übernimmt, ergibt das Sinn. Das Kommando

fault_tolerant_router generate_iptables

erzeugt die Regeln im »iptables-save« -Format.

Damit eventuell nachgelagerte Router keine Konfiguration benötigen, die den FT-Router berücksichtigt, nattet der Netzwerker alle ausgehenden Sessions auf jeder Schnittstelle entsprechend der IP-Adresse der Schnittstelle. Dann startet er den Überwachungsprozess mit dem Kommando »fault_tolerant_router monitor« . Setzt er zusätzlich die Option »–debug« ein, sieht er auf der Konsole im Detail, welche Routen der FT-Router aktiviert und wie die verschiedenen Funktionstests ausgehen.

Dreispurig

Das Linux-Magazin hat den FT-Router mit drei Uplinks in einer KVM-Umgebung getestet. Die VMs waren über Open Vswitch verbunden, das auch zum Einsatz kam, um die Bandbreiten auf den Uplinks des Routers zu beschränken. So lassen sich typische Bandbreitenmuster im Consumer-Bereich nachstellen. Abbildung 3 zeigt eine Skizze des Netzwerks. Über »wget« starteten die Tester anschließend Downloads vom Webserver.

Abbildung 3: Schematisch sieht das mit dem Fault Tolerant Router aufgebaute Testnetzwerk in etwa so aus.

Auf der Schnittstelle zwischen Client und dem FT-Router lauschte zeitgleich ein »iptraf-ng« . Das zeigte: Sequenziell gestartete »wget« -Aufrufe liefen aufgrund der Sessionverteilung nacheinander mit den zugeordneten Bandbreiten. Stießen die Tester mehrere Downloads zugleich an, aktivierte dies alle Leitungen. Auf der Strecke zwischen Client und FT-Router verzeichnete der Traffic-Detektor eine Auslastung der ganzen Bandbreite.

Im nächsten Schritt blockierten die Tester eine der Leitungen. Der über sie laufende Download blieb daraufhin hängen. Bis der Daemon den nächsten Pingtest startete, wurden auch Neuverbindungen, die normalerweise über diese Leitung gelaufen wären, nicht etabliert.

Erst als der Daemon die Leitung aus der Rotation nahm, funktionierten alle Verbindungsaufbauten wieder. Nun aktivierten die Tester die Verbindung erneut. Nach einem weiteren Pingzyklus ließ sich die Leitung wieder normal nutzen.

Fazit

Bekommt ein Admin die Aufgabe, eine Anbindung zu schaffen, bei der die Anwender Ausfälle niemals bemerken, weil die Technik sie in Millisekunden kompensiert, ist der FT-Router die falsche Wahl. Doch für Admins, die mit beschränkten Mitteln Ähnliches vollbringen sollen und deren Nutzer bei einem zweistelligen Betrag im Monat auch Wartezeiten hinnehmen, bietet der FT-Router eine einfach aufsetzbare Lösung. Diese nutzt zudem alle Leitungen gemeinsam, wenn keine Ausfälle vorliegen. Sind die Leitungen unterschiedlich schnell, kann ein Download aber erheblich länger dauern, wenn er über die langsamste Leitung läuft. Der Admin kann hier zwar mit Gewichten gegensteuern, dieses Verhalten aber nicht vollständig ausschließen.