Veciño EIGRP ou tránsito DMVPN? Comproba primeiro o rol

Falta a adxacencia e o enrutador do medio parece o sospeitoso obvio. Pode ser inocente. Reenviar os paquetes externos do túnel e participar no protocolo de enrutamento overlay son dous traballos distintos, e un equipo pode facer o primeiro sen facer o segundo. Fai as cinco comprobacións seguintes en orde e detente na primeira que falle.

Paso 1: debuxa os dous roles

Debuxa a adxacencia EIGRP prevista como unha conexión lóxica entre dous enrutadores e, despois, debuxa os enrutadores underlay que transportan os seus paquetes de túnel. O mesmo equipo non ten que aparecer nas dúas listas, e confundir as listas é a razón máis habitual de que se acuse a un enrutador de tránsito san de romper a adxacencia.

Un enrutador de tránsito reenvía os paquetes externos co seu enrutamento IP e a súa política habituais. Non necesita executar o protocolo que viaxa dentro do túnel protexido nin necesita un proceso EIGRP para facer pasar eses paquetes.

Paso 2: comproba que termina o dispositivo do medio

Se o enrutador do medio termina o túnel e debe formar adxacencias EIGRP cos spoke, a resposta cambia por completo. Ese equipo necesita o comportamento de enrutamento overlay admitido, e chamalo tránsito non fai desaparecer o requisito de veciño. Le a configuración do túnel antes que a do enrutamento. Esa resposta decide todas as comprobacións que seguen.

Así que a primeira pregunta real non é que protocolo axustar. É se a caixa é un hub, un spoke, un simple salto underlay ou un servizo Layer 2 que transporta tramas entre extremos.

Paso 3: verifica o plano de control do veciño

En cada equipo que deba ser veciño, confirma catro cousas: a instancia EIGRP e o número de sistema autónomo, os parámetros de autenticación, a interface que participa no proceso e a sentenza de rede que cobre esa interface. Un desaxuste en calquera delas mantén a adxacencia baixa mentres a interface segue activa e o ping segue funcionando.

O RFC 7868 describe EIGRP como un protocolo IP cun intercambio de control por multicast, e por iso unha relación de veciñanza non é algo que un enrutador intermedio poida suplir enrutando paquetes cara a un destino. Ou o intercambio de control chega ao par, ou a adxacencia non se forma.

Paso 4: verifica que o transporte entrega o intercambio de control

A continuación, comproba que o overlay transporta realmente o tráfico de control entre os extremos previstos. Inspecciona o mapeo NHRP do par e a ruta externa que chega ata el, e despois confirma que a interface do túnel está activa e deixa pasar tráfico. Un ping underlay correcto demostra que o camiño externo existe; non demostra que se entregase o intercambio de control do overlay.

Un servizo Layer 2 transparente, un túnel punto a punto e unha nube DMVPN multipunto entregan o multicast de formas distintas. Segue o modelo de interface, NHRP e multicast admitido para o que está realmente despregado en lugar de supor que os tres se comportan igual.

Paso 5: redeseña a fronteira se non pode participar

Se un equipo overlay necesario non pode executar o protocolo, cambia o deseño de forma explícita. Usa un protocolo ou modelo de intercambio admitido nesa fronteira, ou prepara un túnel de extremo a extremo axeitado para que os veciños sexan os extremos que realmente falan entre si. Non supoñas que unha ruta estática converte un non participante nun relé para cada paquete de control.

Anota o rol de cada equipo no diagrama e consérvao xunto coa configuración. RFC 7868 define o intercambio de protocolo e esa definición é a referencia de por que a relación de veciñanza non se pode simular co enrutamento de tránsito.

Cando a adxacencia segue fallando despois das cinco comprobacións, os sospeitosos restantes son funcións de plataforma como o tratamento do multicast na interface do túnel e as políticas que filtran o protocolo 88. Son causas concretas e comprobables, e valen máis que outra rolda de culpar o enrutador do medio.