MPLS L3VPN-testlab pingt niet? Controleer deze vijf hops

Twee routers bij de klant, een paar provider edge-apparaten en een ping die sterft zonder foutmelding. In een klein MPLS L3VPN-testlab zit de fout bijna altijd op een van vijf controlepunten, en elk daarvan heeft een commando dat laat zien of de afhankelijkheid werkt of ontbreekt. De fout is elke keer dat de ping mislukt BGP opnieuw te starten in plaats van de afhankelijkheden op volgorde te testen. Spring je meteen naar de VRF-configuratie, dan kun je een uur kwijtraken aan een probleem dat begon met een onopgeloste next hop twee apparaten verderop.

Werk de lijst van onderop af. Een controlepunt dat slaagt blijft geslaagd, en de eerste fout is degene die het debuggen waard is.

Controlepunt een: de PE's kunnen elkaar bereiken

Elke PE heeft een route naar de loopback van de andere PE nodig, en die route moet via iets echts oplossen. Een interior gateway protocol is de gebruikelijke manier om daar te komen, maar een statische route werkt ook, zolang de recursieve lookup op een levende adjacency uitkomt. Op IOS-achtige apparaten laat show ip route 10.0.0.2 gevolgd door show ip cef 10.0.0.2 zien of het prefix bestaat en of er een opgeloste adjacency achter zit. Een route in de tabel zonder adjacency erachter is geen bereikbaarheid.

Controleer beide richtingen. Asymmetrische IGP-kosten, een passive interface aan de verkeerde kant of een distribute list die de loopback filtert, breken elk maar een richting, en een richting is genoeg om de sessie te doden. Als de loopbacks pingen maar de BGP-sessie in Active blijft staan, kijk dan naar de update source voordat u iets anders aanraakt.

Controlepunt twee: er bestaat een labelpad

Een IP-route naar de remote loopback bewijst niet dat het transport een label zal pushen. Controleer in een LDP-ontwerp dat de remote loopback een lokale en een remote binding heeft, en dat het uitgaande label in de forwarding table staat. show mpls ldp bindings 10.0.0.2 32 toont de labelparen, en show mpls forwarding-table 10.0.0.2 toont wat de line card werkelijk zal opleggen. Als het tweede commando geen label toont of terugvalt op IP, draagt het transport het VPN-verkeer niet zoals het ontwerp veronderstelt.

Het onderscheid komt voort uit hoe MPLS forwarding state losmaakt van destination prefixes, het model dat in RFC 3031 wordt beschreven. Als uw lab RSVP-TE of BGP-adjacent labels gebruikt in plaats van LDP, controleer dan de eigen state van dat mechanisme; aannemen dat LDP elk underlay-label distribueert is een veelgebruikte manier om een spookbug te achtervolgen. Een gebroken labelpad duikt later meestal op als een VPN-route die aanwezig maar onbruikbaar is.

Controlepunt drie: de VPN-route kwam intact aan

Kijk naar de VPNv4- of VPNv6-route voor het exacte klantprefix, niet naar de sessiesamenvatting. show bgp vpnv4 unicast all 10.10.1.0/24 hoort de route distinguisher te tonen, de next hop ingesteld op de remote PE-loopback en een label. Ontbreekt het prefix, dan is het exportbeleid op de bron-PE of het importbeleid op de ontvangende PE de eerste verdachte, en route targets zijn de gebruikelijke boosdoener.

Lees de route-targetcontrole apart van de BGP-ontvangst. Een route kan met de juiste next hop aankomen en toch niet in de VRF belanden omdat het importtarget niet overeenkomt. Op de ontvangende PE is show ip route vrf CUSTOMER 10.10.1.0 de test die telt; de BGP-tabel bewijst alleen dat de route het controlevlak is overgestoken.

Controlepunt vier: de interface zit in de VRF

Een VRF-definitie met een route distinguisher en route targets verplaatst geen enkele interface erin. De interface richting CE heeft de VRF-toewijzing nodig, en show ip vrf interfaces of show ip interface brief hoort die onder de juiste instantie te vermelden. Dit is het controlepunt waar een gekopieerde configuratie het vaakst misgaat, omdat het VRF-blok compleet lijkt terwijl de interface nog in de globale tabel zit.

Bevestig daarna dat de PE het lokale klantprefix in die VRF heeft geleerd, en dat de CE een route terug heeft via de aansluiting. Een statische default op de CE die naar de PE wijst is genoeg voor een lab, mits de VRF van de PE een route naar het CE-LAN heeft. Ontbreekt een van beide helften, dan mislukt de ping voordat er een label wordt opgelegd.

Controlepunt vijf: het antwoord vindt een weg terug

Traceer het heenpakket en daarna het terugpakket, want ze gebruiken verschillende tabellen. Op de ingress-PE hoort de klantbron binnen de VRF naar het remote prefix met het remote label te resolveren. Op de egress-PE hoort de bestemming binnen dezelfde VRF naar de interface richting CE te resolveren. Een ping vanaf de PE zelf is geen bewijs: die kan via de globale tabel of een ander bronadres vertrekken, en daarom is ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 de test die u moet uitvoeren.

Firewalls op hosts, reverse-path filtering en access lists op de CE blijven gelden. Als het heenpad werkt en het antwoord wegvalt, zit het probleem in een route of filter aan de terugkant, niet in het MPLS-transport.

Houd per controlepunt een regel bij waarin u de eerste afhankelijkheid noemt die faalde. Die regel maakt van de klacht dat de klant niet kan pingen een concrete vraag over bereikbaarheid, labelstatus, route-import, interfacelidmaatschap of het terugpad, en voorkomt dat de volgende debugsessie dezelfde vijf commando's in dezelfde volgorde herhaalt.