Benoemde versus genummerde DMVPN-hub: wat de FQDN verandert

Een DMVPN-spoke kan zijn hub via een hostnaam vinden op platforms die deze functie ondersteunen, en de eerste verleiding is om die hostnaam te lezen als een andere manier om het tunneladres van de hub te schrijven. Dat is het niet. De naam wordt omgezet naar een transporteindpunt, terwijl het protocoladres van de hub de volgende hop binnen de overlay identificeert, en beide rollen blijven in elke configuratievorm behouden. Dat onderscheid bepaalt wat een hernoeming kan en niet kan oplossen.

Twee adressen, twee taken

In een verklaard voorbeeld vertelt hub.example.net de spoke waar transportverkeer naartoe moet, en 10.90.0.1 identificeert de NHS binnen de tunnel. Ontdekking werkt op het eerste; registratie en routing werken op het tweede. Een wijziging van de naam beïnvloedt het pad naar het eindpunt, terwijl een wijziging van het protocoladres de overlay-relatie zelf beïnvloedt.

Het scheiden van de rollen is wat de benoemde vorm debugbaar maakt. Wanneer een spoke niet kan registreren, kun je twee verschillende vragen stellen: is de naam omgezet naar het adres dat ik verwachtte, en kwam dat adres overeen met het protocoladres dat de configuratie beweert? Geen van beide antwoorden impliceert het andere.

Vergelijk de twee configuratievormen

De ene vorm configureert het NHS-protocoladres expliciet naast de naam. De andere laat de spoke dat protocoladres uit het registratieantwoord leren. Beide zijn gedocumenteerd, en beide eindigen bij succes met hetzelfde soort NHS-relatie.

De expliciete vorm heeft een beperking die het onthouden waard is: een opgelost transportadres dat niet aan het geconfigureerde protocoladres wordt toegewezen, verhindert registratie. Dat is geen DNS-storing, ook al verschijnt het symptoom direct na een DNS-wijziging. De naam is correct omgezet en het resultaat werd om een andere reden afgewezen. Lees het opgeloste adres en het geconfigureerde protocoladres naast elkaar.

De lerende vorm verwijdert één handmatige stap en één bron van drift, tegen de prijs van afhankelijkheid van het antwoord om de mapping vast te leggen. Kies de expliciete vorm wanneer het hubadres stabiel is en je wilt dat de mismatch luid faalt. Kies de lerende vorm wanneer het protocoladres van de hub kan veranderen en je liever hebt dat de spoke het volgt. Noteer hoe dan ook welke vorm het ontwerp gebruikt.

Vergelijk DNS-cache met een statische hub

Een statisch hubadres verandert wanneer iemand de configuratie aanpast. Een benoemde hub verandert wanneer DNS verandert, en DNS-antwoorden worden voor hun levensduur gecachet. De documentatie merkt op dat gecachte informatie bruikbaar blijft totdat deze verloopt, en een latere query kan dan het nieuwe adres teruggeven.

Dat verschil is een timingverschil, geen onmiddellijke migratie. Een lange cachelevensduur vertraagt de adoptie van een hernoemd eindpunt, en de vertraging is onzichtbaar als je alleen het DNS-record volgt. Plan een hernoeming rond de cachelevensduur en het registratiegedrag van de geïnstalleerde release, in plaats van aan te nemen dat elke tunnel tegelijk beweegt.

De statische vorm heeft natuurlijk zijn eigen vertraging: niets verandert totdat elke spoke is aangepast. De vergelijking is tussen een gecoördineerde configuratiestoot en een gecachte ontdekkingsvernieuwing, niet tussen traag en onmiddellijk.

Vergelijk wat hetzelfde blijft

Peer-authenticatie beweegt niet. Een hostnaam die het transporteindpunt vindt, vervangt niet de geconfigureerde IKE-identiteit of het authenticatiebeleid dat de peer valideert. Als de identiteit verkeerd is, brengt een geslaagde DNS-resolutie je alleen sneller naar een geweigerde tunnel.

Beveiligd verkeer is ook ongewijzigd. Een reagerende NHS bewijst niet dat de klantroute bestaat of dat de applicatiestroom is toegestaan. Registratie, routing en beleid zijn drie controles, en de naam beïnvloedt alleen de eerste stap die ze voedt.

Een vergelijking die je kunt verifiëren

Cisco documenteert afzonderlijke observaties voor de sessie en de NHS-relatie. Gebruik show dmvpn om de peer- en sessiestatus te lezen, en show ip nhrp nhs om de NHS-registratieweergave te lezen. Vergelijk het opgeloste transportadres, de overlay-peer en de registratiestatus in die volgorde.

Het IOS XE FQDN-DMVPN-hoofdstuk documenteert het ontdekkings-, cache- en beperkingsgedrag achter deze vergelijking. Lees het tegen je geïnstalleerde release voordat je een hernoemde hub als een directe vervanging van een genummerde behandelt.