Nicht ganz so optimale Wege durch OSPF

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.