Cisco IE 9320 stack testing

[grapevine]

We have a stack of 3 IE 9320 switches connected. We tested by powering off each switch and how the end device behaves. While powering off, we see one ping drop and while switch is powered back and then when it gets added to the stack we see intermittent drops, is there a way to mitigate this or is this expected

[balaji.bandi]

Not that I think that is expected behaviour (then that is not called high availability)

How does your configuration look - you may tweak 

stack-mac persistent timer 0

switch <member-number> priority 15 

switch <member-number> priority 14  so on

Make sure the stack ring is full and no errors :

show switch stack-ports summary

Check some guidelines of stacking :

https://www.cisco.com/c/en/us/td/docs/switches/lan/cisco_ie9300/software/17_7/ie93xx-stacking-ha-config.pdf

alternative options

https://www.cisco.com/c/en/us/td/docs/switches/lan/cisco_ie9300/software/17_7/redundancy-protocol-config-ie93xx/m-hsr-ie9300.html#high-availability-seamless-redundancy

[Joseph W. Doherty]

Were you pinging the switch itself or pinging through the switch?

Also, assuming you were testing a cycling of each individual stack member, same behavior on all of them?  (This question because a stack master failure can be more impactful.)

[Cristian Matei]

Hi,

    Not related to your described problem per say, however ensure you manually dictate which switch is the stack active by configuring a higher priority on one of the switches, via command switch X priority ABC, where higher value for ABC means higher priority in being elected the active switch.

   For sure you would want to ensure your stack MAC address never changes, regardless how many switches are still up and running, by using command stack-mac persistent timer 0. This could be related to your seen behaviour, depending on configuration and physical connectivity, ad even if it's not, this setting adds value without any compromise or risk.

   If you use REP, enable REP Fast Mode: https://www.cisco.com/c/en/us/td/docs/switches/lan/cisco_ie9300/software/17_7/redundancy-protocol-config-ie93xx/m-rep-ie93xx.html

  If you use STP, ensure to use RSTP and that your non inter-switch links are configured as PortFast.

  Perform these actions, repeat the test and see the results. I results are the same, can you share a basic logical topology, explain from which source you're pining which destination (where is the source physical located as well as the destination), provide a sanitized stack configuration to take a look at.

Thanks,

Cristian.

[Joseph W. Doherty]

For sure you would want to ensure your stack MAC address never changes, regardless how many switches are still up and running, by using command stack-mac persistent timer 0. This could be related to your seen behaviour, depending on configuration and physical connectivity, ad even if it's not, this setting adds value without any compromise or risk.

"stack-mac persistent timer 0" was also mentioned by @balaji.bandi and totally agree it should be configured, and also, too, unaware of any negative to using it.

I might add, though, (I believe) it only is useful if the stack master switch fails.

Also BTW, at least back in the 3750 stack days, if switch was running L3, NSF required additional configuration.  Otherwise, again with a stack master failure, there could be an impact to L3 forwarding.

Lastly, both @Cristian Matei and @balaji.bandi (and Cisco too) also mention assigning stack priorities.  As far as I know, it doesn't reduce the time it takes for a stack master election, although it can very much determine what switch is elected (which raises the question which switches are best to be stack master - I recall the 3750 recommendation was least busy switch - personally, IMO, if I need to consider that, maybe I shouldn't be using that particular family of switches).

[paul driver]

Hello
Just like to add a word of caution regards using stack-mac persistent timer 0. , this indeed is a useful feature however using it could potentially open up a future possible cause for network outage within your network having set an infinite value.

They may be a reason for a switch member is removed from a stack and sometime later its reused elsewhere on the same network, if in its stack life that switch was the master at some point and the stack-mac persistent timer was set to an infinite value against its base mac-address,  even when that switch is removed the switch stack will continue to use that switches mac address indefinitely.

Now if at some point that removed switch is reintroduce into the same network, Just by a simple oversight in which its forgotten an existing switch stack is using an infinite base mac-address of switch due to be reused within the same network it originally came from, A conflict will be incurred between itself and its original stack causing a lot of network disruption

I would say if you wish to use this stack-mac persistent timer specify a value other then 0 unless you are 100% certain of its use against the hardware it is applied to

[Joseph W. Doherty]

I would say if you wish to use this stack-mac persistent timer specify a value other then 0 unless you are 100% certain of its use against the hardware it is applied to

An issue with that, it creates the same impact as not using that feature at all, now just deferred.  However, if used as a deferral to provide time to schedule stack reset, then it could be very useful!

Regarding use of this feature causing problems due to MAC conflict, yes, agreed, a conflict is possible but multiple variables, likely, decrease the probability of encountering such conflict.  Conversely though, with a decreased probability of bumping into such a conflict, it may be more likely you'll scratch your head wondering what-the-heck is wrong.

What are some of those variables?

Only the initial stack master, that failed, would conflict with its prior, still running stack, using the initial stack master's MAC, if both are in a shared L2 domain and the initial stack master is just itself or the stack master of another stack.

A potentially "easy" way to bump into this conflict is if a running stack's ring is broken forming two stacks, but even without the persistent MAC conflict, partitioned stacks, being two of the same logical device, usually cause issues.

So, although @paul driver's point is excellent, I think it's unlikely to be encountered.  But, the best usage case, again, might be a timer that allows sufficient time for an emergency stack reset at the the least disruptive time.