Implementing and Troubleshooting EtherChannel

Before we get into the technical topics, I’ll give a brief personal update, as I’ve been asked by a few people how close I am to test time.  I’m happy to say that I’ve tentatively scheduled the written test for the first week of March.  I feel ready for it.  Even though I haven’t done full write-ups here on everything here, I’m well ahead in terms of what I’ve studied.  I’ve been through the Cisco Press books, Routing TCP/IP volumes, CBT Nuggets Videos, INE Videos and have started going through the workbooks from INE.  While I know I’m not quite ready for the lab, I’d actually be quite disappointed if I didn’t pass the written at this point.  I’d go take it today if I could.  Ok, maybe not exactly today unless I was guaranteed that I would get no questions on DMVPN or MPLS – but I’ll have enough time to learn those two areas in the next month and a half here.  So I’m putting it in the calendar so that the time is officially reserved!  In the meantime, I’m hoping I can get a few more of these technical write-ups done, as they make a great way to re-examine some of these topics that I haven’t looked at for a few months.  So now, onto today’s topic!


Remember when you first learned about Spanning-Tree and discovered that you could have all these redundant links in your switching environment, but couldn’t ever actually use them except for standby purposes?  Man, that was annoying!  As the picture above pokes fun at… it just feels like a bottleneck that we were forced to include in our designs.  Yet, that was the world we lived in, and we were forced to just accept it for quite a while.  Cisco was the first to the table with an EtherChannel implementation when they created PaGP.  Then the industry created its vendor-neutral homotocol, LACP.  (Yes, I’m sticking with the term “homotocol”, and you can’t stop me!)  EtherChannel is the subject of our next exam topics discussion.  Here’s what the blueprint says we should know:

2.1.e   Implement and troubleshoot EtherChannel
2.1.e (i)   LACP, PAgP, manual
2.1.e (ii)   Layer 2, layer 3
2.1.e (iii)   Load-balancing
2.1.e (iv)   EtherChannel misconfiguration guard

Most configuration settings on an EtherChannel’s member links must be the same, and inconsistent settings will cause link members to become suspended.  It is important to note that, while you can apply configuration settings to the port-channel in order to have them applied to the physical links, this only works for non-suspended links, so it’s always good to verify that what you have configured has led to the results expected to see after applying configuration changes to the port-channel.  Also, remember that, in order to prevent loops, a switch will shut down all member ports if the channel-group is deleted with the no interface port-channel # command, so it is usually best to remove the physical links from the port-channel first.  If there are more than 8 links in the bundle, any and all extras will be held in reserve for hot-standby purposes.  You can configure switch and port priorities if desired, so you can choose which switch will decide which stand-by link will be added to the bundle in the event of a failure.  Also keep in mind that you don’t get the “true advertised” bandwidth of your bundle, as the hashing algorithm that distributes traffic among links will not lead to traffic being distributed perfectly evenly among them, and will lead to individual conversations taking place over a single physical link.  The maximum number of number of active links in a bundle is 8, and the best way to guarantee the most even distribution possible among these links is to implement port-channels in bundles of 2, 4, or 8 links.

LACP, PAgP, Manual

LACP and PAgP are protocols that can negotiate EtherChannels.  It is strongly recommended that you use one of them as opposed to manually configuring EtherChannels.  This is due to the fact that an issue in the bundle can cause loops in your environment, and using one of these negotiation protocols can help detect issues with the bundle.  Keep in mind: EtherChannels essentially trick Spanning-Tree into treating multiple physical links as a single virtual interface, so if one side of the link is essentially not running spanning-tree on each physical link and the other side is, loops will form.  You don’t have to worry about this as much with bundles that are negotiated via PAgP or LACP, as both sides of the link will agree on which links are members of the bundle before actually beginning to run as such.

LACP and PAgP are so similar that we won’t even discuss the differences, aside from the aforementioned Cisco-proprietary vs vendor-neutral nature of them.  For LACP, use the channel-group # mode active|passive command.  At least one side must be active for the bundle to come up.  For PAgP, use the channel-group # mode desirable|auto command, and again, at least one side must be configured as desirable for the bundle to come up.  To manually force all links in the bundle on without negotiation, simply use the channel-group # mode on command.

EtherChannel configuration can be verified with the show etherchannel # command.  For an overview of all of them in use on a switch, use the show etherchannel summary command.  There is a great amount of detail available with the show etherchannel # detail command.  The protocol information can also be viewed with the show pagp neighbor or show lacp neighbor commands, assuming that you are running one of these protocols.

It’s good to note that you can use the channel-protocol lacp|pagp command.  This setting, while completely transparent to the actual operation of the switch, is useful for admins, as it will make is so that the only options you have for configuration are those releated to the selected protocol.  It’s not always easy to remember that pagp uses desirable/auto and lacp uses active/passive.  Using the channel-protocol command will make it so that you don’t really have to remember, and the only options you have are the ones associated with your chosen protocol.  Again though, remember that this command does NOT actually tell the switch or any of its links to actually use the chosen protocol – it only tells the switch to essentially PREVENT you from using the other one.

Layer 2 EtherChannel

To create an L2 etherchannel, simply go to your physical interface(s) and use the channel-group # mode mode command.  It is best to configure physical interfaces while shut down and to bring up the virtual and physical interfaces all together.

After bringing up an L2 EtherChannel, you should verify its operation with traditional spanning-tree verification commands.  Instead of seeing physical links, you should see your EtherChannel in the Spanning-tree show commands.

Layer 3 EtherChannel

First of all, you cannot convert an active port-channel from layer 2 to layer 3 or vice versa, so if you have plans to do so, make sure it is during an outage window and that you have access to both devices outside of the connectivity being provided through the port-channel.

The big step to remember for an L3 port-channel is to simply be sure to create the port-channel as an L3 port-channel first, either with the interface port-channel # command, then setting it as an L3 interface with the no switchport command, or by setting the physical interfaces with the no switchport command before adding them to the bundle.  You then assign your IP address to the L3 port-channel, rather than individually on the physical interfaces.  Just be sure that you don’t configure the channel-group command on an interface while it’s still running as an L2 link or you’ll have to start over, as this will create an L2 Port-channel interface.

Load Balancing

Again, conversations or flows between two hosts will always be carried by the same link within the bundle.  This, we cannot change.  However, we can chose which particular algorithm we want to use to make that choice.  This can be advantageous in cases where the current load-balancing algorithm is leading to poor distribution between physical links.  For instance, if you have two routers connected by an EtherChannel and your load-balancing algorithm is only looking at source and destination MAC addresses, you will find that all the traffic between those two routers gets carried across the same physical link, leading to very little or even no load-balancing at all.  Possible options for these can include source and destination MACs, IPs, TCP/UDP ports, and is very platform dependent.  Verify load-balancing info with the show etherchannel load-balance command.

EtherChannel Misconfiguration Guard

Misconfiguration guard is intended to catch issues with configurations where one side is configured as a port-channel but the other side isn’t.  It doesn’t always work.  (Or doesn’t ever work, depending on who you ask… including me)  It is on by default, so you don’t have to actually configure it (which you would do with the global spanning-tree etherchannel guard misconfig command), but it’s definitely not something you want to count on in lieu of actually paying attention to how you are configuring your switches.  It works by watching the MAC address of BPDUs coming from the neighbor.  If the neighbor is correctly configured, the switch can safely assume that all BPDUs from the neighbor will contain the same source MAC address, and if it sees multiple MACs, it will shut down the ports.  Here’s the thing: this definitely could help save you if you were to somehow plug two links from a port-channel into two different neighboring switches.  The vast majority of the time though, errors with EtherChannels don’t stem from accidentally plugging the cables into the wrong switches – they come from misconfiguring the bundle, or even configuring the bundle correctly, just in the wrong order.  Misconfiguration guard won’t help with that.  Still, since it’s there, we might as well leave it running.  The one time that this could be an issue is if you are connected to a neighboring device that is tunneling BPDUs from different upstream devices.  In our next topic, we’ll see that this tunneling concept does indeed happen with PVST+ switches that are connected to a neighboring non-Cisco switch.  The vast majority of the time though, BPDUs from a neighboring switch will source from that switch’s MAC address.


I’m going to keep this one short, as I can promise that our deep dive into Spanning-tree will be anything but!  Thanks again for stopping by!

Leave a Comment

Your email address will not be published. Required fields are marked *