Von einer CE-RIP-Route zu einem entfernten VRF: wo der Export geschieht

Ein RIPv2-Update trifft am Provider-Edge ein, landet in einer VRF-Routing-Tabelle und bleibt dort stehen, sofern es nicht etwas ausdrücklich exportiert. Drei Entscheidungen folgen aufeinander, und jede kann das Präfix aus eigenem Grund ablehnen. Genau das Lesen als ein einziges Ereignis führt dazu, dass Leute die falsche Kiste suchen, wenn ein entfernter Standort ein Netz nicht erreicht, das der CE eindeutig bewirbt. Folgen Sie der Route durch den PE, und die Abfolge wird offensichtlich.

Was der PE mit einem RIP-Update macht

Der PE nimmt das Update auf dem VRF-Interface entgegen, prüft, ob die Quelle ein erlaubter Nachbar ist, und installiert das Präfix mit einer aus der Ankündigung abgeleiteten Hop-Zahl in die VRF-Routing-Tabelle. Diese Tabelle ist eine normale Routing-Tabelle mit eigenen administrativen Distanzen und eigener Best-Path-Wahl. Bewirbt der CE dasselbe Präfix zweimal mit unterschiedlichen Metriken, überlebt nur das bessere in der Tabelle. Nichts an diesem Schritt betrifft das Backbone des Providers.

Das Präfix existiert nun im Routing-Kontext eines einzelnen Kunden, was weit davon entfernt ist, irgendwo sonst erreichbar zu sein.

Export ist ein politischer Akt, keine Protokollfolge

Um das VRF zu verlassen, muss eine Route in den MP-BGP-Prozess umverteilt werden, der VPN-Routen trägt, und sie braucht eine erweiterte Route-Target-Community, die festlegt, welche entfernten VRFs sie importieren dürfen. Die Architektur in RFC 4364 hält diese Austausche genau deshalb vom CE-zu-PE-Protokoll getrennt. RIP an der Kante einzusetzen sagt nichts darüber aus, was das Providernetz überqueren soll.

Schreiben Sie den Export-Vertrag auf, bevor Sie irgendetwas konfigurieren: die Kundenpräfixe, die remote erreichbar sein müssen, die Routen, die lokal bleiben müssen, und etwaige Defaults, spezifischere Routen oder Ausnahmen für gemeinsame Dienste. Gleichen Sie diesen Vertrag mit dem tatsächlichen VRF ab, nicht mit einem ähnlich benannten eines anderen Kunden.

Die Importseite ist eine zweite Policy mit eigenen Route-Targets, und ein passender Export mit einem nicht passenden Import erzeugt ein Präfix, das im Backbone existiert und in keiner entfernten Tabelle erscheint.

Umverteilung und explizite Herkunft verhalten sich unterschiedlich

Umverteilung nimmt Routen, die bereits in der VRF-Tabelle stehen, und kopiert sie über eine Routen-Map gefiltert in BGP. Die Map entscheidet, welche Präfixe zulässig sind und welche Attribute sie tragen, und die Metrik muss ausdrücklich gesetzt werden, weil eine RIP-Hop-Zahl als BGP-Metrik keine Bedeutung hat. Was Sie ungesetzt lassen, wird auf eine Weise vererbt, die die Person, die die Konfiguration ein halbes Jahr später liest, gewöhnlich überrascht.

Die gegenseitige Umverteilung ist der Ort des stillen Schadens. Ein nach BGP exportiertes Präfix kann über einen zweiten Umverteilungspunkt zurückkommen, und ohne Tags oder Filter schwingt die Route, während beide Tabellen in jedem Moment plausibel aussehen. Filtern Sie an der Kante gesetzte Tags, statt darauf zu vertrauen, dass die Topologie den Rückweg verhindert.

Explizite Herkunft wirkt aufgeräumter und ist nicht bedingungslos. Eine Netzwerk-Anweisung braucht normalerweise eine passende Route in der Routing-Tabelle, bevor das Präfix entsteht, sodass die Ankündigung in dem Moment verschwindet, in dem der CE sie nicht mehr bewirbt. Das ist oft das gewünschte Verhalten und nicht dasselbe wie eine statische Route, die für immer konfiguriert bleibt. Prüfen Sie die tatsächliche Regel der Plattform, statt eines der beiden Verhalten anzunehmen.

So oder so lautet die Frage zu jedem Präfix, welche aktive Quelle es zulässig macht und was passiert, wenn diese Quelle verschwindet.

Prüfen Sie die Kette an vier Stellen

Sehen Sie sich die CE-Ankündigung, die VRF-Routing-Tabelle, die VPN-Routentabelle mit ihrem Route-Target und den Import im entfernten VRF an, in dieser Reihenfolge. Auf IOS heißt das die Ausgabe des CE-Nachbarn, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, und denselben Befehl am fernen PE. Auf IOS-XR liegt die entsprechende Ausgabe unter show bgp vrf CUSTOMER ipv4 unicast. Die Befehlsnamen unterscheiden sich, die vier Prüfpunkte nicht.

Prüfen Sie ein Präfix, das abgelehnt werden soll, genauso sorgfältig wie eines, das durchkommen soll, denn eine Policy, die alles erlaubt, sieht bis zur ersten Ausnahme identisch mit einer korrekten aus. Beobachten Sie dann einen Rückzug: Schalten Sie das CE-Interface herunter und bestätigen Sie, dass der entfernte Eintrag innerhalb des erwarteten Timers verschwindet statt zu bleiben.

Halten Sie fest, wem welche Policy gehört. Betreibt der Provider den CE, gehört das gelieferte Verhalten in den Servicevertrag, und ein anderes Protokoll oder eine andere Rückzugs-Policy auf dem verwalteten Gerät ist ein Dokumentationsproblem, bevor es ein Routingproblem ist.