Navngivet kontra nummereret DMVPN-hub: hvad FQDN ændrer
En hub-FQDN finder NBMA-endepunktet, ikke tunneladressen. Sammenlign, hvad opdagelse, registrering og DNS-cache hver især ændrer, når en hub omdøbes.
En DMVPN-spoke kan finde sin hub via værtsnavn på platforme, der understøtter funktionen, og den første fristelse er at læse det værtsnavn som en anden måde at skrive hubens tunneladresse på. Det er det ikke. Navnet opløses til et transportendepunkt, mens hubens protokoladresse angiver det næste hop inde i overlayet, og de to roller består i enhver konfigurationsform. Den sondring afgør, hvad en omdøbning kan og ikke kan rette.
To adresser, to opgaver
I et erklæret eksempel fortæller hub.example.net spoken, hvor den skal sende transporttrafik, og 10.90.0.1 angiver NHS'en inde i tunnelen. Opdagelse arbejder på den første; registrering og routing arbejder på den anden. En ændring af navnet påvirker vejen til endepunktet, mens en ændring af protokoladressen påvirker selve overlay-forholdet.
Det er adskillelsen af rollerne, der gør den navngivne form fejlfindbar. Når en spoke ikke kan registrere sig, kan du stille to forskellige spørgsmål: blev navnet opløst til den adresse, jeg forventede, og passede den adresse til den protokoladresse, konfigurationen hævder? Ingen af svarene forudsætter det andet.
Sammenlign de to konfigurationsformer
Den ene form konfigurerer NHS-protokoladressen eksplicit sammen med navnet. Den anden lader spoken lære den protokoladresse fra registreringssvaret. Begge er dokumenteret, og begge ender med samme slags NHS-forhold, når de lykkes.
Den eksplicitte form har en begrænsning, der er værd at huske: en opløst transportadresse, der ikke svarer til den konfigurerede protokoladresse, forhindrer registrering. Det er ikke en DNS-fejl, selv om symptomet viser sig lige efter en DNS-ændring. Navnet blev opløst korrekt, og resultatet blev afvist af en anden grund. Læs den opløste adresse og den konfigurerede protokoladresse side om side.
Læringsformen fjerner et manuelt trin og en kilde til drift, til gengæld for at afhænge af svaret for at fastlægge mappingen. Vælg den eksplicitte form, når hubadressen er stabil, og du vil have misforholdet til at fejle højt. Vælg læringsformen, når hubens protokoladresse kan ændre sig, og du hellere vil have spoken til at følge den. Under alle omstændigheder skal du notere, hvilken form designet bruger.
Sammenlign DNS-cache med en statisk hub
En statisk hubadresse ændres, når nogen redigerer konfigurationen. En navngivet hub ændres, når DNS ændres, og DNS-svar caches i deres levetid. Dokumentationen bemærker, at cachede oplysninger forbliver brugbare, indtil de udløber, og en senere forespørgsel kan derefter returnere den nye adresse.
Forskellen er en timingforskel, ikke en øjeblikkelig migrering. En lang cachelevetid forsinker ibrugtagningen af et omdøbt endepunkt, og forsinkelsen er usynlig, hvis du kun overvåger DNS-posten. Planlæg en omdøbning omkring cachelevetiden og registreringsadfærden for den installerede version i stedet for at antage, at hver tunnel flytter på én gang.
Den statiske form har naturligvis sin egen forsinkelse: intet ændres, før hver spoke er redigeret. Sammenligningen er mellem et koordineret konfigurationsskub og en cachet opdagelsesopdatering, ikke mellem langsom og øjeblikkelig.
Sammenlign, hvad der forbliver det samme
Peer-godkendelse flytter sig ikke. Et værtsnavn, der finder transportendepunktet, erstatter ikke den konfigurerede IKE-identitet eller den godkendelsespolitik, der validerer peeren. Hvis identiteten er forkert, bringer en vellykket DNS-opløsning dig bare hurtigere til en afvist tunnel.
Beskyttet trafik er også uændret. En svarende NHS beviser ikke, at kundens rute findes, eller at applikationsflowet er tilladt. Registrering, routing og politik er tre kontroller, og navnet påvirker kun det første trin, der fodrer dem.
En sammenligning, du kan verificere
Cisco dokumenterer separate observationer for sessionen og NHS-forholdet. Brug show dmvpn til at læse peer- og sessionstilstand, og show ip nhrp nhs til at læse NHS-registreringsvisningen. Sammenlign den opløste transportadresse, overlay-peeren og registreringstilstanden i den rækkefølge.
Kapitlet IOS XE FQDN-DMVPN dokumenterer opdagelses-, cache- og begrænsningsadfærden bag denne sammenligning. Læs det mod din installerede version, før du behandler en omdøbt hub som en direkte erstatning for en nummereret.