Why an EtherChannel Will Not Bundle

When a port refuses to join a channel, IOS has compared it against the other members and found a difference it will not tolerate. The comparison covers operational speed, duplex, switchport mode, VLAN settings, and Layer 2 versus Layer 3 status, plus a compatible negotiation mode on the far end. A rejected port lands in one of two states that look similar and behave very differently: suspended, marked (s), or stand-alone, marked (I). Reading show etherchannel summary alongside the %EC-5 log messages tells you which parameter is at fault, usually by name.

The parameters IOS compares

Aggregation depends on the member ports being interchangeable, because a hash may send any given frame down any of them. Anything that would make one member treat a frame differently from another disqualifies it.

Must be identical across members	Does not need to match
Operational speed	The channel-group number used on the neighboring switch
Duplex setting	Interface description text
Switchport mode (access or trunk)	The load-balancing method chosen on each switch
Allowed VLAN list on a trunk	Interface-level counters, MAC addresses, or port position
Native VLAN on a trunk	Cable length or transceiver part number, provided speed and duplex agree
Access VLAN on access ports
Trunk encapsulation type
Layer 2 or Layer 3 status (switchport or no switchport)
Spanning-tree cost and priority per VLAN

Two entries in the right-hand column cause real confusion. The channel-group number is chosen independently on each switch and is never carried in a negotiation packet, so group 8 on one side and group 12 on the other bundle without complaint. Load balancing is a transmit-side decision made locally, so two switches hashing on different fields still form a healthy channel. Neither is ever the answer to a bundling failure.

Mode compatibility belongs on the must-match list in a different sense: it is a property of the pair, not of the local members. LACP active opposite PAgP desirable cannot aggregate, because the two ends are speaking incompatible protocols. So do two responsive keywords opposite each other. The full matrix appears in EtherChannel modes explained.

Suspended versus stand-alone

(s) means the port is administratively part of the group but has been suspended: its parameters conflict with the group or with its LACP partner, and it is not forwarding. This is the safer failure, because a suspended port carries no traffic and cannot form a loop. Investigate a native VLAN difference, a duplex or speed difference, or a trunk-mode difference between that port and its peers.

(I) means the port is operating stand-alone. It never joined the channel and is forwarding as an ordinary independent link, with spanning tree treating it as a separate path. This is what happens when negotiation simply never completes, for instance when the remote port has no channel-group command at all. The output below shows both a healthy bundle and a member that never joined:

SW1# show etherchannel summary
Group  Port-channel  Protocol    Ports
------+-------------+-----------+-------------------------------------
1      Po1(SU)         LACP      Gi1/0/1(P)   Gi1/0/2(P)   Gi1/0/3(I)

(D) on a member means the interface is down, which is a physical or administrative problem rather than an aggregation problem. (H) is an LACP hot-standby member, which is a normal condition on a group configured with more ports than can forward. (M) against a channel indicates a minimum-links threshold that has not been met. (u) marks a port judged unsuitable for bundling. The channel-level flags are separate: S for a switched channel, R for a routed one, U for in use, and D for down.

The log messages

IOS names the offending parameter and the port it disagrees with, which makes these messages the fastest path to a fix:

%EC-5-CANNOT_BUNDLE2: Gi1/0/4 is not compatible with Gi1/0/3 and will be suspended
 (speed of Gi1/0/4 is 100M, Gi1/0/3 is 1000M)

Everything you need is in the parentheses. The remedy is to make the two ports operationally identical, either by letting both autonegotiate to the same result or by pinning them:

SW1(config)# interface range gigabitethernet1/0/3 - 4
SW1(config-if-range)# speed 1000
SW1(config-if-range)# duplex full

Pin both ends of each member link if you pin at all, because hard-coding one end and leaving the other on autonegotiation produces a duplex mismatch and its counter fingerprint on a link that otherwise looks healthy. Changing the negotiation keyword does nothing here, because the ports were never going to be compatible with each other regardless of protocol. Adding more members does not help either; a suspended port is not a symptom of a group being too small.

The same message family reports other mismatches with the relevant values substituted, for example a trunk-mode difference or a native VLAN difference between two members. %EC-5-CANNOT_BUNDLE1 reports that the channel is down and a port will remain stand-alone. Messages in the %EC-5-L3DONTBNDL family report that a port was suspended because the protocol is not enabled on the remote port, which points at the far switch rather than at the local configuration.

A frequent self-inflicted case involves no log drama at all. An engineer edits the allowed VLAN list on one member of a working trunk channel. That member now disagrees with its peers, gets dropped from the bundle, and the group runs a link short until the lists are reconciled. Applying trunk configuration to the Port-channel interface prevents the whole class of problem.

Troubleshooting sequence

Check the summary output first and note which flag each member carries. Read the log with show logging for %EC-5 entries, since they name the parameter directly. Compare the members with show interfaces <id> switchport and show interfaces <id> status side by side, looking specifically at speed, duplex, mode, native VLAN, and allowed VLANs. Confirm the mode keywords on both switches with show etherchannel summary at each end. Fix the mismatch on the member, not on the channel, then confirm the flag changes to (P).

How the 200-301 exam tests this

• A log message with the answer inside it. A %EC-5-CANNOT_BUNDLE2 line naming a speed or trunk-mode difference is given, and the correct response addresses that exact parameter. Distractors offer mode changes, load-balancing changes, or adding links.
• Flag interpretation. A single summary line with one member marked (s) asks what that means and what to check. Suspended means a parameter conflict, not an administrative shutdown, not a hot-standby port, and not a protocol running alone.
• Which conditions individually break a channel. Multi-select items mix genuine causes (protocol mismatch across the pair, inconsistent duplex among members) with harmless differences such as unequal group numbers, differing descriptions, or differing load-balancing methods.
• The one-member edit. A stem describes trunk settings changed on a single physical port of an in-service channel. The result is that the port leaves the bundle, and the durable fix is to configure the logical interface instead.

Most of these stems hand you the answer inside the log line — timed practice exams teach you to trust it instead of second-guessing toward a distractor.

Quick reference

• Members must agree on speed, duplex, switchport mode, native VLAN, allowed VLANs, access VLAN, and Layer 2 or Layer 3 status.
• Channel-group numbers, interface descriptions, and load-balancing methods do not need to match.
• (s) is suspended, caused by a parameter conflict; (P) is bundled; (I) is stand-alone and still forwarding.
• (D) is down, (H) is LACP hot-standby, (M) is below minimum links, (u) is unsuitable for bundling.
• %EC-5-CANNOT_BUNDLE2 names the mismatched parameter and both ports in parentheses.
• Fix speed and duplex mismatches with matching speed and duplex commands on the member range.
• Configure trunk settings on the Port-channel interface so members cannot drift out of agreement.