WAN-Umstellung: Totalausfall durch falsches IP-Design

Kommentieren Drucken

Der Glaube, eine Umstellung der WAN-Technik von Standleitungen auf MPLS wäre nur eine Sache der Provider und der richtigen SLAs, ist ein weit verbreiteter Irrglaube. Vielmehr müssen Netzwerk-Betreiber auch das eigene Netz in allen Standorten unter die Lupe nehmen, um sicher zu stellen, dass es nicht zu einem Totalausfall kommt.

Lange Zeit war eine sternförmige WAN-Struktur üblich. In deren Zentrum stand das Rechenzentrum, an das die Zweigstellen angeschlossen waren. Eine solche Struktur ermöglicht ein sehr einfaches IP-Design:

  1. jeder Standort bekommt seinen Bereich des IP-Netzes;
  2. nur das RZ muss alle Teilnetze kennen;
  3. die Zugangsrouter in den Standorten haben eine Default-Route zum RZ.

Selbst wenn man wie in Bild 1 zwei Rechenzentren oder mehr hat, bleibt das IP-Design überschaubar. Standorte, die an mehrere Rechenzentren angeschlossen sind, müssen neben der Default Route nur die Teilnetze der Rechenzentren kennen, damit sie den effektivsten Weg zum adressierten Server finden.

Wenn man schon immer sauber gearbeitet hat und insbesondere den ersten Punkt (ein Netzbereich pro Standort) eingehalten hat, dann hat man auch bei der Einführung von MPLS wahrscheinlich wenig Probleme. Oft ist das aber nicht der Fall:

  • Standorte sind gewachsen. Es wurden weitere IP-Netze hinzugefügt, die aber eigentlich gar nicht zu den bereits dort vorhandenen passten. Ein typisches Beispiel dafür ist die Einführung für VoIP, wo plötzliche viele weitere IP Adressen notwendig wurden.
  • Geographische Gegebenheiten führen dazu, dass nicht jeder Standort direkt an ein Rechenzentrum angeschlossen ist, sondern der Anschluss über eine in der Nähe liegende Zweigstelle realisiert wurde.
  • Sonderfälle wurden eingeführt, die sich nicht an den Regeln für ein sauberes IP-Design orientierten, sondern an organisatorischen Gegebenheiten. Da braucht man gar nicht zu den Server-Administratoren oder Software-Entwicklern rüber schielen, Netzwerker machen das auch gerne. Sie geben jeder Layer-3 Komponente, wie Routern und Layer-3-Switches, Loopback IP Adressen mit einer 32er Maske, die alle aus einem einzigen Subnetz stammen. Und das am liebsten gleich Standort-übergreifend.

Man könnte diese Aufzählung endlos fortsetzen. Was allen diesen Ausnahmen gemeinsam ist: sie erhöhen die Größe der Routing-Tabellen. Bei der (doppelten) Sternstruktur ist das unproblematisch: die Zugangsrouter und Layer-3-Switches der Rechenzentren sind leistungsfähige Maschinen, die das locker wegstecken.

Problematisch wird es mit dem Wechsel zu einer neuen WAN-Technik, die nicht mehr Punk-zu-Punkt, sondern Punkt-zu-Mehrpunkt arbeitet. Bei der es also möglich ist, Pakete über das WAN ohne Zwischenstopp im Rechenzentrum von einem Standort zu einem anderen zu schicken. Ein Beispiel für eine solche Technik ist MPLS (vgl. Abbildung 2) und ein Beispiel für eine solche Anwendung ist der Datenstrom bei VoIP von Telefon zu Telefon.

Jetzt müssen nicht mehr nur die Rechenzentrumsrouter alle Netzbereiche der verschiedenen Standorte kennen, jetzt muss das jede Layer-3-Komponente in allen Standorten. Und was ein Rechenzentrumsrouter ohne Probleme erledigt, wird bei den „kostengünstigen“ Geräten in vielen Zweigstellen zu einem Problem: die schiere Anzahl der zu lernenden IP-Netze.

Moderne Routing-Protokolle sind von Natur aus speicherhungrig. OSPF beispielsweise generiert nicht nur eine Routing-Tabelle, sondern benötigt auch Platz für die Topologie Datenbank. Verglichen mit dieser ist der Speicherbedarf für die Routing-Tabelle gering. So richtig „heiß“ wird es aber erst, wenn sich etwas ändert: der von OSPF genutzte Dijkstra-Algorithmus, um aus der Topologie-Datenbank die Routing-Tabelle zu berechnen, ist rekursiv. Cisco gibt beispielsweise als Daumenregel an, dass man 4x so viel freien Speicher für die Ausführung des Algorithmus benötigt wie für Routing-Tabelle und Topologie-Datenbank zusammen.

Gibt es nun „irgendwo“ einen Router, der an der Berechnung scheitert, kommt es zur Katastrophe. Wie diese genau aussieht, lässt sich schwer vorhersagen, da es zu einem Zustand kommt, den der Standard nicht vorsieht und es somit den Entwicklern überlassen bleibt, damit umzugehen. Im günstigsten Fall würde der Router einfach die Arbeit einstellen. Das wäre zwar schlecht für alle, die den Router brauchen, aber gut für alle anderen. Bedeutend fataler ist der wahrscheinlichere Fall: der Router vergisst einfach alles und fängt noch mal von vorne an. Er baut seine Nachbarschaftsbeziehungen neu auf, bevölkert seine Topologie-Datenbank.

Durch den Wegfall und das Wiedererscheinen des Routers in deren Topologie-Datenbanken aller anderen Router müssen auch diese ihre Routing-Tabellen zweimal neu berechnen (1x Wegfall, 1x Wiederauftauchen). Da der Router wegen mangelndem Speicher versagt hat, wird er erneut scheitern und das Spiel beginnt von vorne.

Das Troubleshooting in so einem Fall macht ausgesprochen wenig Spaß, insbesondere weil durch den dauernden Wegfall von Routen die eigentliche Komponente vom RZ aus auch gar nicht erreichbar ist.

Welche Maßnahmen kann man nun treffen, um diesen Fall zu verhindern:

  1. Anzahl zu routender Teilnetze weitestgehend reduzieren.
    Je nach Routing-Protokoll durch Route-Aggregierung und/oder Area-Bildung. Ggf. ist sogar ein IP-Redesign erforderlich.
  2. Nicht alle Standorte geleichzeitig umstellen.
  3. Nach jeder Umstellung die Speicherauslastung der einzelnen Komponenten prüfen.
  4. Bei neuen Geräten ggf. Speicher aufrüsten. Alte Geräte gleich ganz austauschen.
zugeordnete Kategorien: IP und IPv6, LAN
zugeordnete Tags: ,

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.