Hands-On Lab: Configuring, Verifying, and Troubleshooting EtherChannel (Static/PAgP/LACP)

This hands-on lab bundles two physical links between switches into a single logical EtherChannel using static, PAgP, and LACP modes in turn, verifies each bundle forms correctly, and demonstrates the mismatched-mode failure that prevents a bundle from forming.

EtherChannel ConfigurationLACP and PAgP ModesPort-Channel Verification

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۳۱ شهریور ۱۴۰۵

Lab Objective

Bundle two physical links between two switches into a single EtherChannel using static mode, then reconfigure the same bundle using PAgP, then LACP, verifying successful formation each time, and finally observe what happens when the two sides use mismatched modes.

Lab Purpose

EtherChannel combines multiple physical links into one logical interface, providing both aggregated bandwidth and Spanning Tree-transparent failover. Knowing all three formation methods — and recognizing a mode mismatch quickly — is essential, since the wrong combination silently prevents a bundle from forming.

Lab Topology

Switch1 ---- Gi1/0/1, Gi1/0/2 ---- Switch2

Two physical links to be bundled into
Port-channel 1

Task 1: Configure a Static EtherChannel

Bundle Gi1/0/1 and Gi1/0/2 into Port-channel 1 using static (unconditional) mode on both switches.

Task 2: Verify the Static Bundle

Confirm both member ports show as bundled (P) in the channel group.

Task 3: Reconfigure Using PAgP

Remove the static configuration and reconfigure using PAgP with desirable mode on both switches.

Task 4: Reconfigure Using LACP

Remove the PAgP configuration and reconfigure using LACP with active mode on both switches.

Task 5: Introduce a Mode Mismatch

Set Switch1 to LACP active while leaving Switch2 on PAgP desirable, and observe the resulting failure.

Solution and Verification

Switch1(config)# interface range gigabitethernet1/0/1-2
Switch1(config-if-range)# channel-group 1 mode on

Switch2(config)# interface range gigabitethernet1/0/1-2
Switch2(config-if-range)# channel-group 1 mode on

Switch1# show etherchannel summary

Group  Port-channel  Protocol   Ports
------+-------------+-----------+-----------------------
1      Po1(SU)       -          Gi1/0/1(P)  Gi1/0/2(P)
-- "-" for protocol confirms static mode
-- (no negotiation protocol used), and (P)
-- confirms both ports are bundled and active

Switch1(config)# interface range gigabitethernet1/0/1-2
Switch1(config-if-range)# no channel-group 1 mode on
Switch1(config-if-range)# channel-group 1 mode desirable

Switch2(config)# interface range gigabitethernet1/0/1-2
Switch2(config-if-range)# no channel-group 1 mode on
Switch2(config-if-range)# channel-group 1 mode desirable

Switch1# show etherchannel summary
Group  Port-channel  Protocol   Ports
1      Po1(SU)       PAgP       Gi1/0/1(P)  Gi1/0/2(P)

Switch1(config)# interface range gigabitethernet1/0/1-2
Switch1(config-if-range)# no channel-group 1 mode desirable
Switch1(config-if-range)# channel-group 1 mode active

Switch2(config)# interface range gigabitethernet1/0/1-2
Switch2(config-if-range)# no channel-group 1 mode desirable
Switch2(config-if-range)# channel-group 1 mode active

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

Switch2(config)# interface range gigabitethernet1/0/1-2
Switch2(config-if-range)# no channel-group 1 mode active
Switch2(config-if-range)# channel-group 1 mode desirable

Switch1# show etherchannel summary

Group  Port-channel  Protocol   Ports
1      Po1(SD)       LACP       Gi1/0/1(I)  Gi1/0/2(I)
-- (I) means "individual" -- the ports failed
-- to bundle, since LACP active and PAgP
-- desirable are incompatible negotiation
-- protocols that cannot form a channel together

Key Takeaway

The show etherchannel summary output's port flag is the fastest diagnostic check: (P) confirms a port successfully bundled, while (I) confirms it remains individual — almost always caused by a mode or protocol mismatch between the two switches, exactly as demonstrated when mixing LACP and PAgP.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه