cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4724
Views
0
Helpful
12
Replies

Whole Etherchannel goes down when one link lost

francisfox
Level 1
Level 1

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?

12 Replies 12

jfraasch
Level 3
Level 3

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.


James

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
Level 10
Level 10

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

Luxembourg

glen.grant
VIP Alumni
VIP Alumni

   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.

I've attached config for this issue, see above

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

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

Luxembourg

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.


James

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

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

Reza

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 !!!!)

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

Kevin Dorrell

Luxembourg

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: