MPLS-L3VPN-Lab pingt nicht? Prüfen Sie diese fünf Hops

Zwei Kundenrouter, ein Paar Provider-Edge-Geräte und ein Ping, der ohne Fehlermeldung stirbt. In einem kleinen MPLS-L3VPN-Lab sitzt der Fehler fast immer an einem von fünf Prüfpunkten, und jeder davon hat einen Befehl, der entweder zeigt, dass die Abhängigkeit funktioniert, oder dass sie fehlt. Der Fehler ist, bei jedem fehlgeschlagenen Ping BGP neu zu starten, statt die Abhängigkeiten der Reihe nach zu testen. Wer direkt in die VRF-Konfiguration springt, kann eine Stunde auf ein Problem verwenden, das mit einem unaufgelösten Next Hop zwei Geräte weiter begann.

Arbeiten Sie die Liste von unten nach oben ab. Ein Prüfpunkt, der besteht, bleibt bestanden, und der erste Fehler ist der, den es zu debuggen lohnt.

Prüfpunkt eins: die PEs erreichen sich gegenseitig

Jede PE braucht eine Route zum Loopback der anderen PE, und diese Route muss über etwas Reales aufgelöst werden. Ein Interior Gateway Protocol ist der übliche Weg dorthin, aber eine statische Route funktioniert ebenso, solange die rekursive Suche auf einer lebenden Adjacency landet. Auf IOS-artigen Geräten zeigt show ip route 10.0.0.2 gefolgt von show ip cef 10.0.0.2, ob das Präfix existiert und ob eine aufgelöste Adjacency dahintersteht. Eine Route in der Tabelle ohne Adjacency dahinter ist keine Erreichbarkeit.

Prüfen Sie beide Richtungen. Asymmetrische IGP-Kosten, ein passive Interface auf der falschen Seite oder eine Distribute List, die das Loopback filtert, brechen jeweils nur eine Richtung, und eine Richtung genügt, um die Sitzung zu beenden. Wenn die Loopbacks pingbar sind, die BGP-Sitzung aber in Active steht, schauen Sie zuerst auf die Update Source, bevor Sie irgendetwas anderes anfassen.

Prüfpunkt zwei: ein Labelpfad existiert

Eine IP-Route zum entfernten Loopback beweist nicht, dass der Transport ein Label aufdrückt. Bestätigen Sie in einem LDP-Design, dass das entfernte Loopback eine lokale und eine entfernte Bindung hat und dass das ausgehende Label in der Forwarding-Tabelle auftaucht. show mpls ldp bindings 10.0.0.2 32 zeigt die Labelpaare, und show mpls forwarding-table 10.0.0.2 zeigt, was die Line Card tatsächlich aufsetzen wird. Wenn der zweite Befehl kein Label zeigt oder auf IP zurückfällt, trägt der Transport den VPN-Verkehr nicht so, wie das Design es annimmt.

Der Unterschied kommt daher, wie MPLS Forwarding State von Zielpräfixen trennt, das Modell, das in RFC 3031 beschrieben wird. Wenn Ihr Lab RSVP-TE oder BGP-angrenzende Labels statt LDP verwendet, prüfen Sie den eigenen Zustand dieses Mechanismus; anzunehmen, LDP verteile jedes Underlay-Label, ist ein üblicher Weg, einem Phantomfehler nachzujagen. Ein gebrochener Labelpfad zeigt sich später meist als VPN-Route, die vorhanden, aber unbrauchbar ist.

Prüfpunkt drei: die VPN-Route kam unversehrt an

Sehen Sie sich die VPNv4- oder VPNv6-Route für das exakte Kundenpräfix an, nicht die Sitzungszusammenfassung. show bgp vpnv4 unicast all 10.10.1.0/24 sollte den Route Distinguisher zeigen, den Next Hop auf das entfernte PE-Loopback gesetzt und ein Label. Fehlt das Präfix, ist die Export-Policy auf der Ursprungs-PE oder die Import-Policy auf der empfangenden PE der erste Verdacht, und Route Targets sind der übliche Übeltäter.

Lesen Sie die Route-Target-Prüfung getrennt vom BGP-Empfang. Eine Route kann mit dem richtigen Next Hop ankommen und trotzdem nicht in der VRF landen, weil das Import-Target nicht passt. Auf der empfangenden PE ist show ip route vrf CUSTOMER 10.10.1.0 der Test, auf den es ankommt; die BGP-Tabelle beweist nur, dass die Route die Steuerungsebene überquert hat.

Prüfpunkt vier: das Interface liegt in der VRF

Eine VRF-Definition mit Route Distinguisher und Route Targets verschiebt kein Interface hinein. Das Interface zum CE braucht die VRF-Zuweisung, und show ip vrf interfaces oder show ip interface brief sollten es unter der richtigen Instanz auflisten. Das ist der Prüfpunkt, an dem eine kopierte Konfiguration am häufigsten schiefgeht, weil der VRF-Block vollständig aussieht, während das Interface noch in der globalen Tabelle sitzt.

Bestätigen Sie dann, dass die PE das lokale Kundenpräfix in diese VRF gelernt hat und dass das CE eine Route zurück über die Anbindung hat. Ein statischer Default auf dem CE, der auf die PE zeigt, reicht für ein Lab, sofern die VRF der PE eine Route zum CE-LAN hat. Fehlt eine der beiden Hälften, schlägt der Ping fehl, bevor irgendein Label aufgesetzt wird.

Prüfpunkt fünf: die Antwort findet den Weg zurück

Verfolgen Sie das Paket vorwärts und dann das Antwortpaket, denn beide nutzen unterschiedliche Tabellen. Auf der Ingress-PE sollte die Kundenquelle innerhalb der VRF auf das entfernte Präfix mit dem entfernten Label auflösen. Auf der Egress-PE sollte das Ziel innerhalb derselben VRF auf das Interface zum CE auflösen. Ein Ping, der von der PE selbst stammt, ist kein Beweis: Er kann über die globale Tabelle oder eine andere Quelladresse hinausgehen, und deshalb ist ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 der Test, den Sie ausführen sollten.

Host-Firewalls, Reverse-Path-Filtering und Access-Listen auf dem CE gelten weiterhin. Funktioniert der Hinweg und stirbt die Antwort, sitzt das Problem in einer Route oder einem Filter auf der Rückseite, nicht im MPLS-Transport.

Halten Sie pro Prüfpunkt eine Zeile fest, die die erste fehlgeschlagene Abhängigkeit benennt. Diese Zeile macht aus dem Klagen, der Kunde könne nicht pingen, eine konkrete Frage nach Erreichbarkeit, Labelzustand, Route-Import, Interface-Zugehörigkeit oder Rückweg, und sie hindert die nächste Debug-Sitzung daran, dieselben fünf Befehle in derselben Reihenfolge zu wiederholen.