Commentary

Cisco uses the term EtherChannel to refer to their link aggregation technology. Link aggregation overcomes some of the shortcomings of the Spanning Tree Protocol (STP). For example, if EtherChannel was not being run on the links between SW1 and SW2, then one of the links would automatically be blocked by STP to ensure that a switching loop does not form; this will lose half of the available throughput. EtherChannel combines both links into a single logical link; because of this, STP considers this a single connection between the devices and does not block any of the ports.

Static EtherChannel configuration uses on mode per the channel-group mode interface subcommand; however, using this mode has the potential for causing problems. Both switches must use compatible settings on their links, and the dynamic methods to form a channel perform compatibility checks. Because of that, Cisco recommends using one of the dynamic protocols to negotiate the use of EtherChannel: Port Aggregation Protocol (PAgP) and Link Aggregation Control Protocol (LACP). PAgP is a Cisco proprietary version of link aggregation that was introduced before LACP. LACP is a standard-based solution and is defined in 802.3ad.

The lab asks for a variety of combinations to exercise your configuration skills. For EtherChannel 20, between SW1 and SW2, both interfaces on each switch need to be configured in on mode with the channel-group 20 mode on command.

For EtherChannel 21, between SW1 and SW3, SW1’s G1/0/3 and G1/0/4 use the channel-group 21 mode desirable command, which uses PAgP, and initiates the negotiation. SW3’s G1/0/1 and G1/0/2 use the channel-group 21 mode auto command, which uses PAgP, but passively waits for the other switch to initiate negotiations.

For EtherChannel 22, between SW2 and SW4, SW2’s G1/0/3 and G1/0/4 use the channel-group 22 mode active command, which uses LACP, and initiates the negotiation. SW4’s G1/0/1 and G1/0/2 use the channel-group 22 mode passive command, which uses LACP, but passively waits for the other switch to initiate negotiations.

Note that all the interfaces used default configuration, so there should be no mismatched interface settings preventing any interfaces from joining a Layer 2 EtherChannel. See the CCNA Official Cert Guides for more details on checking for those dependencies and for a broader look at EtherChannels.

Known Issues in this Lab

This section of each Config Lab Answers post hopes to help with those issues by listing any known issues with Packet Tracer related to this lab. In this case, the issues are:

Why Would Cisco Packet Tracer Have Issues?

(Note: The below text is the same in every Config Lab.)

Cisco Packet Tracer (CPT) simulates Cisco routers and switches. However, CPT does not run the same software that runs in real Cisco routers and switches. Instead, developers wrote CPT to predict the output a real router or switch would display given the same topology and configuration – but without performing all the same tasks, an actual device has to do. On a positive note, CPT requires far less CPU and RAM than a lab full of devices so that you can run CPT on your computer as an app. In addition, simulators like CPT help you learn about the Cisco router/switch user interface – the Command Line Interface (CLI) – without having to own real devices.

CPT can have issues compared to real devices because CPT does not run the same software as Cisco devices. CPT does not support all commands or parameters of a command. CPT may supply output from a command that differs in some ways from what an actual device would give. Those differences can be a problem for anyone learning networking technology because you may not have experience with that technology on real gear – so you may not notice the differences. So this section lists differences and issues that we have seen when using CPT to do this lab.

Beyond comparing your answers to this lab’s Answers post, you can test in Cisco Packet Tracer (CPT) or Cisco Modeling Labs (CML). In fact, you can and should explore the lab once configured. For this lab, once you have completed the configuration, try these verification steps. 

1. Verifying EtherChannel takes just a quick look at the output from the show etherchannel number summary command. This command should list all the ports in the working EtherChannel with a status of P, meaning the port is in the channel.
2. Troubleshooting why a port is not in the EtherChannel requires more effort, such as checking the variety of interface settings that must match on one switch, and on neighboring switches, before a switch will form the channel and add all ports to it. See the CCNA Official Cert Guide, Volume 1, section  “Troubleshooting EtherChannel” section for more details.