Ping drop

[grapevine]

We have a stack of three Cisco IE switches with no other switches connected to the stack.

There are two Palo Alto firewalls connected to the stack using LACP EtherChannels:

• FW1 is connected to SW1 and SW3 as an LACP Port-Channel.

• FW2 is connected to SW2 and SW3 as an LACP Port-Channel.

During testing:

• Removing SW1 from the stack when active results in only one ping drop.

• Removing SW2 from the stack when active also results in one ping drop.

• However, removing SW3 causes more than 20 consecutive ping drops.

While investigating, I noticed Spanning Tree topology changes occurring when SW3 is removed.

Since there are no downstream switches connected to the stack, I'm trying to understand why only the removal of SW3 triggers multiple topology changes and extended packet loss, whereas removing SW1 or SW2 does not.

Has anyone encountered this behavior before or have any ideas on what could be causing it? Any suggestions on what to check would be appreciated.

[mloraditch]

Do the Palo Alto logs show anything different between when SW3 is removed vs SW1 or SW2? Based on your topology, removing SW3 kills a link on both PAs at once. I suspect something is renegotiating in that instance that doesn't happen when you just pull SW1 or SW2.

[Joseph W. Doherty]

Is SW3 the active master?

Is your stack also configured not to change the stack's MAC if there is a stack master failure?

BTW, it's often helpful if you identify the specific switch models and the IOS version being used.

[Giuseppe Larosa]

Hello @grapevine ,

first of all check who is the master in the stack with

show switch

as suggested you should implement MAC address persistency so that also in case of change of master there are no impacts also in STP.

Hope to help

Giuseppe

[Joseph W. Doherty]

@grapevine as you haven't answered my questions, cannot with high assurance answer your questions.  However, what I suspect (likely so does @Giuseppe Larosa ) there can be a noticeable difference in operational impact between a non stack member failing vs. the stack master failing.  The latter, i.e. a stack master failure, can be more impactful, as it's the operational brains of the stack.

One issue, on many stacks, if the stack master fails, by default, the stack uses a new MAC for stack operation.  However, there's often a configuration option to retain the original stack MAC even when the stack master fails.  This often mitigate the impact of a stack master failure.

BTW, if the stack is being used for L3 operation, there are are often (?) other configuration options to minimize the impact of a stack master failure for those too.

Again, though, as you didn't answer my questions, cannot say with much certainty the cause of the behavior you note, but I can say, from experience, loss of a stack master can be more operationally impactful, especially if you've not configured the options to mitigate its impact.