EtherChannel: Combining Links for Redundancy and Speed

I needed more bandwidth between two switches, but adding a second cable created a loop. Spanning Tree blocked one link - exactly what it's designed to do. EtherChannel solved this by making multiple physical links act as one logical connection. No loops, more bandwidth, automatic failover.

Why EtherChannel Exists

Without EtherChannel, multiple links between switches are a problem. STP sees them as potential loops and blocks all but one. You've paid for redundancy but can't use it.

EtherChannel bundles those links into a single logical interface. STP sees one link. Traffic flows across all physical members. If one cable fails, traffic shifts to the remaining ones without disruption.

Requirements

Before configuring, verify all ports match:

• Same speed and duplex
• Same VLAN configuration (access or trunk)
• Same native VLAN if trunking
• Up to 8 ports per bundle

I've seen EtherChannels fail to form because one port was accidentally set to a different speed. Always check the basics.

LACP vs PAgP

LACP (Link Aggregation Control Protocol) - IEEE standard. Works across vendors. Use this.

PAgP (Port Aggregation Protocol) - Cisco proprietary. Only use in Cisco-only environments.

LACP can have up to 16 ports with 8 active and 8 on standby. Standby ports activate automatically if active ones fail. I always use LACP for vendor flexibility.

Configuration

Here's how I configure a 4-port EtherChannel between two switches:

Switch 1:

interface range GigabitEthernet0/1-4
 channel-protocol lacp
 channel-group 1 mode active

Switch 2:

interface range GigabitEthernet0/1-4
 channel-protocol lacp
 channel-group 1 mode active

Both sides are active, meaning they'll actively negotiate. You can use passive on one side, but never both - passive waits for the other side to initiate.

Verify It's Working

show etherchannel summary

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------
1      Po1(SU)       LACP       Gi0/1(P) Gi0/2(P) Gi0/3(P) Gi0/4(P)

Key flags:

• SU = Layer 2, in use (good)
• P = Port is bundled in the channel (good)
• I = Individual, not bundled (problem)
• s = Suspended (check for mismatches)

If ports show I or s, check that all settings match between ports.

Load Balancing

Traffic is distributed across member links using a hash. You choose what to hash on:

port-channel load-balance src-dst-ip

Options I use:

• src-dst-ip - Best for routed traffic, most common
• src-dst-mac - For Layer 2 only environments
• src-dst-port - When endpoints are few but connections are many

The hash determines which physical link carries each flow. A single TCP connection still uses one link - you get aggregate bandwidth across many connections, not per-connection speedup.

Mistakes I've Made

Mismatched configs. One side was trunk, one was access. EtherChannel didn't form. Spent 30 minutes checking cables before noticing the config mismatch.

Forgot both sides. Configured one switch and walked away. Nothing happened. EtherChannel needs both ends configured.

Expected per-flow speed increase. A client complained their single large file transfer wasn't faster. That's not how load balancing works - one flow, one link.

Troubleshooting Commands

# Summary view
show etherchannel summary

# Detailed port-channel info
show etherchannel port-channel

# Check load balancing method
show etherchannel load-balance

# LACP-specific
show lacp neighbor

Key Takeaways

• EtherChannel bundles physical links into one logical interface, avoiding STP blocking
• Use LACP for cross-vendor compatibility
• All member ports must have identical configuration
• Load balancing distributes flows, not individual connections
• Check both sides - configuration must match
• show etherchannel summary is your verification command