Navngitt kontra nummerert DMVPN-hub: hva FQDN endrer

En DMVPN-spoke kan finne huben sin via vertsnavn på plattformer som støtter funksjonen, og den første fristelsen er å lese det vertsnavnet som en annen måte å skrive hubens tunneladresse på. Det er det ikke. Navnet løses til et transportendepunkt, mens hubens protokolladresse identifiserer neste hopp inne i overlayet, og de to rollene består i enhver konfigurasjonsform. Den forskjellen avgjør hva en navneendring kan og ikke kan rette.

To adresser, to jobber

I et erklært eksempel forteller hub.example.net spoken hvor den skal sende transporttrafikk, og 10.90.0.1 identifiserer NHS-en inne i tunnelen. Oppdagelse arbeider på den første; registrering og ruting arbeider på den andre. En endring av navnet påvirker veien til endepunktet, mens en endring av protokolladressen påvirker selve overlay-forholdet.

Det er atskillelsen av rollene som gjør den navngitte formen feilsøkbar. Når en spoke ikke klarer å registrere seg, kan du stille to ulike spørsmål: ble navnet løst til adressen jeg forventet, og samsvarte den adressen med protokolladressen konfigurasjonen hevder? Ingen av svarene forutsetter det andre.

Sammenlign de to konfigurasjonsformene

Den ene formen konfigurerer NHS-protokolladressen eksplisitt sammen med navnet. Den andre lar spoken lære den protokolladressen fra registreringssvaret. Begge er dokumentert, og begge ender med samme slags NHS-forhold når de lykkes.

Den eksplisitte formen har en begrensning det er verdt å huske: en oppløst transportadresse som ikke samsvarer med den konfigurerte protokolladressen, hindrer registrering. Det er ikke en DNS-feil, selv om symptomet vises rett etter en DNS-endring. Navnet ble løst riktig, og resultatet ble avvist av en annen grunn. Les den oppløste adressen og den konfigurerte protokolladressen side ved side.

Læringsformen fjerner ett manuelt trinn og én kilde til drift, mot at mappingen avhenger av svaret. Velg den eksplisitte formen når hubadressen er stabil og du vil at avviket skal feile høyt. Velg læringsformen når hubens protokolladresse kan endre seg og du heller vil at spoken skal følge den. Noter uansett hvilken form designet bruker.

Sammenlign DNS-buffer med en statisk hub

En statisk hubadresse endres når noen redigerer konfigurasjonen. En navngitt hub endres når DNS endres, og DNS-svar bufres for levetiden deres. Dokumentasjonen bemerker at bufret informasjon forblir brukbar til den utløper, og en senere spørring kan da returnere den nye adressen.

Forskjellen er en tidsforskjell, ikke en øyeblikkelig migrering. En lang bufferlevetid forsinker innføringen av et endepunkt med nytt navn, og forsinkelsen er usynlig hvis du bare overvåker DNS-posten. Planlegg en navneendring rundt bufferlevetiden og registreringsatferden til den installerte versjonen, i stedet for å anta at hver tunnel flytter samtidig.

Den statiske formen har naturligvis sin egen forsinkelse: ingenting endres før hver spoke er redigert. Sammenligningen står mellom et koordinert konfigurasjonsskyv og en bufret oppdagelsesoppdatering, ikke mellom langsom og øyeblikkelig.

Sammenlign hva som forblir det samme

Peer-autentisering flytter seg ikke. Et vertsnavn som finner transportendepunktet, erstatter ikke den konfigurerte IKE-identiteten eller autentiseringspolicyen som validerer peeren. Hvis identiteten er feil, bringer en vellykket DNS-oppløsning deg bare raskere til en avvist tunnel.

Beskyttet trafikk er også uendret. En NHS som svarer, beviser ikke at kundens rute finnes eller at applikasjonsflyten er tillatt. Registrering, ruting og policy er tre kontroller, og navnet påvirker bare det første trinnet som mater dem.

En sammenligning du kan verifisere

Cisco dokumenterer separate observasjoner for sesjonen og NHS-forholdet. Bruk show dmvpn til å lese peer- og sesjonstilstand, og show ip nhrp nhs til å lese NHS-registreringsvisningen. Sammenlign den oppløste transportadressen, overlay-peeren og registreringstilstanden i den rekkefølgen.

IOS XE FQDN-DMVPN-kapitlet dokumenterer oppdagelses-, buffer- og begrensningsatferden bak denne sammenligningen. Les det mot din installerte versjon før du behandler en navngitt hub som en direkte erstatning for en nummerert.