Wired Intelligent Edge

Hi all,

I read that VSF does not support redundant MMs - is this still true? I cannot find anything like that in the current manuals.

We are designing for two datacenters on a campus and would like to use two 5406R with rMM and create an VSF between these Switches to simplify e.g. routing configuration.

Thansk for reading

Oliver

Greetings!

5400R VSF pairs can operate with redundant management modules in each member; however, the second (standby) module in each chassis will be in a shutdown state. In the event of a failure of the active management module, the VSF member will reboot, at which point the standby module will take over and the failed module will be shutdown (if it isn't already as a result of the failure).

This will allow the VSF fabric to continue operating with minimal traffic interruption, and the failed module can be replaced without taking the affected chassis out of service for an extended period. 

Greetings! I hope not to hijack this thread but, given explanation provided by Matthew, I add here another possible scenario about the topic "VSF versus dual MMs on Aruba 5400R zl2".

Suppose we're starting with one single Aruba 5400R zl2 actually configured with redundant MMs (non default NonStop switching redudancy mode) then a second Aruba 5400R zl2 is required to be added to form a VSF...I've a doubt about how the second chassis should/would be equipped with in terms of MMs (one MM or two MMs) considering what we know about VSF restrictions.

Does the transition Matthew described about the failing MM of the VSF Member happen indipendently by the MM redudancy model (Warm-Standby or NonStop) the VSF Member had before being part of a VSF (considering that VSF enablement shuts down the second MM on all the members joining) because the redundancy mode doesn't kick at all and it will be automatically disabled? I hope so.

In other terms: VSF deployed where a Chassis has dual MMs is possible but MMs redudancy mode is automatically disabled by VSF and secondary MM kicks in only when the active MM faults and after a reboot of the entire Chassis/VSF Member.

This would imply that you can have a VSF where, as example, VSF Member 1 is equipped with two MMs and VSF Member 2 is equipped with just one MM...or is there a requirement for - sort of - dual MMs simmetry across VSF (even if we know the 2nd MM on each Chassis will be shutted down by design once VSF is setup)?

Since beginning I always thought that VSF implementation required that eventually inserted 2nd MM needs to be physically removed for safely operate VSF...the idea that a VSF Member (or both?) can use the shutted down MM to overcome an hardware MM fault at VSF Member level (so locally) changes my vision a little bit...leveraging few more questions on the topic (as example: how a VSF Member with two MMs deals with software updates and configuration synchronization to shutted down MM/MMs?).

With regards to the redundancy behavior with dual MMs in a VSF member — it does not matter what mode the member was in prior to joining the VSF fabric as the configuration is replaced during the joining (or VSF fabric creation) process, which disables the normal dual-MM redundancy behavior and shuts down the non-active MM (which is referred to by the switch as an "alternate" MM, rather than as a "standby"). 

There is no requirement for both VSF members to have two MMs installed; if a second MM is installed in one member but not the other, the fabric will continue to operate normally, though only the member with dual MMs will automatically recover from a failure of the active module. 

Having dual MMs installed in a 5400R VSF pair was initially considered an unsupported configuration due to uncertainty about the behavior of the second module in the event of a MM failure in one of the VSF members. This scenario was explicitly tested starting with the 16.05 release to verify that the 'alternate' MM would take over as intended in the event of a failure of the active module; as a result of this testing, we now 'officially' support having two MMs installed in one or both VSF members.

Hello Matthew, that's a valuable piece of information!

Just two more questions:

1. How to deal with "Alternate" MM software version potential mismatches considering that a stable VSF Fabric would/should receives necessary software updates over its lifetime (clearly involving "Active" MMs only)? [*]
2. Can you describe the mechanism of VSF Fabric configuration synchronization in the event the "Alternate" MM become the "Active" MM after a chassis reboot (due to previous "Active" MM in fault)?

[*] my thoughts go to involving/bringing up each installed "Alternate" MM to keep it somewhat aligned in terms of software...that's to avoid corner case where, after the "Active" MM failure, a VSF Member is able to reboot to the "Alternate" MM and this one hasn't the expected software version.

Hi,

I recently deployed VSF with 2x 5412s, both with dual MMs. It would be great to see the answers for the above 2 questions from Davide. specially question 2.

Thanks in avance!

Answers that I'm patiently waiting in a religious silence.

Great to see that this thread still attracts curious minds :-).