EVPN está activo, pero el servicio no: cuatro puntos de control

Alcanzar la dirección del VTEP remoto demuestra que la red subyacente transporta paquetes, y eso es todo lo que demuestra. El servicio del inquilino necesita una sesión BGP EVPN con la familia de direcciones correcta, un VNI local conectado y operativo, una ruta originada y una importación en el extremo remoto. Son cuatro puntos de control separados, cada uno con una reparación distinta. Tratar una red subyacente en verde como preparación del servicio es la forma más común de que un despliegue de EVPN se atasque.

Léelos en orden y detente en el primero que no sea lo que espera el diseño. Los puntos de control posteriores no pueden compensar un fallo anterior.

Punto de control 1: transporte hasta el VTEP

Empieza por la accesibilidad entre las direcciones de loopback usadas como origen del VTEP. La ruta debe existir en la red subyacente, el camino debe estar permitido, incluido cualquier requisito de encapsulación, y el camino de vuelta debe funcionar. Una ruta que existe pero está filtrada en una dirección produce un fallo asimétrico que parece intermitente. Confirma ambas direcciones antes de continuar.

Anota las direcciones de origen y destino que comprobaste. Un paso posterior que resuelve un siguiente salto por una dirección distinta es una prueba distinta, y tratarlos como uno solo es como se acaba culpando a un siguiente salto resuelto de un fallo de transporte.

Punto de control 2: la familia EVPN, no el número de sesiones

Una sesión BGP establecida no significa que se haya negociado la familia de direcciones EVPN. Mira el estado específico de la familia para el vecino: si la familia está habilitada, si se negoció con el par y si la sesión la transporta en absoluto. Una sesión activa para IPv4 unicast que nunca negoció EVPN no muestra nada incorrecto en un resumen general de vecinos, y la especificación de superposición EVPN trata los procedimientos de servicio y control como asuntos separados del transporte.

Comprueba también la dirección de origen de la sesión. Un emparejamiento construido sobre una dirección que no es el origen del VTEP es una discrepancia de diseño que espera a explicar un fallo de reenvío.

Punto de control 3: el servicio local está conectado

El VNI local debe estar conectado al puente o al VRF que representa al inquilino, y la plataforma debe informarlo como operativo. El estado de pertenencia que usa el modelo de replicación puede importar antes de que se aprenda cualquier MAC de host, así que una tabla de puntos finales vacía no es prueba de que el servicio esté caído.

Después confirma qué origina realmente el dispositivo: la ruta local para ese VNI con los route targets que especifica el diseño. Un VNI conectado pero no anunciado produce un servicio que existe localmente y en ningún otro lugar.

Punto de control 4: importación en el receptor

En el dispositivo receptor, compara los route targets exportados e importados en lugar de los VNI numéricos. Un número de VNI coincidente no demuestra que la instancia receptora importe el anuncio, y un route target desajustado es invisible en un listado de VNI. Resuelve el siguiente salto anunciado a través de la red subyacente antes de confiar en la entrada de reenvío. Después lee el estado de reenvío de la superposición para el servicio y no para el dispositivo en su conjunto.

Una tabla de pares también puede reflejar datos de plano de datos o aprendizaje de pertenencia específicos de la implementación. Lee su origen y su contexto de servicio junto con la ruta EVPN en lugar de tratar el recuento de filas como prueba.

Un registro que recorre el camino

Mantén un registro por servicio: estado local del VNI, el vecino EVPN y la familia, la ruta originada y el resultado recibido e importado. Recorre ese registro desde el origen hasta la instalación. Cuando algo falla, el registro dice cuál de los cuatro puntos de control hay que reparar en lugar de qué comando probar.

Añade marcas de tiempo mientras lo haces. Una importación que aparece minutos después del anuncio es una cuestión de política o de convergencia, mientras que una que nunca aparece es una cuestión de configuración, y esa diferencia solo se ve si anotaste cuándo miraste.

Cuándo el VXLAN estático es la respuesta correcta

Un camino de datos VXLAN configurado estáticamente puede funcionar con pares proporcionados manualmente mientras la tabla EVPN permanece vacía. No es un despliegue de EVPN roto, es un modelo de control distinto. Decide cuál pretende el diseño antes de diagnosticar una tabla vacía como un fallo.

Un vecino IGP en la red subyacente proporciona transporte y nada más. El estado del servicio de la superposición es algo aparte que construir y algo aparte que verificar.