EtherChannel questions on the CCNA exam fall into two categories: which mode combinations form a bundle, and what happens when there is a misconfiguration. Both require knowing the negotiation modes for LACP and PAgP precisely.
What EtherChannel Does
EtherChannel bundles multiple physical links between two switches into a single logical link. STP treats the bundle as one link, so none of the member ports get blocked. Traffic is load-balanced across the physical links using a hash of source/destination MAC or IP addresses.
LACP Modes (802.3ad — Open Standard)
| SW1 Mode | SW2 Mode | Bundle Forms? |
|---|---|---|
| Active | Active | Yes |
| Active | Passive | Yes |
| Passive | Active | Yes |
| Passive | Passive | No |
Passive/Passive fails because neither side initiates LACP. At least one side must be Active.
PAgP Modes (Cisco Proprietary)
| SW1 Mode | SW2 Mode | Bundle Forms? |
|---|---|---|
| Desirable | Desirable | Yes |
| Desirable | Auto | Yes |
| Auto | Desirable | Yes |
| Auto | Auto | No |
Auto/Auto fails for the same reason — neither side sends PAgP packets to initiate negotiation.
On (Static) Mode
The on mode forces EtherChannel without any negotiation protocol. If one switch is on, the other must also be on. Mixing on with LACP or PAgP modes prevents the bundle from forming.
| SW1 Mode | SW2 Mode | Bundle Forms? |
|---|---|---|
| On | On | Yes |
| On | Active | No |
| On | Passive | No |
| On | Desirable | No |
| On | Auto | No |
Configuration Example
SW1(config)# interface range GigabitEthernet0/0 - 1
SW1(config-if-range)# channel-group 1 mode active
SW1(config-if-range)# exit
SW1(config)# interface port-channel 1
SW1(config-if)# switchport mode trunk
SW2(config)# interface range GigabitEthernet0/0 - 1
SW2(config-if-range)# channel-group 1 mode passive
Active/Passive is a valid LACP combination and forms a bundle.
Requirements for EtherChannel to Form
Even with compatible modes, the bundle will not form if member ports have inconsistent configurations. All ports in the channel must have:
- Same speed and duplex
- Same VLAN assignment (if access) or identical trunk configuration
- Same native VLAN (if trunk)
- Same allowed VLANs (if trunk)
A common exam scenario: EtherChannel modes are compatible, but one member port is in VLAN 10 and another is in VLAN 20. The channel will not form or will be suspended. Candidates check the modes, see they are compatible, and get confused. The real issue is the mismatched VLAN configuration.
Verification Commands
SW1# show etherchannel summary
Look for:
- P next to a port = in the bundle (correct)
- I next to a port = individually bundled (misconfiguration)
- S flag on the bundle = suspended
SW1# show lacp neighbor
SW1# show pagp neighbor
Common Exam Pattern
"SW1 is configured with channel-group 1 mode auto. SW2 is configured with channel-group 1 mode auto. The EtherChannel does not form. What is the problem?"
Answer: both are PAgP Auto. Neither initiates negotiation. At least one side needs to be Desirable.
Practice CCNA EtherChannel and switching questions until the mode compatibility matrix is automatic.
Why show etherchannel summary Is Your Best Friend
This is the single most useful EtherChannel verification command, and the exam asks you to interpret its output directly. Learn to read every flag.
**` SW1# 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 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: 1 Number of aggregators: 1
Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 1 Po1(SU) LACP Gi0/0(P) Gi0/1(P) **`
Breaking down what matters here:
Po1(SU) — The port-channel interface is Su: Layer2 (S) and in Use. This is the healthy state for a Layer 2 EtherChannel. You want to see SU.
LACP — Confirms which protocol is negotiating the bundle.
Gi0/0(P) Gi0/1(P) — Both member ports are Ported-in (bundled and active). This is what success looks like.
Now here is what you see when something is wrong:
**` Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 1 Po1(SD) LACP Gi0/0(I) Gi0/1(I) **`
Po1(SD) — Suspended and Down. The bundle is not working.
Gi0/0(I) Gi0/1(I) — Both ports are Individual (stand-alone). They are not bundled — they are operating as independent ports, which defeats the entire purpose of EtherChannel.
The I flag is the most important problem flag. It means the port gave up trying to bundle and is now acting like a normal switch port. From STP's perspective, these look like two separate links between the same pair of switches — which means STP will block one of them, exactly the situation EtherChannel is supposed to prevent.
Other important flags to recognise:
- s (lowercase, next to a port): Suspended — the port is part of the bundle definition but not participating. Usually due to a configuration mismatch on that specific port.
- D: The port is down at Layer 1. Check physical connection or interface configuration.
- H: Hot-standby — LACP standby port. Only relevant when you have more links assigned to a group than the maximum bundle size (8 for LACP).
What Happens to Traffic During EtherChannel Formation
EtherChannel does not balance traffic the way you might expect. It does not round-robin packets across physical links. Instead, it uses a hash of specific header fields to determine which physical link carries each flow. The hash ensures that all frames in the same conversation always use the same physical link — which preserves frame ordering within a flow.
The load-balancing method determines what gets hashed. Common options:
**` SW1(config)# port-channel load-balance ? dst-ip Dst IP Addr dst-mac Dst Mac Addr src-dst-ip Src XOR Dst IP Addr src-dst-mac Src XOR Dst MAC Addr src-ip Src IP Addr src-mac Src MAC Addr **`
src-mac: hash based on source MAC address. Good when many different source MAC addresses send through the EtherChannel (e.g., uplink from an access switch with many hosts). Traffic from one MAC always uses the same link.
src-dst-ip: hash based on source XOR destination IP. Best balance for routed traffic because the combination of src+dst creates more unique hash values across flows.
src-mac default problem: if all traffic passes through the EtherChannel from one MAC address (e.g., a router with a single interface), all traffic hashes to the same link. One link carries all traffic, the others carry nothing. This looks like EtherChannel "not working" even though the bundle is fully formed.
Check the current method with:
**` SW1# show etherchannel load-balance EtherChannel Load-Balancing Method: src-dst-ip **`
Change it globally (not per-interface):
**` SW1(config)# port-channel load-balance src-dst-ip **`
Troubleshooting a Suspended Bundle
When the port-channel shows (SD) and member ports show (s) or (I), you have a configuration mismatch. Here is the systematic approach:
Step 1: Check modes on both sides.
**` SW1# show etherchannel 1 summary SW2# show etherchannel 1 summary **`
One side active, one side active: fine. One side passive, one side passive: neither initiates — no bundle. One side on, other side active: incompatible — no bundle.
Step 2: Check member port configuration consistency.
**` SW1# show interfaces Gi0/0 trunk SW1# show interfaces Gi0/1 trunk **`
Every member port must have identical configuration. Common culprits:
- One port is access mode, the other is trunk mode
- Native VLANs do not match between member ports
- Allowed VLAN lists differ between member ports
- One port has a different speed or duplex (autoneg vs hard-coded)
Step 3: Check the port-channel interface configuration vs member ports.
The port-channel interface configuration (trunk mode, native VLAN, allowed VLANs) overrides member port configuration in most cases — but if a member port was manually reconfigured after being added to the group, it can cause a mismatch.
The safe practice: configure the port-channel interface first, then add member ports. The member ports inherit the configuration from the port-channel.
EtherChannel vs Trunking — Which Goes on the Port-Channel Interface
This is a configuration order question that causes real problems. The correct hierarchy:
- Configure the member ports with *channel-group N mode {active|passive|desirable|auto|on}*
- Configure the port-channel interface (the logical Po1 interface) with VLAN, trunking, and other Layer 2 settings
What goes on the port-channel interface:
**` SW1(config)# interface port-channel 1 SW1(config-if)# switchport mode trunk SW1(config-if)# switchport trunk native vlan 99 SW1(config-if)# switchport trunk allowed vlan 10,20,30,99 **`
What should NOT be configured on individual member ports separately:
The trunk mode, native VLAN, and allowed VLANs should be set on the port-channel interface, not on Gi0/0 and Gi0/1 individually. If you configure them on individual ports and they differ between ports, the bundle suspends.
The exam question: "A technician configures native VLAN 10 on Gi0/0 and native VLAN 20 on Gi0/1, both members of port-channel 1. What happens?"
The bundle suspends because member port configurations are inconsistent. The fix is to remove the native VLAN configuration from the member ports and set it on the port-channel interface.
When the Bundle Forms But Traffic Is Unbalanced
The bundle is up, all member ports show P (bundled), but one link carries all the traffic while the others are essentially idle. This is a load-balancing method problem, not a bundle problem.
Verify which link is carrying traffic:
**` SW1# show interfaces port-channel 1 counters **`
Then check individual member ports:
**` SW1# show interfaces Gi0/0 counters SW1# show interfaces Gi0/1 counters **`
If Gi0/0 shows millions of packets and Gi0/1 shows almost nothing, the hash is sending everything down one path.
Common cause 1: src-mac balancing with a single source MAC. Change to src-dst-mac or src-dst-ip.
Common cause 2: Only two links in the bundle. With two links, a two-value XOR hash gives you 0 or 1. If most flows hash to 0, link 0 carries everything. Adding a third link gives you hash values 0, 1, 2 — more even distribution. This is why EtherChannels with more member links tend to distribute more evenly.
Common cause 3: Polarisation in a stacked topology. If SW1 load-balances on src-mac and SW2 also load-balances on src-mac, flows between the same pairs of hosts always use the same path through both bundles. Use src-dst-ip at one end to break the pattern.
The exam tests this at a conceptual level: "An EtherChannel bundle with two links is fully formed but traffic is only passing on one link. What is the most likely cause?" Answer: the load-balancing hash is mapping most flows to a single physical link. Resolution is changing the load-balance method.
Practice Question Sets
The best way to lock in EtherChannel is working through real exam questions with immediate feedback. Pick a session size that fits your schedule: