MPLS L3VPN-lab pingar ikkje? Sjekk desse fem hoppa

To kundaruterar, eit par provider edge-boksar og ein ping som døyr utan feilmelding. I eit lite MPLS L3VPN-lab sit feilen nesten alltid på eitt av fem kontrollpunkt, og kvart av dei har ein kommando som anten viser at avhengnaden verkar eller at han manglar. Feilen er å starte BGP på nytt kvar gong pingen feilar i staden for å teste avhengnadene i rekkefølgje. Går du rett på VRF-konfigurasjonen, kan du bruke ein time på eit problem som byrja med eit uoppløyst neste hopp to einingar unna.

Arbeid deg gjennom lista nedanfrå. Eit kontrollpunkt som passerer blir ståande som bestått, og den første feilen er den som er verdt å feilsøkje.

Kontrollpunkt éin: PE-ane kan nå kvarandre

Kvar PE treng ei rute til loopbacken til den andre PE-en, og den ruta må løysast opp gjennom noko ekte. Ein interior gateway protocol er den vanlege vegen dit, men ei statisk rute verkar òg så lenge det rekursive oppslaget landar på ein levande adjacency. På IOS-liknande boksar viser show ip route 10.0.0.2 etterfølgt av show ip cef 10.0.0.2 om prefikset finst og om det har ein oppløyst adjacency bak seg. Ei rute i tabellen utan adjacency bak seg er ikkje nåbarheit.

Sjekk begge retningar. Asymmetriske IGP-kostnader, eit passive interface på feil side eller ei distribute list som filtrerer loopbacken bryt kvar for seg berre éi retning, og éi retning er nok til å drepe sesjonen. Viss loopbackane pingar men BGP-sesjonen står i Active, sjå på update source før du rører noko anna.

Kontrollpunkt to: det finst ein labelsti

Ei IP-rute til den fjerne loopbacken beviser ikkje at transporten vil pushe ein label. I eit LDP-design må du stadfeste at den fjerne loopbacken har både ein lokal og ein fjern binding, og at den utgåande labelen står i forwarding-tabellen. show mpls ldp bindings 10.0.0.2 32 viser labelpara, og show mpls forwarding-table 10.0.0.2 viser kva line cardet faktisk vil setje på. Når den andre kommandoen ikkje viser nokon label eller fell tilbake til IP, ber ikkje transporten VPN-trafikken slik designet føreset.

Skilnaden kjem av korleis MPLS skil forwarding state frå destinasjonsprefiks, modellen som er skildra i RFC 3031. Viss labben din brukar RSVP-TE eller BGP-tilstøytande labels i staden for LDP, sjekk eigen tilstand for den mekanismen; å anta at LDP distribuerer kvar underlagslabel er ein vanleg måte å jage ein spøkjelsesfeil på. Ein broten labelsti dukkar som regel seinare opp som ei VPN-rute som er til stades men ubrukeleg.

Kontrollpunkt tre: VPN-ruta kom intakt fram

Sjå på VPNv4- eller VPNv6-ruta for det nøyaktige kundeprefikset, ikkje på sesjonssamandraget. show bgp vpnv4 unicast all 10.10.1.0/24 bør vise route distinguisher, neste hopp sett til den fjerne PE-loopbacken og ein label. Viss prefikset manglar, er eksportpolicyen på den avsendarande PE-en eller importpolicyen på den mottakande PE-en den første mistenkte, og route targets er den vanlege syndaren.

Les route target-kontrollen skild frå BGP-mottaket. Ei rute kan kome med rett neste hopp og likevel ikkje lande i VRF-en fordi importtarget ikkje samsvarar. På den mottakande PE-en er show ip route vrf CUSTOMER 10.10.1.0 testen som betyr noko; BGP-tabellen beviser berre at ruta kryssa kontrollplanet.

Kontrollpunkt fire: interfaceet ligg i VRF-en

Ein VRF-definisjon med route distinguisher og route targets flyttar ikkje noko interface inn i han. Interfaceet mot CE treng VRF-tildelinga, og show ip vrf interfaces eller show ip interface brief bør liste det under rett instans. Dette er kontrollpunktet der ein kopiert konfigurasjon oftast går gale, fordi VRF-blokka ser komplett ut medan interfaceet framleis sit i den globale tabellen.

Stadfest deretter at PE-en har lært det lokale kundeprefikset inn i den VRF-en, og at CE-en har ei rute tilbake gjennom tilknytinga. Ein statisk default på CE-en som peikar på PE-en er nok for eit lab, føresett at VRF-en til PE-en har ei rute til CE-LAN-et. Manglar ein av halvdelane, feilar pingen før nokon label blir sett på.

Kontrollpunkt fem: svaret finn vegen heim

Spor pakken framover og deretter returpakken, fordi dei brukar ulike tabellar. På inngangs-PE-en bør kundekjelda løysast opp inne i VRF-en til det fjerne prefikset med den fjerne labelen. På utgangs-PE-en bør destinasjonen løysast opp inne i same VRF til interfaceet mot CE. Ein ping frå PE-en sjølv er ikkje bevis: han kan gå ut via den globale tabellen eller ei anna kjeldeadresse, og difor er ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 testen du skal køyre.

Brannmurar på vertar, reverse-path filtering og access-lister på CE-en gjeld framleis. Verkar vegen framover og døyr svaret, sit problemet i ei rute eller eit filter på retursida, ikkje i MPLS-transporten.

Hald éi linje per kontrollpunkt som namngir den første avhengnaden som feila. Den linja gjer påstanden om at kunden ikkje kan pinge om til eit konkret spørsmål om nåbarheit, labeltilstand, ruteimport, interfacemedlemskap eller returvegen, og ho hindrar neste feilsøking i å gjenta dei same fem kommandoane i same rekkefølgje.