cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
837
Views
0
Helpful
6
Replies

Cisco 3750 Stacking - Member Change to Master state

PutmanoAIT
Level 1
Level 1

Dear All,

We have two Cisco Catalyst 3750X as Core Switch that are stacking together and we have some ASWs are connected to the Core Switch through the ether-channel across stack in purpose of more bandwidth and redundancy. It seem work smoothly by test unplug the up-link cables one by one. There is no any interrupt. Yesterday we had power off the master switch for maintenance the UPS. We thought that the member switch will be the master without any interrupt the connectivity. Unfortunately when we turned of the master switch, the member switch spent around 8 - 10 timeout to make the connection back. Then we see the log in member switch all of the interface VLAN is shutdown then back that why it spent about 8 - 10 timeout. I'm not sure it's the normal activity of stacking or not. However in Cisco document said it spend around 2 second.

Anybody have any suggestion?

Thanks.

Best regards,

Mano

2 Accepted Solutions

Accepted Solutions

Leo Laohoo
Hall of Fame
Hall of Fame

We thought that the member switch will be the master without any interrupt the connectivity. Unfortunately when we turned of the master switch, the member switch spent around 8 - 10 timeout to make the connection back. Then we see the log in member switch all of the interface VLAN is shutdown then back that why it spent about 8 - 10 timeout.

I have never seen a behaviour like that before. 

Normally when the master switch goes down, the secondary immediately takes over.  The downstream clients, when dual homed, won't see anything.  

The management, however will see ping drops and this is to be expected.  The downstream clients should NEVER have any issues and data traffic should continue to flow (if etherchannel is configured properly). 

View solution in original post

Oh cr@p-on-a-stick!

The entire stack is running on a rubbish IOS!

I wouldn't be caught dead with a switch running 12.2(58)SE train.   

View solution in original post

6 Replies 6

Leo Laohoo
Hall of Fame
Hall of Fame

We thought that the member switch will be the master without any interrupt the connectivity. Unfortunately when we turned of the master switch, the member switch spent around 8 - 10 timeout to make the connection back. Then we see the log in member switch all of the interface VLAN is shutdown then back that why it spent about 8 - 10 timeout.

I have never seen a behaviour like that before. 

Normally when the master switch goes down, the secondary immediately takes over.  The downstream clients, when dual homed, won't see anything.  

The management, however will see ping drops and this is to be expected.  The downstream clients should NEVER have any issues and data traffic should continue to flow (if etherchannel is configured properly). 

Dear Leo,

Thanks for your answer. 

For ether-channel I configured mode LACP between Core and Access. It seem work fine when I tested by unplug one by one up-link cable, there is no any interrupt.

As I noted after the master switch down all interface VLAN change to down state and back after 30 seconds. 

*Oct 9 13:47:27.801: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan200, changed state to down
*Oct 9 13:47:27.801: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan250, changed state to down
*Oct 9 13:47:27.801: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan400, changed state to down
*Oct 9 13:47:28.456: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0, changed state to down
*Oct 9 13:47:29.412: %LINK-5-CHANGED: Interface GigabitEthernet2/0/4, changed state to administratively down
*Oct 9 13:47:29.496: %LINK-3-UPDOWN: Interface Port-channel1, changed state to down
*Oct 9 13:47:29.496: %LINK-5-CHANGED: Interface GigabitEthernet2/0/5, changed state to administratively down
*Oct 9 13:47:29.571: %LINK-3-UPDOWN: Interface Port-channel2, changed state to down
*Oct 9 13:47:29.571: %LINK-5-CHANGED: Interface GigabitEthernet2/0/6, changed state to administratively down
*Oct 9 13:47:29.655: %LINK-3-UPDOWN: Interface Port-channel3, changed state to down
*Oct 9 13:47:30.427: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/4, changed state to down
*Oct 9 13:47:30.503: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/5, changed state to down
*Oct 9 13:47:30.586: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/6, changed state to down
*Oct 9 13:47:32.021: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/4, changed state to down
*Oct 9 13:47:32.021: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/5, changed state to down
*Oct 9 13:47:32.029: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/6, changed state to down
*Oct 9 13:47:34.932: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/6, changed state to up
*Oct 9 13:47:34.974: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/4, changed state to up
*Oct 9 13:47:34.982: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/5, changed state to up
*Oct 9 13:47:40.737: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/4, changed state to up
*Oct 9 13:47:41.206: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/5, changed state to up
*Oct 9 13:47:41.257: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/6, changed state to up
*Oct 9 13:47:41.693: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up
*Oct 9 13:47:42.171: %LINK-3-UPDOWN: Interface Port-channel2, changed state to up
*Oct 9 13:47:42.221: %LINK-3-UPDOWN: Interface Port-channel3, changed state to up
*Oct 9 13:47:42.700: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to up
*Oct 9 13:47:43.178: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel2, changed state to up
*Oct 9 13:47:43.228: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel3, changed state to up
*Oct 9 13:48:09.761: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan2, changed state to up
*Oct 9 13:48:09.761: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to up
*Oct 9 13:48:09.761: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan20, changed state to up
*Oct 9 13:48:09.912: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan30, changed state to up
*Oct 9 13:48:09.912: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan40, changed state to up
*Oct 9 13:48:09.912: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan50, changed state to up
*Oct 9 13:48:09.912: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan70, changed state to up
*Oct 9 13:48:09.921: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan80, changed state to up
*Oct 9 13:48:09.921: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan90, changed state to up
*Oct 9 13:48:09.921: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan120, changed state to up
*Oct 9 13:48:09.921: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan200, changed state to up
*Oct 9 13:48:09.921: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan250, changed state to up
*Oct 9 13:48:09.929: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan400, changed state to up

Post the complete output to the command "sh version".

Here is the show version of switches

Oh cr@p-on-a-stick!

The entire stack is running on a rubbish IOS!

I wouldn't be caught dead with a switch running 12.2(58)SE train.   

Joseph W. Doherty
Hall of Fame
Hall of Fame

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

As you mention using MEC and SVIs, you might have seen an issue related to the default configuration using the master's MAC.  Are you using the command stack-mac persistent timer 0?