Wired Intelligent Edge

I had a 2-member switch stack go offline after the secondary member had a power failure.  I had forgotten to disable split-detection which should've kept the primary in it's current role instead of changing to a linecard.  The user guide does a good job of explaining what happens in my scenario when split detect is disabled:

When your ArubaStack has only two members, best practices recommends that you disable the split detection feature to ensure
that the Primary does not transition to a dormant state if the Secondary is powered down.

My question is what happens if it's the primary that suffers a failure rather than the secondary.  Will the secondary change its role to a line card to avoid a loop, or will it become primary?

Okay, cool.

Last thing.  Trying to disable split detection and I get the following message:

ERROR! Cannot disable split detection with preset stack config.

What am I doing wrong?

Jay,

The error message is indicating that there is a conflict with preset/preprovisioned stack configurations (e.g. member-id 1 serial-number AU00006600) as opposed to election based stack configuration (member-id 1 election-priority 255). Let me look into it.

Best regards,

Madani

Thanks Madani.  I'd like to set election priorities as well for predictable primary selection, but I get a similar message:

ERROR! Clear any pre-provisioned profile, before configuring election priority for a member.

Hope we can take care of both issues with whatever you find.

Jay,

Can you send me the output of "stack-profile"?

Best regards,

Madani

PM sent.

Jay,

I got the message and per the configuration you have both your members configured for primary-capable which is good.

If you decide to transition to election-priorities, my recommendation is to always set your primary and secondary to an election priority of 255 (maximum) to avoid pre-emption. Setting 255 and 254 (or any lower number for the secondary) for the primary and secondary respectively is not ideal in my opinion because it causes an unnecessary switchover when the primary fails, secondary takes over but then primary returns.

Now to take out preset, just do the 'no' versions of the commands for your member-id 0 and 1, then add the following:

member-id 0 election-priority 255

member-id 1 election-priority 255

Again my preference is to have both primary and secondary has the same priority but if you're alright with preemption, set your secondary to a lower value like 254.

Then the last step would be to add "no split-detection".

Best regards,

Madani

Thanks for the reply.

I may be misunderstanding some of the concepts here.  My intent was to make sure that member 0 is always primary.  I was going to use an election priority of 255 for member 0 and default for member 1.  If you're suggesting that they should both be 255, then will that not defeat the purpose of setting up an election?

If preemption were to occur and it was not performance impacting that would be fine since I always want member 0 to be primary.  Ideally, if member 0 fails, member 1 should take over without any interruption to switching/routing.  Once member 0 comes back online, it should transition back to primary and member 1 to secondary.  Can this be accomplished?  Alternatively, if I could manually transition member 0 back to primary at a scheduled time, I would do that if it were service impacting.

Jay,

Comments/answers inline.

I may be misunderstanding some of the concepts here.  My intent was to make sure that member 0 is always primary.  I was going to use an election priority of 255 for member 0 and default for member 1.  If you're suggesting that they should both be 255, then will that not defeat the purpose of setting up an election?

Let me break this question in two parts, the first is if you absolutely want one member to always be primary as long as it is active, then yes set it to 255. If there is a particular member you want to always be secondary as long as the primary is active, set it's value to 254 or below. I would not necessarily set it to 1 primarily being that by default the value is 128, so any subsequent switch that is added would become the secondary so set it to at least 129 but I typically would just go one step below the primary.

For the second part, setting both to 255 does not necessarily defeat the purpose of the election, in fact it guarantees that these two switches irrespective of any switches that are later added to the stack will not become Secondary switches. Now in a two member stack that will always be until the end of time a two member stack, you're right setting both to 255 won't favor one switch over the other. More on that in your second set of questions.

If preemption were to occur and it was not performance impacting that would be fine since I always want member 0 to be primary.  Ideally, if member 0 fails, member 1 should take over without any interruption to switching/routing.  Once member 0 comes back online, it should transition back to primary and member 1 to secondary.  Can this be accomplished?  Alternatively, if I could manually transition member 0 back to primary at a scheduled time, I would do that if it were service impacting.


Preemption is performance impacting. Today, hardware state is synchronized between the primary and secondary switches however protocol state is not. So in the case of STP or OSPF we have to reconverge which can cause a brief break in forwarding. Regarding manually transitioning primary/secondary, you can actually do this though not on a schedule. The command to do this is "system switchover force".

Best regards,

Madani

Thanks for the info!

If preemption is performance impacting, why not make it a configurable option?  If preemption could be disabled, I could configure the primary at 255 and secondary at 254 without concern of the primary automatically taking back over.

Sorry, one last question.  If preemption would cause both L2/L3 protocols to reconverge, would a failure of the primary cause reconvergence to occur when the secondary becomes primary?  I never thought to test this behavior before deploying stacks. :smileylol:

Jay,

Since all models of S2500/S3500 share the came control plane architecture, there really isn't a technical reason to favor one switch as primary versus another switch as secondary or visa versa. Both can handle the job equally well which is why a knob doesn't exist. What is your specific use case? There are definitely reasons to identify which are primary/secondary versus line cards to account for things like split stack handling but otherwise I haven't ever come up with one where one switch is better at primary versus it's secondary.

Protocol restart and therefore reconvergence will occur anytime a new primary takes over (e.g. primary fails, primary returns and resumes stack responsibility)

Best regards,

Madani