Inicio / Notas técnicas / Resolución de problemas del overlay VXLAN

Fallas del overlay VXLAN: migración de VM, estado del túnel y rastreo de tráfico

Que un túnel VXLAN muestre Up no significa que el tráfico que le interesa realmente lo esté cruzando. Este es el orden de diagnóstico que separa las cuatro cosas que realmente fallan en un fabric VXLAN basado en EVPN — el estado del túnel, una migración de VM que pierde paquetes durante 20 segundos, conteos de tráfico a nivel de paquete en ambos lados del túnel, y si el tráfico de un usuario determinado llegó siquiera al overlay.

Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026

Por qué el overlay oculta la falla

El túnel es una abstracción. Cada una de estas fallas termina residiendo en el underlay, el plano de control, o una sola dirección MAC mal interpretada por debajo.

El trabajo completo de VXLAN es hacer desaparecer una red underlay y dejar en su lugar un overlay de aspecto plano. Esa es precisamente la razón por la que las fallas aquí resultan confusas: display vxlan tunnel puede mostrar Up mientras el tráfico de negocio real va por completo a otro lugar, o el túnel puede estar perfectamente sano mientras una tormenta de rutas EVPN totalmente ajena detiene una migración de VM durante veinte segundos. La forma más rápida de resolverlo sigue siendo la misma disciplina de siempre — confirmar el estado real del túnel, y luego hacer coincidir el síntoma con el caso concreto al que se parece, en lugar de adivinar primero la configuración de BGP EVPN.

A continuación: una topología VXLAN Spine-Leaf para situar la falla, el orden para verificar el estado del túnel antes de tocar cualquier otra cosa, un caso real de pérdida de paquetes en una migración de VM rastreado hasta una tormenta de rutas EVPN en el Route Reflector, estadísticas de tráfico a nivel de paquete tanto en el lado de acceso como dentro del túnel, cómo confirmar que el tráfico de un usuario realmente llegó al overlay, cinco causas raíz recurrentes, y respuestas de preguntas frecuentes probadas en campo.

Lea el fabric antes de leer un solo contador

Border Leaf, Spine actuando como route reflector, pares de Server Leaf con hosts en doble homing por M-LAG — los túneles VXLAN corren de leaf a leaf sobre un plano de control BGP EVPN que nunca aparece en la topología física.

Cada caso a continuación asume esta forma: VTEPs en los pares de Server Leaf que construyen túneles VXLAN dinámicos vía BGP EVPN, con el Spine actuando puramente como route reflector — refleja rutas EVPN, no origina un VTEP por sí mismo.

Las etiquetas del diagrama se mantienen en inglés por claridad técnica.

Es el plano de control EVPN lo que hace que este fabric sea diferente de resolver frente a una red conmutada común: una ruta que nunca se refleja, o un mapeo de VNI a bridge domain incorrecto en un leaf, produce exactamente el mismo agujero negro que un cable cortado — sin ningún síntoma físico.

Recorriendo el estado del túnel y luego el caso concreto

Cuatro investigaciones distintas, cuatro conjuntos de comandos distintos — y la disciplina de verificar primero el estado del túnel antes de asumir cuál aplica.

Confirmar el estado del túnel antes de asumir una falla de VXLAN

display vxlan troubleshooting ejecuta el diagnóstico automático propio de Huawei e informa el motivo en texto claro — léalo antes de abrir un caso sobre cualquier otra cosa.

Verifique primero display vxlan tunnel. Si State es Down, ese es su punto de partida, no la tabla de rutas EVPN.
Ejecute display vxlan troubleshooting para obtener directamente un Event Description — por ejemplo, túnel down porque la ruta hacia la dirección de origen o destino es inalcanzable, o porque no existe una ruta de host de 32 bits.
Confirme con display bgp evpn peer que el vecino EVPN que construyó este túnel está realmente Established, no solo que el objeto túnel existe.
Confirme con display ip routing-table que la tabla de rutas IP del underlay tiene realmente una ruta hacia la dirección loopback de origen o destino del peer.

<HUAWEI> display vxlan tunnel
Number of vxlan tunnel : 1
Tunnel ID    Source                Destination           State
40000001     10.1.1.1              10.1.1.2              down
// state is down -- this is where to start, not the EVPN route table

<HUAWEI> display vxlan troubleshooting
Vxlan Tunnel Troubleshooting Information:
 Tunnel ID       : 40000001
 Event Description : The tunnel is Down because the route to the destination
                      is unreachable, or no 32-bit host route exists for it.

<HUAWEI> display bgp evpn peer
 Peer            V    AS  MsgRcvd  MsgSent  OutQ  Up/Down   State  PrefRcv
 10.1.1.2        4  65001      120      118     0  00:12:40  Established     6

<HUAWEI> display ip routing-table
Destination/Mask    Proto  Pre  Cost      Flags NextHop     Interface
10.1.1.2/32          O_ASE 150  1         D     10.0.0.2    GE1/0/1
// a /32 route to the destination loopback must exist, not just a summary route

Caso: migración de VM que pierde paquetes durante más de 20 segundos

Aquí el problema no es el túnel — es la cola de envío saliente del route reflector.

Síntoma: la migración de VM en este fabric pierde paquetes durante más de 20 segundos, muy por encima de lo previsto en el diseño.
Causa raíz: actualizaciones frecuentes de rutas EVPN (normalmente impulsadas por MAC/ARP) congestionan la cola de envío del route reflector más rápido de lo que puede vaciar las rutas hacia cada peer, por lo que la nueva ubicación de la VM no se anuncia a tiempo.
Verifique display bgp evpn update-peer-group para encontrar el Group ID que maneja los peers afectados.
En la vista diagnose, verifique display bgp evpn update-peer-group index <id> verbose — un conteo UptPeerGrp PktBuffer distinto de cero significa que el route reflector no ha terminado de enviar actualizaciones a ese grupo.
Solución: aumente el tiempo de envejecimiento de MAC dinámicas en Server Leaf y Border Leaf del valor predeterminado de 300 segundos a algo como 1800 segundos, reduciendo la tasa de churn de rutas impulsado por MAC; luego confirme que el conteo UptPeerGrp PktBuffer vuelve a 0.

<HUAWEI> display bgp evpn update-peer-group
 Group ID   PeerNumber  Description
 3          24          EVPN-RR-Group

<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display bgp evpn update-peer-group index 3 verbose
 UptPeerGrp PktBuffer   : 214
// non-zero -- the RR has not finished flushing updates to this peer group

[HUAWEI] mac-address aging-time 1800
// default is 300s; raising it reduces MAC-driven EVPN route churn

[HUAWEI-diagnose] display bgp evpn update-peer-group index 3 verbose
 UptPeerGrp PktBuffer   : 0
// confirms the send queue has cleared after the change

Estadísticas de tráfico a nivel de paquete — lado de acceso frente al interior del túnel

La interfaz del lado de acceso ve el paquete original; la interfaz del lado del túnel lo ve envuelto en un encabezado VXLAN — por eso los dos lados necesitan métodos de coincidencia distintos.

En el lado de acceso, cree una ACL simple que coincida con la IP de origen/destino del tráfico que desea contabilizar, y luego vincúlela a una política de tráfico en la interfaz de acceso.
En el lado del túnel, el paquete ahora lleva un encabezado VXLAN, por lo que el clasificador de tráfico debe referenciar explícitamente el paquete interno con if-match vxlan transit acl.
Aplique la política del lado del túnel a la interfaz de túnel VXLAN (o a la interfaz orientada a NVE) en la dirección de salida o entrada según sea necesario, y luego lea los contadores con display traffic-policy statistics.

[HUAWEI] acl 3000
[HUAWEI-acl-adv-3000] rule 5 permit ip source 10.10.1.0 0.0.0.255 destination 10.10.2.0 0.0.0.255

[HUAWEI] traffic classifier c_access
[HUAWEI-classifier-c_access] if-match acl 3000
[HUAWEI] traffic behavior b_access
[HUAWEI-behavior-b_access] statistic enable
[HUAWEI] traffic policy p_access
[HUAWEI-trafficpolicy-p_access] classifier c_access behavior b_access
[HUAWEI] interface GigabitEthernet1/0/1
[HUAWEI-GigabitEthernet1/0/1] traffic-policy p_access inbound

// tunnel side -- match the inner packet through the VXLAN header
[HUAWEI] traffic classifier c_tunnel
[HUAWEI-classifier-c_tunnel] if-match vxlan transit acl 3000
[HUAWEI] traffic policy p_tunnel
[HUAWEI-trafficpolicy-p_tunnel] classifier c_tunnel behavior b_access

<HUAWEI> display traffic-policy statistics interface GigabitEthernet1/0/1 inbound
 Classifier: c_access
   Matched     : 128664 packets / 96 Mbytes

Cómo confirmar que el tráfico de un usuario realmente llegó a la red VXLAN

Un VNI se mapea 1:1 a un bridge domain; una vez que se sabe cómo decide el VTEP a qué bridge domain pertenece una trama, juzgar si un usuario está dentro o fuera se convierte en una comprobación de tres pasos.

Verifique si la dirección MAC del usuario se aprendió en el bridge domain esperado con display mac-address bridge-domain. Si está ahí, la trama está en el overlay; si no, pase al siguiente paso.
Verifique la interfaz de acceso y su configuración de subinterfaz para determinar si el usuario debe llegar mediante acceso basado en VLAN o mediante una subinterfaz con terminación 802.1Q.
Verifique las VLAN o subinterfaces vinculadas al bridge domain con display bridge-domain <id> — si la VLAN o subinterfaz del usuario no está en esa lista, el tráfico no puede llegar al overlay sin importar cuán correcto parezca todo lo demás.

<HUAWEI> display mac-address bridge-domain 10
MAC Address    VLAN/VSI/BD  Learned-From        Type
5489-98aa-1122 -/-/10       Eth-Trunk1.10        dynamic
// user's MAC is learned into BD 10 -- the frame is in the overlay

<HUAWEI> display this
interface Eth-Trunk1.10
 encapsulation dot1q vid 10
 bridge-domain 10
// confirms this is sub-interface access with 802.1Q termination into BD 10

<HUAWEI> display bridge-domain 10
 Bridge-domain 10 information:
  Binding interface : Eth-Trunk1.10, Eth-Trunk2.10
// if the user's own VLAN/sub-interface is not bound here, it never reaches the overlay

5 causas raíz que aparecen una y otra vez

Una vez que las comprobaciones anteriores le han indicado cuál de las cuatro investigaciones aplica, estas cinco explican la mayor parte de lo que realmente está mal.

1. El churn de rutas EVPN inunda la cola de envío del route reflector

SÍNTOMALa migración de VM causa pérdida de paquetes que dura más de 20 segundos — muy por encima de lo previsto en el diseño.

CAUSALas actualizaciones frecuentes de rutas EVPN superan la capacidad del route reflector para vaciar su cola de envío hacia todos los peers; la nueva ubicación de la VM no se anuncia a tiempo, por lo que el tráfico sigue yendo al leaf antiguo durante ese intervalo.

SOLUCIÓNAumente el tiempo de envejecimiento de MAC dinámicas en Server Leaf y Border Leaf desde el valor predeterminado de 300 segundos para reducir la tasa de churn, y luego confirme que el conteo UptPeerGrp PktBuffer volvió a 0.

[HUAWEI] mac-address aging-time 1800

2. Alarma de flapping de MAC por colisión entre la MAC de la VM y la puerta de enlace

SÍNTOMAEl dispositivo reporta una alarma de flapping de MAC y el tráfico de la VM se vuelve intermitente.

CAUSALa dirección MAC de una VM colisiona con la propia MAC del gateway L3 de VXLAN — por ejemplo, en una interfaz VBDIF — de modo que cada trama que ve la red parece provenir de dos lugares a la vez.

SOLUCIÓNVerifique display mac-address flapping-record para la MAC con flapping, contrástela con display interface vbdif <id>, y luego cambie la MAC de la VM o del gateway, o elimine directamente una interfaz VBDIF sin usar.

<HUAWEI> display mac-address flapping-record
 MAC Address      VLAN/BD   Times    Last-Time
 5489-98aa-3344   10        16        2026-07-18 09:14:02

<HUAWEI> display interface vbdif 10
Vbdif10 current state : UP
 Hardware address is 5489-98aa-3344
// same MAC as the flapping VM -- collision with the gateway's own address

3. Túnel caído porque la ruta hacia el origen o el destino es inalcanzable

SÍNTOMAdisplay vxlan tunnel muestra el State del túnel como down; las VMs detrás no pueden alcanzarse entre sí entre centros de datos.

CAUSANo existe ruta — ni ruta de host de 32 bits — hacia la dirección loopback de origen o destino del túnel; display vxlan troubleshooting lo indica directamente en su Event Description.

SOLUCIÓNConfirme que el vecino EVPN está Established, luego revise la tabla de rutas IP del underlay en busca de una ruta hacia la dirección faltante; corrija el protocolo de enrutamiento subyacente, no la configuración de VXLAN en sí.

4. La tabla de replicación head-end nunca se construye

SÍNTOMAdisplay vxlan peer muestra cero peers para un VNI que debería tener configurada la replicación head-end; las VMs entre centros de datos no pueden alcanzarse.

CAUSANormalmente una configuración incorrecta de la interfaz NVE — una dirección de origen equivocada, o un protocolo de peer-list head-end equivocado — o un vecino EVPN que nunca llegó a establecerse.

SOLUCIÓNVerifique la configuración de la interfaz NVE contra el diseño de referencia, y luego confirme el estado del vecino EVPN con display bgp evpn peer.

<HUAWEI> display vxlan peer vni 10010
Total 0 peer.
// expected head-end replication peers, but none learned

<HUAWEI> display this
interface Nve1
 source 10.1.1.1
 vni 10010 head-end peer-list protocol bgp
// confirm source address and protocol match the reference config on every leaf

5. Ruta EVPN nunca aprendida porque un VPN-Target no coincide, o el ARP remoto nunca se convirtió

SÍNTOMAdisplay ip routing-table vpn-instance no muestra absolutamente nada para una VM de destino que debería ser alcanzable — no hay ruta, no es una ruta errónea.

CAUSATres sospechosos habituales: el leaf remoto nunca aprendió la entrada ARP de la VM de destino; una route-policy en cualquiera de los leaf está filtrando la ruta EVPN; o los atributos de comunidad extendida VPN-target de los dos leaf no coinciden, de modo que la ruta se genera localmente pero se descarta al recibirla.

SOLUCIÓNConfirme primero que la tabla ARP del leaf remoto tiene el destino con display arp network <ip>; verifique si la ruta local se generó con el route-target correcto mediante display bgp instance evpn all routing-table mac-route; si nada está filtrado y los route-targets coinciden, busque una route-policy aplicada al peer BGP.

<HUAWEI> display arp network 10.10.2.20
// empty -- the local leaf never learned this VM's ARP entry, so no route was ever generated

<HUAWEI> display bgp instance vpn1 evpn all routing-table mac-route
 Route Distinguisher: 10.1.1.1:1
 VPN-Target       : 65001:10010 export, 65001:10010 import
// compare export community on the originating leaf against import on the receiving leaf

Cinco preguntas para las que conviene tener una respuesta lista

Extraídas directamente del campo — las que conviene tener respondidas de antemano.

¿Ejecutar VXLAN necesita una License independiente?

VXLAN está condicionado por una License (CE-LIC-VXLAN), pero en los switches CloudEngine viene preinstalada y preactivada de fábrica — no hay nada que activar manualmente.

La encapsulación VXLAN empujó la longitud de mi paquete más allá de lo que permiten los switches del underlay — ¿y ahora qué?

VXLAN añade 54 bytes de sobrecarga a cada paquete original, y eso basta para superar el MTU de un switch underlay común y ser descartado silenciosamente. Elija la combinación que soporte el hardware underlay: aumente la longitud de trama Jumbo que el underlay permite pasar por encima de la longitud del paquete VXLAN, aumente en su lugar el MTU de la interfaz underlay por encima de esa longitud, o ponga el propio gateway VXLAN en hardware capaz de fragmentar y reensamblar, para que el underlay nunca tenga que lidiar con una trama de tamaño excesivo.

¿VXLAN admite IPv6?

Sí, en ambos lados — la red overlay transportada dentro del túnel y la red underlay sobre la que corre el propio túnel pueden ser cada una, de forma independiente, IPv6.

Activé las estadísticas de tráfico del túnel VXLAN y el dispositivo empezó a reportar una alarma de inestabilidad del chip LANSWITCH — ¿rompí algo?

Se alcanzó un límite de recursos de conteo de hardware, no una falla real. Cuando la interfaz de salida del túnel es un puerto miembro de VLAN y se apilan las estadísticas de puerto de entrada, las estadísticas de túnel, las estadísticas de túnel+VNI, las estadísticas de bridge domain y las propias estadísticas de la VLAN de salida unas sobre otras, se supera la capacidad de contadores por flujo del motor de reenvío — las estadísticas de VLAN dejan de funcionar silenciosamente y el chip genera la alarma de inestabilidad. Deshabilite cualquiera de las funciones de estadísticas apiladas y ambos problemas desaparecen.

display vxlan tunnel muestra que el túnel está up pero las VMs detrás aún no pueden comunicarse — ¿por dónde empiezo?

Dos comprobaciones, en orden. Primero, display bgp evpn peer — confirme que el vecino EVPN que construyó este túnel está realmente Established, no solo que el objeto túnel existe; una sesión que fluctuó y se restableció discretamente puede dejar el túnel up mientras las rutas aún no se han reaprendido. Segundo, display mac-address bridge-domain — confirme que la MAC de destino realmente se aprendió en el bridge domain esperado. Un túnel que muestra Up mientras protege el bridge domain equivocado, o uno detrás de una sesión EVPN obsoleta, se ven idénticos desde afuera a “túnel up, nada funciona”.

Límites honestos de esta nota

Límites honestos de esta nota

Esta nota se basa en el modelo VXLAN basado en BGP EVPN del manual de mantenimiento V300 de las series Huawei CloudEngine 16800/9800/8800/6800 — display vxlan tunnel / vxlan troubleshooting / vxlan peer / bgp evpn peer, además de los casos de campo que los respaldan. Si su fabric usa VXLAN basado en multicast sin EVPN, o un gateway de overlay de otro fabricante, los comandos exactos cambian, pero el orden de diagnóstico — estado del túnel, vecino del plano de control, ruta del underlay, y luego el tráfico mismo — se traslada directamente. No cubre en profundidad los casos límite de multi-homing EVPN (ESI) ni las particularidades del overlay VXLAN sobre IPv6.

¿Atascado con un túnel VXLAN específico?

Cuéntenos qué muestran display vxlan troubleshooting y display bgp evpn peer, y a cuál de estas cuatro formas corresponde, y le ayudamos a interpretarlo.

WhatsApp con un ingeniero →