Troubleshooting EtherChannel

EtherChannel (also called Link Aggregation or port-channel) bundles multiple physical links between two switches into a single logical interface — multiplying bandwidth, providing redundancy, and appearing as one link to Spanning Tree Protocol. When it works, the bundle is invisible to higher-layer protocols. When it breaks, the symptoms are almost always the same: the port-channel interface appears down, individual member ports are suspended, traffic drops to zero, or the bundle forms but with fewer members than expected — silently reducing bandwidth without any obvious error. Unlike a simple interface failure, EtherChannel problems are caused by mismatches between the two sides of the bundle, and the diagnosis requires systematically comparing the configuration on both switches simultaneously.

This lab covers every common EtherChannel failure mode: protocol negotiation mismatches (LACP vs PAgP vs static), speed and duplex inconsistency, VLAN and trunk configuration divergence, port-channel interface parameter conflicts, and Spanning Tree interaction issues. The primary diagnostic tools are show etherchannel summary and show etherchannel detail — learning to read their flag codes and inconsistency reports is the fastest path to resolving any EtherChannel problem.

Before starting this lab, ensure you are comfortable with trunk port configuration at Trunk Port Configuration, VLAN management at VLAN Creation & Management, Spanning Tree at Spanning Tree & Root Bridge Configuration, and EtherChannel fundamentals at EtherChannel LACP Configuration. For VLAN tagging see VLAN Tagging 802.1Q. For related Layer 2 troubleshooting see Troubleshooting Layer 2 VLANs & Trunks.

1. EtherChannel Concepts & Requirements

EtherChannel Protocols

Protocol	Standard	Modes	Negotiation	Notes
LACP	IEEE 802.3ad / 802.1AX (open standard)	`active`, `passive`	At least one side must be `active`. Both `passive` = no bundle	Preferred for multi-vendor environments. Supports up to 16 member ports (8 active + 8 standby). Sends PDUs every 1s (fast) or 30s (slow)
PAgP	Cisco proprietary	`desirable`, `auto`	At least one side must be `desirable`. Both `auto` = no bundle	Cisco-only. Supports up to 8 member ports. Adds PAgP TLVs for learning neighbour device ID and port name
Static (on)	No protocol — forced	`on`	None — both sides must be `on`. Static on one side + LACP/PAgP on other = no bundle (and possible STP loop risk)	No PDU exchange. No negotiation. No standby ports. Use only when protocol negotiation is not available (some third-party switches)

LACP and PAgP Mode Compatibility Matrix

Switch A Mode	Switch B Mode	LACP Result	PAgP Result
`active`	`active`	Bundle forms ✓	N/A (LACP modes)
`active`	`passive`	Bundle forms ✓	N/A
`passive`	`passive`	NO bundle ✗	N/A
`desirable`	`desirable`	N/A	Bundle forms ✓
`desirable`	`auto`	N/A	Bundle forms ✓
`auto`	`auto`	N/A	NO bundle ✗
`on`	`on`	Bundle forms (no PDUs)	Bundle forms (no PDUs)
`on`	`active` or `passive`	NO bundle ✗ (ports err-disabled or suspended)	N/A
`active`	`desirable`	NO bundle ✗ (LACP ≠ PAgP)	NO bundle ✗

Mandatory EtherChannel Parameter Match Requirements

All physical ports assigned to the same EtherChannel bundle — on both switches — must have identical values for every parameter in the following table. A mismatch in any single parameter causes the affected ports to be suspended or prevents the bundle from forming.

Parameter	Must Match Across	Common Mismatch Scenario
Speed	All member ports on both switches	One port auto-negotiated to 100 Mbps while others are 1 Gbps
Duplex	All member ports on both switches	One port at half-duplex due to auto-negotiation failure with older NIC
Switchport mode	All member ports (access vs trunk must be consistent)	One port configured as access, others as trunk
Native VLAN	All trunk member ports	One switch has native VLAN 1, the other has native VLAN 10
Allowed VLAN list	All trunk member ports	One switch allows VLANs 1–100, the other allows VLANs 1–50 — mismatch on ports 3 and 4
Access VLAN	All access member ports	Ports assigned to different access VLANs on the same port-channel
Trunk encapsulation	All trunk member ports	One port using ISL, others using 802.1Q (rare on modern hardware)
STP parameters	Port-channel interface and all member ports	PortFast enabled on member port but not the port-channel — causes STP inconsistency
Port-channel number	All member ports must reference the same port-channel number	Two ports on SW1 in channel-group 1 connecting to ports in channel-group 2 on SW2 — both sides must use any number, but member ports must all agree on their local group number

Important: The port-channel number does not need to match between switches. SW1 can use channel-group 1 and SW2 can use channel-group 5 for the same bundle — the number is locally significant only. What matters is that all member ports on SW1 reference channel-group 1 and all member ports on SW2 reference channel-group 5.

2. Lab Topology & Fault Scenarios

         NetsTuts_SW1                    NetsTuts_SW2
  ┌──────────────────────┐       ┌──────────────────────┐
  │  Gi0/1 ──────────────┼───────┼── Gi0/1              │
  │  Gi0/2 ──────────────┼───────┼── Gi0/2              │
  │  Gi0/3 ──────────────┼───────┼── Gi0/3              │
  │  Gi0/4 ──────────────┼───────┼── Gi0/4              │
  │                      │       │                      │
  │  Po1 (port-channel 1)│       │  Po1 (port-channel 1)│
  └──────────────────────┘       └──────────────────────┘

  Expected bundle: Po1 — 4 × 1 Gbps = 4 Gbps aggregate
  Trunk carrying: VLANs 10, 20, 30, 40, 99 (native)
  LACP: both sides active

  ┌────────────────────────────────────────────────────────────────┐
  │  Fault Scenarios Covered in This Lab                          │
  ├───┬────────────────────────────────────────────────────────────┤
  │ 1 │ LACP passive/passive — bundle never forms                 │
  ├───┼────────────────────────────────────────────────────────────┤
  │ 2 │ Mixed protocol — LACP on SW1, PAgP on SW2                 │
  ├───┼────────────────────────────────────────────────────────────┤
  │ 3 │ Static "on" one side, LACP the other                      │
  ├───┼────────────────────────────────────────────────────────────┤
  │ 4 │ Speed mismatch — one port at 100 Mbps, rest at 1 Gbps     │
  ├───┼────────────────────────────────────────────────────────────┤
  │ 5 │ Native VLAN mismatch across member ports                  │
  ├───┼────────────────────────────────────────────────────────────┤
  │ 6 │ Allowed VLAN list inconsistency between member ports      │
  ├───┼────────────────────────────────────────────────────────────┤
  │ 7 │ Switchport mode mismatch (access vs trunk)                │
  ├───┼────────────────────────────────────────────────────────────┤
  │ 8 │ Port-channel interface parameter inconsistency            │
  └───┴────────────────────────────────────────────────────────────┘

3. Reading the Diagnostic Commands

show etherchannel summary — The Primary Diagnostic Tool

NetsTuts_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      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

        A - formed using Device ID
        g - Grp members with differing port speeds / duplex
        z - Grp members lagging behind in sync / receiving

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

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

A healthy bundle shows: port-channel flag (SU) — S=Layer2, U=in use — and all member ports with flag (P) — bundled and carrying traffic. This output confirms all four ports are active in the bundle. Every other flag combination represents a problem state that must be diagnosed.

EtherChannel Flag Code Reference

Flag	Meaning	Where Seen	Implication
`P`	Bundled in port-channel — actively carrying traffic	Member port	Healthy — port is a full member of the bundle
`D`	Down — physical link is down	Member port or port-channel	Physical layer issue — cable, SFP, or remote port shutdown
`s`	Suspended — port is up physically but excluded from bundle due to mismatch	Member port	Configuration mismatch — compare parameters against other bundle members
`I`	Stand-alone — port is not part of any bundle, operating independently	Member port	Protocol negotiation failed, or the port is waiting for a compatible partner
`w`	Waiting to be aggregated — LACP PDU exchange in progress	Member port	Transient during bundle formation — if persistent, LACP PDUs are not arriving from the remote end
`H`	Hot-standby (LACP only) — more than 8 ports assigned; this port is standby	Member port	Normal when more than 8 ports are in the group — port activates automatically if an active port fails
`U`	In use — port-channel is active and forwarding traffic	Port-channel interface	Healthy port-channel state
`N`	Not in use, no aggregation — no member ports are bundled	Port-channel interface	All member ports are down, suspended, or in stand-alone — the bundle has no active members
`S`	Layer 2 port-channel	Port-channel interface	Switching port-channel (most common for access/distribution layer bundles)
`R`	Layer 3 port-channel	Port-channel interface	Routed port-channel — has an IP address assigned directly
`g`	Group members with differing speed or duplex	Member port	Speed/duplex mismatch within the channel group — the offending port will be suspended
`u`	Unsuitable for bundling	Member port	Port has a parameter that disqualifies it from the bundle — check for SPAN destination, private VLAN, or conflicting port profile

show etherchannel detail — Deep Diagnostic Output

NetsTuts_SW1#show etherchannel 1 detail

Group state = L2
Ports: 4   Maxports = 16
Port-channels: 1 Max Port-channels = 16
Protocol:   LACP
Minimum Links: 0

                Ports in the group:
                -------------------
Port: Gi0/1
------------
Port state    = Up Mstr Assoc In-Bndl
Channel group = 1           Mode = Active       Gcchange = -
Port-channel  = Po1         GC   =   -          Pseudo port-channel = Po1
Port index    = 0           Load = 0x55         Protocol =   LACP

Flags:  S - Device is sending Slow LACPDUs   F - Device is sending fast LACPDUs
        A - Device is in active mode.        P - Device is in passive mode.

Local information:
                            LACP port     Admin     Oper    Port        Port
Port      Flags   State     Priority      Key       Key     Number      State
Gi0/1     SA      bndl      32768         0x1       0x1     0x102       0x3D

Partner's information:

                  LACP port                        Admin  Oper   Port    Port
Port      Flags   Priority  Dev ID          Age    key    Key    Number  State
Gi0/1     FA      32768     aabb.cc00.0200  10s    0x0    0x1    0x102   0x3D

Age of the port in the current state: 0d:02h:15m:33s

show etherchannel [group] detail reveals the LACP negotiation state for each member port — the local flags (SA = Slow/Active) and the partner's flags and device ID. The Oper Key values must match between local and partner ports for the port to join the bundle. A mismatch in Oper Key is a reliable indicator of a parameter inconsistency that LACP has detected. The Partner's information section confirms that LACP PDUs are being received from the remote switch — if this section is absent or shows no partner, LACP PDUs are not arriving.

4. Fault 1 — LACP Passive/Passive: Bundle Never Forms

Symptom

NetsTuts_SW1#show etherchannel summary

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

Port-channel shows (SD) — S=Layer2, D=Down. All member ports show (I) — stand-alone, meaning each port is operating independently and not part of any bundle. This is the classic signature of a negotiation failure where neither side is initiating the LACP conversation.

Diagnose

! ── Check the LACP mode on SW1 ───────────────────────────
NetsTuts_SW1#show etherchannel 1 detail | include Mode
Mode = Passive

! ── Check the LACP mode on SW2 ───────────────────────────
NetsTuts_SW2#show etherchannel 1 detail | include Mode
Mode = Passive

! ── Neither side is sending LACP PDUs — no partner info ──
NetsTuts_SW1#show lacp 1 neighbor
No lacp info for port channel 1

Both switches are in passive mode. LACP passive means "respond to LACP PDUs but do not initiate them." With both sides waiting for the other to start, no LACP PDUs are ever sent and the bundle cannot form. show lacp [group] neighbor confirms this — no partner information is present because no LACP PDUs have been exchanged.

Fix

! ── Change at least one side to LACP active ──────────────
NetsTuts_SW1(config)#interface range gi0/1 - 4
NetsTuts_SW1(config-if-range)# channel-group 1 mode active
NetsTuts_SW1(config-if-range)#exit

! ── Verify the bundle forms immediately ──────────────────
NetsTuts_SW1#show etherchannel summary

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

! ── Confirm LACP neighbor information is now populated ───
NetsTuts_SW1#show lacp 1 neighbor

Flags:  S - Device is sending Slow LACPDUs   F - Device is sending 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/1     SP      32768     aabb.cc00.0200  4s     0x0    0x1    0x102   0x3D
Gi0/2     SP      32768     aabb.cc00.0200  4s     0x0    0x1    0x103   0x3D
Gi0/3     SP      32768     aabb.cc00.0200  4s     0x0    0x1    0x104   0x3D
Gi0/4     SP      32768     aabb.cc00.0200  4s     0x0    0x1    0x105   0x3D

After changing SW1 to active mode, SW1 begins sending LACP PDUs. SW2 (still in passive) responds, the negotiation completes, and all four ports bundle immediately. The partner flags now show SP — Slow PDUs, Passive mode — confirming SW2 is responding but not initiating. This is a valid and fully operational configuration: one active, one passive. For interface configuration fundamentals, see Basic Interface Configuration.

5. Fault 2 — Mixed Protocol: LACP on SW1, PAgP on SW2

Symptom

NetsTuts_SW1#show etherchannel summary

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

Diagnose

! ── Check protocol on SW1 ────────────────────────────────
NetsTuts_SW1#show etherchannel 1 summary | include Protocol
Protocol:   LACP

! ── Check protocol on SW2 ────────────────────────────────
NetsTuts_SW2#show etherchannel 1 summary | include Protocol
Protocol:   PAgP

! ── Confirm with running-config on both switches ─────────
NetsTuts_SW1#show run | include channel-group
 channel-group 1 mode active        ← LACP active

NetsTuts_SW2#show run | include channel-group
 channel-group 1 mode desirable     ← PAgP desirable

LACP and PAgP PDUs are completely incompatible — each protocol uses a different EtherType and message format. A switch running LACP on a port simply ignores PAgP PDUs (and vice versa), so neither side sees a valid protocol response and the bundle does not form. The ports remain in stand-alone mode, each operating as an independent link. This mismatch is particularly common when replacing a Cisco switch with another vendor's switch (which may default to LACP) while the existing switch is running PAgP.

Fix

! ── Option A: Change SW2 to LACP (recommended) ──────────
NetsTuts_SW2(config)#interface range gi0/1 - 4
NetsTuts_SW2(config-if-range)# channel-group 1 mode active
NetsTuts_SW2(config-if-range)#exit

! ── Option B: Change SW1 to PAgP ─────────────────────────
! ── (use only if SW2 is Cisco and PAgP is preferred) ─────
NetsTuts_SW1(config)#interface range gi0/1 - 4
NetsTuts_SW1(config-if-range)# channel-group 1 mode desirable
NetsTuts_SW1(config-if-range)#exit

! ── Option C: Change both to static "on" ─────────────────
! ── (use only when protocol negotiation is unavailable) ──
NetsTuts_SW1(config)#interface range gi0/1 - 4
NetsTuts_SW1(config-if-range)# channel-group 1 mode on
NetsTuts_SW1(config-if-range)#exit
NetsTuts_SW2(config)#interface range gi0/1 - 4
NetsTuts_SW2(config-if-range)# channel-group 1 mode on
NetsTuts_SW2(config-if-range)#exit

! ── Verify after fix (Option A shown) ────────────────────
NetsTuts_SW1#show etherchannel summary

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

6. Fault 3 — Static "On" vs LACP: Ports Suspended or Err-Disabled

Symptom

NetsTuts_SW1#show etherchannel summary

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

NetsTuts_SW2#show etherchannel summary

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

SW1 shows Protocol: - (static, mode on) with all ports bundled. SW2 shows Protocol: LACP with all ports (s) — suspended. SW1 forwards traffic because static mode does not require acknowledgement. SW2's LACP ports are suspended because they receive no LACP PDU responses from SW1 (which is not running LACP). This is the most dangerous EtherChannel misconfiguration: SW1 is forwarding traffic on what it believes is a bundle, while SW2 has suspended all member ports — causing a one-way traffic black hole that is extremely difficult to detect without examining both sides.

Diagnose

! ── Check running-config on both switches ────────────────
NetsTuts_SW1#show run | include channel-group
 channel-group 1 mode on            ← static

NetsTuts_SW2#show run | include channel-group
 channel-group 1 mode active        ← LACP

! ── Check for err-disabled ports ─────────────────────────
NetsTuts_SW2#show interfaces status | include err
Gi0/1        connected    err-disabled   full    1G      10/100/1000BaseTX

Fix

! ── Align both sides to LACP ─────────────────────────────
NetsTuts_SW1(config)#interface range gi0/1 - 4
NetsTuts_SW1(config-if-range)# channel-group 1 mode active
NetsTuts_SW1(config-if-range)#exit

! ── If any ports became err-disabled, clear them ─────────
NetsTuts_SW2(config)#interface range gi0/1 - 4
NetsTuts_SW2(config-if-range)# shutdown
NetsTuts_SW2(config-if-range)# no shutdown
NetsTuts_SW2(config-if-range)#exit

! ── Verify ───────────────────────────────────────────────
NetsTuts_SW1#show etherchannel summary
Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP      Gi0/1(P)    Gi0/2(P)    Gi0/3(P)    Gi0/4(P)

Warning: The static on mode is the only EtherChannel mode that can create a unidirectional forwarding condition where one switch is sending traffic into a bundle that the other side has suspended. This can create MAC table instability and STP anomalies. Always use LACP or PAgP in production to ensure both sides agree on bundle membership before forwarding traffic.

7. Fault 4 — Speed or Duplex Mismatch: One Port Suspended

Symptom

NetsTuts_SW1#show etherchannel summary

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

The bundle is up and three ports are active, but Gi0/3 shows (s) — suspended. The bundle is operating at 3 Gbps instead of 4 Gbps, silently reducing bandwidth. Without monitoring, this degradation may go unnoticed for weeks.

Diagnose

! ── Check speed and duplex on all member ports ───────────
NetsTuts_SW1#show interfaces gi0/1 | include duplex|speed|BW
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
  Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX

NetsTuts_SW1#show interfaces gi0/3 | include duplex|speed|BW
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 1000 usec,
  Half-duplex, 100Mb/s, media type is 10/100/1000BaseTX

! ── Look for the 'g' flag in show etherchannel detail ─────
NetsTuts_SW1#show etherchannel 1 detail | include Gi0/3
Port: Gi0/3  (g) speed/duplex mismatch with other member ports

! ── Alternatively — show interfaces status ───────────────
NetsTuts_SW1#show interfaces status

Port      Name               Status       Vlan       Duplex  Speed  Type
Gi0/1                        connected    trunk      full    1000   10/100/1000BaseTX
Gi0/2                        connected    trunk      full    1000   10/100/1000BaseTX
Gi0/3                        connected    trunk      half    100    10/100/1000BaseTX
Gi0/4                        connected    trunk      full    1000   10/100/1000BaseTX

Gi0/3 has auto-negotiated to 100 Mbps half-duplex — typically caused by a faulty cable (damaged pairs causing negotiation failure), a bad SFP, or a forced speed setting on the remote port that is incompatible with auto-negotiation. The g flag in show etherchannel detail explicitly identifies the speed/duplex mismatch. For interface diagnostics, see show interfaces.

Fix

! ── Option A: Force speed and duplex (if hardware supports it)
NetsTuts_SW1(config)#interface gi0/3
NetsTuts_SW1(config-if)# speed 1000
NetsTuts_SW1(config-if)# duplex full
NetsTuts_SW1(config-if)#exit

! ── Option B: Re-enable auto-negotiation and reseat cable ─
NetsTuts_SW1(config)#interface gi0/3
NetsTuts_SW1(config-if)# no speed
NetsTuts_SW1(config-if)# no duplex
NetsTuts_SW1(config-if)# shutdown
NetsTuts_SW1(config-if)# no shutdown
NetsTuts_SW1(config-if)#exit

! ── Verify Gi0/3 re-joins the bundle ─────────────────────
NetsTuts_SW1#show etherchannel summary

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

! ── Confirm speed and duplex are now consistent ──────────
NetsTuts_SW1#show interfaces gi0/3 | include duplex|speed
  Full-duplex, 1000Mb/s

8. Fault 5 — Native VLAN Mismatch: STP Errors and Traffic Loss

Symptom

NetsTuts_SW1#show etherchannel summary

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

! ── STP topology change messages in syslog ───────────────
%SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent
peer vlan id 99 on GigabitEthernet0/3 VLAN10.

%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered
on GigabitEthernet0/3 (10), with NetsTuts_SW2 GigabitEthernet0/3 (99).

Two member ports are suspended. The CDP-4-NATIVE_VLAN_MISMATCH syslog message is the definitive indicator: CDP has detected that the remote port's native VLAN differs from the local port's native VLAN. The STP PVID (Port VLAN ID) error confirms STP BPDUs are arriving tagged with a VLAN that the local port does not expect as the native VLAN. For syslog message analysis, see show logging.

Diagnose

! ── Check native VLAN on all member ports on SW1 ─────────
NetsTuts_SW1#show interfaces trunk

Port        Mode             Encapsulation  Status        Native vlan
Gi0/1       on               802.1q         trunking      99
Gi0/2       on               802.1q         trunking      99
Gi0/3       on               802.1q         trunking      10   ← mismatch
Gi0/4       on               802.1q         trunking      10   ← mismatch

! ── Check native VLAN on SW2 ─────────────────────────────
NetsTuts_SW2#show interfaces trunk

Port        Mode             Encapsulation  Status        Native vlan
Gi0/1       on               802.1q         trunking      99
Gi0/2       on               802.1q         trunking      99
Gi0/3       on               802.1q         trunking      99
Gi0/4       on               802.1q         trunking      99

! ── Check the port-channel interface native VLAN ─────────
NetsTuts_SW1#show interfaces po1 trunk
Port        Mode             Encapsulation  Status        Native vlan
Po1         on               802.1q         trunking      99

Gi0/3 and Gi0/4 on SW1 have native VLAN 10, while all other ports (on both switches) have native VLAN 99. The EtherChannel consistency checker compares each new member port against the existing bundle configuration — when it finds a native VLAN mismatch, it suspends the inconsistent port rather than allowing it to join and corrupt the bundle. For trunk configuration details, see Trunk Port Configuration.

Fix

! ── Align native VLAN on the mismatched ports ────────────
NetsTuts_SW1(config)#interface range gi0/3 - 4
NetsTuts_SW1(config-if-range)# switchport trunk native vlan 99
NetsTuts_SW1(config-if-range)#exit

! ── Verify all ports now have matching native VLAN ───────
NetsTuts_SW1#show interfaces trunk

Port        Mode             Encapsulation  Status        Native vlan
Gi0/1       on               802.1q         trunking      99
Gi0/2       on               802.1q         trunking      99
Gi0/3       on               802.1q         trunking      99
Gi0/4       on               802.1q         trunking      99

! ── Verify ports re-join the bundle ──────────────────────
NetsTuts_SW1#show etherchannel summary

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

9. Fault 6 — Allowed VLAN List Inconsistency

Symptom

! ── Bundle appears healthy — all ports show (P) ──────────
NetsTuts_SW1#show etherchannel summary

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

! ── But VLAN 30 and 40 traffic is intermittent ───────────
! ── No connectivity issues on VLANs 10 and 20 ────────────

This fault is more subtle than the previous ones — the bundle appears fully healthy in show etherchannel summary. All four ports show (P). Yet users on VLANs 30 and 40 experience intermittent connectivity. The issue is an allowed VLAN list inconsistency between member ports — some ports are not carrying certain VLANs, causing traffic hashing to send frames to ports that will drop them.

Diagnose

! ── Check allowed VLANs on each member port individually ─
NetsTuts_SW1#show interfaces trunk

Port        Mode    Encap  Status    Native vlan
Gi0/1       on      802.1q trunking  99
Gi0/2       on      802.1q trunking  99
Gi0/3       on      802.1q trunking  99
Gi0/4       on      802.1q trunking  99

Port        Vlans allowed on trunk
Gi0/1       10,20,30,40,99
Gi0/2       10,20,30,40,99
Gi0/3       10,20          ← missing VLANs 30, 40, 99
Gi0/4       10,20          ← missing VLANs 30, 40, 99

Port        Vlans allowed and active in management domain
Gi0/1       10,20,30,40,99
Gi0/2       10,20,30,40,99
Gi0/3       10,20
Gi0/4       10,20

! ── Check what the port-channel interface allows ─────────
NetsTuts_SW1#show interfaces po1 trunk
Port        Vlans allowed on trunk
Po1         10,20,30,40,99

Gi0/3 and Gi0/4 only allow VLANs 10 and 20, while the port-channel interface and the other two member ports allow VLANs 10, 20, 30, 40, and 99. EtherChannel hashes traffic across member ports based on source/destination MAC or IP. When a VLAN 30 frame hashes to Gi0/3 or Gi0/4, it is dropped because those ports do not allow VLAN 30. Frames hashing to Gi0/1 or Gi0/2 pass normally — producing the observed intermittent behaviour. For VLAN configuration, see Assigning VLANs to Switch Ports, VLAN Tagging 802.1Q, and show vlan.

Fix

! ── Align the allowed VLAN list on all member ports ──────
NetsTuts_SW1(config)#interface range gi0/3 - 4
NetsTuts_SW1(config-if-range)# switchport trunk allowed vlan 10,20,30,40,99
NetsTuts_SW1(config-if-range)#exit

! ── Verify all member ports now show the same VLAN list ──
NetsTuts_SW1#show interfaces trunk

Port        Vlans allowed on trunk
Gi0/1       10,20,30,40,99
Gi0/2       10,20,30,40,99
Gi0/3       10,20,30,40,99
Gi0/4       10,20,30,40,99

10. Fault 7 — Switchport Mode Mismatch: Access vs Trunk

Symptom

NetsTuts_SW1#show etherchannel summary

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

Diagnose

! ── Check switchport mode on all member ports ────────────
NetsTuts_SW1#show interfaces gi0/1 switchport | include Mode
Administrative Mode: trunk
Operational Mode: trunk

NetsTuts_SW1#show interfaces gi0/3 switchport | include Mode
Administrative Mode: static access
Operational Mode: static access

! ── Quick view of all ports ───────────────────────────────
NetsTuts_SW1#show interfaces status

Port      Status       Vlan       Duplex  Speed  Type
Gi0/1     connected    trunk      full    1000   10/100/1000BaseTX
Gi0/2     connected    trunk      full    1000   10/100/1000BaseTX
Gi0/3     connected    10         full    1000   10/100/1000BaseTX
Gi0/4     connected    20         full    1000   10/100/1000BaseTX

Gi0/3 is an access port on VLAN 10 and Gi0/4 is an access port on VLAN 20 — both should be trunk ports like Gi0/1 and Gi0/2. IOS suspended them because their switchport mode does not match the rest of the bundle. This mismatch can occur when someone adds new ports to an existing port-channel without fully configuring them, or when a port profile template was applied incorrectly.

Fix

! ── Convert access ports to trunk ────────────────────────
NetsTuts_SW1(config)#interface range gi0/3 - 4
NetsTuts_SW1(config-if-range)# switchport mode trunk
NetsTuts_SW1(config-if-range)# switchport trunk native vlan 99
NetsTuts_SW1(config-if-range)# switchport trunk allowed vlan 10,20,30,40,99
NetsTuts_SW1(config-if-range)#exit

! ── Verify trunk and bundle status ───────────────────────
NetsTuts_SW1#show interfaces trunk

Port        Mode    Encap   Status    Native vlan
Gi0/1       on      802.1q  trunking  99
Gi0/2       on      802.1q  trunking  99
Gi0/3       on      802.1q  trunking  99
Gi0/4       on      802.1q  trunking  99

NetsTuts_SW1#show etherchannel summary

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

11. Fault 8 — Port-Channel Interface Parameter Inconsistency

Symptom

! ── Bundle shows (SU) but traffic is being dropped ───────
NetsTuts_SW1#show etherchannel summary

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

! ── STP errors in syslog ─────────────────────────────────
%SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent
peer vlan id 99 on Port-channel1 VLAN10.

Diagnose

! ── Compare port-channel interface config vs member ports ─
NetsTuts_SW1#show interfaces po1 trunk
Port        Mode    Encap   Status    Native vlan
Po1         on      802.1q  trunking  10          ← Po1 native VLAN is 10

NetsTuts_SW1#show interfaces gi0/1 trunk
Port        Mode    Encap   Status    Native vlan
Gi0/1       on      802.1q  trunking  99          ← member port native VLAN is 99

! ── The port-channel interface itself has a different native VLAN
! ── than all its member physical ports ───────────────────

! ── Check running-config for the port-channel interface ──
NetsTuts_SW1#show run interface po1
Building configuration...

interface Port-channel1
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 10
 switchport trunk allowed vlan 10,20,30,40,99
 switchport mode trunk

The Port-channel1 logical interface has native VLAN 10 configured directly on it, while all physical member ports have native VLAN 99. In IOS, the port-channel interface configuration takes precedence and is propagated down to the member ports — but if the port-channel interface was manually configured differently, it creates an inconsistency that generates STP errors. Always configure trunk parameters on the port-channel interface, not on individual member ports — the member ports inherit the configuration from the port-channel. If both are configured, the port-channel interface value governs.

Fix

! ── Correct the native VLAN on the port-channel interface ─
NetsTuts_SW1(config)#interface po1
NetsTuts_SW1(config-if)# switchport trunk native vlan 99
NetsTuts_SW1(config-if)# switchport trunk allowed vlan 10,20,30,40,99
NetsTuts_SW1(config-if)#exit

! ── Remove conflicting config from member ports ───────────
NetsTuts_SW1(config)#interface range gi0/1 - 4
NetsTuts_SW1(config-if-range)# no switchport trunk native vlan
NetsTuts_SW1(config-if-range)# no switchport trunk allowed vlan
NetsTuts_SW1(config-if-range)#exit

! ── Verify port-channel and member ports are consistent ──
NetsTuts_SW1#show interfaces po1 trunk
Port        Mode    Encap   Status    Native vlan
Po1         on      802.1q  trunking  99

NetsTuts_SW1#show interfaces trunk

Port        Mode    Encap   Status    Native vlan
Gi0/1       on      802.1q  trunking  99
Gi0/2       on      802.1q  trunking  99
Gi0/3       on      802.1q  trunking  99
Gi0/4       on      802.1q  trunking  99
Po1         on      802.1q  trunking  99

Best Practice: Always configure all trunk parameters (native VLAN, allowed VLANs, encapsulation) on the interface Port-channel[N] logical interface — never directly on individual member ports. This ensures consistent configuration and avoids the inconsistency shown in this fault scenario. When adding a new physical port to an existing bundle, the port inherits the port-channel interface configuration automatically.

12. Complete EtherChannel Troubleshooting Workflow

Step-by-Step Diagnostic Checklist

! ══════════════════════════════════════════════════════════
! STEP 1: Identify the bundle state
! ══════════════════════════════════════════════════════════
NetsTuts_SW1#show etherchannel summary
! ── Look for: port-channel flag (SU vs SD vs SN)
! ── Look for: member port flags — P (good), s/I/D (problem)
! ── Note which ports are affected and which are healthy

! ══════════════════════════════════════════════════════════
! STEP 2: Check the protocol and mode
! ══════════════════════════════════════════════════════════
NetsTuts_SW1#show etherchannel 1 summary | include Protocol
NetsTuts_SW2#show etherchannel 1 summary | include Protocol
! ── Confirm same protocol on both sides
! ── Confirm compatible modes (active+passive, desirable+auto)

! ══════════════════════════════════════════════════════════
! STEP 3: Check for LACP/PAgP neighbour information
! ══════════════════════════════════════════════════════════
NetsTuts_SW1#show lacp 1 neighbor
! ── Partner info present = PDUs being received
! ── No partner info = PDUs not arriving (cable, mode, protocol mismatch)

! ══════════════════════════════════════════════════════════
! STEP 4: Check speed and duplex on all member ports
! ══════════════════════════════════════════════════════════
NetsTuts_SW1#show interfaces status
! ── All member ports must show same speed and duplex
! ── Any port at different speed/duplex → check cable, SFP, autoneg

! ══════════════════════════════════════════════════════════
! STEP 5: Check switchport mode on all member ports
! ══════════════════════════════════════════════════════════
NetsTuts_SW1#show interfaces trunk
! ── All members should appear in trunk list
! ── Any member showing as access port → switchport mode mismatch

! ══════════════════════════════════════════════════════════
! STEP 6: Check native VLAN consistency
! ══════════════════════════════════════════════════════════
NetsTuts_SW1#show interfaces trunk
! ── Native vlan column: must be identical on all member ports
! ── AND on the port-channel interface itself
! ── AND match the remote switch's member ports

! ══════════════════════════════════════════════════════════
! STEP 7: Check allowed VLAN list consistency
! ══════════════════════════════════════════════════════════
NetsTuts_SW1#show interfaces trunk
! ── "Vlans allowed on trunk" must be identical on all members
! ── Mismatch causes intermittent drops for the excluded VLANs

! ══════════════════════════════════════════════════════════
! STEP 8: Check port-channel interface vs member port config
! ══════════════════════════════════════════════════════════
NetsTuts_SW1#show run interface po1
NetsTuts_SW1#show run interface gi0/1
! ── Port-channel interface config should be the authoritative source
! ── Remove conflicting config from member ports

! ══════════════════════════════════════════════════════════
! STEP 9: Check CDP for native VLAN mismatch alerts
! ══════════════════════════════════════════════════════════
NetsTuts_SW1#show cdp neighbors gi0/1 detail | include VLAN
! ── CDP reports native VLAN on both sides — compare them

! ══════════════════════════════════════════════════════════
! STEP 10: Check syslog for EtherChannel and STP error messages
! ══════════════════════════════════════════════════════════
NetsTuts_SW1#show logging | include ETHCNL\|SPANTREE\|CDP\|LINK
! ── ETHCNL messages: IOS reports specific EtherChannel inconsistencies
! ── SPANTREE PVID errors: native VLAN mismatch
! ── CDP NATIVE_VLAN_MISMATCH: native VLAN confirmed wrong

EtherChannel Diagnostic Command Summary

Command	What It Shows	Key Things to Check
`show etherchannel summary`	All port-channels: protocol, member ports, and flag codes for each	Port-channel flag (SU=healthy, SD/SN=problem). Member flags: P=bundled, s=suspended, I=standalone, D=down
`show etherchannel [N] detail`	Per-port LACP/PAgP negotiation state, Oper Key, partner device ID and port number	Partner info present (PDUs being received). Oper Key matches between local and partner. `(g)` flag = speed/duplex mismatch
`show lacp [N] neighbor`	LACP partner information: device ID, port priority, Oper Key, port state flags	If empty: LACP PDUs not arriving from remote (cable, mode mismatch, wrong protocol). Partner flags: A=active, P=passive, F=fast, S=slow
`show pagp [N] neighbor`	PAgP partner information: device ID, group capability, port flags	Same purpose as show lacp neighbor but for PAgP bundles. Empty output = PAgP PDUs not arriving
`show interfaces status`	Speed, duplex, and VLAN assignment for all ports in compact form	All member ports must show same speed and duplex. Access ports in a trunk bundle show VLAN number instead of "trunk"
`show interfaces trunk`	Trunk status, native VLAN, and allowed VLAN list for all trunking interfaces including port-channel and members	Native VLAN must match on all members and the port-channel. Allowed VLAN list must be identical on all member ports
`show interfaces [intf] switchport`	Detailed switchport configuration: administrative mode, operational mode, access VLAN, native VLAN, voice VLAN	Administrative Mode must be consistent across all bundle members (all trunk or all access)
`show run interface po[N]`	Running configuration of the port-channel logical interface	Compare against member port configs — port-channel interface config is authoritative
`show cdp neighbors [intf] detail`	CDP neighbour information including native VLAN on both sides	Native VLAN field: if different from local native VLAN, a mismatch exists. Quick cross-check without accessing remote switch
`show logging \| include ETHCNL`	IOS-generated EtherChannel consistency check error messages	IOS reports the specific inconsistent parameter and which port triggered the check — the fastest path to identifying the exact mismatch type

13. EtherChannel Troubleshooting — Quick Reference

Problem	Flags / Symptom	Root Cause	Fix
Bundle never forms — all ports stand-alone	Port-channel `(SD)`, all members `(I)`, no LACP/PAgP neighbour info	Both sides passive (LACP) or both sides auto (PAgP) — neither side initiating PDUs	Change at least one side to `active` (LACP) or `desirable` (PAgP)
Bundle never forms — different protocols	Port-channel `(SD)`, all members `(I)` — but modes appear compatible	LACP on one switch, PAgP on the other — PDUs ignored because they use different EtherTypes	Align both sides to same protocol — LACP preferred (open standard)
SW1 bundle up, SW2 all ports suspended	SW1: Po1 `(SU)`, members `(P)`. SW2: Po1 `(SD)`, members `(s)`	SW1 on static `on`, SW2 on LACP — static mode does not respond to LACP PDUs; SW2 suspends ports waiting for LACP response that never comes	Align both to LACP or both to static `on` — never mix static with a negotiation protocol
One port suspended in otherwise healthy bundle	Three ports `(P)`, one port `(s)` with `(g)` flag	Speed or duplex mismatch on the suspended port — auto-negotiated to lower speed due to cable fault or forced speed on remote port	Inspect cable on the suspect port, force speed/duplex to match, or re-seat SFP. Shut/no shut the port after fix
Two ports suspended, STP PVID errors in log	Two ports `(s)`, `%SPANTREE-2-RECV_PVID_ERR` and `%CDP-4-NATIVE_VLAN_MISMATCH` in syslog	Native VLAN on suspended ports differs from the rest of the bundle	Set native VLAN consistently with `switchport trunk native vlan [N]` on all member ports and the port-channel interface
Bundle healthy but intermittent drops for specific VLANs	All ports `(P)`, but VLANs 30/40 traffic is intermittent — VLANs 10/20 work fine	Allowed VLAN list inconsistency — some member ports do not allow the affected VLANs. Traffic hashing sends some frames to ports that drop those VLANs	Align `switchport trunk allowed vlan` on all member ports to match the port-channel interface allowed VLAN list
Mixed access/trunk ports in bundle	Some ports `(P)`, others `(s)` — suspended ports show as access ports in `show interfaces status`	Switchport mode mismatch — trunk ports and access ports cannot coexist in the same EtherChannel bundle	Set all member ports to the same switchport mode (`switchport mode trunk` for inter-switch links)
STP errors despite healthy bundle	All ports `(P)` but `%SPANTREE-2-RECV_PVID_ERR` continues	Port-channel logical interface has different native VLAN than member physical ports — IOS is forwarding traffic according to the port-channel config while receiving BPDUs from the remote switch tagged for the member port VLAN	Configure all trunk parameters on `interface Port-channel[N]` only. Remove conflicting config from member ports with `no switchport trunk native vlan`

Key Points & Exam Tips

show etherchannel summary is the mandatory first diagnostic command for any EtherChannel problem. The flag codes tell you exactly what state each port and port-channel is in: P=bundled (healthy), s=suspended (config mismatch), I=stand-alone (negotiation failed), D=down (physical layer), U=in use (healthy port-channel).
LACP requires at least one side to be active — two passive sides produce no bundle. PAgP requires at least one side to be desirable — two auto sides produce no bundle. Static on requires both sides to be on — mixing static with LACP or PAgP causes port suspension or err-disable.
LACP and PAgP are incompatible protocols — they use different EtherTypes and cannot negotiate with each other. A switch running LACP ignores PAgP PDUs entirely and vice versa. When replacing equipment, always confirm the protocol in use.
The static on mode is the only mode that can create a one-way forwarding black hole: SW1 in on mode forwards traffic because it expects no acknowledgement, while SW2 in LACP mode suspends its ports because it receives no LACP PDU responses. Traffic is black-holed in one direction with no clear error indication on SW1. Always use LACP in production.
All member ports in an EtherChannel must have identical speed, duplex, switchport mode, native VLAN, and allowed VLAN list. A mismatch in any parameter causes the affected port to be suspended (s flag). The g flag specifically identifies a speed/duplex inconsistency within the group.
Configure trunk parameters (native VLAN, allowed VLANs) on the port-channel logical interface, not on individual member ports. The port-channel interface is the authoritative configuration source — member ports inherit from it. Conflicting config on both the port-channel and member ports causes the STP PVID errors seen in Fault 8.
The port-channel number does not need to match between switches — it is locally significant. SW1 can use channel-group 1 and SW2 can use channel-group 3 for the same physical bundle. What matters is that all member ports on each switch reference the same local group number.
CDP is a free diagnostic tool for EtherChannel native VLAN mismatches. show cdp neighbors [intf] detail reports the native VLAN on both sides of a link without requiring access to the remote switch — look for the %CDP-4-NATIVE_VLAN_MISMATCH syslog message as an early indicator. For syslog analysis see show logging.
Intermittent connectivity for specific VLANs with all ports showing (P) is the signature of an allowed VLAN list mismatch — some member ports are not carrying the affected VLANs. Because EtherChannel hashing distributes traffic across all member ports, frames for the excluded VLANs are dropped only when they hash to the misconfigured ports, producing exactly the intermittent behaviour observed.
On the exam: know the flag codes in show etherchannel summary, the protocol mode compatibility matrix (active+passive forms, passive+passive does not), what suspended (s) vs stand-alone (I) means, the mandatory match requirements (speed/duplex/mode/native VLAN/allowed VLANs), and the danger of mixing static on with LACP/PAgP.

Next Steps: For EtherChannel initial configuration and load balancing methods, see EtherChannel LACP Configuration. For Spanning Tree interaction with EtherChannel bundles and PortFast/BPDU Guard on port-channel interfaces, see Spanning Tree & Root Bridge Configuration, PortFast & BPDU Guard, and RSTP / Rapid Spanning Tree. For trunk configuration on the port-channel interface, see Trunk Port Configuration and VLAN Tagging 802.1Q. For Layer 3 port-channel configuration used in distribution and core layer designs, see Inter-VLAN Routing — Layer 3 Switch. For diagnosing storm control and traffic shaping on bundled interfaces, see Storm Control & Traffic Shaping. For related Layer 2 troubleshooting, see Troubleshooting Layer 2 VLANs & Trunks. Save the final configuration with write memory.

TEST WHAT YOU LEARNED

1. `show etherchannel summary` shows Po1(SD) with all four member ports showing (I). What does this output tell you, and what are the two most likely causes?

A. (SD) means the port-channel is a Layer 3 routed interface that is administratively shut down. The (I) flag means the member ports are individually in use as routed ports. This is normal for a Layer 3 EtherChannel that has not yet been assigned an IP address B. (SD) means the port-channel is a Layer 2 interface that is Down — no member ports are bundled and the logical interface has no active members. The (I) flag means all member ports are operating in stand-alone mode, each forwarding independently without being part of any bundle. The two most likely causes are: (1) a protocol negotiation failure where both sides are in passive/passive (LACP) or auto/auto (PAgP) — neither side initiating PDUs; or (2) a mixed-protocol mismatch where one switch is running LACP and the other is running PAgP — the PDUs from each side are ignored by the other C. (SD) means the port-channel is suspended due to a Spanning Tree topology change. The (I) flag means the ports are isolated by STP port state — they are in Listening or Learning state and will transition to Forwarding once the STP timer expires D. (SD) means the port-channel has a speed/duplex inconsistency detected across its members — the D flag indicates the bundle is degraded but partially operational. The (I) flag means the ports are individually forwarding in the interim while the inconsistency is resolved

Correct answer is B. Reading show etherchannel summary flag codes precisely is the most important skill for EtherChannel troubleshooting. The port-channel flag format is two characters: the first indicates the layer (S=Layer2, R=Layer3) and the second indicates the operational state (U=in use/up, D=down, N=not in use). So SD = Layer2, Down — the bundle has no active members and the port-channel interface is operationally down. The (I) member port flag means stand-alone — the port is physically up and passing traffic independently as a regular switchport, but is not participating in any EtherChannel bundle. This is different from (s) suspended, where the port is excluded from the bundle due to a parameter mismatch. Stand-alone typically means the negotiation protocol never found a compatible partner — either both sides are in a non-initiating mode (passive+passive, auto+auto) or the PDUs being sent are from a different protocol than what the remote side expects. The diagnostic next step is to check both switches' protocol and mode with show etherchannel [N] detail | include Mode and show lacp [N] neighbor.

2. An EtherChannel bundle has three ports showing (P) and one port showing (s) with the (g) flag. The physical cable on the suspect port was recently replaced. What is the most likely cause of the suspension, and what is the correct diagnostic sequence?

A. The (s) flag with (g) indicates a VLAN configuration mismatch — the recently replaced cable was in a different patch panel position connecting to a different switch port that has a different VLAN assignment. Check show interfaces trunk to compare native VLANs B. The (g) flag indicates the port is in an LACP hot-standby state waiting to become active — it is not a fault condition. This happens when more than 8 ports are in the group and this port has the lowest LACP port priority C. The (g) flag indicates a PAgP group capability mismatch — the replaced cable is connecting to a port on the remote switch that has a different PAgP group name configured. Check show pagp [N] neighbor for the group name field D. The (g) flag explicitly means "group members with differing port speeds or duplex" — the recently replaced cable likely has a wiring fault on one or two pairs, causing auto-negotiation to fail and the port to fall back to 100 Mbps half-duplex instead of 1 Gbps full-duplex. The diagnostic sequence is: (1) show interfaces status to confirm the speed/duplex mismatch; (2) show interfaces [intf] | include BW\|duplex to see the actual negotiated values; (3) check the cable with a cable tester or replace it again; (4) after cable replacement, shut/no shut the interface and verify with show etherchannel summary that the (g) flag is gone and the port shows (P)

Correct answer is D. The (g) flag is one of the most specific and actionable flag codes in EtherChannel diagnostics — it unambiguously identifies a speed or duplex mismatch within the channel group. The fact that the cable was recently replaced is highly significant: a new cable with a manufacturing defect or an incorrectly terminated cable (e.g., a wiring error on pins 4, 5, 7, or 8 in a 1000BASE-T connection) can cause auto-negotiation to fail because 1 Gbps requires all four pairs while 100 Mbps only requires two pairs. When auto-negotiation fails, the port falls back to the speed and duplex it can achieve with the available pairs — typically 100 Mbps half-duplex. This makes the cable replacement the prime suspect. The diagnostic sequence is exact: show interfaces status gives a compact view of speed and duplex on all member ports simultaneously and will immediately show the discrepancy. After identifying the specific port, show interfaces [intf] | include BW|duplex confirms the values. Option B is incorrect — the (H) flag (not g) indicates hot-standby for LACP. The (g) flag always means speed/duplex mismatch, never standby status.

3. SW1's EtherChannel shows all four ports as (P) and users report that VLAN 30 and VLAN 40 traffic is intermittently dropped, while VLAN 10 and VLAN 20 work perfectly. What is the cause and how do you diagnose it?

A. The VLANs 30 and 40 do not exist in the VLAN database on SW1 — the intermittent drops are caused by IOS forwarding frames to VLANs that are not in the active VLAN list. Run show vlan brief to verify VLAN 30 and 40 are created and active B. The EtherChannel load-balancing algorithm is hashing VLAN 30 and 40 traffic to the same single member port, overloading it while the other three ports are underutilised. Change the load-balancing method with port-channel load-balance dst-ip to distribute the traffic more evenly C. The allowed VLAN list is inconsistent between member ports — some ports have only VLANs 10 and 20 in their allowed list while the port-channel and other members allow VLANs 10, 20, 30, and 40. Because EtherChannel hashing distributes frames across all member ports based on source/destination addresses, frames for VLAN 30 and 40 that hash to the misconfigured ports are dropped. Frames for those VLANs that hash to correctly configured ports succeed — producing exactly the intermittent pattern observed. Diagnose with show interfaces trunk and compare the "Vlans allowed on trunk" line for each member port individually D. The STP root bridge for VLANs 30 and 40 is located on the other side of the EtherChannel and the bundle is blocking the STP designated port for those VLANs — causing the intermittent forwarding behaviour while STP reconverges repeatedly

Correct answer is C. This is one of the most subtle EtherChannel faults because it does not trigger the suspended port (s) flag — all ports show (P) (bundled and active). The allowed VLAN list is checked by the IOS EtherChannel consistency checker, but a partial mismatch (where only some VLANs are excluded) may not always suspend the port — particularly if the ports were added to the bundle at different times or if the allowed VLAN list was modified after the bundle was already formed. The key diagnostic insight is the precise pattern: VLANs 10 and 20 work perfectly, VLANs 30 and 40 are intermittently broken. "Perfectly fine" plus "intermittent" for exactly the missing VLANs points directly to a hash distribution problem — the affected VLANs only fail when hashed to the ports that don't allow them. show interfaces trunk is the definitive diagnostic tool: examine the "Vlans allowed on trunk" line for each member port (Gi0/1, Gi0/2, Gi0/3, Gi0/4) individually, not just for Po1. The fix is to apply the correct allowed VLAN list to all member ports and the port-channel interface to ensure consistency. Option B is incorrect — load imbalance causes one port to carry more traffic than others, not protocol-level drops for specific VLANs.

4. An engineer configures an EtherChannel using `channel-group 1 mode on` on SW1 and `channel-group 1 mode active` on SW2. SW1 shows Po1(SU) with all ports (P), but SW2 shows Po1(SD) with all ports (s). What is happening, and why is this the most dangerous EtherChannel misconfiguration?

A. SW1 is in static on mode and does not send or respond to LACP PDUs. SW2 is in LACP active mode, sending LACP PDUs and waiting for responses that never arrive — so SW2 suspends its ports because LACP negotiation cannot complete. SW1 believes the bundle is up and forwards traffic normally because static mode requires no confirmation. This creates a one-way forwarding black hole: traffic from devices behind SW1 is sent into the bundle and forwarded toward SW2's suspended ports, where it is dropped. Devices behind SW2 cannot reach devices behind SW1. This is the most dangerous misconfiguration because SW1 shows a completely healthy Po1(SU) with no error indicators — an operator looking only at SW1 would see no problem B. SW1's static mode is incompatible with SW2's LACP mode because they use different hashing algorithms — SW1 hashes based on source MAC and SW2 hashes based on destination IP. The mismatch causes asymmetric forwarding where some flows reach the destination but return traffic takes a different path and is dropped by the RPF check C. The behaviour is expected — static mode on SW1 means it acts as the LACP active side and SW2 in LACP active mode acts as the passive side. The suspended ports on SW2 are in hot-standby state and will become active after the LACP negotiation timer expires. No action is needed D. SW1's static mode overrides LACP on SW2 because static mode has higher administrative priority in IOS. SW2's ports are suspended temporarily while IOS reconfigures them to static mode to match SW1. They will automatically transition to (P) once the conversion completes

Correct answer is A. This is one of the most important EtherChannel concepts to understand deeply, both for the exam and for production network safety. The mechanism is precise: static on mode in IOS means "form the bundle unconditionally, send no EtherChannel protocol PDUs, and do not wait for any negotiation." A switch in on mode treats all member ports as bundled from the moment the configuration is applied — it begins forwarding traffic across the bundle immediately. LACP active mode means "send LACP PDUs and wait for the remote side to respond before adding the port to the bundle." SW2 sends LACP PDUs, receives nothing back from SW1 (which is in static mode and ignores them), and suspends its ports because LACP cannot confirm the remote side is ready to bundle. The result: SW1 forwards into the "bundle," the frames arrive at SW2's physical ports, but SW2 has those ports suspended (not forwarding) — the frames are dropped. From SW1's perspective, Po1 is fully up with four healthy P-flagged ports. There is no alarm, no error counter, no CDP message. An NOC engineer monitoring only SW1 would see a perfectly healthy network while users behind SW2 cannot communicate. The fix is always to use the same protocol on both sides: both LACP (active/passive or active/active) or both static on. Never mix static with a negotiation protocol.

5. What is the significance of the Partner's information section in `show etherchannel detail`, and what does it mean if this section is absent for a member port?

A. The Partner's information section shows the STP designated bridge information for the port — the partner device ID is the root bridge MAC address. If absent, it means the port is in a non-designated STP state and is blocked B. The Partner's information section shows the CDP neighbour details — device ID, IP address, and platform. It is absent when CDP is disabled on the remote port or the remote device does not support CDP C. The Partner's information section shows the remote switch's SNMP system description and is populated only when SNMP is enabled on both devices. If absent, enable SNMP with snmp-server community public ro on the remote switch D. The Partner's information section shows the LACP PDU data received from the remote switch — device ID (MAC address), port priority, port number, Oper Key, and port state flags. This information is extracted directly from incoming LACP PDUs. If the Partner's information section is absent for a member port, it means the local switch is receiving no LACP PDUs at all from the remote side on that port. This conclusively proves the problem is either: the remote port is down (no PDUs sent), the remote port is in a non-LACP mode (static on or PAgP), the cable is broken in the remote-to-local direction (unidirectional failure), or LACP is not configured on the remote port. The Partner's Oper Key field is particularly useful — if the partner's Oper Key does not match the local Oper Key, LACP has detected a parameter inconsistency and will not bundle the port even though PDUs are being exchanged

Correct answer is D. The Partner's information section in show etherchannel [N] detail is populated entirely from received LACP PDUs — it shows exactly what the remote switch is advertising. Each LACP PDU contains the actor's (sender's) system ID (MAC address used as device identifier), port key (Oper Key), port priority, and port state flags. When the local switch receives these PDUs, it stores them in the LACP state machine and displays them in this section. The complete absence of Partner's information is one of the most useful diagnostic signals in EtherChannel troubleshooting — it definitively proves no LACP PDUs are arriving on that port. This narrows the problem immediately to a small set of physical or configuration causes. The Oper Key matching is also critical: LACP uses the Oper Key as a compatibility check — all ports in a bundle on one switch must have the same Oper Key, and the local Oper Key must match the partner's Oper Key. IOS automatically assigns the Oper Key based on port parameters (speed, duplex, media type) — if a port negotiates to a different speed, its Oper Key changes and LACP will not bundle it with the others. This is exactly how LACP detects and rejects speed/duplex mismatched ports, and why the (g) flag appears when a speed mismatch is present.

6. A network engineer wants to add two new ports (Gi0/5 and Gi0/6) to an existing four-port LACP EtherChannel bundle (Po1). After adding them with `channel-group 1 mode active`, both new ports show (s). What is the most systematic approach to identifying why they are suspended?

A. Remove the new ports from the bundle, delete and recreate the port-channel interface from scratch with all six ports simultaneously — adding ports to an existing bundle is not supported and always results in suspended ports until the bundle is rebuilt B. Compare the new ports' configuration against the existing working ports on every mandatory match parameter in this systematic order: (1) check show interfaces status for speed/duplex mismatch; (2) check show interfaces trunk for switchport mode, native VLAN, and allowed VLAN list; (3) check show interfaces gi0/5 switchport for any access VLAN or voice VLAN assignment that differs; (4) run show logging | include ETHCNL — IOS generates a specific log message identifying the exact inconsistent parameter when it suspends a port during the consistency check. The IOS syslog message is typically the fastest path to the exact cause C. The suspended ports indicate LACP mode incompatibility — the remote switch must be using PAgP on ports Gi0/5 and Gi0/6. Change the new ports to PAgP desirable mode on the remote switch to match the existing bundle D. The six-port bundle exceeds IOS's maximum of four ports per EtherChannel on most catalyst platforms — the two new ports are automatically suspended because the bundle is at capacity. Verify the platform's maximum with show platform etherchannel

Correct answer is B. Adding ports to an existing bundle is fully supported by IOS — the EtherChannel consistency checker automatically evaluates each new port against the bundle's established parameters when it joins. If any parameter does not match, the port is immediately suspended with the (s) flag. The systematic approach described in option B is exactly how to diagnose this efficiently. The sequence matters: start with the easiest checks (speed/duplex via show interfaces status) and progress to more detailed checks. The most powerful tool is often overlooked: show logging | include ETHCNL. IOS generates explicit syslog messages when the consistency checker rejects a port, naming the specific parameter that failed. For example: %EC-5-BUNDLE: Interface Gi0/5 joined port-channel Po1 means success, while %EC-5-CANNOT_BUNDLE2: Gi0/5 is not compatible with Po1 and will be suspended (native vlan of Gi0/5 is 10, Po1 is 99) tells you exactly what to fix without any further diagnosis. Always check the syslog before spending time on systematic parameter comparison — IOS will often just tell you the answer directly. Option D is incorrect — IOS supports up to 8 active LACP ports (and up to 16 total with 8 in hot-standby) per bundle on most Catalyst platforms.

7. Why should trunk parameters (native VLAN, allowed VLANs) always be configured on the `interface Port-channel[N]` logical interface rather than on individual member physical ports?

A. Configuring trunk parameters on physical member ports is not supported — IOS silently ignores any switchport trunk commands entered directly on member ports and only accepts them on the port-channel interface B. Configuring trunk parameters on physical member ports causes them to leave the EtherChannel bundle immediately — IOS detects the configuration attempt and automatically removes the channel-group assignment from any port that has trunk parameters configured directly C. IOS does accept trunk parameter commands directly on member physical ports, and those commands will appear in the running-config. However, if the physical port's trunk parameters differ from the port-channel interface's trunk parameters, IOS may suspend the port or apply the port-channel interface values at runtime — creating a confusing state where the running-config shows one value but the operational state reflects another. Configuring on the port-channel interface ensures a single authoritative source of truth: member ports inherit the port-channel interface configuration, and there is no risk of a split between stored config and operational state. It also simplifies management — changing the native VLAN requires editing one interface instead of four D. Trunk parameters on physical member ports are applied per-packet at the hardware level, while port-channel interface parameters are applied at the software level. Configuring on both creates a double-tagging condition where frames get 802.1Q headers applied twice, corrupting the VLAN encapsulation

Correct answer is C. This is an important operational best practice that the exam tests conceptually. IOS does accept switchport trunk commands on physical member ports — they will appear in show run interface gi0/1. The problem arises from the interaction between the port-channel logical interface and its member ports. In IOS, the port-channel interface acts as a template: its trunk configuration is propagated to all member ports. If a member port has conflicting configuration applied directly, IOS must resolve the conflict — and the resolution behaviour can vary between IOS versions. In most cases, the port-channel interface value takes precedence at runtime (you'll see it in show interfaces trunk) but the physical port's running-config still shows the conflicting value. This creates exactly the STP PVID error scenario in Fault 8: the running-config says native VLAN 10 on Gi0/1, but show interfaces trunk shows native VLAN 99 (from Po1). An engineer reading the running-config would think the native VLAN is 10 and be confused why they're getting VLAN 99 STP BPDUs. The best practice eliminates this ambiguity entirely: configure trunk parameters only on the port-channel interface, and explicitly remove any conflicting trunk config from member ports with no switchport trunk native vlan and no switchport trunk allowed vlan. This produces clean, unambiguous running-configs that match operational state.

8. The output of `show lacp 1 neighbor` shows partner flags of "SP" (Slow, Passive) for all four ports. Is this a problem, and what does it tell you about the remote switch's LACP configuration?

A. This is not a problem — it is a fully valid and operational LACP bundle configuration. "SP" partner flags mean the remote switch is sending LACP PDUs at the Slow rate (one PDU every 30 seconds) and is in Passive mode (responding to LACP PDUs but not initiating them). The local switch must therefore be in Active mode (which it is, since it is receiving partner information — if the local switch were also passive, no PDUs would be exchanged and the partner section would be empty). A bundle with one Active side and one Passive side is fully operational with no reduced functionality. The Slow PDU rate means the LACP hold-down timer is 90 seconds (3× the PDU interval) — a link failure will take up to 90 seconds to be detected via LACP timeout rather than 3 seconds with Fast rate B. "SP" flags indicate the remote switch is in an LACP standby state — all four remote ports are hot-standby ports that will only become active if the local switch's active ports fail. The bundle is currently running with zero bandwidth because only standby ports are present on the remote side C. "SP" flags indicate a version mismatch — the remote switch is running an older IOS version that only supports slow LACP and passive mode. Upgrade the remote switch IOS to enable fast LACP and active mode D. "SP" flags indicate the remote switch is receiving LACP PDUs but not forwarding them — STP has blocked the physical ports on the remote side and LACP is operating over the STP management VLAN only. The bundle will not carry data traffic until STP converges

Correct answer is A. Understanding LACP PDU flags is essential for correctly reading show lacp neighbor output without misdiagnosing a healthy bundle as faulty. The partner flags have two components: the PDU rate (S=Slow/30s, F=Fast/1s) and the mode (A=Active/initiating, P=Passive/responding). "SP" means the partner is sending Slow PDUs in Passive mode. This is a completely valid state — passive mode switches respond to LACP PDUs but do not initiate them. Since the Partner's information section is populated, PDUs are definitely being received from the remote switch. The fact that the remote is passive means the local switch must be active (initiating), which is why the exchange is happening at all. The only operational consideration is the PDU rate: Slow rate (S) means LACP PDUs every 30 seconds and a dead-interval of 90 seconds. If a link fails, LACP will remove the port from the bundle within 90 seconds (waiting for 3 missed PDUs). Fast rate (F) would detect the failure in 3 seconds. For most deployments, 90-second LACP failover is acceptable. For latency-sensitive environments, configure both sides to use fast LACP with lacp rate fast on the interface. But SP partner flags with a populated partner section confirm a healthy, fully operational LACP bundle.

9. Does the port-channel group number need to match on both switches? For example, if SW1 uses `channel-group 1 mode active` and SW2 uses `channel-group 5 mode active` for the same physical links, will the LACP bundle form?

A. No — the channel-group number must match on both sides. LACP encodes the group number in the LACP System ID field and both switches must agree on the group number for the Oper Key to match. SW1's group 1 and SW2's group 5 will have different Oper Keys and LACP will refuse to bundle the ports B. No — the channel-group number must match because IOS uses it to identify the bundle across the link. If the numbers differ, IOS generates a warning message and the ports remain in stand-alone mode until the numbers are aligned C. Yes, but only if both switches are running the same IOS major version — IOS normalises the group number across the link during the first LACP PDU exchange. On different IOS versions, the group number must match D. Yes — the bundle forms normally. The channel-group number is locally significant only and is never communicated to the remote switch. LACP identifies bundles using the System ID (a combination of LACP system priority and the switch's MAC address) and the Oper Key (derived from port parameters like speed, duplex, and media type — not the group number). SW1's group 1 and SW2's group 5 will have matching Oper Keys as long as their port parameters match, and LACP will successfully form the bundle. The logical interface name will be Po1 on SW1 and Po5 on SW2 — both are valid and both refer to the same physical bundle of links

Correct answer is D. This is a commonly misunderstood EtherChannel concept that trips up many candidates on lab exams. The channel-group number is a local label — it identifies the bundle to the local IOS switch and determines the port-channel interface name (channel-group 1 = Port-channel1, channel-group 5 = Port-channel5). It is never sent to the remote switch. LACP uses a completely different mechanism to identify and match bundle members: the System ID (LACP system priority + switch MAC address, unique per switch) and the Oper Key (a 16-bit value derived from the physical port parameters). When SW1 sends an LACP PDU from its Gi0/1, the PDU contains SW1's System ID and SW1's Oper Key for that port. SW2 receives this, compares it against the PDUs from its other ports connecting to SW1, and groups them into a bundle based on matching System IDs and Oper Keys. The group numbers 1 and 5 are irrelevant to this process. In practice, using different group numbers between switches is uncommon (most engineers use the same number for clarity), but it works perfectly. The practical implication: when troubleshooting LACP failures, never waste time checking if group numbers match between switches — they don't need to, and checking them is a distraction. Focus instead on the Oper Key, which DOES need to be consistent and IS communicated via LACP PDUs.

10. An engineer uses `show logging | include ETHCNL` and sees the message: %EC-5-CANNOT_BUNDLE2: Gi0/3 is not compatible with Po1 and will be suspended (native vlan of Gi0/3 is 1, Po1 is 99). What exactly does this tell you, and what is the precise fix?

A. The message indicates that VLAN 1 does not exist in the VLAN database and must be created before Gi0/3 can join the bundle. Create VLAN 1 with vlan 1 in global config and then re-add the port to the channel group B. The message indicates that the port-channel interface (Po1) has been misconfigured with native VLAN 99 when it should be native VLAN 1. Change the port-channel native VLAN to 1 with interface po1 followed by switchport trunk native vlan 1 to match what Gi0/3 expects C. The IOS EtherChannel consistency checker has identified precisely that the native VLAN on Gi0/3 is VLAN 1 (the IOS default), while the established bundle Po1 is using native VLAN 99. IOS has suspended Gi0/3 to prevent it from disrupting the bundle. The fix is to align Gi0/3's native VLAN with the bundle: interface gi0/3 → switchport trunk native vlan 99. Verify with show interfaces gi0/3 trunk that the native VLAN is now 99, then confirm show etherchannel summary shows Gi0/3 as (P) rather than (s) D. The message indicates a physical layer incompatibility — Gi0/3 is connected to a switch port that is in access mode on VLAN 1, while Po1 is a trunk carrying native VLAN 99. The fix is to change the remote switch port to trunk mode with native VLAN 99

Correct answer is C. The %EC-5-CANNOT_BUNDLE2 syslog message is the IOS EtherChannel consistency checker's explicit report — it names the port, the bundle, the parameter that failed, the value found on the port, and the value expected by the bundle. This is the most informative single message in all of EtherChannel troubleshooting. Reading it precisely: "Gi0/3 is not compatible with Po1" — the consistency check failed. "native vlan of Gi0/3 is 1, Po1 is 99" — the port's native VLAN is 1 (VLAN 1 is the IOS default, which means no explicit switchport trunk native vlan command was ever entered on Gi0/3) while the bundle's established native VLAN is 99. The fix is exactly as described: add the missing configuration to Gi0/3. Gi0/3 is the new port being added to a pre-existing bundle — the bundle's parameters are correct (99 was intentionally chosen for the bundle), and the new port simply has the default value (1) because it was not fully configured before being added to the channel group. This is the most common scenario for this message: a new port added to an existing bundle without first configuring all trunk parameters to match. After fixing, the port automatically re-evaluates and joins the bundle without needing to shut/no shut. Option B is incorrect — the bundle is correct at 99; the port is the outlier at 1. Changing the bundle would break the three already-working ports.

Back to Home

Troubleshooting EtherChannel

1. EtherChannel Concepts & Requirements

EtherChannel Protocols

LACP and PAgP Mode Compatibility Matrix

Mandatory EtherChannel Parameter Match Requirements

2. Lab Topology & Fault Scenarios

3. Reading the Diagnostic Commands

show etherchannel summary — The Primary Diagnostic Tool

EtherChannel Flag Code Reference

show etherchannel detail — Deep Diagnostic Output

4. Fault 1 — LACP Passive/Passive: Bundle Never Forms

Symptom

Diagnose

Fix

5. Fault 2 — Mixed Protocol: LACP on SW1, PAgP on SW2

Symptom

Diagnose

Fix

6. Fault 3 — Static "On" vs LACP: Ports Suspended or Err-Disabled

Symptom

Diagnose

Fix

7. Fault 4 — Speed or Duplex Mismatch: One Port Suspended

Symptom

Diagnose

Fix

8. Fault 5 — Native VLAN Mismatch: STP Errors and Traffic Loss

Symptom

Diagnose

Fix

9. Fault 6 — Allowed VLAN List Inconsistency

Symptom

Diagnose

Fix

10. Fault 7 — Switchport Mode Mismatch: Access vs Trunk

Symptom

Diagnose

Fix

11. Fault 8 — Port-Channel Interface Parameter Inconsistency

Symptom

Diagnose

Fix

12. Complete EtherChannel Troubleshooting Workflow

Step-by-Step Diagnostic Checklist

EtherChannel Diagnostic Command Summary

13. EtherChannel Troubleshooting — Quick Reference

Key Points & Exam Tips

TEST WHAT YOU LEARNED

1. show etherchannel summary shows Po1(SD) with all four member ports showing (I). What does this output tell you, and what are the two most likely causes?

2. An EtherChannel bundle has three ports showing (P) and one port showing (s) with the (g) flag. The physical cable on the suspect port was recently replaced. What is the most likely cause of the suspension, and what is the correct diagnostic sequence?

3. SW1's EtherChannel shows all four ports as (P) and users report that VLAN 30 and VLAN 40 traffic is intermittently dropped, while VLAN 10 and VLAN 20 work perfectly. What is the cause and how do you diagnose it?

4. An engineer configures an EtherChannel using channel-group 1 mode on on SW1 and channel-group 1 mode active on SW2. SW1 shows Po1(SU) with all ports (P), but SW2 shows Po1(SD) with all ports (s). What is happening, and why is this the most dangerous EtherChannel misconfiguration?

5. What is the significance of the Partner's information section in show etherchannel detail, and what does it mean if this section is absent for a member port?

6. A network engineer wants to add two new ports (Gi0/5 and Gi0/6) to an existing four-port LACP EtherChannel bundle (Po1). After adding them with channel-group 1 mode active, both new ports show (s). What is the most systematic approach to identifying why they are suspended?

7. Why should trunk parameters (native VLAN, allowed VLANs) always be configured on the interface Port-channel[N] logical interface rather than on individual member physical ports?

8. The output of show lacp 1 neighbor shows partner flags of "SP" (Slow, Passive) for all four ports. Is this a problem, and what does it tell you about the remote switch's LACP configuration?

9. Does the port-channel group number need to match on both switches? For example, if SW1 uses channel-group 1 mode active and SW2 uses channel-group 5 mode active for the same physical links, will the LACP bundle form?

10. An engineer uses show logging | include ETHCNL and sees the message: %EC-5-CANNOT_BUNDLE2: Gi0/3 is not compatible with Po1 and will be suspended (native vlan of Gi0/3 is 1, Po1 is 99). What exactly does this tell you, and what is the precise fix?

1. `show etherchannel summary` shows Po1(SD) with all four member ports showing (I). What does this output tell you, and what are the two most likely causes?

4. An engineer configures an EtherChannel using `channel-group 1 mode on` on SW1 and `channel-group 1 mode active` on SW2. SW1 shows Po1(SU) with all ports (P), but SW2 shows Po1(SD) with all ports (s). What is happening, and why is this the most dangerous EtherChannel misconfiguration?

5. What is the significance of the Partner's information section in `show etherchannel detail`, and what does it mean if this section is absent for a member port?

6. A network engineer wants to add two new ports (Gi0/5 and Gi0/6) to an existing four-port LACP EtherChannel bundle (Po1). After adding them with `channel-group 1 mode active`, both new ports show (s). What is the most systematic approach to identifying why they are suspended?

7. Why should trunk parameters (native VLAN, allowed VLANs) always be configured on the `interface Port-channel[N]` logical interface rather than on individual member physical ports?

8. The output of `show lacp 1 neighbor` shows partner flags of "SP" (Slow, Passive) for all four ports. Is this a problem, and what does it tell you about the remote switch's LACP configuration?

9. Does the port-channel group number need to match on both switches? For example, if SW1 uses `channel-group 1 mode active` and SW2 uses `channel-group 5 mode active` for the same physical links, will the LACP bundle form?

10. An engineer uses `show logging | include ETHCNL` and sees the message: %EC-5-CANNOT_BUNDLE2: Gi0/3 is not compatible with Po1 and will be suspended (native vlan of Gi0/3 is 1, Po1 is 99). What exactly does this tell you, and what is the precise fix?