Does an EtherChannel REALLY redirect traffic from a failed link to the remaining links in the channel without intervention?

[richard.thomas]

Hi All,

The reason for my question is that while studying Etherchannels for my CCNP switch exam, I simulated this scenario using Packet Tracer and noticed no traffic redirection.

Now I realise this was simulated but unfortunately I don’t have any real equipment to test this out on. Can anyone confirm if an EtherChannel does redirect traffic from a failed link to the remaining links in THE REAL WORLD?

To demonstrate what happened please see the setup I simulated below:

• Two switches back to back connected together with 4 links comprising the EtherChannel
  
• Both switches configured for source MAC address load balancing across their respective EtherChannels.
  
• A PC connected to each switch with the last Hex digit of their MAC addresses deliberately configured to pre-determine the EtherChannel link used for intercommunication.
  
• A constant PING sent from one PC to the other
  

I chose this setup in order for the Hash algorithm to generate the same 3 bit hash result on both switches and therefore allow the same link to accept distribution of the ICMP packets sent from the PC’s.

Packet Tracer confirmed the link was indeed the link I pre-determined.

Next....

With the PING between the PC’s still running successfully, I deliberately failed the Etherchannel link they were using and noticed the PING constantly fail thereafter. It seemed clear to me that the ICMP traffic was not redirected at all, to any of the remaining operational channel links.

Now, in a way I can understand why it wouldn’t redirect the traffic because the Source MAC addresses have already been hashed and the links have already been assigned specific hash values they accept. So, once the link failed, none of the remaining links could accept that particular Hash value.

This is of course me speculating why I might be seeing this. What I really need to know is what happens in the real world.

Is it for example, simply a case of the remaining links adjusting what hash values they can accept when a link fails, therefore allowing traffic to continue to flow?

If anyone has got real world experience of this and knows what happens on real equipment, I would really appreciate your help.

Many thanks..

[Somasundaram Jayaraman]

Hi,

Fast EtherChannel allows multiple physical Fast  Ethernet links to combine into one logical channel. This allows load  sharing of traffic among the links in the channel as well as redundancy  in the event that one or more links in the channel fail. Fast  EtherChannel can be used to interconnect LAN switches, routers, servers,  and clients via unshielded twisted pair (UTP) wiring or single-mode and  multimode fiber.

When one link fails, all traffic that previously  used that link now uses the link next to it. For example, if Link 1  fails in a bundle, traffic that previously used Link 1 before the  failure now uses Link 2.

The Cisco-proprietary hash algorithm computes a  value in the range 0 to 7. With this value as a basis, a particular  port in the EtherChannel is chosen. The port setup includes a mask which  indicates which values the port accepts for transmission. With the  maximum number of ports in a single EtherChannel, which is eight ports,  each port accepts only one value. If you have four ports in the  EtherChannel, each port accepts two values, and so forth. This table  lists the ratios of the values that each port accepts, which depends on  the number of ports in the EtherChannel:

Number of Ports in the EtherChannel	Load Balancing
8	1:1:1:1:1:1:1:1
7	2:1:1:1:1:1:1
6	2:2:1:1:1:1
5	2:2:2:1:1
4	2:2:2:2
3	3:3:2
2	4:4

Pls refer the below link for more details about etherchannel.

http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtml#ioscat4k

Hope this helps

Cheers

Somu

Rate helpful posts

[richard.thomas]

Hi Somasundaram,

Thanks for your reply.

I've already read and understand what an EtherChannel is SUPPOSED to do on link failure and also understand the load balencing ratios when setting up an EtherChannel with 2 links, 3 links, 4 links etc....

All I was doing was proving the concept works using Cisco's Packet Tracer simulator.

Put another way, I wanted to  "prove it does what it says on the tin?"

What I was more interested in was traffic redirection on link failure. I understand that it is SUPPOSED to redirect traffic to its remaining links but this did NOT happen in the simulation.

I guess what I'm really asking here is, is what I'm seeing just a Packet Tracer simulator issue that doesn't happen in the real world?

Hope this is a bit clearer!!!

Many thanks...

[Somasundaram Jayaraman]

Have you tried with GNS3 simulator? In real switches when we shut one of the ports in etherchannel, the traffic will flow through the other one.

And in the show etherchannel summary, you will see the interface which is shutdown as (D) status.

for example let us consider Gi 0/1 & Gi 0/2 are the interfaces in port-channel 1

when Gi0/1 is down, the show etherch summary output would be Gi 0/1 (D) Gi 0/1 (P)

Also you can check this command as well.

show port-channel loadbalance ---> will show the port-channel loadbalance method used.

then using the output of port-channel loadbalance, issue the command,

test etherchannel load-balance

You can see by giving source mac, destination mac in the above command to see which interface it will take if the packet matching the above criteria arrived on the port-channel.

Hope this answers your questions

Cheers

Somu

[richard.thomas]

Hi Somasundaram,

Sadly, GNS3's simulation gives an even more bizarre load sharing outcome even before failing a link. It ended up performing a round robin across the links for frames with just one source MAC address which goes against all the load sharing principles for EtherChannel. Hence, this was completely unreliable to prove the concepts.

Again, sadly, Cisco Packet Tracer does not include the "test etherchannel" command, as I already tried that.

What is interesting however is what you said " In real switches when we shut one of the ports in etherchannel, the traffic will flow through the other one."

Do you happen to know if the same is true when one of the ports goes down naturally due to loss of carrier signal ?

( as opposed to administrively "shutting" the port)

Have you seen this happen?

Again, many thanks.....

[richard.thomas]

Sorry, I should have stated from the start - This is with regards to Cisco's PAgPprotocol - NOT Lacp.

Again, if anyone has any more info to add, it will be much appreciated....

Thanks..

[Peter Paluch]

Richard,

Packet Tracer is fine for practicing commands to get fluent in configuration, but is not so well suited for detailed exploring how a particular protocol or mechanism works.

Regardless of LACP or PAgP, if a port is detected as unusable - disconnected, shut down, errdisabled, or if the remote peer stops sending LACP or PAgP PDUs, that port will automatically be separated from the EtherChannel bundle, and will remain in that state until it becomes fully operational again and the LACP/PAgP messages are heard over it again (that last step is naturally skipped if using the on mode).

Neither PAgP nor LACP influence how the load balancing is performed on an EC bundle. That is always hardware-dependent, and may even be performed differently on each side of an EC bundle.

Somu, sorry for breaking into this discussion so abruptly. Please do add your comments!

Best regards,

Peter

[Richard Michael]

Hello Richard,

what is the IOS version/switch or router model that you are using in GNS3 or the packettracer?

In switch the load balancing by default is flow based every flow is hashed and sent through one specific physical port in the bundle. It would definetly flip the flow to the other working ports,  if there is a link failure happens due to the loss of the carrier signal.

It would be better if you could use some test bed switches to check  etherchannel instead with these simulators

Thanks,

Ricky Micky

*Pls rate useful posts

[richard.thomas]

Packet Tracer v5.3.2.00.27

Cisco IOS Software, C3560 Software (C3560-ADVIPSERVICESK9-M), Version 12.2(37)SE1, RELEASE SOFTWARE (fc1)

Switch#sh etherchannel load-balance
EtherChannel Load-Balancing Configuration:
src-mac

EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Source MAC address
IPv4: Source MAC address
IPv6: Source MAC address

Guy's

I think from everything that you've said, my suspicions about using a simulator to prove the concept are founded. I thought it was odd behaviour. I guess thats the danger of using simulators!!!!

So I think in conclusion, what we are saying here is in the real world, traffic IS redirected to an Etherchannels remaining links when a link failure occurs.

How it actually does this internally with what the remaining ports accept as revised hash values, I guess doesn't really matter. There must be some internal logic going on somewhere!!! That's just me being curious.

Thanks again guy's.

I appreciate your help.......

[ajtheguy]

I encounter the same problem in GNS3 2.1 with VIRL IOSvL2 15.2.  The traffic( HSRP Hello multicast) hashed to one of the EtherChannel link (G0/1) didn't fail over to other remaining EtherChannel links (G0/2) when I shut down the G0/1 interface on A side switch.  

It turns out by using 'show EtherChannel sum', it proves it's because the B side switch EtherChannel still think the link (G0/1) is UP and continue to sending traffic to it, black holes the traffic, it's kinda like ASIC failure case in the real world I have seen.  That's because software simulation has no way to simulate the real world scenario detect the link down by sending the loopback test signal.

Once I shut down the B side switch G0/1 interface. The traffic started to get redirected to the remaining link (G0/2) as it supposes to.