DMVPN jerárquico: una nube por cada relación de túnel

Un nodo de sucursal se registra correctamente en su concentrador regional y aun así no alcanza un servicio en otra región. El túnel está activo, el estado de NHS parece saludable y el fallo solo aparece para destinos que cruzan un límite de nivel. Ese patrón suele significar que el diseño nunca declaró qué dispositivos participan en qué nube DMVPN, así que los niveles se construyeron por intuición y ahora no concuerdan.

El síntoma aparece en el límite de niveles

En un diseño jerárquico, un concentrador central, varios concentradores regionales y muchas sucursales ocupan cada uno una posición. Un concentrador regional puede tener más de una relación de túnel, y las sucursales no necesitan registrarse en cada punto central. Las rutas que importan son de sucursal a servicio regional, de sucursal a otro nodo regional aprobado y de sucursal a un destino central.

Cuando una de esas rutas falla mientras las demás funcionan, el problema casi siempre es una definición de rol ausente o contradictoria y no un túnel roto. Escriba las rutas previstas y compárelas con lo que los dispositivos construyeron realmente. Esa comparación lleva una hora y evita una semana de conjeturas. Guárdela junto con el documento de diseño.

Una nube, un contrato de interfaz

Para cada nube, registre la interfaz del túnel, el direccionamiento de superposición, la fuente local de la red subyacente, las relaciones NHS y NBMA, la entrega multicast y la política de protección. Indique también qué rutas cruzan entre los contextos regional y central, porque esa frase es el diseño.

Un concentrador regional con dos interfaces de túnel necesita dos contratos, no uno con dos direcciones. La fuente de la red subyacente, el dominio NHRP y las rutas pueden diferir por interfaz, y un documento que las fusiona engañará a quien configure la segunda.

Los identificadores son contexto local, no control de acceso

Los identificadores de red NHRP y las claves GRE son los dos valores que más a menudo se confunden con ajustes globales. La guía NHRP de IOS XE describe el identificador de red como localmente significativo, así que los números coincidentes en routers remotos no autentican nada y cambiar el número local de un router no crea una frontera de acceso.

Una clave GRE, cuando el diseño usa una, ayuda a identificar el contexto del túnel receptor y se acuerda entre los extremos que comparten ese contexto. No es una contraseña y no sustituye la autenticación IKE ni la política de enrutamiento. Trate ambos valores como contexto de configuración que debe coincidir dentro de una relación, no como controles de seguridad que separan regiones.

Enrute entre niveles deliberadamente

Decida qué prefijos anuncia el concentrador regional hacia arriba y qué destinos centrales ofrece a sus sucursales. Después compruebe el siguiente salto real y el comportamiento de atajo específico de la fase para cada ruta, porque una ruta resumen y un atajo pueden producir un reenvío muy distinto del que sugiere el diagrama.

Use el enrutamiento y la política de acceso para imponer la separación regional. Si una sucursal no debe alcanzar directamente otra región, la ruta y la política deben decirlo, en lugar de confiar en un identificador que nunca se diseñó para imponerlo. Escriba la política junto al identificador. De lo contrario, el siguiente ingeniero asumirá que el número hace el trabajo.

Diagnostique el atajo inesperado

Cuando una sucursal intenta crear una relación directa con un punto central, examine su ruta, su mapeo NHRP y el contexto de túnel seleccionado antes de cambiar identificadores al azar. La falta de accesibilidad, una relación NHS no deseada y un atajo legítimo pero no autorizado exigen tres correcciones distintas.

La guía de configuración de DMVPN muestra los ajustes de túnel y NHRP juntos, y por eso mismo los ámbitos deben separarse primero sobre el papel. Registre los contratos de la nube, mantenga explícitas las rutas de nivel y el próximo fallo de frontera tendrá dónde señalar.