On this page
Why bundle linksStatic bundles versus LACPHashing: why one flow cannot use two linksMember port requirementsMLAG, stacking and chassisFoundry heritage: trunk groups and lagVerificationQuestions01 /Why bundle links
Two problems push engineers to aggregation. The first is capacity: when a single 1 Gbit/s uplink saturates and 10 Gbit/s ports are unavailable or unaffordable, four parallel 1 Gbit/s links are the next step. The second is redundancy: a bundle with one failed member keeps forwarding at reduced capacity with no topology change, where a lone link would drop everything.
Parallel links between two switches would normally form a loop, and spanning tree would block all but one. Aggregation presents the members as one logical port, so spanning tree sees one link and every member stays active. The logical port carries VLAN tags, so a bundle is usually also a trunk in the 802.1Q sense.
02 /Static bundles versus LACP
A static bundle is configured identically on both ends and starts forwarding immediately. Nothing checks that the far end agrees. If one cable is patched to the wrong port, or the far switch loses its configuration, frames are hashed onto a member that leads nowhere and a fraction of traffic silently disappears.
LACP (Link Aggregation Control Protocol) fixes that by exchanging LACPDUs on every member. A port joins the bundle only after both ends confirm the same partner system and key. If a member stops receiving LACPDUs it is removed after three missed intervals: 90 seconds at the slow rate, 3 seconds at the fast rate. An active port sends LACPDUs unprompted; a passive port only answers. At least one side must be active.
| Property | Static | LACP |
|---|---|---|
| Configuration | Both ends manually, must match | Both ends, then negotiated |
| Misconfiguration | Silent loss of a fraction of traffic | Member left out of the bundle |
| One-way fault | Undetected without extra protocols | Detected by missing LACPDUs |
| Interoperability | Works with anything | Requires LACP on both ends |
| Typical use | Servers with simple NIC teaming, legacy gear | Switch to switch, switch to hypervisor |
03 /Hashing: why one flow cannot use two links
The bundle does not stripe packets across members. Reordering would wreck TCP performance, so every implementation hashes fields from each frame (source and destination MAC, IP addresses, sometimes Layer 4 ports) to pick a member. All packets of one flow share a hash and therefore a member. A single large file transfer between two hosts runs at the speed of one link no matter how many links are bundled. Aggregate throughput rises only with many concurrent flows.
Include Layer 3 and Layer 4 fields in the hash when the platform allows. Hashing on MAC alone puts all traffic through one router onto one member, because every frame carries the same router MAC.
04 /Member port requirements
- Same speed and duplex on every member; a mixed 100 Mbit/s and 1 Gbit/s bundle is rejected or hashes traffic onto the slow link.
- Same VLAN membership, tagging and QoS settings; most platforms copy configuration from a designated primary port.
- Physically between the same two devices, unless the far end is a chassis, a stack or an MLAG pair that presents one system ID.
- Member counts of 2, 4 or 8; some ASICs hash unevenly over 3 or 6 members.
05 /MLAG, stacking and chassis
LACP requires one partner system on each end, so two independent switches cannot terminate one bundle unless they cooperate. Chassis systems solve this trivially: all line cards share one control plane. Stacking joins fixed switches into one logical switch over a stack link. MLAG (multi-chassis link aggregation) lets two separate switches present a shared LACP system ID over a peer link so a downstream device sees one partner. MLAG implementations are vendor specific and do not interoperate.
06 /Foundry heritage: trunk groups and lag
IronWare called link aggregation trunking, a term that collides with the 802.1Q meaning of trunk and confused a generation of engineers moving between vendors. On BigIron, FastIron and ServerIron platforms the original command created a trunk group from consecutive ports, with the lowest-numbered port as the primary that carried the configuration. The Trunking chapter of the ServerIron basic configuration guide was among the most linked Foundry documents. Later releases replaced the syntax with lag configuration that supported LACP.
! legacy trunk group (older IronWare) trunk ethernet 1/1 to 1/2 trunk deploy show trunk ! ! later lag syntax with LACP lag "uplink-core" dynamic id 1 ports ethernet 1/1 to 1/4 primary-port 1/1 deploy show lag show lag "uplink-core"
07 /Verification
Confirm three things on both ends: every intended member is active in the bundle, LACP partner system IDs match, and traffic is spreading. Watch per-member counters under load; a member near zero indicates a hash that ignores the fields that vary in your traffic. sFlow or SNMP interface counters from the IF-MIB make the imbalance visible over time.
08 /Questions
Does link aggregation double bandwidth?
For aggregate traffic across many flows, approximately yes. For a single flow, no. Each flow is hashed to one member and runs at that member speed. A two-member 1 Gbit/s bundle gives one host-to-host transfer 1 Gbit/s, not 2.
Should I use static or LACP?
LACP whenever both ends support it. It detects miswiring and one-way faults and removes bad members automatically. Use static only for devices that cannot speak LACP, and then monitor the members closely.
What does trunking mean on Foundry switches?
On IronWare, trunk meant a link aggregation group, created with the trunk ethernet command. The 802.1Q concept other vendors call a trunk is a tagged port in Foundry terminology. Later IronWare releases adopted lag for aggregation.
Can members have different speeds?
No. Every member must run at the same speed and duplex. A mismatched port is excluded from the bundle by LACP or, on static bundles, causes uneven and unpredictable distribution.
Is LACP the same as EtherChannel?
EtherChannel is one vendor name for its aggregation feature, which can run static, with a proprietary negotiation protocol, or with LACP. LACP is the IEEE standard negotiation protocol and is what you use between different vendors.
Sources
- IEEE Std 802.3ad-2000, Aggregation of Multiple Link Segments
- IEEE Std 802.1AX-2008 (revised 2014, 2020), Link Aggregation
- IETF RFC 7424, Mechanisms for Optimizing LAG/ECMP Component Link Utilization in Networks, 2015
- Foundry Networks, ServerIron basic configuration guide, Trunking chapter (original Foundry documentation, historical, around 2001 to 2004)