Concentratore DMVPN con nome o numerato: cosa cambia il FQDN
Il FQDN di un concentratore individua l’endpoint NBMA, non l’indirizzo del tunnel. Confrontate cosa cambiano scoperta, registrazione e cache DNS quando un concentratore viene rinominato.
Uno spoke DMVPN può individuare il proprio concentratore tramite nome host sulle piattaforme che supportano la funzione, e la prima tentazione è leggere quel nome come un altro modo di scrivere l’indirizzo del tunnel del concentratore. Non lo è. Il nome si risolve in un endpoint di trasporto, mentre l’indirizzo di protocollo del concentratore identifica il salto successivo all’interno dell’overlay, ed entrambi i ruoli sopravvivono in ogni forma di configurazione. Questa distinzione decide cosa può e cosa non può correggere una rinomina.
Due indirizzi, due compiti
In un esempio dichiarato, hub.example.net indica allo spoke dove inviare il traffico di trasporto, e 10.90.0.1 identifica l’NHS all’interno del tunnel. La scoperta opera sul primo; la registrazione e l’instradamento operano sul secondo. Un cambiamento del nome influisce sul percorso verso l’endpoint, mentre un cambiamento dell’indirizzo di protocollo influisce sulla relazione di overlay stessa.
È la separazione dei ruoli che rende la forma con nome depurabile. Quando uno spoke non riesce a registrarsi, potete porre due domande diverse: il nome si è risolto nell’indirizzo che mi aspettavo, e quell’indirizzo corrispondeva all’indirizzo di protocollo dichiarato dalla configurazione? Nessuna risposta implica l’altra.
Confrontate le due forme di configurazione
Una forma configura esplicitamente l’indirizzo di protocollo dell’NHS accanto al nome. L’altra lascia che lo spoke apprenda quell’indirizzo di protocollo dalla risposta di registrazione. Entrambe sono documentate, ed entrambe terminano con lo stesso tipo di relazione NHS quando riescono.
La forma esplicita comporta una restrizione che vale la pena ricordare: un indirizzo di trasporto risolto che non corrisponde all’indirizzo di protocollo configurato impedisce la registrazione. Non è un guasto DNS, anche se il sintomo compare subito dopo un cambiamento DNS. Il nome si è risolto correttamente e il risultato è stato rifiutato per un altro motivo. Leggete l’indirizzo risolto e l’indirizzo di protocollo configurato fianco a fianco.
La forma di apprendimento elimina un passaggio manuale e una fonte di deriva, al costo di dipendere dalla risposta per stabilire la mappatura. Scegliete la forma esplicita quando l’indirizzo del concentratore è stabile e volete che la discrepanza fallisca in modo rumoroso. Scegliete la forma di apprendimento quando l’indirizzo di protocollo del concentratore può cambiare e preferite che lo spoke lo segua. In ogni caso, annotate quale forma usa il progetto.
Confrontate la cache DNS con un concentratore statico
Un indirizzo di concentratore statico cambia quando qualcuno modifica la configurazione. Un concentratore con nome cambia quando cambia il DNS, e le risposte DNS vengono memorizzate nella cache per la loro durata. La documentazione rileva che le informazioni in cache restano utilizzabili fino alla scadenza, e una query successiva può quindi restituire il nuovo indirizzo.
Questa differenza è una differenza di tempistica, non una migrazione istantanea. Una lunga durata della cache ritarda l’adozione di un endpoint rinominato, e il ritardo è invisibile se osservate solo il record DNS. Pianificate una rinomina intorno alla durata della cache e al comportamento di registrazione della versione installata, invece di presumere che ogni tunnel si sposti contemporaneamente.
La forma statica ha naturalmente il proprio ritardo: nulla cambia finché ogni spoke non viene modificato. Il confronto è tra una spinta di configurazione coordinata e un aggiornamento di scoperta in cache, non tra lento e istantaneo.
Confrontate ciò che resta uguale
L’autenticazione dei peer non si sposta. Un nome host che individua l’endpoint di trasporto non sostituisce l’identità IKE configurata né la politica di autenticazione che convalida il peer. Se l’identità è errata, una risoluzione DNS riuscita vi porta solo più rapidamente a un tunnel rifiutato.
Anche il traffico protetto è invariato. Un NHS che risponde non dimostra che la rotta del cliente esista o che il flusso applicativo sia consentito. Registrazione, instradamento e politica sono tre controlli, e il nome influisce solo sul primo passaggio che li alimenta.
Un confronto che potete verificare
Cisco documenta osservazioni separate per la sessione e per la relazione NHS. Usate show dmvpn per leggere lo stato del peer e della sessione, e show ip nhrp nhs per leggere la vista di registrazione NHS. Confrontate l’indirizzo di trasporto risolto, il peer dell’overlay e lo stato di registrazione in quest’ordine.
Il capitolo IOS XE FQDN-DMVPN documenta il comportamento di scoperta, cache e restrizione dietro questo confronto. Leggetelo rispetto alla versione installata prima di trattare un concentratore rinominato come sostituto diretto di uno numerato.