Wired Intelligent Edge

I have two 5412r in their default configuration. I enabled VSF by the following command (via console on the switch which should be the physical core1):

vsf member 1 link 1 j1

vsf member 1 link 2 l1

vsf enable domain 1

The physical core2 resets and becomes part of the VSF stack as member 2.

I adjusted priority on physical unit 1 to 255 instead of 128.

I see the message standby booting once i remove j1 and l1 cabling on unit 1. Is member 2 actually rebooting?

Shouldn't the second unit think "i am now commander", or shouldn't both units be thinking this? Instead of the secondary unit rebooting?

Or is this purely because of priority i set?

I thought they both would get in a split brain scenario, where both are taking the role of commander.

Just attached the console to physical unit 2, and disconnected j1 and l1 on this side. Then re-attached.

I see unit 2 does in fact do a reboot.

I have no other switches/devices connected to unit 2 yet, but i am assuming on a link failure of j1 and l1, all equipment connected on unit 2 will also loose connectivity until unit 2 is rebooted?

Greetings!

The expected behavior if the VSF link goes down (either due to cable removal or disabling all interfaces in the link), with no multi-active detection (MAD) mechanism configured, would be the split-brain scenario you described where both members would act as the commander of their respective fragments.

When the VSF link is brought back up, the member with the highest priority (or the previous commander, if both members have the same priority) merges the standby with the stack, triggering a reboot of the standby (as any configuration changes on the standby switch that occurred after the split must be replaced by the VSF commander's configuration).

With regard to loss of connectivity for devices on member 2 when the VSF link goes down: if both VSF members have redundant uplinks, and no MAD mechanism is configured, devices on member 2 may retain connectivity to network resources during a VSF split — this would depend on your topology, whether or not the VSF stack was using IP routing, or other network conditions.  That being said, we strongly recommend configuring a MAD mechanism such as OOBM-MAD to prevent potential issues (duplicate IPs, routing problems, etc) if a split were to occur.

I will verify on the second member if it thinks it's active as well.

VSF member priority – default value is 128; configurable; Member priority determines the possibility of a member device to be elected the Commander. A member with higher priority is more likely to be elected the Commander.

-> What determines the commander role election? Is it based on MAC address if prio is the same? I see the term "more likely" used, which doesn't give me much confidence that it will become commander even if i give it a higher priority. If VSF member 1 with prio 255 goes down, VSF member 2 with prio 128 takes over. Will VSF member 1 take the Commander role again once it returns back online due to prio 255? Will in turn, unit 2 be rebooted again since it became the Standby again?

My scenario would be replacing the L3/SVI functionality of the current 5400zl switches running VRRP, with the single VSF chassis. The firewalls and WAN connectivity are connected on both switches at this moment.

I will look into the MAD configuration.

Is there a good documentation/drawing, of how traffic flows from a distribution switch for example, connected to a VSF core? When the distribution switch is stacked and has one logical port channel connecting to the cores. Will it load balance traffic on both physical links to the core, or?

In your scenario (member 1 with priority 255 goes down, member 2 with priority 128 becomes new commander), member 1 will retain the standby role when it comes back up, rather than taking over immediately as the commander. This behavior is intentional, as triggering a commander election causes whichever switch is designated the new standby to reboot and sync config/firmware with the commander, which would result in additional downtime for devices connected only to that switch.

With regard to member priority determining the outcome of a commander election: in cases where a split stack has occurred and two active members are reconnected, or if both VSF members reboot at the same time, the member with the higher priority should always become the new commander. If both members have the same priority, the one with the lowest MAC address (as you suggested) becomes commander. Whereas, in a failover situation (as described above), the former standby becomes the new commander, and retains that role when the other member (the new standby) recovers. 

I will look into traffic flow diagrams for trunked uplinks/downlinks from a VSF stack.

Thanks.

We have the situation where the current primary firewall is connected to Core1 and active (secondary standby firewall connected to Core2).

And if i wanted to do the same on the VSF stack, would it make most sense to hard code the priority of VSF member 1 higher than member 2?

In a failover scenario as described earlier we would have to failover back to member 1 by hand. We do this for the firewall as well (no pre empt). So the only impact in this case is single connected switches to member 2 losing their uplink for a brief time?

Keep in mind that the role of commander/standby does not necessarily imply that traffic forwarding is prioritized on one switch or the other — that is still determined using the normal forwarding/routing tables based on your configuration.

That said: if a stack split occurs with MAD configured (which we recommend), the standby member will shut down all interfaces, which — for any devices with redundant links to both VSF members — will force all traffic to be forwarded through the commander.  This would be a situation in which you would want to set a higher VSF priority on member 1, and ensure that it is the commander by manually initiating a failover (using the reload command) if member 2 ever assumes the role (obviously, you would want both members to be up with no VSF synchronization in progress before doing so). This would, as you noted, cause all links on member 2 to go down for the amount of time it takes for the switch to reboot.