DMVPN fase 3: lese snarvegen i begge retningar

Du ser éin ping gå frå spoke til spoke den lange vegen gjennom huben, og den andre går direkte. Det er freistande å erklære snarvegen som verkar på det punktet. Den konklusjonen er halvvegs riktig. Vegen fram kan vere ein snarveg medan vegen tilbake framleis går gjennom huben, og tilstanden som provar kvar retning er ein annan tilstand. Gå gjennom begge retningar og les tre tabellar før du godtek designet som sunt.

Start med pakkevegen du faktisk kan sjå

Byrja på ein spoke med ein destinasjon som burde vere direkte. Følg den første pakken: han følgjer ruta til spoken mot huben, fordi det enno ikkje finst nokon snarveg. Huben vidaresender han og sender i eit fase 3-design òg ei omdirigering til kjelda om at det finst ein betre veg.

Den omdirigeringa er utløysaren, ikkje provet. Ho seier at huben har sett trafikk som kunne optimaliserast. Ho seier ikkje at kjelda bygde snarvegen, at destinasjonen svara på oppslaget, eller at returvegen brukar han.

Så den første nyttige observasjonen er ein før og etter: den første flyten gjennom huben, den seinare flyten direkte.

Tre tilstandar som ser ut som éin tunnel

Snarvegen er avhengig av tre tilstandsdelar, og kvar har si eiga levetid og sin eigen kommando.

Ein NHRP-bufferoppføring koplar ein overlay-adresse til ei NBMA-transportadresse. Ei rute eller ein snarveg avgjer kvar ein indre destinasjon blir vidaresend. Ei IPsec-tilknyting vernar trafikken som følgjer. Eit manglande svar kan kome frå ein av dei tre, og kommandoane fortel deg kven som manglar.

Les dei i den rekkjefølgja, fordi ein manglande kopling gjer dei to andre uinteressante.

Gå gjennom førespurnaden og svaret kvar for seg

Frå spoke A, be om oppslaget og sjå kva som kjem tilbake. Førespurnaden går gjennom den støtta NHRP-vidaresendingsvegen, og destinasjonen kan svare direkte i staden for gjennom huben. Den asymmetrien er normal, og difor er svaret den interessante halvdelen av utvekslinga.

Byt no roller. Send frå B til A og gjer dei same tre lesingane om att. Eit design som snarvegar den eine retninga og ikkje den andre, er ikkje symmetrisk, og asymmetrien kjem vanlegvis frå eit manglande prefiks på den eine sida eller eit oppslag som aldri fekk svar.

Svaret til motparten treng ikkje å passere huben berre fordi førespurnaden gjorde det. Ikkje les det som ein feil, og ikkje byrja å jage ein rutefeil som ikkje finst.

Les omdirigeringa til huben, ikkje berre ruta hans

Rutetabellen til huben fortel deg kvar huben ville sende ein pakke. Omdirigeringa fortel deg kva huben bad kjelda gjere med det. Det er ulike fakta, og ein hub med rett rute og ingen omdirigeringar held kvar flyt på den lange vegen på ubestemt tid. Sjekk NHRP-hendingane til huben og stadfest at omdirigeringar blir genererte for trafikken du bryr deg om.

Fase 3 endrar òg kva oppsummering tyder. Med snarvegåtferd treng ikkje spokes heile settet med spesifikke fjernruter som eit fase 2-design forventa, så ei oppsummert rute på spoken er ikkje automatisk eit manglande nettverk. Stadfest fasen og rutepolitikken før du les ei oppsummering som ein feil.

Den eine mistydinga skapar fleire DMVPN-saker enn noko anna.

Skriv konklusjonen som eit manglande objekt

Avslutt med ein autorisert applikasjonsflyt og svaret hans, og noter for kvar retning om han brukte den direkte vegen. Skriv deretter konklusjonen som objektet som mangla: ei kopling, ein vidaresendingssnarveg, ein verneassosiasjon eller eit applikasjonssvar.

Eit rutenaboskap og ein delt sikkerheitstilknyting er prov på sunnheit, ikkje prov på vegen. Begge kan vere perfekte medan kvar pakke framleis tek den lange omvegen. Sjekk vidaresendingsavgjerda først, deretter tilknytinga som ber henne. Rekkjefølgja betyr noko, fordi tilknytinga blir danna uansett.

Den vanen betaler seg på neste sak. «Tunnelen er oppe, men treg» blir «B har ingen snarveg til verten til A», og den andre påstanden er ei fem-minutts retting. Ta vare på utdata frå kommandoen saman med konklusjonen, og ha fase 3-gjennomgangen til leverandøren ved sida av.