Swapping another vendor's box out for a Huawei one is rarely just a cabling exercise — the two field cases below both passed every physical check and still broke traffic, because the fault was in how the new switch negotiates, not in how it's wired. One Eth-Trunk to an ESX server that stopped passing traffic entirely, and one GE port that quietly auto-negotiated down to 10Mbit/s and flooded a discard counter.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Both cases below passed the obvious physical checks — cabling, port status, link lights — and still broke traffic, because the fault was in default negotiation behavior, not wiring.
Replacing another vendor's switch with a Huawei one is a routine project, right up until traffic that worked perfectly on the old box won't pass on the new one, or a link that should run at full speed quietly settles for a fraction of it. Neither of the two cases here involves a damaged cable or a wrong VLAN — one is an Eth-Trunk aggregation to a virtualization host that never actually completes LACP negotiation with its peer, and the other is a gigabit port whose auto-negotiation converges on 10Mbit/s instead of 1000Mbit/s. The same discipline that catches these applies whether the fault is in aggregation behavior or link-layer negotiation — see our companion note on
What follows is the fault tree these two cases split into, the exact display interface / display logbuffer evidence for each, the lacp force-forward and non-auto-negotiation fixes, and a handful of FAQ answers from real field cases.
Both faults present as a link that's physically fine and yet won't carry the traffic it should — the difference is in what display interface actually shows once you look.
Placing the symptom on this tree first stops you from re-terminating a cable that was never the problem, or replacing an optic on a link that was only ever a negotiation mismatch.
Diagram labels are kept in English for engineering clarity.
Both branches share the same underlying lesson: the old vendor's box had a default behavior — permissive LACP forwarding, or a negotiation outcome that happened to land at full speed — that the replacement box doesn't automatically reproduce, and nothing about the physical layer will tell you that on its own.
An S5720 replaced a Cisco switch on an LACP-mode Eth-Trunk connected to an ESX server — every physical check was clean, and the server still couldn't be reached.
The Cisco configuration used channel-group 1 mode active on both member interfaces, with the port-channel itself in trunk mode — a standard active-LACP aggregation. After the swap, the S5720 side was configured with an equivalent Eth-Trunk in mode lacp, with the same two physical ports added as members.
! 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-forwardAn S switch replaced an NE device facing an MSC device — after the swap, the MSC side reported heavy packet loss, and the discard counter told the real story.
<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 duplexA port that negotiates down instead of failing outright is a different symptom than one that's simply physically down — if what you're actually looking at is a port refusing to come Up at all rather than settling at a low speed, see our companion note on
Both cases above are specific examples of a broader pattern worth watching for on every vendor-replacement project.
SYMPTOMEth-Trunk member ports are physically Up on the new switch, the configuration mirrors the old vendor's setup, and traffic still won't pass to the peer device.
CAUSESome peers — a virtualization host's vSwitch is the classic example — present a physically Up link without actually exchanging LACP protocol data units, and by default a Huawei switch won't forward on an Eth-Trunk member until LACP negotiation with the peer is confirmed.
FIXConfigure lacp force-forward on the Eth-Trunk interface so the switch forwards on physically Up members even without confirmed LACP negotiation from the peer.
SYMPTOMA gigabit-rated link comes Up without any error, but throughput is far below expectation and the output discard counter climbs steadily.
CAUSEAuto-negotiation between the two ends converged on a much lower common speed — 10Mbit/s instead of 1000Mbit/s in this case — and traffic volumes sized for gigabit simply exceed what a 10M link can carry, so the excess gets discarded rather than the link failing outright.
FIXConfirm the actual negotiated speed with display interface before assuming a routing or ACL problem; if it's settled low, move both ends to a fixed, matching speed and duplex with undo negotiation auto plus an explicit speed command.
SYMPTOMOne side is configured for a fixed speed, the other side is left on auto-negotiation, and the link behaves inconsistently — sometimes Up, sometimes not, never fully reliable.
CAUSEIf the two ends of a link don't agree on negotiation mode, the side configured for a fixed speed may show Up or Down depending on conditions, but the auto-negotiating side is effectively guaranteed to end up Down or misnegotiated — negotiation mode has to match on both ends, not just the numeric speed value.
FIXWhen moving a link to non-auto-negotiation, configure both ends the same way, with matching speed and duplex explicitly set on each side.
SYMPTOMThe replacement switch's configuration is a faithful, line-by-line translation of the old vendor's configuration, and something still behaves differently once real traffic hits it.
CAUSEDifferent vendors ship different default behaviors around exactly the situations that don't show up in a static configuration diff — how permissively a trunk forwards before LACP is confirmed, how negotiation failures are handled, which counters increment silently instead of raising an alarm.
FIXTreat every vendor-replacement project as a negotiation-behavior audit as well as a configuration migration — check LACP forwarding behavior and negotiated interface speed against the old device's actual runtime behavior, not just its saved configuration.
Pulled straight from the field — the ones worth having an answer ready for.
It tells the switch to keep forwarding traffic on an Eth-Trunk member port that's physically Up even if LACP negotiation with the peer was never confirmed — which is what lets an Eth-Trunk keep working against a peer that doesn't run real LACP, like some virtualization hosts. It's safe to leave configured for as long as that peer's behavior doesn't change, but it does mean the switch is no longer using LACP negotiation as a safety check against a genuine miswiring on that trunk, so it's worth confirming the peer really is what you think it is before relying on it long-term.
Check display interface first — a genuinely bad cable or optic usually shows rising CRC, Symbol or Jabber error counts alongside the low speed, while a pure negotiation mismatch typically shows a clean error count with the Speed field simply reporting a lower value than expected. If the error counters are clean, the fault is almost certainly negotiation, not the physical medium.
The most common remaining culprits are VLAN tagging mode mismatches (trunk native VLAN handling differs meaningfully between vendors), a NAT or ACL rule that behaves differently in the new device's forwarding order, and MTU or jumbo-frame settings that were implicit on the old device but need to be configured explicitly on the new one.
No — a Up status on one side doesn't confirm the pairing is healthy. When the two ends disagree on negotiation mode, the fixed-speed side can show Up or Down depending on conditions, while the auto-negotiating side is effectively guaranteed to end up Down or badly negotiated. Configure both ends the same way, whichever mode you choose.
mode lacp on the Eth-Trunk interface is the equivalent dynamic-LACP configuration. The gap that shows up in practice isn't the mode keyword itself — it's whether the peer on the other end of that Eth-Trunk actually completes LACP negotiation, which is exactly the condition lacp force-forward is there to work around.
It can, but the bigger caution for hyperconverged scenarios is a separate one: campus-class switches generally aren't recommended for hyperconverged infrastructure traffic in the first place, because their port buffers are usually sized for campus traffic patterns rather than the burstier east-west traffic a hyperconverged cluster generates, and that mismatch can show up as congestion-driven discards even once the LACP and speed negotiation are both configured correctly.
This note is built around two specific Huawei S-series field cases — an S5720 replacing a Cisco switch on an LACP Eth-Trunk to an ESX server, and an S-series switch replacing an NE device facing an MSC device — plus the display interface / display logbuffer / diag-logfile evidence behind them. The exact commands are Huawei VRP syntax; the underlying lesson (a vendor swap changes negotiation behavior, not just configuration syntax) applies regardless of which two vendors are involved. It doesn't cover LACP interoperability with non-Huawei, non-Cisco stacks in depth, or MLAG/stacking-specific aggregation behavior.
Tell us what display interface and display logbuffer show on the link that's misbehaving, and whether it's an aggregation or a speed problem, and we'll help you read it.