Pojmenované vs. číslované DMVPN centrum: co mění FQDN

Spoke DMVPN může najít své centrum podle názvu hostitele na platformách, které tuto funkci podporují, a první pokušení je číst tento název jako jiný způsob zápisu adresy tunelu centra. Není to tak. Název se překládá na transportní koncový bod, zatímco adresa protokolu centra určuje další skok uvnitř overlaye a obě role přetrvávají v každé formě konfigurace. Tento rozdíl rozhoduje, co přejmenování může a nemůže opravit.

Dvě adresy, dva úkoly

V deklarovaném příkladu hub.example.net říká spokeu, kam posílat transportní provoz, a 10.90.0.1 určuje NHS uvnitř tunelu. Zjišťování pracuje s první; registrace a směrování pracují s druhou. Změna názvu ovlivňuje cestu ke koncovému bodu, zatímco změna adresy protokolu ovlivňuje samotný vztah overlaye.

Právě oddělení rolí dělá pojmenovanou formu laditelnou. Když se spoke nedokáže zaregistrovat, můžete položit dvě různé otázky: přeložil se název na adresu, kterou jsem očekával, a odpovídala tato adresa adrese protokolu, kterou konfigurace tvrdí? Žádná odpověď neimplikuje tu druhou.

Porovnejte obě formy konfigurace

Jedna forma konfiguruje adresu protokolu NHS explicitně vedle názvu. Druhá nechává spoke naučit se tuto adresu protokolu z odpovědi na registraci. Obě jsou zdokumentované a obě při úspěchu končí stejným typem vztahu s NHS.

Explicitní forma nese omezení, které stojí za zapamatování: přeložená transportní adresa, která se nemapuje na konfigurovanou adresu protokolu, brání registraci. Není to selhání DNS, i když se symptom objeví hned po změně DNS. Název se přeložil správně a výsledek byl odmítnut z jiného důvodu. Čtěte přeloženou adresu a konfigurovanou adresu protokolu vedle sebe.

Forma učení odstraňuje jeden ruční krok a jeden zdroj odchylek, za cenu závislosti na odpovědi při vytváření mapování. Zvolte explicitní formu, když je adresa centra stabilní a chcete, aby nesoulad hlasitě selhal. Zvolte formu učení, když se adresa protokolu centra může změnit a raději chcete, aby ji spoke následoval. V obou případech si poznamenejte, kterou formu návrh používá.

Porovnejte mezipaměť DNS se statickým centrem

Statická adresa centra se změní, když někdo upraví konfiguraci. Pojmenované centrum se změní, když se změní DNS, a odpovědi DNS se ukládají do mezipaměti na dobu své životnosti. Dokumentace uvádí, že informace v mezipaměti zůstávají použitelné, dokud nevyprší, a pozdější dotaz pak může vrátit novou adresu.

Tento rozdíl je rozdíl v čase, ne okamžitá migrace. Dlouhá životnost mezipaměti zpožďuje přijetí přejmenovaného koncového bodu a zpoždění je neviditelné, pokud sledujete jen záznam DNS. Plánujte přejmenování kolem životnosti mezipaměti a chování registrace nainstalované verze, místo abyste předpokládali, že se každý tunel přesune najednou.

Statická forma má samozřejmě své vlastní zpoždění: nic se nezmění, dokud se neupraví každý spoke. Srovnání je mezi koordinovaným zatlačením konfigurace a obnovením zjišťování z mezipaměti, ne mezi pomalým a okamžitým.

Porovnejte, co zůstává stejné

Ověřování protějšku se neposouvá. Název hostitele, který určuje transportní koncový bod, nenahrazuje konfigurovanou identitu IKE ani zásady ověřování, které protějšek validují. Pokud je identita špatná, úspěšné překlad DNS vás jen rychleji dostane k odmítnutému tunelu.

Chráněný provoz se také nemění. Odpovídající NHS nedokazuje, že trasa zákazníka existuje nebo že tok aplikace je povolen. Registrace, směrování a zásady jsou tři kontroly a název ovlivňuje jen první krok, který je napájí.

Srovnání, které můžete ověřit

Cisco dokumentuje oddělená pozorování pro relaci a vztah s NHS. Pomocí show dmvpn čtěte stav protějšku a relace a pomocí show ip nhrp nhs čtěte zobrazení registrace NHS. Porovnejte přeloženou transportní adresu, protějšek overlaye a stav registrace v tomto pořadí.

Kapitola IOS XE FQDN-DMVPN dokumentuje chování zjišťování, mezipaměti a omezení za tímto srovnáním. Přečtěte si ji proti nainstalované verzi, než přejmenované centrum budete považovat za přímou náhradu číslovaného.