Skip to content
Log in Sign up My account

3.1.b Troubleshooting EtherChannel

Blueprint 3.1.b: Troubleshoot static and dynamic EtherChannels

  • Static EtherChannel (mode on)
  • Dynamic EtherChannel with LACP (active, passive) and PAgP (desirable, auto)
  • Member port consistency requirements and suspended ports
  • EtherChannel misconfiguration guard and err-disabled bundles
  • Load balancing (hashing) and why one link can carry most of the traffic
  • Layer 2 and Layer 3 port channels

The verb is troubleshoot. Expect show etherchannel summary exhibits with flags you must decode, mode combinations to evaluate, and member ports that are suspended for a reason you must find in the running configuration.

Two parallel links between switches form a loop, so spanning tree blocks one of them. An EtherChannel (port channel) combines up to eight active physical links into one logical interface. STP sees one port, so every member forwards. If a member fails, traffic moves to the remaining members without an STP reconvergence. Bandwidth is shared per flow, not per packet, so one flow never goes faster than one member link.

Benefit How
More bandwidth Flows hash across all active members
Redundancy Member failure is handled in the bundle; no STP topology change
Simpler STP One logical port, one cost, no blocked parallel links
One place to configure Settings on interface Port-channel N apply to members

Three ways to form a bundle

Mode Protocol Standard Sends negotiation frames Forms with
active LACP IEEE 802.3ad, now 802.1AX Yes, initiates active, passive
passive LACP IEEE Only responds active
desirable PAgP Cisco proprietary Yes, initiates desirable, auto
auto PAgP Cisco Only responds desirable
on None n/a No on only

Rules that answer most mode questions:

  1. One side must initiate. passive/passive and auto/auto never form.
  2. Protocols do not mix. LACP on one end and PAgP on the other never form.
  3. on only works with on. It sends nothing, so an LACP or PAgP partner never sees a partner.
  4. Mixing on one side is not allowed. All members of one channel group on one switch use the same protocol family. You can mix active and passive members on the same switch, but not LACP and PAgP.
graph LR
  subgraph "Bundle forms"
    a1["active"] --- a2["passive"]
    b1["desirable"] --- b2["auto"]
    c1["on"] --- c2["on"]
  end
  subgraph "No bundle"
    d1["passive"] --- d2["passive"]
    e1["active"] --- e2["desirable"]
    f1["on"] --- f2["active"]
  end

LACP details worth knowing

Item Default Notes
Active members 8 Up to 8 more can sit in hot-standby (flag H); platforms differ
lacp system-priority 32768 The switch with the lower system priority (then lower MAC) decides which ports are active
lacp port-priority 32768 Lower is preferred when choosing active members
LACPDU rate Normal (30 s) lacp rate fast sends every 1 s for faster failure detection
lacp max-bundle N Platform maximum Under the port-channel; caps active members, the rest go hot-standby
port-channel min-links N 1 Under the port-channel; the bundle goes down if fewer members are up

PAgP details worth knowing

PAgP bundles up to 8 ports. Its desirable and auto modes accept the non-silent keyword, which tells the port to expect PAgP packets from the partner; the default silent mode lets a port bundle even if the partner is a silent device. PAgP is still seen on older Cisco-only networks. For anything new, and always for non-Cisco partners such as servers and firewalls, use LACP.

Exam trap

on paired with active does not form a bundle, but it is worse than "no bundle". The on side treats both links as one port channel while the LACP side runs them as two individual ports. That is a potential loop, which is exactly what EtherChannel misconfiguration guard detects (see below). Questions that ask what happens with on at one end and LACP at the other usually expect "the LACP ports stay individual (I) and the on side may be err-disabled by misconfiguration guard".

Member consistency requirements

A port joins the bundle only if its configuration is compatible with the port channel. A port that differs is suspended (flag s) and does not forward.

Must match across members (and with the port channel) Does not need to match
Speed and duplex Interface description
Switchport mode (access or trunk) LACP port priority
Access VLAN (on access bundles) LACP active or passive on the same side
Native VLAN (on trunks) CDP settings
Allowed VLAN list (on trunks)
Trunk encapsulation
Layer 2 vs Layer 3 (switchport vs no switchport)

Other things that stop a port from joining: the port is a SPAN destination, it has port security configured on platforms that do not allow it in a bundle, or it is connected to a different device from the other members. LACP and PAgP detect the last case because the partner system ID differs, and the odd port stays individual.

Order of configuration

When you run channel-group N mode ... on a set of ports, IOS XE creates interface Port-channelN automatically and copies the configuration of the first port to it. After that, configuration you apply to the port channel interface is pushed to every member. Two habits avoid most suspended-port problems:

  1. Make the physical ports identical first (interface range helps), then add the channel-group line.
  2. After the bundle exists, change trunk settings on interface Port-channelN, not on members.

If a member ends up different, you will see a log similar to %EC-5-CANNOT_BUNDLE2: Gi0/1 is not compatible with Po1 and will be suspended (native vlan of Gi0/1 is 1, Po1 id 999). The log names the parameter that differs, which is the fastest way to the fix.

Reading show etherchannel summary

DIST1# show etherchannel summary
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      N - not in use, no aggregation
        f - failed to allocate aggregator
        M - not in use, minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port

Number of channel-groups in use: 2
Number of aggregators:           2

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP      Gi0/0(P)    Gi0/1(P)
2      Po2(SD)         PAgP      Gi1/2(I)    Gi1/3(I)
Flag Meaning Usual cause
SU on the port channel Layer 2, in use. Healthy.
RU Layer 3, in use. Healthy.
SD Layer 2, down No members bundled
P on a member Bundled and forwarding
I Stand-alone No LACP or PAgP partner (partner is on, passive/passive, auto/auto, or protocol mismatch)
s Suspended Configuration mismatch with the bundle
H Hot-standby More members than max-bundle allows
D Down Physical link down or err-disabled
M Minimum links not met port-channel min-links larger than members up

Po2 above has both members stand-alone: PAgP is configured locally but no PAgP partner is answering. Look at the far end for auto (if this end is also auto), LACP, or on.

The rest of the toolkit

Command Use
show etherchannel summary One-line health per group with member flags
show etherchannel 1 detail Per-port state, partner information, age of the bundle
show lacp neighbor Partner system ID, port numbers, LACP flags (S slow, F fast, A active, P passive)
show lacp sys-id Local LACP system priority and MAC
show pagp neighbor PAgP partner name, port and capabilities
show interfaces Port-channel1 Logical interface counters and combined bandwidth
show interfaces Port-channel1 etherchannel Members, load-balancing bucket allocation
show etherchannel load-balance Hashing method in use
show interfaces status err-disabled Members disabled by misconfiguration guard 
DIST1# show lacp neighbor
Flags:  S - Device is requesting Slow LACPDUs
        F - Device is requesting Fast LACPDUs
        A - Device is in Active mode       P - Device is in Passive mode

Channel group 1 neighbors

Partner's information:

                  LACP port                        Admin  Oper   Port    Port
Port      Flags   Priority  Dev ID          Age    key    Key    Number  State
Gi0/0     SA      32768     5254.0002.0000  12s    0x0    0x1    0x1     0x3D
Gi0/1     SA      32768     5254.0002.0000  12s    0x0    0x1    0x2     0x3D

Both members see the same partner Dev ID, which confirms both cables go to the same neighbour.

Exam trap

A member that is suspended (s) has a local configuration mismatch. A member that is stand-alone (I) has a negotiation problem with the partner. Do not mix them up: changing the channel mode will not fix a suspended port, and fixing VLAN lists will not fix a stand-alone port.

EtherChannel misconfiguration guard

If one switch bundles two links with mode on and the neighbour does not bundle them, the neighbour treats them as two separate ports. Broadcasts sent by the on side down one member can come back on the other, creating a loop that STP cannot see because the on side believes it has a single port.

EtherChannel misconfiguration guard is part of STP and is enabled by default. When the bundled side receives BPDUs on its port channel that show it is connected to more than one separate neighbour port, it err-disables the port channel members and logs:

%SPANTREE-2-CHNL_MISCFG: Detected loop due to etherchannel misconfiguration of Gi0/0 Gi0/1
%PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Po1, putting Gi0/0 in err-disable state
Item Command
Global on/off spanning-tree etherchannel guard misconfig (default on)
Is it enabled? show spanning-tree summary shows EtherChannel misconfig guard is enabled
Recover manually Fix the mode mismatch, then shutdown and no shutdown on the port channel
Recover automatically errdisable recovery cause channel-misconfig and errdisable recovery interval <seconds> (default 300)

Do not disable the guard to "fix" the problem. Fix the mode on whichever side is wrong.

Load balancing

EtherChannel does not spread packets round robin. It runs a hash over chosen header fields and maps each result to one member. All frames of one flow follow the same member, which keeps packets in order.

DIST1(config)# port-channel load-balance src-dst-ip
Method Hash input Good for
src-mac Source MAC Many hosts sending to one router (rarely ideal)
dst-mac Destination MAC Few senders, many destinations on the same segment
src-dst-mac Both MACs Layer 2 traffic between many host pairs
src-ip / dst-ip One IP Asymmetric patterns
src-dst-ip Both IPs Most routed traffic; the usual recommendation
src-dst-port and mixed IP and port options L4 ports, sometimes combined with IP Many flows between the same two hosts (platform dependent)

The setting is global on most Catalyst switches and applies to every port channel on the switch. The default depends on platform: Catalyst 9000 uses src-dst-ip, while older access switches and IOSvL2 default to src-mac. Always verify:

DIST1# show etherchannel load-balance
EtherChannel Load-Balancing Configuration:
        src-dst-ip

EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Source XOR Destination MAC address
  IPv4: Source XOR Destination IP address
  IPv6: Source XOR Destination IP address

Some Catalyst platforms offer test etherchannel load-balance interface port-channel 1 ip <src> <dst> to show which member a given flow will use. Availability varies by image.

Why one member is saturated

  • The method is src-mac or dst-mac and almost all traffic goes to or comes from one router MAC, so every frame hashes the same way.
  • A single large flow (backup job, storage replication) cannot be split across members.
  • The number of members is not a power of two. The hash produces a fixed number of buckets (often 8) that are shared among members, so three members get a 3/3/2 split.
  • Each switch hashes its own outbound traffic independently. The two directions of a conversation can use different members, which is normal.

Exam trap

The load-balancing method does not have to match on both ends of the channel. Each switch hashes only the traffic it sends. A question that says "the bundle failed because the two switches use different load-balance methods" describes something that does not happen.

Layer 3 EtherChannel

A routed port channel needs no switchport on the members and on the port channel, and the IP address goes on the port channel only.

interface range GigabitEthernet0/0 - 1
 no switchport
 no ip address
 channel-group 3 mode active
!
interface Port-channel3
 no switchport
 ip address 10.1.2.1 255.255.255.252

The summary shows Po3(RU). A mix of routed and switched members cannot bundle.

Troubleshooting workflow

graph TB
  S["Bundle not working"] --> F{"Flags on members?"}
  F -- "D" --> P["Physical: cable, shutdown,<br/>err-disabled? check misconfig guard"]
  F -- "I" --> N["Negotiation: compare modes<br/>show lacp neighbor / show pagp neighbor"]
  F -- "s" --> C["Consistency: speed, duplex,<br/>VLANs, native, L2 vs L3<br/>read the EC-5 log"]
  F -- "H" --> M["Too many members:<br/>max-bundle, port priority"]
  F -- "P but slow" --> L["Hashing: show etherchannel load-balance"]

Lab: build an LACP bundle, then break it three ways

Topology: DIST1 Gi0/0 and Gi0/1 to DIST2 Gi0/0 and Gi0/1 (IOSvL2). Uses the VLANs from the trunking lab.

graph LR
  D1["DIST1"] -- "Gi0/0 to Gi0/0" --- D2["DIST2"]
  D1 -- "Gi0/1 to Gi0/1" --- D2

Steps

  1. Configure both switches as below and confirm Po1(SU) with both members P.
  2. Change DIST2 to channel-group 1 mode passive on both members. Confirm the bundle stays up (active to passive works).
  3. Change DIST1 to passive too. Wait for the LACP timeout and confirm both sides show I. Restore active on DIST1.
  4. On DIST2 Gi0/1 only, enter switchport trunk native vlan 1. Confirm that Gi0/1 is suspended (s) and read the %EC-5 log. Restore it from the port channel interface.
  5. Remove the channel group from DIST2 (no channel-group 1 on both members) and set DIST1 members to mode on. Watch for misconfiguration guard err-disabling DIST1's members. Restore LACP active on both sides, then bounce Po1 on DIST1.
  6. Run show etherchannel load-balance, change it to src-dst-ip, and check again.

Configuration

interface range GigabitEthernet0/0 - 1
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,99,999
 switchport mode trunk
 switchport nonegotiate
 channel-group 1 mode active
!
port-channel load-balance src-dst-ip

interface range GigabitEthernet0/0 - 1
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,99,999
 switchport mode trunk
 switchport nonegotiate
 channel-group 1 mode active
!
port-channel load-balance src-dst-ip

Expected verification after step 1

DIST1# show etherchannel summary | begin Group
Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP      Gi0/0(P)    Gi0/1(P)

DIST1# show interfaces trunk | include Po1
Po1         on               802.1q         trunking      999
Po1         10,20,99,999
Po1         10,20,99,999
Po1         10,20,99,999

DIST1# show spanning-tree vlan 10 | include Po1
Po1                 Desg FWD 3         128.65   P2p

STP lists only Po1, not the physical members. The cost reflects the combined bandwidth (the exact value depends on the path cost method and the number of members).

Expected after step 3

1      Po1(SD)         LACP      Gi0/0(I)    Gi0/1(I)

Expected after step 4

1      Po1(SU)         LACP      Gi0/0(P)    Gi0/1(s)

Try the same scenario under time pressure in Sim 01, and review diagram E20.

Quick check

SW1 members are desirable, SW2 members are passive. Does a bundle form?

No. SW1 runs PAgP and SW2 runs LACP. Neither protocol hears a partner, so both sides show their ports as stand-alone (I).

Five members are configured with LACP active on both switches, and lacp max-bundle 4 is set on SW1's port channel. What does the summary show?

Four members are bundled (P) and one is hot-standby (H). If a bundled member fails, the standby member joins.

A port channel uses src-mac load balancing and connects an access switch to the distribution router. Most user traffic goes to the router. Which direction is most likely unbalanced?

Traffic from the router toward the access switch hashes on the router's single source MAC, so on the distribution side it all lands on one member. Use src-dst-ip (or dst-mac on that side) to spread it.

References

  • Catalyst 9300 Series Layer 2 Configuration Guide, chapter "Configuring EtherChannels" (search on cisco.com for your release)
  • IEEE 802.1AX, Link Aggregation (formerly 802.3ad)
  • Cisco tech note "Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches" (search on cisco.com)
  • Cisco Live On-Demand Library: search "EtherChannel" and "campus high availability"