Bond the two physical ports inside the same hardware bypass pair together, and the bypass relay that's supposed to keep traffic flowing when the WAF fails looks perfectly configured — and still doesn't work. This is the interface pairing hardware bypass actually depends on, the LACP settings that have to match before aggregation even negotiates, and how to prove bypass works before you trust it in production.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The failure mode here isn't a missing setting — it's two correct-looking features that quietly cancel each other out.
Hardware bypass exists for exactly one reason: keep business traffic flowing through a transparent, inline WAF even if the device loses power or crashes. On a WAF with four bypass-capable ports, it's tempting to treat link aggregation as a purely logical decision — group whichever ports are next to each other into a bond, bridge the two bonds, done. That instinct is exactly what breaks bypass, because the two physical ports inside a single bypass relay pair are fixed in hardware and don't care how you've grouped them logically.
What follows is the interface pairing bypass actually depends on, the wiring that keeps the physical short-circuit and the logical bridge pointed the same direction, the LACP negotiation settings that have to match before aggregation comes up at all, the gotchas that account for most of these tickets, and field-sourced answers to the questions that come up constantly.
Two physical ports form a bypass pair whether or not you've put them in the same bond — the relay doesn't know or care about your logical grouping.
On this WAF's bypass-capable ports, s1p1↔s1p2 is one hardware relay pair and s1p3↔s1p4 is the other. When the device loses power, the relay physically shorts each pair together so traffic keeps moving through the box without the WAF in the path. Whether that short-circuit actually helps your traffic depends entirely on which bond each port ends up in.
Diagram labels are kept in English for engineering clarity.
The wrong wiring (left) isn't a rare mistake — it's the more intuitive one, because grouping s1p1+s1p2 into one bond looks tidy on a cabling diagram. It's also exactly what defeats bypass: the relay shorts two ports that are both members of the same bond, so failed-over traffic loops back into where it came from instead of crossing to the other bond. The fix is to cross the wiring so each bond contains one port from each bypass pair.
Two separate things have to be true at once: the physical wiring has to cross the bypass pairs, and LACP has to actually negotiate — neither one alone is enough.
This is the one wiring decision the whole rest of the deployment depends on — get it right before configuring anything else.
Bridge: br0
bond1 members: s1p1, s1p3 // one port from each bypass pair
bond2 members: s1p2, s1p4 // the other port from each bypass pair
bypass pairs (fixed in hardware): s1p1<->s1p2 , s1p3<->s1p4
// bypass short on s1p1<->s1p2 now crosses bond1 -> bond2, matching the bridge directionThe WAF only speaks dynamic LACP — confirm that before you spend time comparing load-balancing algorithms.
WAF supported aggregation modes:
LACP 802.3ad -- dynamic only, no static aggregation support
Load-balance Round-robin
Load-balance XOR
active-backup
Bridge build checklist:
[ ] Resolve LACPDU packets -- must be checked, or LACP frames are never read
[ ] Load-balancing algorithm: 2+3-layer or 3+4-layer -- match the peer's hash
// symptom: negotiation fails even after changing mode and algorithm repeatedly
// -> peer is very likely on STATIC aggregation, which WAF cannot negotiate againstOnce the wiring and the LACP settings are both right, these are the specific ways this still goes wrong in the field.
SYMPTOMHardware bypass event fires — power loss or a deliberate test — but business traffic still doesn't flow, even though bypass status shows active.
CAUSEBoth physical ports of one bypass relay pair (s1p1+s1p2, or s1p3+s1p4) were bonded into the same logical bond. When the relay shorts that pair together, the failed-over traffic loops back into the same bond it came from — it never reaches the other bond, so it never crosses the bridge.
FIXRebuild the bonds so each one contains exactly one port from each bypass pair: bond1 = s1p1 + s1p3, bond2 = s1p2 + s1p4.
// wrong
bond1: s1p1, s1p2 // both members of the same bypass relay pair
bond2: s1p3, s1p4
// correct
bond1: s1p1, s1p3 // one port from each bypass pair
bond2: s1p2, s1p4SYMPTOMAggregation mode and load-balancing algorithm have been changed repeatedly on the WAF side, and negotiation still fails.
CAUSEThe peer switch is configured for a static / manual aggregation group. The WAF's 802.3ad implementation only speaks dynamic LACP — there's no static aggregation mode to fall back to, so no algorithm change on the WAF side will ever fix this.
FIXMove the peer switch to dynamic LACP (802.3ad) and confirm the negotiation protocol matches before touching the algorithm.
SYMPTOMBoth ends explicitly configured for 802.3ad, and the aggregation still won't negotiate — or negotiates but traffic distribution looks wrong.
CAUSEThe hashing / distribution algorithm differs between the two ends — for example the WAF set to 3+4-layer against a switch hashing on 2+3-layer, or the peer not actually running 802.3ad at all despite appearing to.
FIXIf the peer is confirmed on 802.3ad, try switching the WAF between 2+3-layer and 3+4-layer to find the match. If the peer isn't explicitly on 802.3ad, switch the WAF's own aggregation mode to Round-robin or XOR instead.
SYMPTOMBoth ends look correctly configured for 802.3ad and the same algorithm, and aggregation still never forms.
CAUSEThe bridge-creation step has a separate checkbox to parse LACPDU packets. Without it, the WAF never reads the peer's LACP control frames at all — from the WAF's side, there's no LACP conversation happening, regardless of how correct the rest of the configuration is.
FIXEdit the bridge configuration and enable Resolve LACPDU packets, then recheck negotiation status.
SYMPTOMTime spent building a bypass emergency runbook for a deployment that's actually in bypass / monitoring (out-of-path) mode.
CAUSEIn monitoring mode the WAF isn't inline with business traffic at all — a device failure has no effect on the pass-through path, and there's no hardware bypass relay decision to make because there's nothing in the traffic path to bypass.
FIXConfirm the deployment mode first — inline transparent bridge vs. out-of-path monitoring — before spending time on a bypass wiring plan; monitoring mode needs none of the above.
Pulled from field cases — the ones worth having a ready answer for.
Hardware bypass is a physical relay built into specific port pairs so that, in an inline transparent deployment, traffic keeps flowing straight through those two ports even if the WAF loses power or crashes — no software involved, purely electrical. It matters which logical bond each port ends up in, because the relay only shorts the two physical ports in its own pair; if link aggregation has already grouped both of those ports into the same bond, the short-circuit routes traffic back into that bond instead of across to the bridge partner, and business traffic stays down even though bypass fired correctly.
Check the hardware panel labeling and the platform's port documentation before wiring — bypass pairs are fixed per port group on the device (for example s1p1↔s1p2 and s1p3↔s1p4 on this platform) and don't change based on configuration. Confirming this before cabling is far cheaper than re-cabling after a failed bypass test.
Confirm the peer switch is on dynamic LACP (802.3ad), not a static aggregation group — the WAF has no static fallback. Then check that Resolve LACPDU packets is enabled on the bridge; without it the WAF never reads the peer's control frames at all. Only after both of those are confirmed is it worth comparing the load-balancing algorithm (2+3-layer vs 3+4-layer) between the two ends.
No. Monitoring mode doesn't put the WAF in the business traffic path at all, so a device failure has no effect on pass-through traffic and there's no hardware bypass relay decision to make. The bonding and bypass wiring above only matters for an inline transparent bridge deployment.
Four options: LACP 802.3ad (dynamic negotiation with the peer, the usual choice when the peer switch supports it), load-balance Round-robin, load-balance XOR (policy-based hashing), and active-backup (one port active, one standby). If the peer switch explicitly runs 802.3ad, match it and align the hashing algorithm; if it doesn't, Round-robin or XOR avoids a negotiation that will never complete.
This note is built around a Huawei WAF appliance's bypass-capable port pairing (s1p1↔s1p2, s1p3↔s1p4), its supported aggregation modes, and the field cases behind the bonding-versus-bypass conflict. If your platform's bypass-capable ports are numbered or grouped differently, the exact interface names change, but the underlying rule — bond across bypass pairs, never inside one — carries over directly. It doesn't cover software / application-layer bypass behavior, non-transparent (reverse proxy) deployments where hardware bypass doesn't apply the same way, or aggregation with more than two bypass-capable port pairs.
Send us the bypass pair labeling from your hardware panel and how the bonds are currently wired, and we'll help you check whether the crossing is right before you test failover in production.