DMVPN fase 3: lese snarveien i begge retninger

Du ser én ping gå fra spoke til spoke den lange veien gjennom huben, og den andre går direkte. Det er fristende å erklære snarveien som fungerende på det punktet. Den konklusjonen er halvveis riktig. Veien fram kan være en snarvei mens veien tilbake fortsatt går gjennom huben, og tilstanden som beviser hver retning er en annen tilstand. Gå gjennom begge retninger og les tre tabeller før du godtar designet som sunt.

Start med pakkeveien du faktisk kan se

Begynn på en spoke med en destinasjon som burde være direkte. Følg den første pakken: den følger spokens rute mot huben, fordi det ennå ikke finnes noen snarvei. Huben videresender den og sender i et fase 3-design også en omdirigering til kilden om at det finnes en bedre vei.

Den omdirigeringen er utløseren, ikke beviset. Den sier at huben har sett trafikk som kunne optimaliseres. Den sier ikke at kilden bygde snarveien, at destinasjonen svarte på oppslaget, eller at returveien bruker den.

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

Tre tilstander som ser ut som én tunnel

Snarveien avhenger av tre tilstandsdeler, og hver har sin egen levetid og sin egen kommando.

En NHRP-bufferoppføring kobler en overlay-adresse til en NBMA-transportadresse. En rute eller snarvei avgjør hvor én indre destinasjon videresendes. En IPsec-tilknytning beskytter trafikken som følger. Et manglende svar kan komme fra en av de tre, og kommandoene forteller deg hvilken som mangler.

Les dem i den rekkefølgen, fordi en manglende kobling gjør de to andre uinteressante.

Gå gjennom forespørselen og svaret hver for seg

Fra spoke A, be om oppslaget og se hva som kommer tilbake. Forespørselen går gjennom den støttede NHRP-videresendingsveien, og destinasjonen kan svare direkte i stedet for gjennom huben. Den asymmetrien er normal, og derfor er svaret den interessante halvdelen av utvekslingen.

Bytt nå roller. Send fra B til A og gjenta de samme tre lesingene. Et design som snarveier den ene retningen og ikke den andre, er ikke symmetrisk, og asymmetrien kommer vanligvis fra et manglende prefiks på den ene siden eller et oppslag som aldri fikk svar.

Motpartens svar trenger ikke å passere huben bare fordi forespørselen gjorde det. Ikke les det som en feil, og ikke begynn å jage en rutingfeil som ikke finnes.

Les hubens omdirigering, ikke bare ruten dens

Hubens rutetabell forteller deg hvor huben ville sende en pakke. Omdirigeringen forteller deg hva huben ba kilden gjøre med det. Det er forskjellige fakta, og en hub med riktig rute og ingen omdirigeringer holder hver flyt på den lange veien på ubestemt tid. Sjekk hubens NHRP-hendelser og bekreft at omdirigeringer genereres for trafikken du bryr deg om.

Fase 3 endrer også hva oppsummering betyr. Med snarveiadferd trenger ikke spokes hele settet med spesifikke fjernruter som et fase 2-design forventet, så en oppsummert rute på spoken er ikke automatisk et manglende nettverk. Bekreft fasen og rutingpolitikken før du leser en oppsummering som en feil.

Den ene misforståelsen skaper flere DMVPN-saker enn noe annet.

Skriv konklusjonen som et manglende objekt

Avslutt med en autorisert applikasjonsflyt og svaret dens, og noter for hver retning om den brukte den direkte veien. Skriv deretter konklusjonen som objektet som manglet: en kobling, en videresendingssnarvei, en beskyttelsestilknytning eller et applikasjonssvar.

Et rutenaboskap og en delt sikkerhetstilknytning er bevis på sunnhet, ikke bevis på veien. Begge kan være perfekte mens hver pakke fortsatt tar den lange omveien. Sjekk videresendingsbeslutningen først, deretter tilknytningen som bærer den. Rekkefølgen betyr noe, fordi tilknytningen dannes uansett.

Den vanen betaler seg på neste sak. «Tunnelen er oppe, men treg» blir «B har ingen snarvei til A sin vert», og den andre påstanden er en fem-minutters rettelse. Ta vare på kommandoens utdata sammen med konklusjonen, og ha leverandørens fase 3-gjennomgang ved siden av.