Cambiar el equipo de otro fabricante por uno de Huawei rara vez es solo un ejercicio de cableado — los dos casos de campo a continuación pasaron todas las verificaciones físicas y el tráfico igual se rompió, porque la falla estaba en cómo negocia el nuevo switch, no en su cableado. Un Eth-Trunk hacia un servidor ESX que dejó de pasar tráfico por completo, y un puerto GE que discretamente se auto-negoció a 10Mbit/s inundando un contador de descartes.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Ambos casos a continuación pasaron las verificaciones físicas evidentes — cableado, estado del puerto, luces de enlace — y el tráfico igual se rompió, porque la falla estaba en el comportamiento de negociación predeterminado, no en el cableado.
Reemplazar el switch de otro fabricante por uno de Huawei es un proyecto de rutina, hasta que el tráfico que funcionaba perfectamente en el equipo anterior no pasa en el nuevo, o un enlace que debería correr a velocidad completa se conforma discretamente con una fracción de ella. Ninguno de los dos casos aquí involucra un cable dañado o una VLAN incorrecta — uno es una agregación Eth-Trunk hacia un host de virtualización que nunca completa realmente la negociación LACP con su par, y el otro es un puerto gigabit cuya auto-negociación converge en 10Mbit/s en lugar de 1000Mbit/s. La misma disciplina que detecta esto aplica ya sea que la falla esté en el comportamiento de agregación o en la negociación de capa de enlace — vea nuestra nota complementaria sobre
A continuación, el árbol de fallas en el que se dividen estos dos casos, la evidencia exacta de display interface / display logbuffer para cada uno, las soluciones lacp force-forward y no auto-negociación, y algunas respuestas de preguntas frecuentes de casos reales de campo.
Ambas fallas se presentan como un enlace físicamente correcto que aun así no transporta el tráfico que debería — la diferencia está en lo que realmente muestra display interface al observarlo.
Ubicar primero el síntoma en este árbol evita reterminar un cable que nunca fue el problema, o reemplazar una óptica en un enlace que solo fue un desajuste de negociación.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Ambas ramas comparten la misma lección subyacente: el equipo del fabricante anterior tenía un comportamiento predeterminado — reenvío LACP permisivo, o un resultado de negociación que casualmente llegaba a velocidad completa — que el equipo de reemplazo no reproduce automáticamente, y nada en la capa física se lo dirá por sí solo.
Un S5720 reemplazó a un switch Cisco en un Eth-Trunk en modo LACP conectado a un servidor ESX — todas las verificaciones físicas estaban limpias, y el servidor seguía siendo inalcanzable.
La configuración de Cisco usaba channel-group 1 mode active en ambas interfaces miembro, con el propio port-channel en modo trunk — una agregación LACP activa estándar. Tras el reemplazo, el lado S5720 se configuró con un Eth-Trunk equivalente en mode lacp, con los mismos dos puertos físicos agregados como miembros.
! Cisco configuration before replacement
interface PORT-CHANNEL1
switchport trunk encapsulation dot1q
switchport trunk native vlan 4
switchport mode trunk
!
interface GigabitEthernet1/0/2
switchport trunk encapsulation dot1q
switchport trunk native vlan 4
switchport mode trunk
channel-protocol lacp
channel-group 1 mode active
!
interface GigabitEthernet1/0/3
description pdsesxi01 Port 2
switchport trunk encapsulation dot1q
switchport trunk native vlan 4
switchport mode trunk
channel-protocol lacp
channel-group 1 mode active
# S5720 configuration after replacement
interface Eth-Trunk1
port link-type trunk
port trunk pvid vlan 4
port trunk allow-pass vlan 2 to 4094
mode lacp
#
interface GigabitEthernet0/0/5
description vmesxi-viewR7-01 Port 1
eth-trunk 1
#
interface GigabitEthernet0/0/6
description vmesxi-viewR7-01 Port 2
eth-trunk 1
# Fix — configured under the Eth-Trunk interface view
[S5720] interface Eth-Trunk 1
[S5720-Eth-Trunk1] lacp force-forwardUn switch S reemplazó a un equipo NE frente a un equipo MSC — tras el reemplazo, el lado MSC reportó una pérdida de paquetes intensa, y el contador de descartes reveló la verdadera historia.
<HUAWEI> display interface GigabitEthernet 0/0/5
GigabitEthernet0/0/5 current state : DOWN
Line protocol current state : DOWN
Switch Port, PVID : 3957, TPID : 8100(Hex), The Maximum Frame Length is 9216
Port Mode: COMMON COPPER, Transceiver: 1000_BASE_T_SFP
Speed : 1000, Loopback: NONE
Duplex: FULL, Negotiation: ENABLE // port working in auto-negotiation mode
Output: 127584698 packets, 34122796642 bytes
Unicast: 127511799, Multicast: 1632
Broadcast: 71267, Jumbo: 0
Discard: 127147932, Pause: 0 // massive output discard count
<HUAWEI> display logbuffer
Nov 1 2017 11:17:45 %%01IFNET/4/LINK_STATE(l): The line protocol IP on the
interface GigabitEthernet0/0/5 has entered the DOWN state.
Nov 1 2017 11:15:38 %%01IFNET/4/LINK_STATE(l): The line protocol IP on the
interface GigabitEthernet0/0/5 has entered the UP state.
// repeated Up/Down cycling around the fault window
<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display diag-logfile buffer
...Interface GigabitEthernet0/0/5 duplex mode log. (PhyStatus=UP, PreDuplex=FULL,
CurrDuplex=FULL, Speed=10M, Function=IFPDT_ChangePortStatus, Line=909)
// confirms the port actually settled at 10M during the fault window
# Fix
<HUAWEI> system-view
[HUAWEI] interface GigabitEthernet 0/0/5
[HUAWEI-GigabitEthernet0/0/5] undo negotiation auto
[HUAWEI-GigabitEthernet0/0/5] speed 1000
// confirm the peer interface is also set to a fixed, matching speed and duplexUn puerto que negocia a la baja en lugar de fallar por completo es un síntoma distinto de uno que simplemente está físicamente caído — si lo que realmente está viendo es un puerto que se niega a subir en absoluto en lugar de asentarse en una velocidad baja, vea nuestra nota complementaria sobre
Ambos casos anteriores son ejemplos específicos de un patrón más amplio que vale la pena vigilar en cada proyecto de reemplazo de fabricante.
SÍNTOMALos puertos miembro de Eth-Trunk están físicamente Up en el nuevo switch, la configuración refleja la del fabricante anterior, y el tráfico aún no pasa hacia el dispositivo peer.
CAUSAAlgunos peers — el vSwitch de un host de virtualización es el ejemplo clásico — presentan un enlace físicamente Up sin realmente intercambiar unidades de datos del protocolo LACP, y por defecto un switch Huawei no reenvía en un miembro de Eth-Trunk hasta que la negociación LACP con el peer se confirma.
SOLUCIÓNConfigure lacp force-forward en la interfaz Eth-Trunk para que el switch reenvíe en miembros físicamente Up incluso sin negociación LACP confirmada del peer.
SÍNTOMAUn enlace clasificado como gigabit sube Up sin ningún error, pero el rendimiento está muy por debajo de lo esperado y el contador de descartes de salida sube constantemente.
CAUSALa auto-negociación entre los dos extremos convergió en una velocidad común mucho más baja — 10Mbit/s en lugar de 1000Mbit/s en este caso — y los volúmenes de tráfico dimensionados para gigabit simplemente exceden lo que un enlace de 10M puede transportar, así que el excedente se descarta en lugar de que el enlace falle por completo.
SOLUCIÓNConfirme la velocidad realmente negociada con display interface antes de asumir un problema de enrutamiento o ACL; si se asentó baja, pase ambos extremos a una velocidad y dúplex fijos y coincidentes con undo negotiation auto más un comando speed explícito.
SÍNTOMAUn lado está configurado a velocidad fija, el otro se deja en auto-negociación, y el enlace se comporta de forma inconsistente — a veces Up, a veces no, nunca del todo confiable.
CAUSASi los dos extremos de un enlace no están de acuerdo en el modo de negociación, el lado configurado a velocidad fija puede mostrar Up o Down según las condiciones, pero el lado con auto-negociación prácticamente está garantizado a terminar Down o mal negociado — el modo de negociación tiene que coincidir en ambos extremos, no solo el valor numérico de velocidad.
SOLUCIÓNAl pasar un enlace a no auto-negociación, configure ambos extremos de la misma manera, con velocidad y dúplex coincidentes establecidos explícitamente en cada lado.
SÍNTOMALa configuración del switch de reemplazo es una traducción fiel, línea por línea, de la configuración del fabricante anterior, y algo aún se comporta de forma diferente cuando el tráfico real lo alcanza.
CAUSADiferentes fabricantes traen comportamientos predeterminados distintos precisamente en las situaciones que no aparecen en una comparación de configuración estática — cuán permisivo es el reenvío de un trunk antes de que se confirme LACP, cómo se manejan los fallos de negociación, qué contadores se incrementan silenciosamente en lugar de generar una alarma.
SOLUCIÓNTrate cada proyecto de reemplazo de fabricante como una auditoría de comportamiento de negociación además de una migración de configuración — verifique el comportamiento de reenvío LACP y la velocidad de interfaz negociada contra el comportamiento real en tiempo de ejecución del equipo anterior, no solo su configuración guardada.
Sacadas directamente del terreno — las que vale la pena tener una respuesta lista.
Le indica al switch que siga reenviando tráfico en un puerto miembro de Eth-Trunk que está físicamente Up incluso si la negociación LACP con el peer nunca se confirmó — que es lo que permite que un Eth-Trunk siga funcionando frente a un peer que no ejecuta LACP real, como algunos hosts de virtualización. Es seguro dejarlo configurado mientras el comportamiento de ese peer no cambie, pero sí significa que el switch ya no usa la negociación LACP como verificación de seguridad contra un cableado incorrecto genuino en ese trunk, así que vale la pena confirmar que el peer realmente es lo que usted cree antes de depender de él a largo plazo.
Verifique primero display interface — un cable u óptica realmente defectuosos suelen mostrar conteos de errores CRC, Symbol o Jabber en aumento junto a la velocidad baja, mientras que un desajuste puro de negociación típicamente muestra un conteo de errores limpio con el campo Speed simplemente reportando un valor menor al esperado. Si los contadores de errores están limpios, la falla es casi con certeza de negociación, no del medio físico.
Los culpables restantes más comunes son desajustes en el modo de etiquetado VLAN (el manejo de la VLAN nativa de trunk difiere significativamente entre fabricantes), una regla NAT o ACL que se comporta de forma diferente en el orden de reenvío del nuevo equipo, y ajustes de MTU o tramas jumbo que eran implícitos en el equipo anterior pero necesitan configurarse explícitamente en el nuevo.
No — un estado Up en un lado no confirma que el emparejamiento esté saludable. Cuando los dos extremos no están de acuerdo en el modo de negociación, el lado de velocidad fija puede mostrar Up o Down según las condiciones, mientras que el lado con auto-negociación está prácticamente garantizado a terminar Down o mal negociado. Configure ambos extremos de la misma manera, cualquiera sea el modo elegido.
mode lacp en la interfaz Eth-Trunk es la configuración LACP dinámica equivalente. La brecha que aparece en la práctica no es la palabra clave de modo en sí — es si el peer en el otro extremo de ese Eth-Trunk realmente completa la negociación LACP, que es exactamente la condición que lacp force-forward está ahí para sortear.
Puede, pero la advertencia más importante para escenarios hiperconvergentes es otra: los switches de clase campus generalmente no se recomiendan para tráfico de infraestructura hiperconvergente en primer lugar, porque sus búferes de puerto suelen estar dimensionados para patrones de tráfico de campus en lugar del tráfico este-oeste más ráfaga que genera un clúster hiperconvergente, y ese desajuste puede aparecer como descartes por congestión incluso una vez que la negociación LACP y de velocidad estén ambas configuradas correctamente.
Esta nota se basa en dos casos de campo específicos de Huawei serie S — un S5720 reemplazando un switch Cisco en un Eth-Trunk LACP hacia un servidor ESX, y un switch serie S reemplazando un equipo NE frente a un equipo MSC — además de la evidencia de display interface / display logbuffer / diag-logfile detrás de ellos. Los comandos exactos son sintaxis VRP de Huawei; la lección subyacente (un cambio de fabricante cambia el comportamiento de negociación, no solo la sintaxis de configuración) aplica sin importar qué dos fabricantes estén involucrados. No cubre en profundidad la interoperabilidad LACP con pilas que no sean Huawei ni Cisco, ni el comportamiento de agregación específico de MLAG/apilamiento.
Cuéntenos qué muestran display interface y display logbuffer en el enlace que se comporta mal, y si es un problema de agregación o de velocidad, y le ayudamos a interpretarlo.