Concentrateur DMVPN nommé ou numéroté : ce que change le FQDN

Un spoke DMVPN peut localiser son concentrateur par nom d’hôte sur les plateformes qui prennent en charge cette fonction, et la première tentation est de lire ce nom d’hôte comme une autre façon d’écrire l’adresse de tunnel du concentrateur. Ce n’est pas le cas. Le nom se résout en un point de terminaison de transport, tandis que l’adresse de protocole du concentrateur identifie le saut suivant dans l’overlay, et les deux rôles subsistent dans chaque forme de configuration. Cette distinction détermine ce qu’un renommage peut corriger et ce qu’il ne peut pas.

Deux adresses, deux rôles

Dans un exemple déclaré, hub.example.net indique au spoke où envoyer le trafic de transport, et 10.90.0.1 identifie le NHS à l’intérieur du tunnel. La découverte agit sur la première ; l’enregistrement et le routage agissent sur la seconde. Un changement de nom affecte le chemin vers le point de terminaison, tandis qu’un changement d’adresse de protocole affecte la relation d’overlay elle-même.

C’est la séparation des rôles qui rend la forme nommée débogable. Lorsqu’un spoke ne parvient pas à s’enregistrer, vous pouvez poser deux questions différentes : le nom s’est-il résolu vers l’adresse que j’attendais, et cette adresse correspondait-elle à l’adresse de protocole revendiquée par la configuration ? Aucune réponse n’implique l’autre.

Comparez les deux formes de configuration

Une forme configure explicitement l’adresse de protocole du NHS à côté du nom. L’autre laisse le spoke apprendre cette adresse de protocole à partir de la réponse d’enregistrement. Les deux sont documentées, et les deux aboutissent au même type de relation NHS lorsqu’elles réussissent.

La forme explicite comporte une restriction qu’il vaut la peine de retenir : une adresse de transport résolue qui ne correspond pas à l’adresse de protocole configurée empêche l’enregistrement. Ce n’est pas une défaillance DNS, même si le symptôme apparaît juste après un changement DNS. Le nom s’est résolu correctement et le résultat a été rejeté pour une autre raison. Lisez l’adresse résolue et l’adresse de protocole configurée côte à côte.

La forme d’apprentissage supprime une étape manuelle et une source de dérive, au prix d’une dépendance à la réponse pour établir la correspondance. Choisissez la forme explicite lorsque l’adresse du concentrateur est stable et que vous voulez que l’incohérence échoue bruyamment. Choisissez la forme d’apprentissage lorsque l’adresse de protocole du concentrateur peut changer et que vous préférez que le spoke la suive. Dans tous les cas, notez quelle forme le design utilise.

Comparez le cache DNS à un concentrateur statique

Une adresse de concentrateur statique change lorsque quelqu’un modifie la configuration. Un concentrateur nommé change lorsque le DNS change, et les réponses DNS sont mises en cache pendant leur durée de vie. La documentation note que les informations en cache restent utilisables jusqu’à leur expiration, et une requête ultérieure peut alors renvoyer la nouvelle adresse.

Cette différence est une différence de timing, pas une migration instantanée. Une longue durée de vie du cache retarde l’adoption d’un point de terminaison renommé, et le retard est invisible si vous ne surveillez que l’enregistrement DNS. Planifiez un renommage autour de la durée de vie du cache et du comportement d’enregistrement de la version installée, plutôt que de supposer que chaque tunnel se déplace en même temps.

La forme statique a bien sûr son propre décalage : rien ne change tant que chaque spoke n’a pas été modifié. La comparaison oppose une poussée de configuration coordonnée à un rafraîchissement de découverte mis en cache, et non le lent à l’instantané.

Comparez ce qui reste identique

L’authentification des pairs ne bouge pas. Un nom d’hôte qui localise le point de terminaison de transport ne remplace ni l’identité IKE configurée ni la politique d’authentification qui valide le pair. Si l’identité est erronée, une résolution DNS réussie ne vous mène que plus vite à un tunnel rejeté.

Le trafic protégé est également inchangé. Un NHS qui répond ne prouve pas que la route du client existe ni que le flux applicatif est autorisé. L’enregistrement, le routage et la politique sont trois contrôles, et le nom n’affecte que la première étape qui les alimente.

Une comparaison vérifiable

Cisco documente des observations distinctes pour la session et pour la relation NHS. Utilisez show dmvpn pour lire l’état du pair et de la session, et show ip nhrp nhs pour lire la vue d’enregistrement NHS. Comparez l’adresse de transport résolue, le pair d’overlay et l’état d’enregistrement dans cet ordre.

Le chapitre IOS XE FQDN-DMVPN documente le comportement de découverte, de cache et de restriction derrière cette comparaison. Lisez-le au regard de votre version installée avant de traiter un concentrateur renommé comme un remplacement direct d’un concentrateur numéroté.