Pingar inte MPLS L3VPN-labbet? Kontrollera de här fem hoppen

Två kundroutrar, ett par provider edge-enheter och en ping som dör utan felmeddelande. I ett litet MPLS L3VPN-lab sitter felet nästan alltid vid en av fem kontrollpunkter, och var och en har ett kommando som antingen visar att beroendet fungerar eller att det saknas. Misstaget är att starta om BGP varje gång pinget misslyckas i stället för att testa beroendena i ordning. Går du rakt på VRF-konfigurationen kan du lägga en timme på ett problem som började med en oupplöst nexthop två enheter bort.

Arbeta igenom listan underifrån. En kontrollpunkt som passerar förblir godkänd, och det första felet är det som är värt att felsöka.

Kontrollpunkt ett: PE-routrarna kan nå varandra

Varje PE behöver en route till den andra PE:ns loopback, och den routen måste lösas upp via något verkligt. Ett interior gateway protocol är det vanliga sättet dit, men en statisk route fungerar också så länge den rekursiva uppslagningen landar på en levande adjacency. På IOS-liknande enheter visar show ip route 10.0.0.2 följt av show ip cef 10.0.0.2 om prefixet finns och om det har en upplöst adjacency. En route i tabellen utan adjacency bakom sig är inte nåbarhet.

Kontrollera båda riktningarna. Asymmetriska IGP-kostnader, ett passive interface på fel sida eller en distribute list som filtrerar loopbacken bryter var och en bara en riktning, och en riktning räcker för att döda sessionen. Om loopbackarna pingar men BGP-sessionen står i Active, titta på update source innan du rör något annat.

Kontrollpunkt två: det finns en labelväg

En IP-route till den avlägsna loopbacken bevisar inte att transporten kommer att trycka på en label. I en LDP-design ska du bekräfta att den avlägsna loopbacken har en lokal och en avlägsen bindning, och att den utgående labeln finns i forwarding-tabellen. show mpls ldp bindings 10.0.0.2 32 visar labelparen, och show mpls forwarding-table 10.0.0.2 visar vad line cardet faktiskt kommer att lägga på. När det andra kommandot inte visar någon label eller faller tillbaka på IP bär transporten inte VPN-trafiken som designen förutsätter.

Skillnaden kommer av hur MPLS skiljer forwarding state från destinationsprefix, den modell som beskrivs i RFC 3031. Om labbet använder RSVP-TE eller BGP-angränsande labels i stället för LDP, kontrollera det mekanismens eget tillstånd; att anta att LDP distribuerar varje underlagslabel är ett vanligt sätt att jaga en spökbugg. En trasig labelväg brukar senare dyka upp som en VPN-route som finns men inte går att använda.

Kontrollpunkt tre: VPN-routen kom fram intakt

Titta på VPNv4- eller VPNv6-routen för det exakta kundprefixet, inte på sessionsammanfattningen. show bgp vpnv4 unicast all 10.10.1.0/24 ska visa route distinguisher, nexthop satt till den avlägsna PE-loopbacken och en label. Saknas prefixet är exportpolicyn på den avgivande PE:n eller importpolicyn på den mottagande PE:n den första misstänkta, och route targets är den vanliga boven.

Läs route target-kontrollen separat från BGP-mottagandet. En route kan komma in med rätt nexthop och ändå inte hamna i VRF:en eftersom importtarget inte matchar. På den mottagande PE:n är show ip route vrf CUSTOMER 10.10.1.0 testet som avgör; BGP-tabellen bevisar bara att routen korsade kontrollplanet.

Kontrollpunkt fyra: interfaceet ligger i VRF:en

En VRF-definition med route distinguisher och route targets flyttar inte in något interface i den. Interfaceet mot CE behöver VRF-tilldelningen, och show ip vrf interfaces eller show ip interface brief ska lista det under rätt instans. Det här är kontrollpunkten där en kopierad konfiguration oftast går fel, eftersom VRF-blocket ser komplett ut medan interfaceet fortfarande ligger i den globala tabellen.

Bekräfta sedan att PE:n har lärt sig det lokala kundprefixet in i den VRF:en, och att CE:n har en route tillbaka genom anslutningen. En statisk default på CE:n som pekar på PE:n räcker för ett labb, förutsatt att PE:ns VRF har en route till CE-LAN:et. Saknas någon av halvorna misslyckas pinget innan någon label läggs på.

Kontrollpunkt fem: svaret tar en väg hem

Spåra det framåtgående paketet och sedan returpaketet, eftersom de använder olika tabeller. På ingress-PE:n ska kundkällan lösas upp inom VRF:en till det avlägsna prefixet med den avlägsna labeln. På egress-PE:n ska destinationen lösas upp inom samma VRF till interfaceet mot CE. Ett ping som utgår från PE:n själv är inget bevis: det kan lämna via den globala tabellen eller en annan källadress, och därför är ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 testet du ska köra.

Brandväggar på värden, reverse-path filtering och access-listor på CE:n gäller fortfarande. Fungerar framvägen och dör svaret sitter problemet i en route eller ett filter på retursidan, inte i MPLS-transporten.

Håll en rad per kontrollpunkt som namnger det första beroende som misslyckades. Den raden förvandlar påståendet att kunden inte kan pinga till en konkret fråga om nåbarhet, labeltillstånd, route-import, interfacemedlemskap eller returvägen, och den hindrar nästa felsökningspass från att upprepa samma fem kommandon i samma ordning.