[ Main | Local ]

Viele Leute stecken in ihren Server zwei NICs (Netzwerkadapter). Diesen vergeben sie Adressen im selben Subnetz, also z.B. 192.168.140.5/24 und 192.168.140.6/24 (also die Rechner 5 und 6 auf dem Netz 192.168.140).

Sie erwarten jetzt, das sich der Verkehr dieser Maschine gleichmäßig auf die beiden Interfaces verteilt, und zwar in beide Richtungen. Dazu versuchen sie, zwei Routen auf dasselbe Netz oder sogar zwei Default-Routen anzulegen. Diese Versuche scheitern grandios.

Das hat sich mittlerweile zum besseren gewendet - alle gängigen Unix Systeme sind in der Lage, mehrere Routen gleicher Eigenschaften zum selben Ziel zu verwalten. Das folgende Problem taucht also bei aktuellen Systemen nicht mehr auf.

Eigentlich ist es TCP/IP und dem Betriebssystem völlig egal, wieviele Interfaces man in einer Maschine für ein Subnetz anlegt. Es gibt keine Fehlermeldung, und auch sonst keine Probleme mit der Funktion.

Allerdings funktioniert es auch nicht so wie meist erwartet. Das liegt an der Art, wie IP das Routing durchführt, speziell am Aufbau und Beschickung der Routing Table des Kernels. Genaues steht im Stevens, Implementation of the TCP/IP Stack (Band 2) oder auch in McKusick, The Design and Implementation of the 4.4 BSD Operating System.

Die Routing Table ist, um den Zugriff möglichst schnell zu gestalten, als binärer Baum angelegt. Die Blätter des Baumes sind Zieladressen, also Hosts oder Netze, während alle Zwischenschritte Verzweigungen darstellen. Eine gesuchte Adresse wird binär dargestellt, und dann wird das erste Bit mit der Spitze des Baumes verglichen; ist es 0, so geht es in die Verzweigung nach links, andernfalls nach rechts. Dieser bitweise Vergleich endet mit der größtmöglichen Übereinstimmung zwischen den Einträgen im Baum und der gesuchten Adresse. Das Paket wird dann auf der gefundenen Route befördert.

Technisch bedeutet das, daß es für einen Weg immer nur eine Route geben kann - entweder eine Host-Route oder eine Netz-Route. Dieser Suchalgorithmus läßt keine Alternativen zu.

Daraus folgt praktisch, daß man zu einem Ziel keine zwei Routen einrichten kann. Der Routing-Algorithmus findet an der angegebenen Stelle schon eine Verzweigung oder ein Blatt und verweigert den Eintrag der Route.

Gehen wir davon aus, das diese Person folgendes getan hat: Auf dem Server sind 4 Interfaces eingebaut und definiert, mit IPs im selben Subnetz. Auf je einem Viertel der Clients ist eine Hostroute zu je einem der Interfaces des Servers definiert. Es wird erwartet, das der Verkehr mit den vier Client-Gruppen über das zugeordnete Interface läuft.

Da wir jetzt wissen, wie die Routing Table funktioniert, ist auch klar, was passiert: Der Verkehr vom Client zum Server fließt brav über das zugeordnete Interface - der Client schaut in seine Routing Table, findet die Host-Route und sendet los. Der Verkehr vom Server zum Client fließt jedoch nur über ein Interface des Servers! Und zwar das, was zuerst eingerichtet wurde. Beim booten der Maschine hat ifconfig das erste Interface hochgefahren und eine Route ins lokale Netz angelegt. Damit ist dieser Punkt im binären Baum belegt. Beim hochfahren der anderen Interfaces wurde die Route gecheckt, und da sie existiert keine neue eingerichtet. Wenn jetzt der Server in beliebiges Paket auf das lokale Netz schicken möchte, schaut der in die Routing Table, findet die Route und das eine Interface und sendet sein Paket darüber.

Einmal kann es Situationen geben, in denen man damit leben kann. Wenn z.B. 90% des Verkehrs vom Client zum Server ist, dann hat man kein Problem.

Sind die Clients alle auf dem lokalen Netz, dann kann man Host-Routen auf dem Server für jeden Client anlegen und diese an ein Interface binden. Das geht jedoch nicht, wenn man über ein Gateway muß, denn dann schlägt das Problem wieder zu: man kann nicht 4 identische Routen zum Gateway einrichten, genauswenig wie man mehrere Default-Routen einrichten kann.

Man kann auf dem selben Medium mehrer logische Subnetze fahren; für jede Client-Gruppe eines. Dann würden die Routen in ein unabhängiges Netz zeigen.

Unter Umständen - und nicht mit jedem Unix - kann man folgenden Trick anwenden; wobei es hier nur um eine Notmaßnahme geht, wenn ein Gateway kaputt geht:
route add -net 0.0.0.0 -netmask 128.0.0.0 xx.xx.xx.xx
route add -net 128.0.0.0 -netmask 128.0.0.0 xx.xx.xx.xx
route add -net 0.0.0.0 -netmask 0.0.0.0 bb.bb.bb.bb
Dabei ist xx.xx.xx.xx das Hauptgateway, und bb.bb.bb.bb das Backupgateway.

Mit AIX5L sind beide Probleme angegangen worden. Es existiert einmal die Möglichkeit, zwei Default-Gatewayrouten einzurichten, die dann im "Round Robin" Verfahren angesprochen werden. Ausserdem gibt es die Möglichkeit der Entdeckung toter Gateways (Dead Gateway Detection).

Zwei Routen zum selben Ziel: Im SMIT gibt es ein neues Feld, indem man ein Interface, an das man die Route binden möchte, angeben kann. Dasselbe erzielt man mit dem -interface Parameter, wenn man das route-Kommando benutzt. Die Funktion dieses Befehls ist offensichtlich erweitert worden. Wenn man eine Route in dasselbe Netz an ein anderes Interface bindet, so wird das für den Such-Algorithmus offensichtlich unterscheidbar, und das gewünschte Verhalten tritt ein. Soweit ich es überblicke, ist aber "round robin" das einzige Verfahren, es werden also alle Interfaces gleich ausgelastet, der Verkehr einer Client-Gruppe ist nicht auf ein Interface beschränkt. (Das könnte man über Routing-Gruppen erreichen...).

Dead Gateway Detection (DGD): Hier finden sich zwei Spielarten, passive und aktive DGD.

• Passives DGD: Wird über einen Satz an no-Parametern konfiguriert: passive_dgd, dgd_packets_lost und dgd_retry_time. Nähere Informationen dazu in Tcp-ip, AIX-Tuning. Kann nach einem Gateway nicht mehr gearped werden, (dgd_packets_lost Versuche, das zu tun) dann wird die Metric der Route hochgesetzt. Nach einer Zeit von dgd_retry_time wird die Metric wieder "normal" gesetzt, also es wird nochmal versucht. Dasselbe passiert, wenn eine TCP-Verbindung diese Anzahl an Paketen verliert.

• Aktives DGD: Wird mit dem route-Kommando pro Route festgelegt; das Keywort ist -active_dgd. Dadurch wird das Gateway dieser Route alle dgd_ping_time Sekunden angepingt, bleiben die Antworten aus, dann wird wie oben vorgegangen, also die Metrik hochgesetzt, bis wieder Kontakt entstanden ist.

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]