Namngiven kontra numrerad DMVPN-hubb: vad FQDN ändrar

En DMVPN-spoke kan hitta sin hubb via värdnamn på plattformar som stöder funktionen, och den första frestelsen är att läsa det värdnamnet som ett annat sätt att skriva hubbens tunneladress. Det är det inte. Namnet löses upp till en transportändpunkt, medan hubbens protokolladress identifierar nästa hopp inne i overlayskiktet, och båda rollerna består i varje konfigurationsform. Den skillnaden avgör vad ett namnbyte kan och inte kan åtgärda.

Två adresser, två uppgifter

I ett deklarerat exempel berättar hub.example.net för spaken vart transporttrafiken ska skickas, och 10.90.0.1 identifierar NHS:n inne i tunneln. Upptäckt arbetar på den första; registrering och routing arbetar på den andra. En ändring av namnet påverkar vägen till slutpunkten, medan en ändring av protokolladressen påverkar själva overlayrelationen.

Det är åtskillnaden av rollerna som gör den namngivna formen felsökningsbar. När en spoke inte kan registrera sig kan du ställa två olika frågor: löstes namnet upp till den adress jag förväntade mig, och stämde den adressen med den protokolladress som konfigurationen hävdar? Inget av svaren förutsätter det andra.

Jämför de två konfigurationsformerna

Den ena formen konfigurerar NHS-protokolladressen uttryckligen vid sidan av namnet. Den andra låter spaken lära sig den protokolladressen från registreringssvaret. Båda är dokumenterade, och båda slutar med samma typ av NHS-relation när de lyckas.

Den uttryckliga formen har en begränsning som är värd att komma ihåg: en upplöst transportadress som inte mappas till den konfigurerade protokolladressen hindrar registrering. Det är inte ett DNS-fel, även om symtomet visas direkt efter en DNS-ändring. Namnet löstes upp korrekt och resultatet avvisades av en annan anledning. Läs den upplösta adressen och den konfigurerade protokolladressen sida vid sida.

Lärformen tar bort ett manuellt steg och en källa till drift, till priset av att mappningen beror på svaret. Välj den uttryckliga formen när hubbadressen är stabil och du vill att avvikelsen ska misslyckas högt. Välj lärformen när hubbens protokolladress kan ändras och du hellre vill att spaken följer den. Anteckna i vilket fall vilken form designen använder.

Jämför DNS-cache med en statisk hubb

En statisk hubbadress ändras när någon redigerar konfigurationen. En namngiven hubb ändras när DNS ändras, och DNS-svar cachas under sin livstid. Dokumentationen noterar att cachad information förblir användbar tills den löper ut, och en senare fråga kan då returnera den nya adressen.

Skillnaden är en tidsskillnad, inte en omedelbar migrering. En lång cachelivstid fördröjer införandet av en slutpunkt med nytt namn, och fördröjningen är osynlig om du bara övervakar DNS-posten. Planera ett namnbyte kring cachelivstiden och registreringsbeteendet i den installerade versionen, i stället för att anta att varje tunnel flyttar samtidigt.

Den statiska formen har förstås sin egen fördröjning: ingenting ändras förrän varje spoke har redigerats. Jämförelsen står mellan en samordnad konfigurationsknuff och en cachad upptäcktsuppdatering, inte mellan långsam och omedelbar.

Jämför vad som förblir detsamma

Peer-autentisering flyttar sig inte. Ett värdnamn som hittar transportändpunkten ersätter inte den konfigurerade IKE-identiteten eller den autentiseringspolicy som validerar peeren. Om identiteten är fel leder en lyckad DNS-upplösning dig bara snabbare till en avvisad tunnel.

Skyddad trafik är också oförändrad. En NHS som svarar bevisar inte att kundens rutt finns eller att applikationsflödet är tillåtet. Registrering, routing och policy är tre kontroller, och namnet påverkar bara det första steget som matar dem.

En jämförelse du kan verifiera

Cisco dokumenterar separata observationer för sessionen och NHS-relationen. Använd show dmvpn för att läsa peer- och sessionstillstånd, och show ip nhrp nhs för att läsa NHS-registreringsvyn. Jämför den upplösta transportadressen, overlay-peeren och registreringstillståndet i den ordningen.

IOS XE FQDN-DMVPN-kapitlet dokumenterar upptäckts-, cache- och begränsningsbeteendet bakom denna jämförelse. Läs det mot din installerade version innan du behandlar en namngiven hubb som en direkt ersättning för en numrerad.