The Limitation Spanning Tree Imposes on Redundant Links
Spanning Tree Protocol, discussed earlier in this series, solves the loop problem by blocking all but one path between two switches, even when multiple physical links exist between them. This is safe, but wasteful: a second physical cable, purchased and installed specifically for redundancy and extra bandwidth, sits completely idle in a blocking state, providing no benefit at all unless the primary link fails.
What EtherChannel Actually Does
EtherChannel (the Cisco implementation of Link Aggregation) solves this by bundling multiple physical links between two switches into a single logical interface. Spanning Tree sees only this one logical bundle, not the individual physical links inside it, so no member link is ever blocked — all of them actively carry traffic simultaneously.
Without EtherChannel: 2 links, STP blocks one
Result: 1 Gbps usable bandwidth, no load sharing
With EtherChannel: 2 links bundled into Port-channel 1
Result: up to 2 Gbps usable bandwidth
(traffic load-shared across both links),
and if one physical link fails, traffic
automatically shifts entirely onto the
remaining link with no STP recalculation neededThis dual benefit — combined bandwidth and instant failover without waiting for STP convergence, discussed earlier in this series — is why EtherChannel is standard practice wherever redundant links exist between two switches or between a switch and a server.
Static Versus Dynamic EtherChannel Formation
An EtherChannel bundle can be formed statically, with no negotiation, or dynamically, using a negotiation protocol that verifies both sides agree on the bundle's configuration before activating it.
Static (mode "on"):
no negotiation — both sides simply assume
the bundle is correctly configured
Risk: a misconfiguration on one side can
silently create a partial or broken bundleBecause static mode provides no safety check, it is rarely recommended in production environments — a dynamic negotiation protocol is almost always the better choice.
PAgP: Cisco's Proprietary Negotiation Protocol
PAgP (Port Aggregation Protocol) is a Cisco-proprietary protocol that negotiates and verifies EtherChannel formation between two Cisco devices.
PAgP modes:
Desirable - actively sends PAgP packets,
attempting to negotiate a bundle
Auto - passively waits, only forms a
bundle if the other side initiates
Valid combinations that successfully form a bundle:
Desirable + Desirable ✓
Desirable + Auto ✓
Auto + Auto ✗ (neither side initiates)LACP: The Open Industry Standard
LACP (Link Aggregation Control Protocol, IEEE 802.3ad) serves the same purpose as PAgP but is a vendor-neutral standard, making it the correct choice whenever a bundle needs to connect a Cisco device to non-Cisco equipment.
LACP modes:
Active - actively sends LACP packets,
attempting to negotiate a bundle
Passive - passively waits, only forms a
bundle if the other side initiates
Valid combinations:
Active + Active ✓
Active + Passive ✓
Passive + Passive ✗ (neither side initiates)Given the choice between the two protocols on an all-Cisco network, LACP is generally preferred in modern deployments specifically because it is an open standard, avoiding any future dependency on Cisco-specific equipment for that link.
Configuring an EtherChannel with LACP
Switch(config)# interface range gigabitethernet 1/0/1-2
Switch(config-if-range)# channel-group 1 mode active
Switch(config-if-range)# exit
Switch(config)# interface port-channel 1
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk allowed vlan 10,20,30Configuration is applied to the individual member interfaces to place them into the channel group, but ongoing configuration such as trunk settings, discussed earlier in this series, is applied to the resulting logical Port-channel interface, since it represents the bundle as a single unit from that point forward.
A Critical Requirement: Matching Configuration Across Member Links
Every physical port joining an EtherChannel bundle must share identical configuration — the same speed, duplex, VLAN membership or trunk settings, and native VLAN. A mismatch on any of these settings prevents the bundle from forming correctly, or in some cases forms it while silently misbehaving.
Common EtherChannel misconfiguration:
Port 1: switchport mode trunk
Port 2: switchport mode access
This mismatch typically prevents the bundle
from forming at all, with the switch logging
an error rather than allowing an inconsistent
channel to become activeVerifying EtherChannel Status
Switch# show etherchannel summary
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------
1 Po1(SU) LACP Gi1/0/1(P) Gi1/0/2(P)
-- (P) indicates the port is a bundled, active member
-- (I) would indicate the port is individual, not
-- successfully bundled — a sign of misconfigurationshow etherchannel summary is the primary command for confirming a bundle formed correctly, immediately revealing whether every intended member port is actively participating (P) or has failed to join the bundle (I) — the first place to look when a supposedly redundant link pair is not behaving as expected.
Why EtherChannel Is a Standard Building Block
EtherChannel appears throughout real enterprise network designs wherever high availability and bandwidth aggregation both matter — connecting core switches, connecting switches to servers with multiple network interfaces, and connecting a switch to a firewall or load balancer. Understanding how it interacts with Spanning Tree, discussed earlier in this series, and the distinction between PAgP and LACP negotiation, is essential for both designing resilient topologies and troubleshooting the specific failure modes that occur when a bundle's member links fall out of sync.