03-14-2023 10:02 AM
Hello, I am trying to figure out the behavior of something but having some difficulty getting a conclusive answer. We have 4 ports connecting two Catalyst switches connected via an LACP etherchannel. Yesterday, someone mistakenly misconfigured one of the ports as an access port, changing it from trunk. This brought that one link out of the etherchannel to an up/down state at which time multiple devices on the network experienced connectivity issues -- presumably because of the etherchannel load balancing, their link went down while other devices continued using the other 3 links without issue. Am I correct in thinking that? If so, would those devices that lost connectivity ever recover automatically? I would assume they should have recovered almost immediately, but such was not the case. Is there some kind of stored load-balancing table with a timeout? Was the MAC Address table still pointing to the etherchannel interface for things so after 5 minutes the stale entry would time out and connectivity would be restored? In our case, I was immediately notified of the erroneous change and reverted the interface back to a trunk which corrected the issue, but I'm curious about the details. Thanks!
03-14-2023 10:14 AM
Although there isn't a table, Ether channel totally can automatically redistribute traffic over the remaining ports that are up! It can use various factors to determine which traffic belong to a certain stream to provide load balancing such as source and destination ip or mac address. You are correct in your assumption totally!
03-14-2023 10:31 AM
What is supposed to happen is if one link fails on one side (configured as access by mistake in your case) then the other side should detect it and take the port out of the bundle. If that did not happen and traffic continued to forward on the bad link because the other side thought it was still up then yes traffic would be lost. What you can do is re-create the problem and see if the other side removes the link from the bundle. If not then there could be corner cases where the remote side doesnt see when a port is misconfigured to remove the link
-David
03-14-2023 10:58 AM
03-14-2023 01:24 PM - edited 03-14-2023 01:24 PM
To be fair...I would not trust packet tracer to be accurate in any sense when it comes to deeper understanding of protocols. I've spent countless hours on LACP in Packet Tracer trying to figure out why it wasn't working according to documentation I have read. You best bet is to re-create it on your network as that's where the issue happened. Preferably not during work hours as its a live network. I would schedule it.
03-15-2023 07:48 AM
Yes, very true. Unfortunately, Packet Tracer isn't the best option to gauge correct behavior as I've seen plenty of weird things with it. I guess at this time it's sort of a mystery as to why this happened. It's a bit disconcerting that one side may have thought the port was still bundled but the other didn't. I can only hope STP was blocking the port on the side it didn't. Though, in crisis mode, I didn't have chance to poke around to settle my curiosity! Thank you for your insight.
03-15-2023 01:30 PM - edited 03-15-2023 02:22 PM
connectivity issue is happened is other protocol detect this link failed faster than the LACP.
let me share with you story,
years ago, I am in home and read some book, (I read book alot), anyway, I reach point we know the hash and it effect of selection of link for forwarding data traffic between two Peer.
but what about STP, CDP .... which link both peer will use??
there is no right answer until now I found, so I assume that both Peer agree on one link, and if this link is down then some protocol like STP is enter into election process even if there are three other link is UP. this because the timeout of LACP is long around 90 sec.
good story LoL..
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide