EtherChannel - Load Balancing and Misconfiguration Guard

hey everyone charles judd here from kevin wallace training if you've been following my study progress you know that i've been going down the ccie blueprint from the top and working my way through those study topics today i wanted to share one of those items with you which is ether channel in this video i'll discuss ether channel load balancing algorithms and ether channel misconfiguration guard if you'd like to see more content related to ccie studies or if you want to see the previous video that i made related to lacp and layer 3 ether channel feel free to check out my personal channel which you can find a link to in the description below one of the big misconceptions about etherchannel is that we can simply multiply the number of ports that we've bundled together by the port speed itself and that this is going to be our throughput for that poor channel and that's not quite true so let's talk about why first take a look at our topology we have two switches with a layer three ether channel between those and that port channel consists of four physical links that are bundled together i also have four pcs connected to switch two with everything here in the same subnet so i'm connected into switch 1 in the console let me go ahead and ping switch 2 at 10.1.1.2 and i'm going to take the size of that up to the maximum datagram size 18024 just for testing purposes so that looks like that is successful i'm able to ping the other side of that ether channel and now i want to say show interface i want a pipe to include the sections line and rate so this is going to just really just pare down the information that i'm getting in my show output so that i can see the physical links that are being used and let me just ping that once more ping across there and again run my show command and now you can see in the output of my show command under gig zero slash zero you can see that we have an input and an output rate listed and this is currently at three thousand bits per second if you notice my other three gig connections zero slash one zero slash two and zero slash three all of those are not showing any input or output rates what does this mean well what this means is that although our physical links are bundled together we are currently utilizing only a single link a single physical link to send this traffic why is that well that's because of the default ether channel load balancing that the switch uses to determine which interface is used for forwarding traffic so that's very tricky and that's somewhat misleading although we do gain redundancy through etherchannel we can get a false sense of security if we don't understand how this load balancing works many people assume that we're just sending traffic over all of those links simultaneously but that's not necessarily the case so we need to understand how etherchannel chooses the best physical path and the different options that we have if we go under global configuration mode on this switch and let's say port hyphen channel load hyphen balance and let's look at contextual help from here you can see all of the load balancing algorithms that we're able to configure for our port channel interface now i'll also say that based on your ios or your switch model these might be different they might be more limited in my case i have six different options here these options are fairly self-explanatory as you can see from the output and there are many considerations for which one is going to be right for you that's going to be based on your specific network topology the location of your switch inside that topology what type of traffic you're trying to load balance and several other considerations and i'll also point out that this is a global command this cannot be changed on a per interface or per ether channel basis this is going to affect the entire switch and in general we want to use the option here that's going to provide us the most variety in the physical links that we're utilizing and what i mean by variety is if we have an ether channel between two switches as we do here and let's say on one side of the switch we have a high utilization server with lots of host traffic going out to that single server ip and mac address then we probably don't want to load balance using destination ip or destination mac options those are the first two options that we see here at the top that isn't going to give us any variety and the same physical channel link will be used each time that traffic goes to that server however if you have a large subnet of host pcs that are connecting out to this server you might want to choose source ip or source mac the bottom two options that we see that would certainly give you better load balancing for the best possible randomness in regard to physical link utilization the best recommendation is to use one of these two middle options to use both source and destination addressing whether that's source and destination ip or source and destination mac addressing so we have what we call the simple methods which are just source or just destination the top two and bottom two options with those simple methods the same type of traffic is always going to choose the same path so here on switch one let's play around with this a bit and let's change this let's go ahead and change this to source hyphen destination hyphen ip so that we use the source and destination ip addressing for our load balancing algorithm by the way if we break out of here if we want to see what our current load balancing algorithm is we can simply say show ether channel load hyphen balance and that's going to show us our current load balancing configuration which is of course source and destination ip address let's go to switch 2 and let's also change our algorithm on switch 2 as well so let's say port hyphen channel load hyphen balance and on this switch i'll say source hyphen destination hyphen ip okay let's go back to switch 1 and i'm going to run the command clear counters just to make sure that we don't have any old information coming into our show interfaces output so i'm going to clear those i'm going to clear off some space here on switch one just so we have a nice clean output that we can start over with and now what i'm going to do is i'm going to quickly jump to each of these pcs and i'm going to ping switch one at 10.1.1.1 you can see i have a repeat keyword in there i'm going to repeat that 20 times and i have a larger size datagram as well so i'll do that from pc1 pc2 pc3 and pc4 i'm gonna go back to switch one i'm gonna again run the show interfaces command and this time we're gonna see a little something different in the output of that if you notice now instead of all of the traffic only using gig zero slash one you'll see that we have some input and output rates variously on all four of these physical links so we can see that etherchannel is now load balancing in a different method that looks better and it's definitely not perfect you can see that these numbers aren't quite even at the moment so this does take some thought and some planning in a network if you're going to optimize an ether channel and if you're going to utilize your physical links more appropriately so the big takeaway here is don't get lulled into a sense of comfort just because you have an ether channel in place just because we're bundling physical links together doesn't mean we're realizing the full potential of those links we still need to take the proper care to load balance those as best we can one last ether channel topic to cover is etherchannel misconfiguration guard this is enabled by default on cisco switches and we can see this by running the command show spanning hyphen tree summary and near the bottom of that output we'll see etherchannel misconfiguration guard is enabled this feature uses spanning tree to make sure there are no errors between switches by checking the port id of the incoming bpdu if that is different than expected then the entire port channel is going to be placed into an error disable state let's jump over to switch 2 and let's go under interface gig 0 0 and let's actually remove this from our ether channel bundle just to see what happens so let's say no channel hyphen group 1 mode on and that's going to remove this interface from our ether channel bundle if we break out of here and say show ether channel summary then you'll see that this particular port is missing now we're only using zero one zero two and zero three over on switch one if we run that same command you'll see on this side we're configured to use gig zero slash zero we can say show interface status and nothing has happened just yet but in a moment we should see this create an error disable state and there we just saw those errors come in you'll notice that we have all of our interfaces have gone into the down state we see some spanning tree errors from ether channel misconfiguration guard so let's again say show interface status and you'll notice that now all of our interfaces including our port channel interface are in air disabled states so using ether channel misconfiguration guard when a single interface was removed from our ether channel configuration which changed those bpdus that were coming in this caused our safety mechanism to kick in and to shut down the entire port channel interface and to air disable all of our physical ports as well so to recover from this first we could re-add the interface to our port channel and then we would need to shut and no shut the interface we could also use some of our air disable automatic recovery options as well if we wanted to do that the big takeaway here is that this is a default feature that's enabled on a switch if for some reason you do need to make changes to an ether channel configuration in production and you're trying to avoid your interfaces going into an air disabled state and causing downtime like this you can disable this globally and just to show you that command just for completion we go under global configuration mode you would simply say no spanning hyphen tree ether channel guard misconfig and that's going to disable this globally but that's really not recommended that you do that this underscores another reason that you should use lacp when setting up an ether channel using dynamic lacp or even p that's typically going to help avoid any issues where you may run into misconfiguration guard putting your interfaces into an error disabled state it's much easier to unintentionally set up our ether channel incorrectly if we're using a static configuration as opposed to using something like dynamic lacp so that's why it's recommended that we use a dynamic protocol such as that so that's a brief look at ether channel load balancing and a look at etherchannel misconfiguration guard i hope you found this content useful and i want to thank you sincerely for watching

Channel: Kevin Wallace Training, LLC

Views: 6,480

Keywords: cisco, networking, ccna, ccnp, ccie, ccna 200-301, enarsi, encor, kwtrain, etherchannel, etherchannel load balancing, etherchannel misconfiguration guard, LACP

Id: E8fTTqi1sdY

Length: 12min 22sec (742 seconds)

Published: Thu Aug 06 2020