BGP-session uppe, kundens väg bruten: MPLS över DMVPN

Peeringen har varit uppe i veckor, antalet prefix ser korrekt ut, och ändå tar en kunds trafik fortfarande den långa vägen eller kommer aldrig fram. Två olika saker bedöms av samma indikator. En BGP-session rapporterar att två peers kan utbyta meddelanden över en TCP-anslutning; den säger ingenting om huruvida overlayet kan bära ett märkt paket för just den kunden.

Det gapet syns lättast i en MPLS-över-DMVPN-design, där hub-vägen och den direkta spoke-vägen kan bete sig olika av skäl som inte har något med peeringen att göra.

Vad sessionen faktiskt bevisar

BGP körs över TCP, så varje peer behöver en rutt till den andra änden adress innan något annat kan hända. Väljer du en loopback som den änden har du skapat ett krav på nåbarhet, inte en garanti för vidarebefordran. Sessionen kan därefter stå kvar över ett gränssnitt som kundens trafik aldrig skulle använda.

Notera fyra fakta i båda ändar innan du drar slutsatser: sessionens källadress, dess destinationsadress, den routingkontext den ligger i, och vilket gränssnitt kärnan eller routern skulle välja för det paret. Dessa fakta beskriver kontrollplanet. Kundpaket lägger till en VRF, en etikettstack och en overlay-mappning ovanpå.

Fyra mekanismer, inte en

Ciscos dokumentation för MPLS över DMVPN skiljer delarna tydligt. MP-BGP distribuerar kundens overlay-etiketter mellan utrustningen vid leverantörens kant. MPLS använder etiketterna för att välja vidarebefordringskontext för ett paket. NHRP mappar en overlay-adress till den transportända som en dynamisk tunnel behöver. IPsec skyddar peer-vägen där det gäller.

Vilken som helst av de fyra kan vara rätt medan en annan är fel, och kombinationen är det som bär trafiken. Ett ruttutbyte kan slutföras medan etikettbindningen för en VRF saknas, medan NHRP-mappningen pekar på en inaktuell transportadress, eller medan tunneln finns men ingen policy tillåter det inre paketet. Ingen av dessa förutsättningar får sessionen att falla.

Jämför hub-vägen med genvägen, en variabel i taget

Lås källvärden, målvärden och VRF:en och följ sedan samma flöde två gånger. På hub-vägen noterar du nästa hopp, tjänsteetiketten som identifierar den avlägsna kundkontexten, och den overlay-till-transport-mappning som används. På den avsedda direkta vägen noterar du samma tre saker. Skillnaden mellan de två listorna är felet, eller avsaknaden av det.

Håll flödet konstant under jämförelsen. Att ändra källvärden, VRF:en eller destinationen mellan observationer ger två orelaterade historier, och det är det vanligaste sättet den här övningen går fel.

Håll loopback-tester i sitt eget fack

En ping från en routers loopback är ett användbart test, och det övar ett annat fall än ett flöde från en värd. Källadressen tillhör routern, dess routingkontext kan vara global istället för en VRF, och svarsvägen kan skilja sig från den ett kundprefix skulle ta. Så loopbacken som svarar och applikationen som fungerar via genvägen är separata resultat, och bara det andra beskriver kunden.

Testa båda och märk dem sedan separat i dina anteckningar. När de inte stämmer överens har du lärt dig något konkret om var designen avviker, och det är mer än ett enda grönt kryss någonsin kommer att berätta.

Versions- och defektpåståenden behöver egna bevis

Fältrapporter rekommenderar ibland att ändra en värdmask eller en BGP-källadress, och sådana rapporter är bara värda att läsa tillsammans med defekten de skrevs om och de versioner den drabbade. En kringgång från en version är inte ett påstående att arkitekturen inte stöder något /32-prefix.

Använd dokumentation som matchar din DMVPN-fas, plattform och version, och kom ihåg att ett kapitel kan täcka flera uppsättningar, inklusive FlexVPN. Ett exempel från en uppsättning överförs inte tyst till en annan. Välj sessionsändar för den kontrollplansdesign du faktiskt behöver, och verifiera sedan kundens vidarebefordringsväg separat, eftersom att skriva om varje loopback-mask inte ersätter att ta reda på vilken uppgift som misslyckades.