DMVPN fas 3: läsa genvägen i båda riktningarna

Du ser en ping gå från spoke till spoke den långa vägen genom hubben, och den andra går direkt. Det är frestande att förklara genvägen fungerande vid den punkten. Den slutsatsen är halvt rätt. Vägen fram kan vara en genväg medan vägen tillbaka fortfarande går genom hubben, och tillståndet som bevisar varje riktning är ett annat tillstånd. Gå igenom båda riktningarna och läs tre tabeller innan du accepterar designen som sund.

Börja med den paketväg du faktiskt kan se

Börja på en spoke med en destination som borde vara direkt. Följ det första paketet: det följer spokens rutt mot hubben, eftersom det ännu inte finns någon genväg. Hubben vidarebefordrar det och skickar i en fas 3-design också en omdirigering till källan om att det finns en bättre väg.

Den omdirigeringen är utlösaren, inte beviset. Den säger att hubben har sett trafik som kunde optimeras. Den säger inte att källan byggde genvägen, att destinationen svarade på uppslaget eller att returvägen använder den.

Så den första användbara observationen är ett före och efter: det första flödet genom hubben, det senare flödet direkt.

Tre tillstånd som ser ut som en enda tunnel

Genvägen beror på tre tillståndsdelar, och var och en har sin egen livstid och sitt eget kommando.

En NHRP-cachepost kopplar en overlay-adress till en NBMA-transportadress. En rutt eller genväg avgör vart en inre destination vidarebefordras. En IPsec-association skyddar den trafik som blir resultatet. Ett saknat svar kan komma från vilken som helst av de tre, och kommandona talar om vilken som saknas.

Läs dem i den ordningen, eftersom en saknad mappning gör de andra två ointressanta.

Gå igenom förfrågan och svaret var för sig

Från spoke A, begär uppslaget och se vad som kommer tillbaka. Förfrågan går via den stödda NHRP-vidarebefordringsvägen, och destinationen kan svara direkt i stället för genom hubben. Den asymmetrin är normal, och därför är svaret den intressanta halvan av utbytet.

Byt nu roller. Skicka från B till A och upprepa samma tre läsningar. En design som genvägar den ena riktningen och inte den andra är inte symmetrisk, och asymmetrin kommer vanligtvis från ett saknat prefix på ena sidan eller ett uppslag som aldrig fick svar.

Motpartens svar behöver inte passera hubben bara för att förfrågan gjorde det. Läs inte det som ett fel och börja inte jaga ett routingfel som inte finns.

Läs hubbens omdirigering, inte bara dess rutt

Hubbens rutttabell talar om vart hubben skulle skicka ett paket. Omdirigeringen talar om vad hubben bad källan göra åt saken. Det är olika fakta, och en hubb med korrekt rutt och utan omdirigeringar håller varje flöde på den långa vägen på obestämd tid. Kontrollera hubbens NHRP-händelser och bekräfta att omdirigeringar genereras för den trafik du bryr dig om.

Fas 3 ändrar också vad sammanfattning betyder. Med genvägsbeteende behöver spokes inte hela uppsättningen specifika fjärrrutter som en fas 2-design förväntade, så en sammanfattad rutt på spoken är inte automatiskt ett saknat nätverk. Bekräfta fasen och routingpolicyn innan du läser en sammanfattning som ett fel.

Det enda missförståndet skapar fler DMVPN-ärenden än något annat.

Skriv ner slutsatsen som ett saknat objekt

Avsluta med ett auktoriserat applikationsflöde och dess svar, och notera för varje riktning om den använde den direkta vägen. Skriv sedan slutsatsen som objektet som saknades: en mappning, en vidarebefordringsgenväg, en skyddsassociation eller ett applikationssvar.

Ett routinggrannskap och en delad säkerhetsassociation är bevis på sundhet, inte bevis på vägen. Båda kan vara perfekta medan varje paket fortfarande tar den långa omvägen. Kontrollera vidarebefordringsbeslutet först och sedan associationen som bär det. Ordningen spelar roll, eftersom associationen bildas ändå.

Den vanan lönar sig på nästa ärende. «Tunneln är uppe men långsam» blir «B har ingen genväg till A:s värd», och det andra påståendet är en rättelse på fem minuter. Spara kommandots utdata tillsammans med slutsatsen och ha leverantörens fas 3-genomgång bredvid.