Etherchannel which is also known as Link Aggregation and it is a protocol that allows grouping or bundling of multiple physical Ethernet links into a single logical one. Its main purpose is to provide fault-tolerant high-speed links between network devices and also servers.
In today’s network, bottlenecks are fairly common and sometimes you may be financially limited to address those issues appropriately. Well, you can leverage the link aggregation protocol to increase bandwidth and the nice thing about it is that when a bundled link goes down, traffic is dynamically load balanced across the remaining links without the admin intervention. Let’s use a simple topology such as the following…

Before we dive into the consoles, let’s discuss a few points you’d need to know about Etherchannel. It is important to know that there are 2 different Etherchannel protocol which are PAgP and LACP which we will discuss in a second. You have the ability to configure a static etherchannel meaning no negotiation process takes place before the links are bundled or a dynamic etherchannel which a negotiation process takes place to set the etherchannel. Note that you can bundle Layer 2 or Layer 3 interfaces. We will see an example of one of those.
Also note that etherchannel provides full-duplex bandwidth up to 800 Mbps or 8 Gbps depending on the speed of your interface. So basically, you can only bundle up to 8 ports in a single switch.

In our case, we will be bundling 2 interfaces of 1 Gig each. Here is what it looks like…

Once the bundle is complete, here is what we will logically have…

All right, let’s talk about the different methods for each protocol.

1) PAgP: This is a Cisco proprietary protocol and below is the different options you have with PAgP.

*Mode On: Statically set the etherchannel. It forces the interface into an etherchannel without PAgP or LACP

*Mode Desirable: The interface will actively negotiate the formation of the etherchannel by sending PAgP packets

*Mode Auto: The interface will be in passive negotiation state meaning it will only responds to PAgP packets but does not start the negotiation process. This setup is useful in certain design because it minimizes the transmission of PAgP packets

Note that both auto and desirable PAgP modes allows interfaces to negotiate with their peer interfaces to determine the formation of a etherchannel based on criteria such as speed or trunking state and VLAN numbers for L2 etherchannels.

Let’s look at the compability modes with PAgP.

• An interface in the desirable mode can form an EtherChannel with another interface that is in the desirable or auto mode.

• An interface in the auto mode can form an EtherChannel with another interface in the desirable mode.

An interface in the auto mode cannot form an EtherChannel with another interface that is also in the auto mode because neither interface starts PAgP negotiation.

2) LACP: This is a IEEE standard and below is the different options you have with LACP.

*Mode On: Statically set the etherchannel. It forces the interface into an etherchannel without PAgP or LACP

*Mode Active: The interface will actively negotiate the formation of the etherchannel by sending LACP packets

*Mode Passive: The interface will be in passive negotiation state meaning it will only responds to LACP packets but does not start the negotiation process. This setup is useful in certain design because it minimizes the transmission of LACP packets

Let’s look at the compability modes with LACP.

• An interface in the active mode can form an EtherChannel with another interface that is in the active or passive mode.

• An interface in the active mode can form an EtherChannel with another interface in the passive mode.

An interface in the passive mode cannot form an EtherChannel with another interface that is also in the passive mode because neither interface starts LACP negotiation.

Let’s dive into the consoles now. Let’s connect to RouteLeak-SW01 and configure our etherchannel using PAgP protocol… It’s always good practice to check and make sure the interfaces displayed in the diagram are in fact the ones in play here. let’s check our neighbor relationship using cdp and also let’s default those interfaces out…

We can see that we are in fact connected to RouteLeak-SW02 via Gig1/0/1 and Gig1/0/2. We’ve also went ahead and defaulted the interfaces on RouteLeak-SW01. We will do the same on our peer switch once we get to it. Let’s now configure our Etherchannel…

It is that simple. First we needed to get at the interface mode and configure a channel group; I’m using 1 in this case and specify the mode. As you can see here, If I do a “?” after “mode” we notice that we have several options described in the beginning of this post. We configured PAgP in desirable mode so it actively send PAgP packets across. Let’s now connect to RouteLeak-SW02 and configure it the same way except this time, we will set the mode to “auto” so it only responds to Etherchannel requests….

We’ve successfully defaulted the interfaces out.

Good ! now that we have both side configured, let’s verify…

The “show etherchannel summary” and the “Show interface port-channel 1 | inc channel” are 2 good ways to verify if your etherchannel is up and running and what are the members of the bundled link. We can do the same with RouteLeak-SW02 just to make sure…

Looks like we are good ! Note that we have not configure any ports as access or trunk at this point… We have just configured the etherchannel. For this demo, I’m only doing PAgP and I’ll let you do LACP. Just run the “channel-group 1 mode” then type a “?”. You can then refer to the different combinations we have for either LACP and PAgP. The combinations are in the beginning of this post.

Now, I would like to show how to configure Layer 3 Etherchannel now before we are done with this section. The same analogy applies here with minor changes that I will discuss in a minute. First thing first, let’s default our interfaces out and configure our etherchannel. This time, we will use “Mode On” to unconditionally set our Etherchannel…

As you can see here, we’ve basically used the same approach but we now have introduced the command “no switchport” at the interface level. This is needed to make the Etherchannel as layer 3. Let’s do the same for our peer switch…

Let’s now configure our IP addresses. We will use 10.1.1.0/24.

Let’s now run the “sh etherchannel summary” command to make all is as we expected. Let’s also check the interface and make sure it has an IP address and both the status and the protocol are “up”.

RouteLeak-SW01 looks good ! Noticed the RU next to Po5 ? That’s what tells us that this is a Layer 3 Etherchannel. If you go back up a bit and check the output in our Layer 2 Etherchannel, you will notice a “SU” instead. Let’s now check RouteLeak-SW02…

Very nice ! Let’s ping across and see what we get…

Looks like we are good here. Any idea why our first ping has an average of 203ms and the 2nd is just about 4ms ? If you don’t, look up ARP (Address Resolution Protocol).

Quick Tips: In an Etherchannel, DTP and CDP both send and receive packets via the physical interfaces and not the virtual interface. Trunk ports send and receive PAgP and LACP protocol data units (PDUs) on the lowest numbered VLAN. Meanwhile, STP (Spanning-tree) forward packets over the first interface in the EtherChannel. Also note that the MAC address of a L3 Etherchannel is the MAC of the first interface in the port-channel.

All right, that completes this topic… I’ll talk to you guys later.