MPLS L3VPN-lab pinger ikke? Tjek de fem hop her

To kundeforere, et par provider edge-bokse og en ping, der dør uden fejlmeddelelse. I et lille MPLS L3VPN-lab sidder fejlen næsten altid ved et af fem kontrolpunkter, og hvert af dem har en kommando, der enten viser, at afhængigheden virker, eller at den mangler. Fejlen er at genstarte BGP, hver gang pingen fejler, i stedet for at teste afhængighederne i rækkefølge. Springer du direkte til VRF-konfigurationen, kan du bruge en time på et problem, der begyndte med en uopløst next hop to enheder væk.

Arbejd listen igennem nedefra. Et kontrolpunkt, der passerer, bliver ved med at være bestået, og den første fejl er den, der er værd at fejlfinde.

Kontrolpunkt et: PE'erne kan nå hinanden

Hver PE skal have en rute til den anden PE's loopback, og den rute skal opløses gennem noget rigtigt. En interior gateway protocol er den sædvanlige vej derhen, men en statisk rute virker også, så længe det rekursive opslag lander på en levende adjacency. På IOS-lignende bokse viser show ip route 10.0.0.2 efterfulgt af show ip cef 10.0.0.2, om prefixet findes, og om der er en opløst adjacency bag det. En rute i tabellen uden adjacency bag sig er ikke nåbarhed.

Tjek begge retninger. Asymmetriske IGP-omkostninger, et passive interface på den forkerte side eller en distribute list, der filtrerer loopbacken, bryder hver kun én retning, og én retning er nok til at dræbe sessionen. Hvis loopbackene pinger, men BGP-sessionen står i Active, så kig på update source, før du rører noget andet.

Kontrolpunkt to: der findes en labelsti

En IP-rute til den fjerne loopback beviser ikke, at transporten vil påsætte en label. I et LDP-design skal du bekræfte, at den fjerne loopback har både en lokal og en fjern binding, og at den udgående label står i forwarding-tabellen. show mpls ldp bindings 10.0.0.2 32 viser labelparrene, og show mpls forwarding-table 10.0.0.2 viser, hvad line cardet faktisk vil påsætte. Når den anden kommando ikke viser nogen label eller falder tilbage til IP, bærer transporten ikke VPN-trafikken, som designet forudsætter.

Forskellen kommer af, hvordan MPLS adskiller forwarding state fra destinationsprefixer, den model der er beskrevet i RFC 3031. Hvis dit lab bruger RSVP-TE eller BGP-tilstødende labels i stedet for LDP, så tjek den mekanismes egen tilstand; at antage, at LDP fordeler hver underlagslabel, er en almindelig måde at jage en spøgelsesfejl på. En brudt labelsti dukker som regel senere op som en VPN-rute, der er til stede, men ubrugelig.

Kontrolpunkt tre: VPN-ruten ankom intakt

Se på VPNv4- eller VPNv6-ruten for det præcise kundeprefix, ikke på sessionsoversigten. show bgp vpnv4 unicast all 10.10.1.0/24 bør vise route distinguisher, next hop sat til den fjerne PE-loopback og en label. Hvis prefixet mangler, er eksportpolitikken på den afsendende PE eller importpolitikken på den modtagende PE den første mistænkte, og route targets er den sædvanlige synder.

Læs route target-kontrollen adskilt fra BGP-modtagelsen. En rute kan ankomme med den rigtige next hop og alligevel ikke lande i VRF'en, fordi importtarget ikke matcher. På den modtagende PE er show ip route vrf CUSTOMER 10.10.1.0 den test, der betyder noget; BGP-tabellen beviser kun, at ruten krydsede kontrolplanet.

Kontrolpunkt fire: interfaceet er i VRF'en

En VRF-definition med route distinguisher og route targets flytter ikke nogen interface ind i den. Interfaceet mod CE skal have VRF-tildelingen, og show ip vrf interfaces eller show ip interface brief bør vise det under den rigtige instans. Det er det kontrolpunkt, hvor en kopieret konfiguration oftest går galt, fordi VRF-blokken ser komplet ud, mens interfaceet stadig ligger i den globale tabel.

Bekræft derefter, at PE'en har lært det lokale kundeprefix ind i den VRF, og at CE'en har en rute tilbage gennem tilslutningen. En statisk default på CE'en, der peger på PE'en, er nok til et lab, forudsat at PE'ens VRF har en rute til CE-LAN'et. Mangler en af halvdelene, fejler pingen, før der påsættes nogen label.

Kontrolpunkt fem: svaret tager en vej hjem

Spor det fremadgående paket og derefter returpaketet, fordi de bruger forskellige tabeller. På ingress-PE'en bør kundekilden opløses inde i VRF'en til det fjerne prefix med den fjerne label. På egress-PE'en bør destinationen opløses inde i samme VRF til interfaceet mod CE. En ping fra PE'en selv er ikke et bevis: den kan forlade via den globale tabel eller en anden kildeadresse, og derfor er ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 den test, du skal køre.

Værtsbrandmure, reverse-path filtering og access-lister på CE'en gælder stadig. Virker den fremadgående vej, og dør svaret, sidder problemet i en rute eller et filter på retursiden, ikke i MPLS-transporten.

Hold en linje for hvert kontrolpunkt, der navngiver den første afhængighed, der fejlede. Den linje gør påstanden om, at kunden ikke kan pinge, til et konkret spørgsmål om nåbarhed, labeltilstand, ruteimport, interfacemedlemskab eller returvejen, og den forhindrer den næste fejlfinding i at gentage de samme fem kommandoer i samme rækkefølge.