Whole Etherchannel goes down when one link lost

Unanswered Question
Feb 12th, 2010

I have etherchannel configured between a 6500 and 2 separate 3750 switches using fibre links.  One Port-channel is configured on 6500 ports gi1/11 & gi1/12 and is trunked with a single vlan allowed.  It is connected to a 3750 with 2 corresponding ports configured in a port-channel.  Another Port-channel  is configured on 6500 ports gi1/13 & gi1/14 and is trunked with the same VLAN as before allowed.  It is connected to another 3750 with 2 corresponding ports configure in a port-channel.  When one of the fibres on the second port-channel is disconnected the whole etherchannel goes down, "show etherchannel summary" shows both interfaces as down.  Channel group mode is "on", presume connected using PAGP.  Why does the whole etherchannel go down, not just the disconnected link?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
jfraasch Fri, 02/12/2010 - 07:56

Can you post the corresponding config.

Post the Port-Channel interface configuration

Post the physical interface configuration on both sides of the port-channel.

That should give a really good idea of what is happening.


francisfox Fri, 02/12/2010 - 08:27

I've attached log sessions for the 6500 & 3750 end sessions with config etc shown. Not sure if the 1st port-channel on the 6500 is relevant but it trunks the same VLAN as the 2nd one.  The 1st port-channel has only one fibre connected and manages to stay up (status D,P). The second port-channel has 2 fibres connected and goes down completely when one of them is disconnected.  I enabled debugging on the 3750 end when disconnecting the fibre. Help is appreciated.

Kevin Dorrell Fri, 02/12/2010 - 07:57

My guess is that you need to check the cabling goes where you think it goes.  Maybe you have the channels cross-linked, which can be quite dangerous, which can lead to network meltdown if you use "on" mode.  For this reason, I prefer not to use "on" mode for such configuration, but rather I use active-active or desirable-desirable.  The switches will then tell you if they are cross-linked, and will not bundle the ports if it reckons they go to different destinations.

It is also a good idea to have UDLD on such topologies, just in case you get the TX and RX crossed.  I know fibres nowadays come in pairs and it is difficult to cross link them, but I do remeber the days when fibre patches were one for the TX and one for the RX.

Kevin Dorrell


glen.grant Fri, 02/12/2010 - 08:26

   I would say it is misconfigured .   It's not using pagp if the channel mode is on .  PAGP is when you let the switch negotiate the etherchannel using the channel-group X mode desirable non-silent"   configure option .   That is one of the problems with "on" mode it can say it working when it might not be working correctly.  A post of the etherchannel SVI  and ports of both sides should reveal any misconfigs. Please post if possible.

francisfox Wed, 02/17/2010 - 09:51

I've attached configs to an earlier reply if you wouldn't mind having a look at it, thanks

Kevin Dorrell Wed, 02/17/2010 - 09:58

I could not see anything wrong in the configs.  Did you check the cabling?

I would strongly suggest you use desirable-desirable rather than on-on.  If you do that, it will tell you immediately if you have your channels cross-connected.  It will also protect you from Spanning Tree failure, which can happen if each end believes it is bundling but in fact is not.

Kevin Dorrell


jfraasch Wed, 02/17/2010 - 10:06

Kevin beat me to it.  The config looks fine.  I would also change to desirable mode.  For LACP I always go Active.

If memory serves, the desirable mode will give you more information with which to troubleshoot anyhow.  I have seen this happen if cables are plugged into the wrong ports and I think there was actually a bug in Cisco IOS that made a etherchannel go down when a link went down.  Check your CDP output to make sure you are plugged into the right ports on each side.

After the above, if you still have a problem capture the log output and put it over here so we can take a look.


francisfox Wed, 02/17/2010 - 10:18

thanks for prompt replies, I'll check this out and get back to you

Reza Sharifi Wed, 02/17/2010 - 10:17

Is there a reason you are using 2 differnt portchannel idea?  you have portchannel 2 on the 3750 and 4 and 5 on the 6500


francisfox Wed, 02/17/2010 - 10:28

If you mean why don't the interconnected port-channel numbers match then this is historic.  Port-channel numbers 1 and 2 were already used on the 500.  I hope I'm right in saying this doesn't matter, but obviously makes it more difficult to understand. This solution BTW is only intended to support a transition period after which the 3750's will be decommissioned (we've all heard that one before !!!!)

Kevin Dorrell Wed, 02/17/2010 - 12:58

You are right ... the channel numbers have only local significance in each switch.

Kevin Dorrell



This Discussion