Komplikationen in der OSPF Umstellung
Wie angekündigt, wurde in einem Kundennetz das OSPF komplett umgekrempelt. Dabei gab es mehrere Überraschungen, die mit zwei ernsthaften Zwischenfällen einher gingen. Ein Rückblick.
Vorgehensweise
Der geplante Ansatz war, das Routing der BGP-Außenrouter untereinander in eine extra OSPF Instanz zu verschieben und die Default-Route in die jeweilige Standort-Area einzuspeisen, sowie die notwendigen Routen aus der Standort-Area zu lernen.
Dieser Teil des Konzeptes wurde wie folgt geändert:
- Die BGP-Außenrouter kommen in die Area 0 statt in die Standortareas. Hintergrund ist, dass das Erlernen der (meist statischen) Routen aus einer normalen Area heraus nicht möglich ist, da redistributierte Routen im OSPF area-übergreifend sind.
- Anstatt die Loopback-IPs der BGP-Außenrouter zwischen zwei OSPF-Instanzen zu redistributieren, wurde die Verbindung der BGP-Außenrouter untereinander in eine extra Area verschoben, deren Intra-Area-Routen gegenüber den anderen OSPF-Routen stets bevorzugt wird. Damit ist die Routing-Trennung erfolgreich durchgeführt.
- Um die Standorte zu trennen wird auf den Leitungen zwischen den Standorten eine OSPF-Cost von 1000 eingetragen. Lokale verfügbare Routen haben damit eine Metrik von kleiner 1000 und können per "match metric 450 +- 500" in route-maps leicht erkannt werden.
Die Umstellung erfolgt schrittweise:
- Die aktuelle Redistribution von OSPF nach BGP wird von Standortinformationen befreit. Alle Routen werden an allen Standorten weiter injeziert. Damit kann man umbauen, ohne die Außenverbindung zu verlieren.
- Die Standort-Router wandern zusätzlich in die Area 0, ohne die Standorte direkt miteinander zu verbinden. Auf diese Weise bleibt das Routing über die BGP-Außenrouter bestehen.
- Aggregierung verschiebt sich von den BGP-Außenroutern zu den Standort-Routern.
- Die BGP-Außenrouter verlieren ihre Verbindung in die jeweilige Standortarea. Sie kommunizieren nun nur noch über die Area 0.
- Die für das BGP benötigten Interfaces (Loopback) wandern in eine neue Area, die aktuell fragmentiert ist. Da über die Area 0 aber nur Interarea-Routen ohne Angabe der originalen Area-Nummer verteilt werden, bekommen die Router weiterhin ihre BGP-Nachbarn erlernt.
- Die BGP-Außenrouter werden nach und nach mit extra VLANs zu einer eigenen OSPF-Wolke verbunden. Sie erreichen nun ihre BGP-Nachbarn direkt über diese neue OSPF-Area, nicht mehr über die Area 0.
- Die Area 0 kann zwischen den Standorten direkt verbunden werden. BGP-Quertraffic geht ja nun nicht mehr über diese Area.
- Die Area 0 zwischen den BGP-Außenroutern wird entfernt. Sie reden nun in der Area 0 nur noch mit den jeweiligen Standort-Routern.
- Die Kosten auf der Querverbindung der Standorte werden angehoben. Man kann nun anhand der Metrik die Lokalität der Routen erkennen.
- Routen aus dem OSPF werden nun anhand der Metrik gefiltert, so dass der alte Zustand (lokale Routen am Standort announcen) wieder hergestellt ist.
Soweit der Plan. Aber in der Praxis sieht das alles noch etwas anders aus.
Überraschungen
Zunächst einmal ist fest zu stellen, dass der oben stehende Plan sich erst während der Umstellung heraus bildete. Jeder einzelne Schritt wurde in der Praxis so ausgeführt, dass das Monitoring des gesamten Netzes auf sehr feine Details achten konnte. So wurde binnen einer Minute erkannt, wenn mehr als 10 von 70000 versorgten Endgeräten unzureichende Kommunikation hatten.
Um sich nicht selbst abzuschießen, erfolgte der Management-Zugriff bei IPv4 Änderungen über IPv6 und umgekehrt. (Vorzugsweise gibt es Management nur über IPv6.)
Der Ablauf des Umbaus war also folgendermaßen:
- Vornehmen einer einzelnen Änderung an einem einzelnen Gerät.
- Beobachten des Monitorings für ca. 10 min.
- Gibt es einen Abfall, wird die Änderung zurück genommen. Kehrt das Monitoring zu normalen Werten zurück, muss man nachdenken, was man gerade falsch gemacht hat.
- Bleibt der Abfall bestehen, wird rumtelefoniert, ob jemand anders am Netz ebenfalls Änderungen vornimmt oder ungeplanten Ausfälle erkennbar sind. Ist das der Fall, wird Stabilität im Netz abgewartet und die Änderung nochmal versucht.
Auf diese Weise hat sich der Umbau über fast zwei Wochen hin gezogen. Dabei durften Zwischenstände mit massiv eingeschränkter Performance (wenn der gesamte Traffic nur über eine statt vier Leitungen läuft) nicht über die Hochlastzeiten bestehen bleiben.
Einer der Fälle, die auf diese Weise aufgefallen ist, war: Man trenne die Area0 zwischen den BGP-Routern nicht, bevor es eine direkte Area0 Kopplung der Standorte gibt!
Aber es gab auch schwerere Fälle, die besonders lehrreich sind.
Zum einen hatten wir einen Standort-Router mit einer kaputten OSPF-Datenbank.
Das ist im Normalbetrieb nicht aufgefallen, als aber größere Umstellungen passierten, routete er nicht so, wie man es erwarten sollte. Es gab Kreisrouting und Paketverlust. Nach einem ganzen Tag ständiger Versuche, konnte der Übeltäter eingekreist werden. Ein beherztes "clear ip ospf process" am kommenden Morgen brachte spontane Besserung. Alle bis dahin unerklärlichen Vorfälle waren verschwunden und die Konfigurationsänderungen zeigten die erwünschte Wirkung.
Da nicht alle Geräte zur gleichen Zeit einer Änderung folgen konnten, wurde die Umstellung durch Aufbau von parallelen Verbindungen nach einem neuen VLAN-Konzept durch geführt. Dabei wechseln die beteiligten Geräte einzeln in ein neues VLAN mit neuen IP Adressen. Viele Point-to-Point Verbindungen sind jedoch als "unnumbered" Interface ausgeführt um Adressen zu sparen.
Der interessante Effekt tritt auf, wenn das referenzierte Interface seine iP-Adresse verliert (durch den Umzug auf ein anderes VLAN). In dem Fall bleibt das unnumbered Interface im OSPF aktiv in der Area. Es verbreitet weiter Routing-Informationen und spricht mit den OSPF Nachbarn. Sollen dann aber Datenpakete über dieses Interface geschickt werden, so verwirft der Cisco-L3-Switch diese Pakete kommentarlos. Das unnumbered Interface wird zum aktiven Blackhole. Erst, als das Interface auf shutdown gesetzt wurde, war der Spuk vorbei.
Weil's so wichtig ist, hier nochmal das Rezept:
- Man erzeuge ein VLAN zwischen zwei Geräten, dass "ip unnumbered xxx" als Point-2-Point Interface auf beiden Seiten eingerichtet wird.
- Man nehme das Interface XXX und damit das Vlan-Interface per "network"-statement ins OSPF auf.
- Man etabliere eine OSPF Kopplung über das VLAN-Interface zum Nachbarn.
- Nun lösche man die IP Adresse vom Interface XXX mit "no ip address".
- Das Vlan-Interface verbleibt voll funktional im OSPF: Es hält Nachbarschaftsbeziehungen und Routing-Updates aufrecht.
- Ein- und ausgehende Datenpakete über das Interface werden verworfen: Black Hole.
Die von dem Verhalten ausgehenden Störungen waren sporadisch, aber merkbar. Es hat ziemlich lange gedauert, das Phänomen zu verstehen und gezielt in Angriff zu nehmen. Auslöser der Erkenntnis war dann eine Fehlereingrenzung auf einen deutlich merkbaren, stabilen Stör-Pfad, bei dem Interfaces stückweise shutdown genommen wurden.
Und dann war da noch der wirklich heftige Ausfall, der einen Standort komplett erdete. An diesem Standort gab es noch Überreste einer älteren NSSA, die nun wirklich weg geräumt werden sollte. Aber wie wechselt man bei einem Gerät, das unter Last steht, die OSPF Area? In dem Fall handelt es sich um die Anycast-DNS Server, die mit vier externen Beinen sowohl ihre DNS Anfragen machen, als auch ihre OSPF-Uplinks bedienen. Die Interfaces auszuschalten, kam wegen der DNS-Nutzung nicht in Frage. So kam die Idee auf, diese Maschinen in zwei regionale Areas gleichzeitig zu stellen.
Grundsätzlich ist es möglich, einen Router in zwei Areas zu haben, auch wenn keine davon die Area 0 ist. Dies wird ausführlich in verschiedenen Design Dokumenten von OSPF diskutiert, und zwar wird dabei betont, dass dieser Router keine Routen von der einen in die andere Area weiter leiten wird. Das wäre ja sogar ein gewünschtes Verhalten. Die Software bird auf FreeBSD fand die Idee auch erstmal ganz gut und importierte aus beiden Areas die Routen.
Allerdings injezierte sie die nun widersprüchlichen Ziele für die exteren Routen nicht in die Kernel-Routing-Tabelle. Auf diese Weise verloren die DNS-Server ihre Default Route und konnten keine neuen DNS Namen mehr auflösen. Das fiel auf die Schnelle natürlich nicht auf, dann aber um so heftiger. Ohne DNS brach die Internet-Versorgung des Standorts zusammen.
Der Fehler war nach einer guten Viertelstunde behoben und der alte Zustand wieder her gestellt. Bis sich der Rest beruhigte, dauerte es noch ein wenig länger. Die eigentliche Lösung bestand dann darin, mit einem Schlag die Area zu wechseln. Das klappte dann problemlos.