Encontrar una MAC en la base de datos EVPN demuestra que se anunció o recibió como ruta, y nada más. La tabla de reenvío es otra estructura, programada más tarde, así que la misma MAC puede aparecer en una y faltar en la otra mientras todos los protocolos se comportan correctamente. Tratar esas dos salidas como copias una de otra lleva a los ingenieros tras una falla de BGP cuando el vacío real es una política de importación o un siguiente salto sin resolver. La pregunta que vale la pena hacerse no es si el fabric conoce la MAC, sino en qué etapa dejó de pasarla.

Dos tablas que responden preguntas distintas

En Junos EVPN la base de datos lista las direcciones MAC por instancia junto con cómo llegó cada una: aprendida de un puerto de acceso, recibida en una ruta Type 2 o marcada como parte de un grupo de multihoming. La referencia de Juniper show evpn database cubre los filtros por MAC y por instancia que hacen legible la vista. Es un resumen del plano de control indexado por instancia y MAC, no la tabla con la que el hardware conmuta las tramas.

La tabla de conmutación es ese estado de reenvío. Ambas salidas listan MAC junto al contexto de VLAN o VNI, que es exactamente por qué se comparan línea por línea, y exactamente por qué la comparación engaña. Una entrada en la base de datos dice que la ruta existe y se aceptó en la instancia; no dice nada sobre si la plataforma la instaló para el reenvío.

Una ruta Type 2 transporta la MAC, una IP opcional, una etiqueta o VNI, un distinguidor de ruta y un siguiente salto que nombra el VTEP remoto. Cuatro cosas pueden romperse entre el cable y esa ruta: el host nunca se aprende, la ruta nunca se anuncia, se rechaza en la importación o su siguiente salto no se resuelve. Cada falla deja un conjunto distinto de tablas pobladas, y por eso la secuencia puede diagnosticarse.

El aprendizaje local sigue ocurriendo primero

La suposición habitual es que EVPN se hace cargo del aprendizaje de MAC, así que una base de datos vacía debe significar un problema de overlay. El aprendizaje local sigue ejecutándose en el lado de acceso, exactamente como antes de que existiera VXLAN: el switch aprende la MAC de origen de una trama permitida en el VLAN y el servicio correctos, y solo entonces origina una Type 2 para ella. Un host que no ha enviado ninguna trama relevante no tiene nada que anunciar. Un host cuyas tramas se descartan por pertenencia al VLAN, un filtro o un miembro caído de un agregado se ve idéntico desde el punto de vista del overlay.

Empiece en el punto de conexión y avance con comandos de solo lectura. El objetivo es demostrar que una trama del host cruzó en el servicio previsto, porque nada aguas abajo compensa una trama que nunca llegó.

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

Los miembros LACP seleccionados importan más que el bundle esté activo, ya que un agregado puede estar activo en un miembro mientras el tráfico del host se dispersa hacia un enlace caído o bloqueado. Los contadores de interfaz separan un host silencioso de uno que descarta, porque un host que nunca transmite y un host cuyas tramas se descartan por clasificación dejan la misma tabla vacía.

Dónde se pierde una MAC remota

Una MAC remota falla en la dirección opuesta, y en silencio. La ruta Type 2 llega, pero solo entra en una instancia cuando su objetivo de ruta y el VNI coinciden con la configuración local, y solo se vuelve utilizable cuando el siguiente salto se resuelve en un VTEP alcanzable. Un desajuste del objetivo de ruta deja una ruta válida en la tabla BGP que ninguna instancia solicita.

Lea las tres vistas en orden: presencia de ruta, entrada de base de datos, entrada de reenvío. Los comandos siguientes consultan la misma MAC en cada etapa, y la dirección de ejemplo mantiene las salidas comparables.

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

Esas salidas responden tres preguntas separadas. Una ruta en bgp.evpn.0 sin entrada de base de datos apunta a política de importación, objetivo de ruta o configuración de instancia. Una entrada de base de datos sin entrada de reenvío apunta a la programación de la plataforma, que pertenece a una ruta de escalado distinta. Una ruta activa cuyo siguiente salto no se resuelve es un problema de transporte o de etiqueta, y ninguna cantidad de depuración de MAC lo repara.

Un reinicio que lo arregló demuestra muy poco

Cuando un reinicio hace desaparecer el síntoma, la conclusión tentadora es que la configuración debe ser sólida. Un reinicio reprograma cada tabla desde cero, así que también oculta el caso en que una entrada obsoleta eclipsaba un error de política; la falla suele volver en el siguiente cambio, el parpadeo de un enlace o la retirada de una ruta.

Antes de cualquier ventana de mantenimiento, capture lo que el reinicio borrará. Estos tres comandos bastan para comparar antes y después, y no cambian nada en el dispositivo.

show evpn database instance blue
show route table bgp.evpn.0
show version

Archive esas salidas con la fecha y la compilación del software al lado. Un informe posterior de que el mismo reinicio funcionó antes es una pista más que una prueba, y la diferencia solo se hace visible cuando alguien conservó la salida anterior.

Cuatro observaciones que resuelven la mayoría de los casos

Cuatro observaciones cubren casi todos los casos: el punto de conexión y su servicio, la MAC como valor de ejemplo, el estado de la ruta y de la base de datos, y la compilación en uso. Elija una MAC obviamente de ejemplo para que nadie la confunda con una dirección de producción: un primer octeto 02 marca una dirección unicast administrada localmente, el resto de octetos queda libre, y 02:00:00:00:00:5c es por tanto un marcador seguro.

Luego deje que las respuestas apunten a la etapa que falló. Ningún aprendizaje en el punto de conexión significa el lado de acceso; una ruta sin entrada de base de datos significa importación; una entrada de base de datos sin estado de reenvío significa programación. Sea cual sea, entregue las salidas recogidas junto con el host, la interfaz, el servicio y la compilación, para que el siguiente ingeniero pueda reproducir el camino en lugar de repetir la consulta.

Artículos relacionados