Trocar o equipamento de outro fabricante por um da Huawei raramente é apenas um exercício de cabeamento — os dois casos de campo abaixo passaram em todas as verificações físicas e o tráfego mesmo assim quebrou, porque a falha estava em como o novo switch negocia, não em como está cabeado. Um Eth-Trunk para um servidor ESX que parou de passar tráfego completamente, e uma porta GE que discretamente auto-negociou para 10Mbit/s inundando um contador de descarte.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Ambos os casos abaixo passaram nas verificações físicas óbvias — cabeamento, status da porta, luzes de link — e o tráfego mesmo assim quebrou, porque a falha estava no comportamento de negociação padrão, não na fiação.
Substituir o switch de outro fabricante por um da Huawei é um projeto de rotina, até que o tráfego que funcionava perfeitamente no equipamento antigo não passe no novo, ou um link que deveria rodar em velocidade total se acomode discretamente com uma fração dela. Nenhum dos dois casos aqui envolve um cabo danificado ou uma VLAN errada — um é uma agregação Eth-Trunk para um host de virtualização que nunca completa de fato a negociação LACP com seu par, e o outro é uma porta gigabit cuja auto-negociação converge para 10Mbit/s em vez de 1000Mbit/s. A mesma disciplina que detecta isso se aplica seja a falha no comportamento de agregação ou na negociação de camada de enlace — veja nossa nota complementar sobre
A seguir está a árvore de falhas na qual esses dois casos se dividem, a evidência exata de display interface / display logbuffer para cada um, as correções lacp force-forward e não auto-negociação, e algumas respostas de perguntas frequentes de casos reais de campo.
Ambas as falhas se apresentam como um link fisicamente correto que mesmo assim não transporta o tráfego que deveria — a diferença está no que display interface realmente mostra ao observar.
Colocar primeiro o sintoma nesta árvore evita reterminar um cabo que nunca foi o problema, ou substituir uma óptica em um link que era apenas uma incompatibilidade de negociação.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Ambos os ramos compartilham a mesma lição subjacente: o equipamento do fabricante antigo tinha um comportamento padrão — encaminhamento LACP permissivo, ou um resultado de negociação que por acaso chegava à velocidade total — que o equipamento substituto não reproduz automaticamente, e nada na camada física dirá isso por si só.
Um S5720 substituiu um switch Cisco em um Eth-Trunk em modo LACP conectado a um servidor ESX — todas as verificações físicas estavam limpas, e o servidor continuava inacessível.
A configuração Cisco usava channel-group 1 mode active em ambas as interfaces membro, com o próprio port-channel em modo trunk — uma agregação LACP ativa padrão. Após a substituição, o lado S5720 foi configurado com um Eth-Trunk equivalente em mode lacp, com as mesmas duas portas físicas adicionadas como membros.
! 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-forwardUm switch S substituiu um equipamento NE de frente para um equipamento MSC — após a substituição, o lado MSC reportou perda pesada de pacotes, e o contador de descarte revelou a verdadeira história.
<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 duplexUma porta que negocia para baixo em vez de falhar completamente é um sintoma diferente de uma que está simplesmente fisicamente inativa — se o que você está realmente vendo é uma porta que se recusa a ficar Up de jeito nenhum, em vez de se assentar em uma velocidade baixa, veja nossa nota complementar sobre
Ambos os casos acima são exemplos específicos de um padrão mais amplo que vale a pena observar em cada projeto de substituição de fabricante.
SINTOMAAs portas membro do Eth-Trunk estão fisicamente Up no novo switch, a configuração espelha a do fabricante antigo, e o tráfego ainda não passa para o dispositivo peer.
CAUSAAlguns peers — o vSwitch de um host de virtualização é o exemplo clássico — apresentam um link fisicamente Up sem realmente trocar unidades de dados do protocolo LACP, e por padrão um switch Huawei não encaminha em um membro de Eth-Trunk até que a negociação LACP com o peer seja confirmada.
SOLUÇÃOConfigure lacp force-forward na interface Eth-Trunk para que o switch encaminhe em membros fisicamente Up mesmo sem negociação LACP confirmada do peer.
SINTOMAUm link classificado como gigabit fica Up sem nenhum erro, mas a taxa de transferência está muito abaixo do esperado e o contador de descarte de saída sobe constantemente.
CAUSAA auto-negociação entre os dois lados convergiu para uma velocidade comum muito mais baixa — 10Mbit/s em vez de 1000Mbit/s neste caso — e os volumes de tráfego dimensionados para gigabit simplesmente excedem o que um link de 10M pode transportar, então o excedente é descartado em vez de o link falhar completamente.
SOLUÇÃOConfirme a velocidade realmente negociada com display interface antes de presumir um problema de roteamento ou ACL; se estiver assentada baixa, mova ambos os lados para uma velocidade e duplex fixos e correspondentes com undo negotiation auto mais um comando speed explícito.
SINTOMAUm lado está configurado para velocidade fixa, o outro é deixado em auto-negociação, e o link se comporta de forma inconsistente — às vezes Up, às vezes não, nunca totalmente confiável.
CAUSASe os dois lados de um link não concordam no modo de negociação, o lado configurado para velocidade fixa pode mostrar Up ou Down dependendo das condições, mas o lado em auto-negociação está praticamente garantido a terminar Down ou mal negociado — o modo de negociação precisa coincidir em ambos os lados, não apenas o valor numérico de velocidade.
SOLUÇÃOAo mover um link para não auto-negociação, configure ambos os lados da mesma forma, com velocidade e duplex correspondentes definidos explicitamente em cada lado.
SINTOMAA configuração do switch substituto é uma tradução fiel, linha por linha, da configuração do fabricante antigo, e algo ainda se comporta de forma diferente quando o tráfego real o atinge.
CAUSAFabricantes diferentes vêm com comportamentos padrão diferentes exatamente nas situações que não aparecem em uma comparação estática de configuração — quão permissivo é o encaminhamento de um trunk antes da confirmação do LACP, como falhas de negociação são tratadas, quais contadores incrementam silenciosamente em vez de gerar um alarme.
SOLUÇÃOTrate cada projeto de substituição de fabricante como uma auditoria de comportamento de negociação além de uma migração de configuração — verifique o comportamento de encaminhamento LACP e a velocidade de interface negociada em relação ao comportamento real em tempo de execução do equipamento antigo, não apenas sua configuração salva.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Ele diz ao switch para continuar encaminhando tráfego em uma porta membro de Eth-Trunk que está fisicamente Up mesmo que a negociação LACP com o peer nunca tenha sido confirmada — que é o que permite que um Eth-Trunk continue funcionando contra um peer que não executa LACP real, como alguns hosts de virtualização. É seguro deixá-lo configurado enquanto o comportamento desse peer não mudar, mas isso significa que o switch não está mais usando a negociação LACP como verificação de segurança contra um cabeamento genuinamente errado nesse trunk, então vale a pena confirmar que o peer realmente é o que você pensa antes de depender dele a longo prazo.
Verifique primeiro display interface — um cabo ou óptica realmente ruins geralmente mostram contagens crescentes de erros CRC, Symbol ou Jabber junto com a velocidade baixa, enquanto uma incompatibilidade pura de negociação normalmente mostra uma contagem de erros limpa com o campo Speed simplesmente reportando um valor menor que o esperado. Se os contadores de erro estiverem limpos, a falha é quase certamente de negociação, não do meio físico.
Os culpados remanescentes mais comuns são incompatibilidades no modo de marcação VLAN (o tratamento da VLAN nativa de trunk difere significativamente entre fabricantes), uma regra NAT ou ACL que se comporta de forma diferente na ordem de encaminhamento do novo equipamento, e configurações de MTU ou quadros jumbo que eram implícitas no equipamento antigo mas precisam ser configuradas explicitamente no novo.
Não — um status Up de um lado não confirma que o pareamento está saudável. Quando os dois lados não concordam no modo de negociação, o lado de velocidade fixa pode mostrar Up ou Down dependendo das condições, enquanto o lado em auto-negociação está praticamente garantido a terminar Down ou mal negociado. Configure ambos os lados da mesma forma, qualquer que seja o modo escolhido.
mode lacp na interface Eth-Trunk é a configuração LACP dinâmica equivalente. A lacuna que aparece na prática não é a palavra-chave do modo em si — é se o peer na outra ponta desse Eth-Trunk realmente completa a negociação LACP, que é exatamente a condição que o lacp force-forward existe para contornar.
Pode, mas o cuidado maior para cenários hiperconvergentes é outro: switches de classe campus geralmente não são recomendados para tráfego de infraestrutura hiperconvergente em primeiro lugar, porque seus buffers de porta geralmente são dimensionados para padrões de tráfego de campus em vez do tráfego leste-oeste mais em rajadas que um cluster hiperconvergente gera, e essa incompatibilidade pode aparecer como descartes por congestionamento mesmo depois que a negociação LACP e de velocidade estejam ambas configuradas corretamente.
Esta nota se baseia em dois casos de campo específicos da Huawei série S — um S5720 substituindo um switch Cisco em um Eth-Trunk LACP para um servidor ESX, e um switch série S substituindo um equipamento NE de frente para um equipamento MSC — além da evidência de display interface / display logbuffer / diag-logfile por trás deles. Os comandos exatos são sintaxe VRP da Huawei; a lição subjacente (uma troca de fabricante muda o comportamento de negociação, não apenas a sintaxe de configuração) se aplica independentemente de quais dois fabricantes estejam envolvidos. Não cobre em profundidade a interoperabilidade LACP com pilhas que não sejam Huawei ou Cisco, nem o comportamento de agregação específico de MLAG/empilhamento.
Conte-nos o que display interface e display logbuffer mostram no link que está se comportando mal, e se é um problema de agregação ou de velocidade, e ajudamos você a interpretá-lo.