Wired Intelligent Edge (Campus Switching and Routing)

Reply
New Contributor

5400 VSF vs. redundant Management Modules

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

MVP Expert

Re: 5400 VSF vs. redundant Management Modules

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. 



Matt Fern
Technical Marketing Engineer, Wired Intelligent Edge

Aruba, a Hewlett Packard Enterprise company

8000 FOOTHILLS BLVD  |  ROSEVILLE, CA 95747
T: 916.540.1759  |  E: mfern@hpe.com   |   Matt @ Twitter
MVP Expert

Re: 5400 VSF vs. redundant Management Modules

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?).

MVP Expert

Re: 5400 VSF vs. redundant Management Modules

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.



Matt Fern
Technical Marketing Engineer, Wired Intelligent Edge

Aruba, a Hewlett Packard Enterprise company

8000 FOOTHILLS BLVD  |  ROSEVILLE, CA 95747
T: 916.540.1759  |  E: mfern@hpe.com   |   Matt @ Twitter
MVP Expert

Re: 5400 VSF vs. redundant Management Modules

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.

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: