DMVPN xerárquico: unha nube por cada relación de túnel

Un nodo de sucursal rexístrase correctamente no seu concentrador rexional e aínda así non alcanza un servizo noutra rexión. O túnel está activo, o estado do NHS parece saudable, e o fallo só aparece para destinos que cruzan un límite de nivel. Ese patrón adoita significar que o deseño nunca declarou que dispositivos participan en que nube DMVPN, así que os niveis construíronse por intuición e agora non concordan.

O síntoma aparece no límite de niveis

Nun deseño xerárquico, un concentrador central, varios concentradores rexionais e moitas sucursais ocupan cada unha unha posición. Un concentrador rexional pode ter máis dunha relación de túnel, e as sucursais non necesitan rexistrarse en cada punto central. As rutas que importan son de sucursal a servizo rexional, de sucursal a outro nodo rexional aprobado e de sucursal a un destino central.

Cando unha desas rutas falla mentres as demais funcionan, o problema case sempre é unha definición de rol ausente ou contraditoria e non un túnel roto. Escriba as rutas previstas e compáraas co que os dispositivos construíron realmente. Esa comparación leva unha hora e evita unha semana de conxecturas. Gárdea xunto co documento de deseño.

Unha nube, un contrato de interface

Para cada nube, rexistre a interface do túnel, o direccionamento de superposición, a fonte local da rede subxacente, as relacións NHS e NBMA, a entrega multicast e a política de protección. Indique tamén que rutas cruzan entre os contextos rexional e central, porque esa frase é o deseño.

Un concentrador rexional con dúas interfaces de túnel necesita dous contratos, non un con dúas direccións. A fonte da rede subxacente, o dominio NHRP e as rutas poden diferir por interface, e un documento que as fusiona enganará a quen configure a segunda.

Os identificadores son contexto local, non control de acceso

Os identificadores de rede NHRP e as claves GRE son os dous valores que máis a miúdo se confunden con axustes globais. A guía NHRP de IOS XE describe o identificador de rede como localmente significativo, así que os números coincidentes en routers remotos non autentican nada e cambiar o número local dun router non crea unha fronteira de acceso.

Unha clave GRE, cando o deseño usa unha, axuda a identificar o contexto do túnel receptor e acórdase entre os extremos que comparten ese contexto. Non é un contrasinal e non substitúe a autenticación IKE nin a política de encamiñamento. Trate ambos valores como contexto de configuración que debe coincidir dentro dunha relación, non como controis de seguridade que separan rexións.

Encamiñe entre niveis deliberadamente

Decida que prefixos anuncia o concentrador rexional cara arriba e que destinos centrais ofrece ás súas sucursais. Despois comprobe o seguinte salto real e o comportamento de atallo específico da fase para cada ruta, porque unha ruta resumo e un atallo poden producir un reenvío moi distinto do que suxire o diagrama.

Use o encamiñamento e a política de acceso para impoñer a separación rexional. Se unha sucursal non debe alcanzar directamente outra rexión, a ruta e a política deben dicilo, en lugar de confiar nun identificador que nunca se deseñou para impoñelo. Escriba a política xunto ao identificador. Se non, o seguinte enxeñeiro asumirá que o número fai o traballo.

Diagnostique o atallo inesperado

Cando unha sucursal intenta crear unha relación directa cun punto central, examine a súa ruta, o seu mapeo NHRP e o contexto de túnel seleccionado antes de cambiar identificadores ao azar. A falta de accesibilidade, unha relación NHS non desexada e un atallo lexítimo pero non autorizado esixen tres correccións distintas.

A guía de configuración de DMVPN mostra os axustes de túnel e NHRP xuntos, e por iso mesmo os ámbitos deben separarse primeiro sobre o papel. Rexistre os contratos da nube, manteña explícitas as rutas de nivel e o próximo fallo de fronteira terá onde sinalar.