Concentrador DMVPN con nombre frente a numerado: qué cambia el FQDN
El FQDN de un concentrador localiza el extremo NBMA, no la dirección del túnel. Compare qué cambian el descubrimiento, el registro y la caché de DNS cuando se renombra un concentrador.
Un spoke de DMVPN puede localizar su concentrador por nombre de host en plataformas que admiten esa función, y la primera tentación es leer ese nombre como otra forma de escribir la dirección del túnel del concentrador. No lo es. El nombre se resuelve en un extremo de transporte, mientras que la dirección de protocolo del concentrador identifica el siguiente salto dentro del overlay, y ambos papeles se mantienen en cada forma de configuración. Esa distinción decide qué puede corregir un cambio de nombre y qué no.
Dos direcciones, dos tareas
En un ejemplo declarado, hub.example.net indica al spoke dónde enviar el tráfico de transporte, y 10.90.0.1 identifica el NHS dentro del túnel. El descubrimiento opera sobre la primera; el registro y el enrutamiento operan sobre la segunda. Un cambio en el nombre afecta la ruta hacia el extremo, mientras que un cambio en la dirección de protocolo afecta la relación de overlay en sí.
Mantener separados los papeles es lo que hace depurable la forma con nombre. Cuando un spoke no logra registrarse, puede plantear dos preguntas distintas: ¿se resolvió el nombre a la dirección que esperaba, y coincidía esa dirección con la dirección de protocolo que afirma la configuración? Ninguna respuesta implica la otra.
Compare las dos formas de configuración
Una forma configura explícitamente la dirección de protocolo del NHS junto al nombre. La otra permite que el spoke aprenda esa dirección de protocolo de la respuesta de registro. Ambas están documentadas y ambas terminan con el mismo tipo de relación con el NHS cuando tienen éxito.
La forma explícita conlleva una restricción que conviene recordar: una dirección de transporte resuelta que no se asigna a la dirección de protocolo configurada impide el registro. No es un fallo de DNS, aunque el síntoma aparece justo después de un cambio de DNS. El nombre se resolvió correctamente y el resultado se rechazó por otro motivo. Lea la dirección resuelta y la dirección de protocolo configurada una junto a otra.
La forma de aprendizaje elimina un paso manual y una fuente de deriva, a costa de depender de la respuesta para establecer la asignación. Elija la forma explícita cuando la dirección del concentrador sea estable y quiera que la discrepancia falle de forma ruidosa. Elija la forma de aprendizaje cuando la dirección de protocolo del concentrador pueda cambiar y prefiera que el spoke la siga. En cualquier caso, anote qué forma usa el diseño.
Compare la caché de DNS con un concentrador estático
Una dirección de concentrador estática cambia cuando alguien edita la configuración. Un concentrador con nombre cambia cuando cambia el DNS, y las respuestas de DNS se almacenan en caché durante su vida útil. La documentación señala que la información en caché sigue siendo utilizable hasta que caduca, y una consulta posterior puede devolver entonces la nueva dirección.
Esa diferencia es una diferencia de tiempo, no una migración instantánea. Una vida útil larga de la caché retrasa la adopción de un extremo renombrado, y el retraso es invisible si solo vigila el registro de DNS. Planifique un cambio de nombre en torno a la vida útil de la caché y el comportamiento de registro de la versión instalada, en lugar de suponer que cada túnel se mueve a la vez.
La forma estática tiene, por supuesto, su propio retraso: nada cambia hasta que se edita cada spoke. La comparación es entre un empuje coordinado de configuración y una actualización de descubrimiento en caché, no entre lento e instantáneo.
Compare qué permanece igual
La autenticación de pares no se mueve. Un nombre de host que localiza el extremo de transporte no sustituye la identidad IKE configurada ni la política de autenticación que valida el par. Si la identidad es incorrecta, una resolución de DNS correcta solo le lleva más rápido a un túnel rechazado.
El tráfico protegido tampoco cambia. Un NHS que responde no demuestra que exista la ruta del cliente ni que se permita el flujo de la aplicación. El registro, el enrutamiento y la política son tres comprobaciones, y el nombre solo afecta al primer paso que las alimenta.
Una comparación que puede verificar
Cisco documenta observaciones separadas para la sesión y para la relación con el NHS. Use show dmvpn para leer el estado del par y de la sesión, y show ip nhrp nhs para leer la vista de registro del NHS. Compare la dirección de transporte resuelta, el par del overlay y el estado de registro en ese orden.
El capítulo IOS XE FQDN-DMVPN documenta el comportamiento de descubrimiento, caché y restricción que hay detrás de esta comparación. Léalo contra su versión instalada antes de tratar un concentrador renombrado como un sustituto directo de uno numerado.