MPLS L3VPN-lab pinger ikke? Sjekk disse fem hoppene

To kunderutere, et par provider edge-bokser og en ping som dør uten feilmelding. I et lite MPLS L3VPN-lab sitter feilen nesten alltid på ett av fem kontrollpunkter, og hvert av dem har en kommando som enten viser at avhengigheten virker eller at den mangler. Feilen er å starte BGP på nytt hver gang pingen feiler i stedet for å teste avhengighetene i rekkefølge. Går du rett på VRF-konfigurasjonen, kan du bruke en time på et problem som begynte med en uoppløst neste hopp to enheter unna.

Arbeid deg gjennom listen nedenfra. Et kontrollpunkt som passerer blir stående som bestått, og den første feilen er den som er verdt å feilsøke.

Kontrollpunkt én: PE-ene kan nå hverandre

Hver PE trenger en rute til den andre PE-ens loopback, og den ruten må løses opp gjennom noe ekte. En interior gateway protocol er den vanlige veien dit, men en statisk rute fungerer også så lenge det rekursive oppslaget lander på en levende adjacency. På IOS-lignende bokser viser show ip route 10.0.0.2 etterfulgt av show ip cef 10.0.0.2 om prefikset finnes og om det har en oppløst adjacency bak seg. En rute i tabellen uten adjacency bak seg er ikke nåbarhet.

Sjekk begge retninger. Asymmetriske IGP-kostnader, et passive interface på feil side eller en distribute list som filtrerer loopbacken bryter hver for seg bare én retning, og én retning er nok til å drepe sesjonen. Hvis loopbackene pinger men BGP-sesjonen står i Active, se på update source før du rører noe annet.

Kontrollpunkt to: det finnes en labelsti

En IP-rute til den fjerne loopbacken beviser ikke at transporten vil pushe en label. I et LDP-design må du bekrefte at den fjerne loopbacken har både en lokal og en fjern binding, og at den utgående labelen står i forwarding-tabellen. show mpls ldp bindings 10.0.0.2 32 viser labelparene, og show mpls forwarding-table 10.0.0.2 viser hva line cardet faktisk vil sette på. Når den andre kommandoen ikke viser noen label eller faller tilbake til IP, bærer ikke transporten VPN-trafikken slik designet forutsetter.

Forskjellen kommer av hvordan MPLS skiller forwarding state fra destinasjonsprefikser, modellen som er beskrevet i RFC 3031. Hvis labben din bruker RSVP-TE eller BGP-tilstøtende labels i stedet for LDP, sjekk den mekanismens egen tilstand; å anta at LDP distribuerer hver underlagslabel er en vanlig måte å jage en spøkelsesfeil på. En brutt labelsti dukker som regel senere opp som en VPN-rute som er til stede men ubrukelig.

Kontrollpunkt tre: VPN-ruten kom intakt fram

Se på VPNv4- eller VPNv6-ruten for det nøyaktige kundeprefikset, ikke på sesjonssammendraget. show bgp vpnv4 unicast all 10.10.1.0/24 bør vise route distinguisher, neste hopp satt til den fjerne PE-loopbacken og en label. Hvis prefikset mangler, er eksportpolicyen på den avsendende PE eller importpolicyen på den mottakende PE den første mistenkte, og route targets er den vanlige synderen.

Les route target-kontrollen atskilt fra BGP-mottaket. En rute kan ankomme med riktig neste hopp og likevel ikke lande i VRF-en fordi importtarget ikke samsvarer. På den mottakende PE er show ip route vrf CUSTOMER 10.10.1.0 testen som betyr noe; BGP-tabellen beviser bare at ruten krysset kontrollplanet.

Kontrollpunkt fire: interfaceet ligger i VRF-en

En VRF-definisjon med route distinguisher og route targets flytter ikke noe interface inn i den. Interfaceet mot CE trenger VRF-tildelingen, og show ip vrf interfaces eller show ip interface brief bør liste det under riktig instans. Dette er kontrollpunktet der en kopiert konfigurasjon oftest går galt, fordi VRF-blokken ser komplett ut mens interfaceet fortsatt sitter i den globale tabellen.

Bekreft deretter at PE-en har lært det lokale kundeprefikset inn i den VRF-en, og at CE-en har en rute tilbake gjennom tilkoblingen. En statisk default på CE-en som peker på PE-en er nok for en lab, forutsatt at PE-ens VRF har en rute til CE-LAN-et. Mangler en av halvdelene, feiler pingen før noen label settes på.

Kontrollpunkt fem: svaret finner veien hjem

Spor pakken fremover og deretter returpakken, fordi de bruker forskjellige tabeller. På inngangs-PE-en bør kundekilden løses opp inne i VRF-en til det fjerne prefikset med den fjerne labelen. På utgangs-PE-en bør destinasjonen løses opp inne i samme VRF til interfaceet mot CE. En ping fra PE-en selv er ikke bevis: den kan gå ut via den globale tabellen eller en annen kildeadresse, og derfor er ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 testen du skal kjøre.

Brannmurer på verter, reverse-path filtering og access-lister på CE-en gjelder fortsatt. Virker veien framover og dør svaret, sitter problemet i en rute eller et filter på retursiden, ikke i MPLS-transporten.

Hold én linje per kontrollpunkt som navngir den første avhengigheten som feilet. Den linjen gjør påstanden om at kunden ikke kan pinge om til et konkret spørsmål om nåbarhet, labeltilstand, ruteimport, interfacemedlemskap eller returveien, og den hindrer neste feilsøking i å gjenta de samme fem kommandoene i samme rekkefølge.