Good afternoon -
We have two 3750X switches stacked using Stackwise. From a downstream device we have a running ping going across the stack - as part of our testing we have pulled the power cables to simulate the loss of the master switch in the stack. Our assumption was there would be no packet loss from the downstream device when the switch stack fails down to a single switch. However we are dropping 2 pings during this failure.
switch 1 provision ws-c3750x-24
switch 2 provision ws-c3750x-24
stack-mac persistent timer 0
We have switch 1 priority 15 and switch 2 priority 1 and both are showing Ready as their current state
Is there anyway to configure the stack to fail without any packet loss? We are also running ip routing and running as a Layer 3 device.
We were pinging across subnets correct
We are running NSF IETF
There is a theory that the 8 second outage is to be expected, based on Cisco documentation, because we are running at Layer 3. I am trying to find this documentation as to report the behaviour is expected and by design.
I have not seen it directly my colleague believes he has read this is normal.
I have found the following that does not indicate 100% uptime, only 'greater resilency' but does not indicate how long, or if any, L3 outage will occur during a Master stack failure
RPR+ for Layer 3 resiliency - Each switch is initialized for routing capability and is ready to be elected as master if the current master fails. Subordinate switches are not reset so that Layer 2 forwarding can continue uninterrupted. Layer 3 Nonstop Forwarding (NSF) is also supported when two or more nodes are present in a stack.
Forwarding Resiliency During Master Change
When one master switch becomes inactive and while a new master is elected, the stack continues to function. Layer 2 connectivity continues unaffected. The new master uses its hot standby unicast table to continue processing unicast traffic. Multicast tables and routing tables are flushed and reloaded to avoid loops. Layer 3 resiliency is protected with NSF, which gracefully and rapidly transitions Layer 3 forwarding from the old to new master node.
Several things come to mind. Have you tried enabling console logging and logging into the priority 1 switch to see what is actually happening during the power transition? Is the delay in the master re-election process where the secondary switch realizes that the primary switch has gone off-line or is the delay in the routing protocol recovery? That's the question. Is the target of your pings a SVI in another subnet on the 3750 stack or is it a host in another subnet downstream of the stack? What mode is spanning-tree running in?
Sent from Cisco Technical Support iPhone App
I will check the console logging and see what is occuring. We are pinging across the stack to upstream devices yes. We are running RSTP+.
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.
In no event shall Author be liable for any damages whatsoever (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.
With RPR+, yes there likely will be an interruption. However, with NSF (non stop forwarding), there really shouldn't be an interruption, or very little. Perhaps much depends on Cisco meanings of "... which gracefully and rapidly transitions Layer 3 forwarding ...".
What IOS version are you running?
Speaking with some consultants (CCIE level) they believe if we have multiple running pings to different destinations only some of them would fail and this is expected behaviour. I still believe the whole 'point' of stacking with NSF configured at L3 is to ensure no packet loss. We have the following configured:
port-channel load-balance src-dst-ip in the
Which may or may not be relevant