EVPN está activo, pero o servizo non: catro puntos de control

Alcanzar o enderezo do VTEP remoto demostra que a rede subxacente transporta paquetes, e iso é todo o que demostra. O servizo do inquilino necesita unha sesión BGP EVPN coa familia de enderezos correcta, un VNI local conectado e operativo, unha ruta orixinada e unha importación no extremo remoto. Son catro puntos de control separados, cada un cunha reparación distinta. Tratar unha rede subxacente en verde como preparación do servizo é a forma máis habitual de que unha implantación de EVPN se atasca.

Léos en orde e detente no primeiro que non sexa o que espera o deseño. Os puntos de control posteriores non poden compensar un fallo anterior.

Punto de control 1: transporte ata o VTEP

Comeza pola accesibilidade entre os enderezos de loopback usados como orixe do VTEP. A ruta debe existir na rede subxacente, o camiño debe estar permitido, incluído calquera requisito de encapsulación, e o camiño de volta debe funcionar. Unha ruta que existe pero está filtrada nunha dirección produce un fallo asimétrico que parece intermitente. Confirma ambas as dúas direccións antes de continuar.

Anota os enderezos de orixe e destino que comprobaches. Un paso posterior que resolve un seguinte salto por un enderezo distinto é unha proba distinta, e tratalos como un só é como se acaba culpando a un seguinte salto resolto dun fallo de transporte.

Punto de control 2: a familia EVPN, non o número de sesións

Unha sesión BGP establecida non significa que se negociase a familia de enderezos EVPN. Mira o estado específico da familia para o veciño: se a familia está habilitada, se se negociou co par e se a sesión a transporta en absoluto. Unha sesión activa para IPv4 unicast que nunca negociou EVPN non mostra nada incorrecto nun resumo xeral de veciños, e a especificación de superposición EVPN trata os procedementos de servizo e control como asuntos separados do transporte.

Comproba tamén o enderezo de orixe da sesión. Un emparellamento construído sobre un enderezo que non é a orixe do VTEP é unha discrepancia de deseño que espera explicar un fallo de reenvío.

Punto de control 3: o servizo local está conectado

O VNI local debe estar conectado á ponte ou ao VRF que representa o inquilino, e a plataforma debe informalo como operativo. O estado de pertenza que usa o modelo de replicación pode importar antes de que se aprenda calquera MAC de host, así que unha táboa de puntos finais baleira non é proba de que o servizo estea caído.

Despois confirma que orixina realmente o dispositivo: a ruta local para ese VNI cos route targets que especifica o deseño. Un VNI conectado pero non anunciado produce un servizo que existe localmente e en ningún outro lugar.

Punto de control 4: importación no receptor

No dispositivo receptor, compara os route targets exportados e importados en lugar dos VNI numéricos. Un número de VNI coincidente non demostra que a instancia receptora importe o anuncio, e un route target desaxustado é invisible nunha listaxe de VNI. Resolve o seguinte salto anunciado a través da rede subxacente antes de confiar na entrada de reenvío. Despois le o estado de reenvío da superposición para o servizo e non para o dispositivo no seu conxunto.

Unha táboa de pares tamén pode reflectir datos de plano de datos ou aprendizaxe de pertenza específicos da implementación. Le a súa orixe e o seu contexto de servizo xunto coa ruta EVPN en lugar de tratar o reconto de filas como proba.

Un rexistro que percorre o camiño

Mantén un rexistro por servizo: estado local do VNI, o veciño EVPN e a familia, a ruta orixinada e o resultado recibido e importado. Percorre ese rexistro desde a orixe ata a instalación. Cando algo falla, o rexistro di cal dos catro puntos de control hai que reparar en lugar de que comando probar.

Engade marcas de tempo mentres o fas. Unha importación que aparece minutos despois do anuncio é unha cuestión de política ou de converxencia, mentres que unha que nunca aparece é unha cuestión de configuración, e esa diferenza só se ve se anotaches cando mirastes.

Cando o VXLAN estático é a resposta correcta

Un camiño de datos VXLAN configurado estaticamente pode funcionar con pares proporcionados manualmente mentres a táboa EVPN permanece baleira. Non é unha implantación de EVPN rota, é un modelo de control distinto. Decide cal pretende o deseño antes de diagnosticar unha táboa baleira como un fallo.

Un veciño IGP na rede subxacente proporciona transporte e nada máis. O estado do servizo da superposición é algo aparte que construír e algo aparte que verificar.