Dva zákaznícke smerovače, pár zariadení provider edge a ping, ktorý zomrie bez chybovej správy. V malom laboratóriu MPLS L3VPN porucha takmer vždy sedí na jednom z piatich kontrolných bodov a každý z nich má príkaz, ktorý ukáže buď že závislosť funguje, alebo že chýba. Chybou je reštartovať BGP zakaždým, keď ping zlyhá, namiesto testovania závislostí v poradí. Ak skočíte priamo do konfigurácie VRF, môžete stráviť hodinu na probléme, ktorý začal nevyriešeným ďalším skokom o dve zariadenia ďalej.

Prejdite zoznam zdola nahor. Kontrolný bod, ktorý prejde, zostane splnený, a prvý neúspech je ten, ktorý sa oplatí ladiť.

Prvý kontrolný bod: PE sa navzájom dosiahnu

Každý PE potrebuje trasu k loopbacku druhého PE a tá trasa sa musí vyriešiť cez niečo skutočné. Interior gateway protocol je obvyklá cesta tam, ale aj statická trasa funguje, pokiaľ rekurzívne vyhľadávanie skončí na živom adjacency. Na zariadeniach v štýle IOS show ip route 10.0.0.2 a potom show ip cef 10.0.0.2 ukáže, či prefix existuje a či je za ním vyriešený adjacency. Trasa v tabuľke bez adjacency za sebou nie je dosiahnuteľnosť.

Skontrolujte oba smery. Asymetrické náklady IGP, passive interface na nesprávnej strane alebo distribute list, ktorý filtruje loopback, prelomia každý len jeden smer, a jeden smer stačí na zabitie relácie. Ak loopbacky odpovedajú na ping, ale relácia BGP stojí v Active, pozrite sa na update source, skôr než sa dotknete čohokoľvek iného.

Druhý kontrolný bod: existuje cesta značiek

Trasa IP k vzdialenému loopbacku nedokazuje, že transport pridá značku. V návrhu LDP potvrďte, že vzdialený loopback má lokálnu aj vzdialenú väzbu a že výstupná značka sa objaví v tabuľke forwarding. show mpls ldp bindings 10.0.0.2 32 zobrazí páry značiek a show mpls forwarding-table 10.0.0.2 ukáže, čo line card naozaj pridá. Keď druhý príkaz neukáže žiadnu značku alebo spadne späť na IP, transport nenesie prevádzku VPN tak, ako návrh predpokladá.

Rozdiel vychádza z toho, ako MPLS oddeľuje forwarding state od cieľových prefixov, model opísaný v RFC 3031. Ak vaše laboratórium používa RSVP-TE alebo značky susediace s BGP namiesto LDP, skontrolujte vlastný stav tohto mechanizmu; predpokladať, že LDP distribuuje každú značku spodnej vrstvy, je častý spôsob ako naháňať duchársku chybu. Pokazená cesta značiek sa zvyčajne neskôr objaví ako trasa VPN, ktorá existuje, ale je nepoužiteľná.

Tretí kontrolný bod: trasa VPN prišla neporušená

Pozrite sa na trasu VPNv4 alebo VPNv6 presného prefixu zákazníka, nie na zhrnutie relácie. show bgp vpnv4 unicast all 10.10.1.0/24 by mal ukázať route distinguisher, next hop nastavený na loopback vzdialeného PE a značku. Ak prefix chýba, prvým podozrivým je exportná politika na zdrojovom PE alebo importná politika na prijímajúcom PE, a route targety sú obvyklým vinníkom.

Kontrolu route target čítajte oddelene od príjmu BGP. Trasa môže prísť so správnym next hopom a napriek tomu nepristáť vo VRF, pretože importtarget nesedí. Na prijímajúcom PE je show ip route vrf CUSTOMER 10.10.1.0 test, na ktorom záleží; tabuľka BGP len dokazuje, že trasa prešla riadiacou rovinou.

Štvrtý kontrolný bod: interface je vo VRF

Definícia VRF s route distinguisher a route targetmi nepresunie do nej žiadny interface. Interface smerom k CE potrebuje priradenie VRF a show ip vrf interfaces alebo show ip interface brief by ho mal uviesť pod správnou inštanciou. Toto je kontrolný bod, kde kopírovaná konfigurácia najčastejšie zlyhá, pretože blok VRF vyzerá úplný, kým interface stále sedí v globálnej tabuľke.

Potom potvrďte, že sa PE naučil lokálny prefix zákazníka do tejto VRF a že CE má trasu späť cez pripojenie. Statický default na CE ukazujúci na PE stačí pre laboratórium, za predpokladu že VRF na PE má trasu do LAN zákazníka. Ak chýba ktorákoľvek z dvoch polovíc, ping zlyhá skôr, než sa nasadí akákoľvek značka.

Piaty kontrolný bod: odpoveď nájde cestu domov

Sledujte paket dopredu a potom odpoveďový paket, pretože používajú rôzne tabuľky. Na vstupnom PE sa má zdroj zákazníka vyriešiť vnútri VRF na vzdialený prefix so vzdialenou značkou. Na výstupnom PE sa má cieľ vyriešiť vnútri tej istej VRF na interface smerom k CE. Ping odoslaný z PE samotného nie je dôkaz: môže odísť cez globálnu tabuľku alebo inú zdrojovú adresu, a preto je ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 test, ktorý treba spustiť.

Firewally na hostiteľoch, reverse-path filtering a access listy na CE stále platia. Ak cesta dopredu funguje a odpoveď zomrie, problém je v trase alebo filtri na spätnej strane, nie v transporte MPLS.

Pre každý kontrolný bod veďte jeden riadok s menom prvej závislosti, ktorá zlyhala. Ten riadok mení sťažnosť, že zákazník nemôže pingovať, na konkrétnu otázku o dosiahnuteľnosti, stave značiek, importe trás, príslušnosti interface alebo spätnej ceste, a bráni tomu, aby ďalšia ladiaca relácia zopakovala tých istých päť príkazov v rovnakom poradí.

Súvisiace články