Zwei PEs, ein Präfix: Warum der RD die Sichtbarkeit entscheidet

Zwei Edge-Router, die dasselbe Kundenpräfix annoncieren, beschreiben ein einziges VPNv4-Ziel, bis etwas sie trennt, und der Trenner ist der Route Distinguisher. Er qualifiziert das Präfix; er entscheidet nicht, wer das Ergebnis importiert, das ist Aufgabe des Route Targets. Vergeben Sie RDs aus der Menge der Routen, die in jeder Domäne unterscheidbar bleiben müssen, in der diese Annoncen aufeinandertreffen können, nicht aus dem Dateilayout einer einzelnen Box. Die Nummer, die Sie wählen, ist eine Identität, auf die sich spätere Reviews stützen werden, also gehört sie in ein Inventar, bevor sie in eine Konfiguration wandert.

Ein RD plus ein Präfix ist ein Ziel

Ein RD plus ein IPv4-Präfix bildet das VPNv4-Ziel, das die Control Plane vergleicht. Geben Sie zwei PEs dasselbe Präfix für verschiedene Kunden, und ohne unterschiedliche RDs annoncieren sie Pfade zu einem Ziel. Nichts auf einem Display sagt Ihnen, dass diese Gruppierung falsch ist, weil die Plattform genau das tut, was die Identität sagt. Ändern Sie den RD auf einem von beiden, und die alte Annonce wird zurückgezogen, während unter einer anderen Identität eine neue erscheint. Alles stromabwärts, das auf der alten Identität aufsetzte, von der Routenauswahl bis zu einem gespeicherten Operatorfilter, verweist jetzt auf etwas, das es nicht mehr gibt.

Mehrere Pfade pro Ziel sind normales BGP-Verhalten, kein Symptom. Ein Speaker kann mehrere empfangene Pfade halten, während er einen besten Pfad für die Weiterleitung auswählt, und die Lücke zwischen empfangen und ausgewählt ist der Ort, an dem Sichtbarkeitsfragen leben. Wenn ein Pfad verschwunden zu sein scheint, prüfen Sie zuerst, ob die Identität, zu der er gehörte, noch existiert, bevor Sie die Session ansehen.

Gleicher RD, gleiches Ziel, verschiedene Pfade

Senden Sie einen RD und ein Präfix von zwei Routern im Namen desselben Dienstes, und beide bieten Pfade zu einem Ziel an, meist mit unterschiedlichen Next Hops. Welchen davon ein Route Reflector weitergibt, ist eine Entscheidung über den Reflector: seine Pfadauswahl, seine Annonce-Fähigkeit und jede darüber gelegte Policy. Keiner der Edge-Router kontrolliert diese Wahl. Geben Sie den beiden Annoncen unterschiedliche RDs, und jede wird ihr eigenes Ziel, sodass beide eine Control Plane überstehen können, die sonst nur den ausgewählten Pfad für eine Identität trägt.

Sichtbarkeit und Multipath treffen sich in der empfangenden VRF, sind aber nicht dieselbe Entscheidung, und ein Reflector, der zwei Identitäten trägt, hat keinen zweiten installierten Pfad konfiguriert. Die VRF installiert was ihre Import-Policy zulässt und was ihre eigene Maximum-Path-Einstellung erlaubt. Prüfen Sie diese Einstellung separat, wenn der zweite Pfad genutzt und nicht nur sichtbar sein soll.

Eine lokale Eindeutigkeitsregel ist keine Policy

Jedem PE und jeder Routing-Instanz einen eigenen RD zu geben, ist eine solide Konvention: Er benennt den Ursprung, hält unabhängige Dienste davon ab, auf einer Identität zu kollidieren, und gibt dem Inventar einen stabilen Schlüssel. Manche Plattformen verlangen Eindeutigkeit nur innerhalb der Box und erlauben ausdrücklich, dass Router einen RD für dieselbe VPN-Instanz teilen. Diese Erlaubnis ist eine Implementierungsbedingung, keine netzwerkübergreifende Regel, die Sie an einen Hersteller delegieren können. Wenn die Domäne Teams umfasst, schreiben Sie die Vergaberichtlinie selbst.

Mitgliedschaft kommt nie aus den Ziffern. Ein Muster wie 65000:12 für ein PE und 65000:13 für ein anderes ist eine Gewohnheit, während passende Export- und Import-Targets wie 65000:112 das sind, was eine Route in eine VRF bringt. Behandeln Sie den RD als die Identität einer Route und das Route Target als die Erlaubnis, die sie in eine VRF trägt.

Belegen Sie die Änderung an der VRF, nicht am Display

Bevor Sie einen RD anfassen, schreiben Sie vier Dinge auf: was das PE heute annonciert, was der Reflector reflektiert, was die empfangende VRF importiert und welchen Pfad sie auswählt. Ein neuer RD zieht eine Annonce zurück und führt eine andere ein, also zeigt sich die Änderung auf beiden Seiten der Session und ist leicht falsch zu lesen, wenn Sie nur die annoncierende Seite beobachten. Abnahme sollte auf der gewünschten Erreichbarkeit beruhen, nicht auf einer zusätzlichen Zeile in einer Präfixliste. Die Tabelle unten hält die drei Bezeichner bei diesem Review auseinander.

Beginnen Sie am annoncierenden PE und vergleichen Sie beide Identitäten für dasselbe Präfix, bevor Sie etwas entfernen. Die IOS-Befehle unten beantworten drei Fragen der Reihe nach: Ist die alte Annonce noch da, ist die neue Identität für den Reflector sichtbar, und wählt die VRF das Präfix.

show bgp vpnv4 unicast rd 65000:12 203.0.113.0/24
show bgp vpnv4 unicast rd 65000:13 203.0.113.0/24
show ip route vrf CUSTOMER-A 203.0.113.0/24

Andere Plattformen geben dieselbe Information unter anderer Syntax aus, und die Fragen überstehen diese Änderung. Fehlt die neue Identität am Reflector, während das PE sie als annonciert listet, ist die Policy oder die Annonce-Fähigkeit des Reflectors der erste Verdacht, nicht die Nummerierung.

Halten Sie PE, Instanz, RD, Export- und Import-Targets und die Präfix-Inhaberschaft an einer Stelle fest, denn die nächste Vergabe ist nur dann ein Nachschlagen und keine Vermutung, wenn dieser Eintrag existiert. Behalten Sie den alten RD, bis die neue Identität in der empfangenden VRF sichtbar ist, und ziehen Sie ihn dann in einem zweiten Schritt zurück, damit jede Phase umkehrbar bleibt.