Dos VM en el mismo fabric VXLAN de hardware no pueden comunicarse, o el tráfico entre ellas se corta de forma intermitente, y la ruta pasa por un Spine que no se puede simplemente observar. Este es el método tradicional en dos etapas para encontrar el dispositivo que realmente pierde los paquetes — confirmar primero la base Underlay/Overlay, luego configurar estadísticas de flujo para localizar la pérdida.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
El método tradicional para localizar la pérdida de paquetes en un fabric Spine-Leaf VXLAN de hardware no consiste en revisar cuarenta cosas a la vez — son dos etapas, y la segunda solo comienza cuando la primera resulta limpia.
Cuando dos VM en el mismo fabric no pueden comunicarse, o el tráfico entre ellas se corta de forma intermitente, el instinto es empezar a revisar de golpe la configuración de cada dispositivo en la ruta. El método tradicional en dos etapas usado en fabrics Spine-Leaf VXLAN distribuidos por hardware hace lo contrario: primero confirmar que la base Underlay y Overlay está realmente sana de extremo a extremo, y solo entonces — si esa base realmente se confirma — activar las estadísticas de flujo para encontrar el único dispositivo de la ruta que realmente está perdiendo paquetes.
A continuación, ambas etapas con los comandos display exactos, la configuración de estadísticas de flujo de cinco tuplas que localiza con precisión el salto que descarta paquetes, y las trampas que atrapan incluso cuando se sigue el método correctamente.
Las estadísticas de flujo de la etapa 2 se corresponden de forma distinta en cada salto de esta ruta — vale la pena tener este esquema a la vista antes de configurar nada.
Este es el patrón de acceso más común en un fabric VXLAN distribuido por hardware: Server Leaf de origen, atravesando el fabric por un Spine, pasando por un Service/Border Leaf si el destino está detrás de uno, de vuelta por un Spine, y llegando al Server Leaf de destino. La etapa 2 solo tiene sentido una vez que se puede ubicar el síntoma en esta ruta.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Si la etapa 1 revela una ruptura — ruta faltante, túnel Down, ARP o ruta de host faltante — corríjala directamente; es un simple error de configuración de enrutamiento, VXLAN o EVPN, no un misterio de pérdida de paquetes, y nuestra nota de resolución de problemas del túnel VXLAN cubre esas causas en profundidad. Las estadísticas de flujo de la etapa 2 solo valen la pena configurarlas una vez que la base realmente se ve limpia de extremo a extremo.
Cinco comprobaciones en la etapa 1, luego una configuración de estadísticas de flujo de cinco tuplas en la etapa 2 — en ese orden, no al revés.
Tomando como ejemplo a VM1 (10.120.120.5, gateway vBDIF111 en el Server Leaf de origen) que no logra alcanzar a VM2 (10.141.141.3, gateway vBDIF222 en el Server Leaf de destino) — cinco comprobaciones, cada una en el Server Leaf de origen y en el de destino.
<SourceLeaf> display ip routing-table 3.3.3.100
Routing Table : Public
Destination/Mask Proto Pre Cost NextHop Interface
3.3.3.100/32 OSPF 10 2 10.0.12.2 GE1/0/1
// route to the peer NVE (Dest. Server Leaf) source address exists -> Underlay is reachable this direction
<SourceLeaf> display vxlan tunnel
Tunnel ID Source Destination State Type Uptime
4026531844 4.4.4.100 3.3.3.100 up dynamic 9:14:02
// State up, Type dynamic -> tunnel itself is fine, not the problem here
<SourceLeaf> display arp interface vbdif 111
IP ADDRESS MAC ADDRESS EXP(M) TYPE VLAN/CEVLAN INTERFACE
10.141.141.3 0019-9400-000b 18 dynamic BD1012254 Eth-Trunk1.4
// destination VM's ARP is learned
<SourceLeaf> display ip routing-table vpn-instance ABC 10.141.141.3
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.141.141.3/32 IBGP 255 0 RD 3.3.3.100 VXLAN
// EVPN host route to VM2 is present -> repeat steps 4-5 on Dest. Server Leaf for VM1's ARP/host routeSolo se llega aquí una vez que la etapa 1 está completamente limpia en ambos extremos. Las estadísticas de tráfico funcionan sobre la cinco-tupla, pero solo admiten la dirección de entrada — y el formato del paquete es distinto en cada salto.
// example flow: source 192.168.20.2, destination 192.168.10.2, VNI 5001
// match rule differs by hop on the reference path:
// Source Server Leaf : if-match acl xxx (original packet, pre-VXLAN)
// Spine (transit) : if-match vxlan transit tag-format none
// Service/Border Leaf : if-match vxlan tag-format none
// Dest. Server Leaf : if-match vxlan tag-format none
[SourceLeaf] acl number 3001
[SourceLeaf-acl-adv-3001] rule 5 permit ip source 192.168.20.2 0 destination 192.168.10.2 0
[SourceLeaf] traffic classifier c_flow
[SourceLeaf-classifier-c_flow] if-match acl 3001
[SourceLeaf] traffic behavior b_count
[SourceLeaf-behavior-b_count] statistic enable
[SourceLeaf] traffic policy p_count
[SourceLeaf-trafficpolicy-p_count] classifier c_flow behavior b_count
[SourceLeaf] interface vbdif 111
[SourceLeaf-Vbdif111] traffic-policy p_count inbound
// repeat the equivalent classifier + policy, matched to that hop's packet format, on Spine / Service Leaf / Dest. Server Leaf
<SourceLeaf> display traffic-policy statistic interface Vbdif111 inbound verbose
// compare this counter against the same query on the next hop down the path ->
// the first hop where the count doesn't carry through is the dropping deviceUna vez que las dos etapas anteriores han indicado dónde está el problema, estas cinco causas explican la mayor parte de lo que realmente falla — incluidas un par de formas de engañarse a uno mismo aun siguiendo el método correctamente.
SÍNTOMAdisplay ip routing-table hacia la dirección del NVE remoto vuelve vacío en un Server Leaf pero se ve bien en el otro — la etapa 1 pareció aprobarse solo porque se revisó un solo sentido.
CAUSALa convergencia IGP/BGP hacia direcciones loopback no siempre es simétrica — un cambio de costo IGP, una política de rutas o un filtro en un solo dispositivo puede dejar la ruta de retorno sin ruta hacia el VTEP remoto mientras la ruta de ida parece completamente normal.
SOLUCIÓNEjecute la comprobación de la tabla de enrutamiento tanto en el Server Leaf de origen como en el de destino, cada uno hacia la dirección source NVE del otro, antes de concluir que la etapa 1 pasó.
SÍNTOMAdisplay vxlan tunnel muestra el State como down para el túnel de la ruta de referencia, aunque otros túneles en el mismo dispositivo estén up.
CAUSAUn túnel VXLAN solo se levanta cuando existe una ruta hacia el VTEP remoto; si ese estado Down pasa desapercibido en una revisión rápida de la etapa 1, todo lo que sigue — ARP, rutas de host, estadísticas de flujo — termina revisándose sobre una ruta que de todos modos nunca iba a transportar tráfico.
SOLUCIÓNTrate un túnel Down como una falla en sí misma, no como un síntoma de pérdida de paquetes — trabaje primero con nuestra nota de resolución de problemas del túnel VXLAN, y vuelva a este método una vez que el túnel esté confirmado como up.
SÍNTOMAEl paso 4 (ARP) se aprueba en ambos Server Leaf, pero el paso 5 (la ruta de host EVPN) falta en un lado.
CAUSAEl Server Leaf remoto sí convirtió la entrada ARP en una ruta EVPN y la anunció — pero una discrepancia de VPN-Target, un filtro de política de rutas, o una colisión de Router-ID en el reflector de rutas impidieron que el otro lado la aceptara en su tabla de enrutamiento.
SOLUCIÓNEsto es un error de configuración de enrutamiento/EVPN, no una falla de hardware del fabric — el análisis detallado de las discrepancias de VPN-Target y el filtrado por el reflector de rutas está en nuestra nota de resolución de problemas del túnel VXLAN; corríjalo antes de pasar a la etapa 2.
SÍNTOMALas estadísticas de flujo muestran contadores limpios en cada salto, pero el ping entre VM sigue perdiendo paquetes.
CAUSALas estadísticas de tráfico solo admiten la dirección de entrada, y el formato del paquete cambia en cada salto: el primer dispositivo NVE ve el paquete original, antes de VXLAN, y necesita un clasificador basado en ACL, mientras que cada dispositivo aguas abajo ve un paquete encapsulado VXLAN y necesita un clasificador vxlan tag-format. Reutilice la regla if-match equivocada en el salto equivocado y el contador de ese dispositivo simplemente nunca aumenta — sin decirle nada sobre dónde está realmente la pérdida.
SOLUCIÓNHaga coincidir el clasificador con el salto: if-match acl en el Server Leaf de origen, if-match vxlan transit tag-format none en los Spine de tránsito, if-match vxlan tag-format none en los Leaf que terminan el túnel.
SÍNTOMAEl síntoma parece intermitente — algunos pings pasan, otros no — y volver a ejecutar la misma prueba no lo reproduce de forma consistente.
CAUSAEl ECMP entre varios Spine hace hash sobre la cinco-tupla; un ping simple reutiliza siempre la misma tupla y siempre caerá en la misma ruta, lo que puede ocultar una falla en un Spine que otro flujo habría alcanzado, o hacer que un Spine realmente defectuoso parezca intermitente si algunos flujos lo evitan por completo.
SOLUCIÓNVaríe deliberadamente la cinco-tupla al probar — diferentes puertos de origen, no solo pings repetidos — o confíe en los contadores de estadísticas de flujo de la etapa 2 en lugar de depender solo del ping para decidir si un segmento de ruta determinado está realmente limpio.
Sacadas directamente del terreno — las que vale la pena tener una respuesta lista.
Porque la convergencia Underlay y EVPN no está garantizada de forma simétrica. Una ruta, una entrada ARP o una ruta de host puede estar presente en un sentido y faltar en el otro, y comprobar solo el Leaf de origen le cuenta la mitad equivocada de la historia justo cuando más importa.
Puede hacerlo, pero desperdicia una ronda de configuración. Cada una de las cinco comprobaciones de la etapa 1 se ejecuta más rápido que configurar clasificadores, comportamientos y políticas en cada salto, y un problema simple de enrutamiento, estado del túnel, ARP o ruta de host aparece de inmediato en la etapa 1 sin necesitar estadísticas en absoluto.
Este método lee contadores y tablas que usted configura a mano, salto por salto — funciona en cualquier fabric VXLAN distribuido por hardware y no necesita nada más que acceso CLI. Una plataforma de análisis basada en controlador automatiza la misma idea — registros de pérdida de paquetes, rastreo de flujo, comprobaciones de ruta conscientes de la topología — y lo lleva a la respuesta más rápido si está implementada, pero la lógica subyacente es idéntica: confirmar la base, luego localizar la pérdida.
Sí importa, y por eso el clasificador de cada salto debe coincidir con lo que ese dispositivo específico realmente recibe — el paquete original en el primer salto NVE, un paquete encapsulado VXLAN en todos los siguientes. Configurar el contador en el lado equivocado de un salto, o hacer coincidir el formato de paquete equivocado, es la forma más común en que este método da una lectura falsamente “limpia”.
En ese punto, el fabric en sí ha quedado prácticamente descartado. Verifique si se realizó un cambio de configuración manual en algún dispositivo de la ruta alrededor del momento en que comenzó la falla, y si los contadores realmente se mantienen limpios en toda la ruta de referencia, trate esto como un problema del nodo de cómputo o de la aplicación, y coordínese con el equipo de TI/servidores en lugar de seguir buscando dentro de la red.
Esta nota se basa en el método tradicional en dos etapas, guiado por CLI, para fabrics Spine-Leaf VXLAN distribuidos por hardware — primero la base Underlay/Overlay, luego las estadísticas de flujo de cinco tuplas. Asume una falla ya ubicada en la ruta VM a VM mostrada arriba; un túnel Down, o una ruta EVPN que nunca cruzó, son fallas en sí mismas y se tratan en profundidad en nuestra nota de resolución de problemas del túnel VXLAN, no se repiten aquí. Tampoco cubre las plataformas de análisis basadas en controlador que automatizan la misma lógica de localización — donde una esté implementada, normalmente lo llevará a la respuesta más rápido que el método manual aquí descrito. Para el mismo árbol de decisión de tres fuentes (óptica, capa física/CRC, descartes) aplicado a un solo enlace en lugar de una ruta de fabric multisalto, vea nuestra nota de pérdida de paquetes en campus.
Cuéntenos en qué etapa está atascado — la base Underlay/Overlay o las estadísticas de flujo — junto con la salida de display, y le ayudaremos a interpretarla.