Fehlende Route in der VRF: lokal, VPNv4 oder Weiterleitungstabelle?

Ein Kunde meldet, dass ein Präfix nach einer Änderung am Route-Target fehlt, und der erste Screenshot, den er schickt, zeigt meist die falsche Tabelle. Drei verschiedene Tabellen beantworten drei verschiedene Fragen: ob das Präfix innerhalb der VRF existiert, ob es als VPNv4-Route angekündigt und importiert wurde und ob tatsächlich ein Weiterleitungseintrag installiert wurde. Wer sie in falscher Reihenfolge liest, kommt zu sicheren falschen Schlüssen. Dieser Runbook führt ein lokales und ein entferntes Präfix in dieser Reihenfolge durch alle drei Tabellen und endet mit einem Rückrollplan für die RT-Änderung, die das ausgelöst hat.

Benennen Sie das Präfix und die Tabelle, in die es gehört

Notieren Sie zwei Präfixe, bevor Sie etwas eintippen. Eines ist lokal am Kundenstandort und wurde über eine angeschlossene Schnittstelle oder eine CE-Ankündigung gelernt. Das andere ist entfernt und soll über das Backbone des Anbieters eintreffen. Sie nehmen verschiedene Wege in dieselbe VRF, und ein Fehler im einen sagt nichts über den anderen aus.

Halten Sie die Unterscheidung zwischen den beiden Identifikatoren sauber, denn daraus entsteht der meiste Wirrwarr in diesen Tickets. Der Route Distinguisher ist Teil der VPNv4-NLRI und existiert, um ansonsten identische Kundenpräfixe über das Backbone hinweg eindeutig zu machen. Das Route-Target ist eine erweiterte Community, die als Attribut übertragen wird, und darauf gleicht die Import- und Exportrichtlinie ab. Es ist kein zweiter Name für den Distinguisher und es wird nicht in den Paketen des Kunden übertragen.

Schritt 1: Beweisen Sie, dass das Präfix in der VRF ist

Beginnen Sie mit der lokalen Sicht, dann mit den RTs, die den Import steuern. Fehlt das lokale Präfix hier, kann nichts weiter oben schuld sein:

show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A

Ein Präfix, das als angeschlossen oder statisch erscheint, ist lokal gelernt, und seine Anwesenheit sagt nichts darüber aus, ob es exportiert wurde. Das ist die häufigste Fehldeutung in diesem Ablauf: Eine gesunde VRF-Tabelle ist nur ein Beleg für lokales Lernen. Die Exportseite ist eine eigene Frage, die die Nachbarsicht und das angehängte Export-Target beantworten.

Prüfen Sie die RT-Listen an der VRF, solange Sie hier sind. Steht das beabsichtigte Import-Target nicht auf der Liste, ist alles dahinter irrelevant. Ist es vorhanden, weicht aber von dem ab, was der entfernte PE exportiert, haben Sie den Fehler gefunden, ohne einen einzigen Paketmitschnitt zu öffnen.

Schritt 2: Lesen Sie die VPNv4-Tabelle und ihre Targets

Die VPNv4-Tabelle zeigt, was die Steuerungsebene tatsächlich ausgetauscht hat. Suchen Sie das entfernte Präfix unter dem richtigen Distinguisher und sehen Sie dann auf die angehängten Communities:

show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes

Ein Eintrag mit dem richtigen Route-Target, aber ohne lokale Installation, deutet auf die Importrichtlinie oder die Routenauswahl hin, nicht auf Erreichbarkeit. Ein Eintrag, der gar nicht in der VPNv4-Tabelle erscheint, deutet nach oben: Vielleicht hat der Ursprungs-PE ihn nicht exportiert, oder die Sitzung trägt die Adressfamilie nicht.

Es gibt einen dritten Fall, der Leute bei Änderungen aus dem Tritt bringt. Manche Plattformen begrenzen, welche VPN-Routen sie anfordern oder behalten, anhand von Mitgliedschaftsinformationen zu Route-Targets, daher ist die Abwesenheit einer entfernten NLRI in einer gefilterten Ansicht kein Beweis, dass die Ankündigung nirgends existiert. Prüfen Sie die ungefilterte Tabelle und die angekündigten Routen des Nachbarn, bevor Sie schließen, dass eine Route global zurückgezogen wurde.

Schritt 3: Bestätigen Sie, dass etwas installiert und gelabelt wurde

Ein BGP-Eintrag ist eine Entscheidung, kein Weg. Die Weiterleitungstabellen sagen, ob Pakete irgendwohin können:

show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A

Ein CEF-Eintrag mit aufgelöster Nachbarschaft und ausgehendem Label bedeutet, dass Datenverkehr funktionieren sollte, und jedes verbleibende Symptom gehört zur Anwendung oder zur Filterung innerhalb der VRF. Ein CEF-Eintrag mit unaufgelöstem nächsten Hop bedeutet, dass der Labelpfad unvollständig ist, obwohl BGP gesund aussieht, und genau dieser Fall ist es, in dem ein Screenshot der BGP-Tabelle eine Änderungsprüfung in die Irre geführt hat.

Vergleichen Sie das Label, das der lokale PE aufprägt, mit dem, das der entfernte PE zu empfangen erwartet. Eine Abweichung zwischen beiden Ansichten ist ein Problem der Labelzuweisung oder der Sitzung, und sie lässt sich nicht durch Ändern von Route-Targets beheben, egal wie oft Sie es tun.

Rollen Sie die RT-Änderung mit erklärtem Umfang zurück

Wenn der Fehler mit einer Route-Target-Änderung begann, machen Sie sie als einen bewussten Schritt rückgängig und sagen Sie, welchen Umfang Sie ändern. Ein Import-Target zu entfernen nimmt die Berechtigung innerhalb dieser VRF zurück. Es löscht die VPNv4-Ankündigung nicht aus dem Backbone, und auf manchen Plattformen bleibt die Route in der Tabelle gehalten. Das sind verschiedene Ergebnisse, und die sichtbare Wirkung hängt davon ab, welches Sie meinen.

configure terminal
vrf definition CUST-A
 address-family ipv4
  no route-target import 65000:410
 end
clear ip bgp vpnv4 vrf CUST-A soft in

Eine weiche eingehende Rekonfiguration reicht, wenn die Sitzung die Präfixe bereits speichert; ein harter Reset einer anbieterseitigen Sitzung während der Geschäftszeit ist eine Entscheidung, die jemand anderes treffen sollte. Auf Junos lesen die entsprechenden Prüfungen die Tabelle je VRF und die VPN-Tabelle direkt, und das Zurückrollen ist ein Zurücksetzen beim Commit statt eines Undo je Befehl, also sichern Sie das Konfigurationsdiff, bevor Sie beginnen.

Schließen Sie mit denselben drei Befehlen, mit denen Sie begonnen haben, in derselben Reihenfolge, und protokollieren Sie deren Ausgabe mit Zeitstempel. Ein Ticket, das sagt, das RT war falsch und jetzt ist es richtig, ist nicht wiederverwendbar; eines, das das Präfix in der VRF, in VPNv4 und in CEF installiert zeigt, ist ein Beleg, mit dem die nächste Person vergleichen kann. Haben sich nur die ersten beiden geändert, ist die Änderung nicht abgeschlossen.