MPLS L3VPN-laboratorium ping nie? Gaan hierdie vyf spronge na

Twee klantrouters, ’n paar provider edge-bokse en ’n ping wat sonder ’n foutboodskap sterf. In ’n klein MPLS L3VPN-laboratorium sit die fout byna altyd by een van vyf kontrolepunte, en elkeen het ’n opdrag wat óf wys die afhanklikheid werk óf wys dit ontbreek. Die fout is om BGP elke keer te herbegin wanneer die ping misluk, in plaas daarvan om die afhanklikhede in volgorde te toets. Spring jy reguit na die VRF-konfigurasie, kan jy ’n uur spandeer aan ’n probleem wat begin het met ’n onopgeloste volgende sprong twee toestelle verder.

Werk die lys van onder af deur. ’n Kontrolepunt wat slaag, bly geslaag, en die eerste fout is die een wat werd is om te ontfout.

Kontrolepunt een: die PE's kan mekaar bereik

Elke PE het ’n roete na die ander PE se loopback nodig, en daardie roete moet deur iets werkliks opgelos word. ’n Interior gateway protocol is die gewone manier om daar te kom, maar ’n statiese roete werk ook, solank die rekursiewe opsoek op ’n lewende adjacency beland. Op IOS-agtige bokse wys show ip route 10.0.0.2 gevolg deur show ip cef 10.0.0.2 of die voorvoegsel bestaan en of daar ’n opgeloste adjacency agter is. ’n Roete in die tabel sonder ’n adjacency agter hom is nie bereikbaarheid nie.

Toets beide rigtings. Asimmetriese IGP-koste, ’n passive interface aan die verkeerde kant of ’n distribute list wat die loopback filtreer, breek elkeen net een rigting, en een rigting is genoeg om die sessie te dood. As die loopbacks ping maar die BGP-sessie sit in Active, kyk na die update source voordat jy enigiets anders aanraak.

Kontrolepunt twee: daar bestaan ’n etiketpad

’n IP-roete na die afgeleë loopback bewys nie dat die transport ’n etiket sal opsit nie. Bevestig in ’n LDP-ontwerp dat die afgeleë loopback ’n plaaslike en ’n afgeleë binding het, en dat die uitgaande etiket in die forwarding-tabel verskyn. show mpls ldp bindings 10.0.0.2 32 wys die etiketpare, en show mpls forwarding-table 10.0.0.2 wys wat die line card werklik sal opsit. Wanneer die tweede opdrag geen etiket wys of na IP terugval, dra die transport nie die VPN-verkeer soos die ontwerp veronderstel nie.

Die onderskeid kom uit hoe MPLS forwarding state van bestemmingsvoorvoegsels skei, die model wat in RFC 3031 beskryf word. As jou laboratorium RSVP-TE of BGP-aangrensende etikette in plaas van LDP gebruik, toets daardie meganisme se eie toestand; om aan te neem dat LDP elke onderlaag-etiket versprei, is ’n algemene manier om ’n spookfout te jaag. ’n Gebreekte etiketpad duik later gewoonlik op as ’n VPN-roete wat teenwoordig maar onbruikbaar is.

Kontrolepunt drie: die VPN-roete het ongeskonde aangekom

Kyk na die VPNv4- of VPNv6-roete vir die presiese klantvoorvoegsel, nie na die sessieopsomming nie. show bgp vpnv4 unicast all 10.10.1.0/24 behoort die route distinguisher te wys, die next hop wat op die afgeleë PE-loopback gestel is, en ’n etiket. As die voorvoegsel ontbreek, is die uitvoerbeleid op die oorsprong-PE of die invoerbeleid op die ontvangende PE die eerste verdagte, en route targets is die gewone skuldige.

Lees die route target-kontrole apart van die BGP-ontvangs. ’n Roete kan met die regte next hop aankom en tog nie in die VRF beland nie, omdat die importtarget nie ooreenstem nie. Op die ontvangende PE is show ip route vrf CUSTOMER 10.10.1.0 die toets wat saak maak; die BGP-tabel bewys net dat die roete die beheervlak oorgesteek het.

Kontrolepunt vier: die interface is in die VRF

’n VRF-definisie met ’n route distinguisher en route targets skuif geen interface daarin nie. Die interface na die CE het die VRF-toewysing nodig, en show ip vrf interfaces of show ip interface brief behoort dit onder die regte instansie te lys. Dit is die kontrolepunt waar ’n gekopieerde konfigurasie die meeste foutgaan, want die VRF-blok lyk volledig terwyl die interface nog in die globale tabel sit.

Bevestig dan dat die PE die plaaslike klantvoorvoegsel in daardie VRF geleer het, en dat die CE ’n roete terug het deur die aansluiting. ’n Statiese default op die CE wat na die PE wys, is genoeg vir ’n laboratorium, mits die PE se VRF ’n roete na die CE-LAN het. As een van die twee helftes ontbreek, misluk die ping voordat enige etiket opgesit word.

Kontrolepunt vyf: die antwoord vind ’n pad huis toe

Spoor die vorentoe-pakket en dan die terugpakket na, want hulle gebruik verskillende tabelle. Op die inkomende PE behoort die klantbron binne die VRF na die afgeleë voorvoegsel met die afgeleë etiket op te los. Op die uitgaande PE behoort die bestemming binne dieselfde VRF na die interface na die CE op te los. ’n Ping wat van die PE self af kom, is nie bewys nie: dit kan deur die globale tabel of ’n ander bronadres vertrek, en daarom is ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 die toets wat jy moet hardloop.

Gasheer-firewalls, reverse-path filtering en access-lyste op die CE geld steeds. As die vorentoe-pad werk en die antwoord sterf, sit die probleem in ’n roete of ’n filter aan die terugkant, nie in die MPLS-transport nie.

Hou een reël per kontrolepunt wat die eerste afhanklikheid noem wat misluk het. Daardie reël maak van die klag dat die klant nie kan ping nie ’n spesifieke vraag oor bereikbaarheid, etiketstatus, roete-invoer, interface-lidmaatskap of die terugpad, en dit keer dat die volgende ontfoutsessie dieselfde vyf opdragte in dieselfde volgorde herhaal.