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:

1. 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.
2. 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.
3. Aggregierung verschiebt sich von den BGP-Außenroutern zu den Standort-Routern.
4. Die BGP-Außenrouter verlieren ihre Verbindung in die jeweilige Standortarea. Sie kommunizieren nun nur noch über die Area 0.
5. 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.
6. 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.
7. Die Area 0 kann zwischen den Standorten direkt verbunden werden. BGP-Quertraffic geht ja nun nicht mehr über diese Area.
8. Die Area 0 zwischen den BGP-Außenroutern wird entfernt. Sie reden nun in der Area 0 nur noch mit den jeweiligen Standort-Routern.
9. Die Kosten auf der Querverbindung der Standorte werden angehoben. Man kann nun anhand der Metrik die Lokalität der Routen erkennen.
10. 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.

Ein Kundennetz ist im Laufe der Zeit organisch gewachsen. Irgendwann kommt dann der Augenblick, wo man es in verschiedene Standorte trennen muss. Denn es gibt ungeplante Überlastungssituationen.

Ausgangslage

Das Netz besteht aus einigen Au0enroutern an den Rändern und innen aus einer Reihe von Layer3-Switchen. L3-Switche sind Geräte, die genauso schnell routen wie switchen können, allerdings nur mit einer beschränkten Anzahl von Routen, weil sonst die Hardwarekosten explodieren.

Seit einiger Zeit sind einige der Geräte an einen anderen Standort umgezogen. Nun kann man nicht mehr bei Bedarf einfach wild Querverbindungen zwischen den Geräten patchen. Es gibt drei Leitungen zwischen den Standorten sowie separate Uplinks und das war es.

Geroutet wird per OSPF. Streng nach Design Guide gibt es zwei lokale Areas, in denen Ziele bevorzugt direkt erreichen werden können. Und dazwischen gibt es eine Area 0, den Backbone, der alles aufnimmt, was in den einzelen Areas nicht zu finden ist.

Konsequenterweise ist die Area 0, also die Resterampe des Routings, die Quelle der Default Route, auch das Heim der BGP Router mit Außenanbindung. Diese kennen so viele Routen, dass man diese den Switchen keinesfalls  erzählen darf, sollen die nicht spontan an Herzdrücken versterben. So gesehen, sind die Außenrouter eigentlich in der Mitte des OSPF Protokolls.

Die Area 0, der Backbone, darf nicht mit seinen externem Routen die L3-Switche berühren. Denn diese würden die Pakete per Default Route einfach nur wieder zurück zum lokalen BGP Router schicken, und der wieder ... ein Routing-Loop. Deswegen besteht die Area 0 eigentlich aus switchübergreifenden VLANs, in denen die BGP-Router je ein Bein stehen haben.

Für das OSPF sieht es also so aus, als gäbe es drei LAN-Segmente, die die Router direkt miteinander verbinden.

In der Realität ist dem allerdings nicht so, denn die OSPF-Idee eines LAN-Segmentes kommt noch aus der Zeit des echten Ethernets, wo alle Geräte im wahrsten Sinne an einem gemeinsam genutzten Strang hängen. Dabei ist es komplett egal, wer mit wem redet, das Medium ist für alle gleich teuer in der Benutzung.

In der Realität der heutigen, strukturierten Ethernet-Verkablung sieht es allerdings ganz anders aus. Hier wandert ein Datenpaket zwischen zwei Routern in Form eines Ethernet-Frames mehrfach über verschiedene Leitungen, oft sogar mehrfach über die gleiche physikalische Strippe.

Eine solche Mehrfachbenutzung ist bei begrenzten Ressourcen ein Problem. Konkret aufgefallen ist es als sieben Gbps über mehrere Stunden transportiert werden mussten. Dann blieb auf den 10G-Leitungen der Router kaum noch was für anderen Traffic frei.

Lösungen

Die einfachste Lösung ist, neue Technik zu kaufen, die um den Faktor 4 oder 10 höhere Leitungskapazitäten anbietet. Leider versackte die Bestellung und wird auch so schnell nicht realisiert werden.

Eine zweite Lösung wäre, die Standorte als eigenständige BGP Inseln zu betreiben.

Das hält den Traffic lokal und der Datenverkehr zwischen den Bereichen lässt sich feingranular steuern. Selbst Loadbalancing über mehrere Wege ist kein Problem. Zusätzlich reizt an dem Ansatz, dass die extern sichtbaren Routen schon an der Stelle fertig im BGP erzeugt werden können, an den sie entstehen.

Leider fehlt für die Benutzung von BGP die Lizenz auf den L3-Switchen. Deren Beschaffung ist auch nicht so einfach, denn auch hier hängen Bestellprozesse dran.

Bleibt also nur der Versuch, die Datenflüsse innerhalb des OSPF selbst neu zu sortieren. Dabei gibt es einige grundlegende Konzepte:

• Die Area0 dient als Bindeglied zwischen den anderen Area.
• Traffic, der in einer Area zugestellt werden kann, verlässt diese Area nicht (intra-Area first).
• Traffic, den sich die BGP-Router gegenseitig zustellen, darf mit keinen anderen Routern in Berührung kommen.
• Traffic, der nicht extern zugestellt werden soll, soll schnellstmöglich an die L3-Switche übergeben werden.

Damit ergibt sich, dass das gesamte Netz auf den Kopf zu stellen ist:

• Die Area 0 kommt ganz nach innen, sie bildet die Standortkopplung.
• Pro Standort gibt es ein eigne Area, die den Traffic am Standort fest hält.
• Die BGP-Außenrouter gehören zwar zum Standort, den sie bedienen, kommunizieren aber untereinander über eine komplett eigene Struktur.

Die Interaktion zwischen den Außenroutern und der jeweiligen Area besteht grundsätzlich darin, dass die BGP-Router eine Default-Route in die lokale Area injizieren und aus der Area lernen, welche Netze in beiden Standorten bedient werden können.

Das Injizieren der Default-Route durch die BGP-Router in die jeweilge lokale Area ist kein Problem. Die BGP-Router werden somit zu ASBRs. Im Gegenzug werden alle Geräte am Standort zu einem lokal nahe gelegenen BGP-Router routen. Traffic, der das Netz verlässt, tut es am gleichen Standort.

Umgekehrt lernen die BGP-Router die internen Routen aus dem OSPF und können sie ins BGP redistributieren. Dabei setzen sie Communities etc. pp. Dies sind vor allem die extern sichtbaren Aggregates des Autonomen Systems. Erzeugt man die Aggragate (per Null-Route) lokale auf dem BGP-Router, besteht die Gefahr des Blackholings, insbesondere wenn der BGP-Router keine funktionierende Verbindung nach innen hat.

In der rot gepunkteten Area tauschen die BGP-Router untereinander ihre für die BGP relevanten Loopback-Adressen aus. Über diese sprechen sie internal BGP miteinander. Es sind die Next-Hop Adressen der externen Ziele, die ein BGP-Router anderswo los werden muss. Dabei gibt es einiges zu beachten:

• Die vom internen BGP erzeugten Routen haben als Next-Hop eine (Loopback-)IP die im rot gepunkteten Bereich auftaucht. Diese IPs dürfen keinesfalls durch das interne OSPF hindurch erreichbar sein, weil das zu Routing-Loops für externe Ziele führt.
• Die Loopback-IPs der BGP-Router sollen aus dem internen Bereich erreichbar sein,  auch wenn sie von einer internen Sammel-(Aggregate)-Route überdeckt werden.
• Bestimmte externe (Eyeball-)Ziele sollen auch standortübergreifend auf dem jeweils besten Weg erreicht werden. Diese Ziele sollen direkt zum zuständigen BGP-Router gelangen, nicht erst eine extra Runde im rot gepunkteten Bereich laufen müssen.

Um diese Anforderungen zu erreichen, muss man zwischen verschiedenen Routing-Protokollen redistributieren. Gleichzeitig, darf die rot gepunktete Area nicht einfach Bestandteil der gleichen OSPF Instanz sein, die auch die internen Areas bedient. Zwischen zwei nicht-backbone Areas, die am gleichen Router anliegen erfolgt kein Austausch von Routen, deswegen würden die Loopback-IPs nie in den internen Bereich gelangen. Mit zwei OSPF Instanzen geht das aber problemlos.

Die BGP-Router haben nur vier verschiedene Quellen für Routing-Informationen:

• externes BGP
• OSPF zwischen den BGP-Routern
• OSPF im internen Netz
• internes BGP

Externes BGP kann aufgrund der Eingangsfilter keine netzinternen Routen enthalten. Dieser Teil ist für (interne) Routingprobleme also irrelevant.

OSPF zwischen den BGP-Routern muss immer zuerst berücksichtigt werden. Egal welche Metriken eine Route hier hat, es ist ein BGP-Peer und damit auf diesem Weg zu erreichen. Anderenfalls gibt es Routingloops für externe Ziele.

Wenn ein anderes internes Ziel erreicht werden soll, dann ist das immer unmittelbar an die inneren Router abzugeben. Anderenfalls gibt es das eingangs skizzierte Problem der Überlastung von Leitungen.

Interne Ziele, die über iBGP (von anderen BGP-Routern gelernt und redistributiert) erreichbar sind, müssen zwar an externe Partner übermittelt werden, damit das Netz extern erreichbar bleibt. Traffic an interne Ziele sollten aber nur dann an andere BGP-Nachbarn geroutet werden, wenn man diese Ziele nicht über interne Wege erreichen konnte.

Es beitet sich also an, für das OSPF zwischen den BGP-Routern eine eigene Instanz zu betreiben. Aus dieser Instanz kann in die andere OSPF-Instranz redistributiert werden. Und diese wird mit einer niedrigeren administrativen Distanz versehen:

Und nun bleibt die Aufgabe, dieses Umstellung im laufenden Betrieb vor zu nehmen.