Wired Intelligent Edge

last person joined: 12 hours ago 

Bring performance and reliability to your network with the Aruba Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of the ArubaOS-Switch and ArubaOS-CX devices, and find ways to improve security across your network to bring together a mobile first solution.
Expand all | Collapse all

Management Module for 5400Rzl2

This thread has been viewed 40 times
  • 1.  Management Module for 5400Rzl2

    Posted Oct 07, 2021 07:36 AM
    Hi Everyone,

    We have two Aruba 5412Rzl2 and we are planning to configure VSF on both switches.

    Now if VSF is configured and up and running on both switches, then all of a sudden one of the management module fails.

    1. Will it cause an outage for that switch or will the second management module act as the active management module for the whole switch?
    2. Is it recommended or best practice to purchase additional management modules to achieve management module redundancy on switches that are already  configured in VSF?

    Regards,

    ------------------------------
    GSM
    ------------------------------


  • 2.  RE: Management Module for 5400Rzl2

    Posted Oct 07, 2021 09:37 AM
    Hi CesarPin (GSM), there are some long threads (here and also on HPE Community where VSF was discussed first, some years ago...2017?) explaining what there is behind the "VSF on Aruba 5400R zl2 with dual Management Modules installed" scenario...the story is long because initially (and for long time) a VSF consequence (more than a restriction di-per-sè) was that a Standby MM goes disabled once VSF is up and running, in other terms VSF doesn't support the secondary MM in a dual MMs configuration...that's to say that if you have two Aruba 5400R zl2 with dual MMs installed (set either with Standby or with NonStop Switching redundancy mode of operation) on each chassis and you deploy VSF then both the secondary MMs will be disabled because they aren't supported by the VSF scenario.

    Lately (recently) Aruba came with a news: secondary MMs will be supported by VSF but they stay disabled, in any case.

    The difference was that, for some years was valid the approach to forcefully disable the secondary MM (those that were used ad Standby) or, at worst, remove them...then this suggestion changed with the recent support statement in a VSF scenario.

    Personally I've some doubts about how VSF will deal to software updates (apart being capable of FSU on VSF implemented with two Aruba 5400R zl2) when a chassis has a MM disabled (and, worst, when two chassis have two MMs disabled).

    As reference, have look at this, this, this here on Airheads and - on the HPE Community - this and this just to start 8-).

    Also keep an eye wide open on this too.

    In any case, apart what I wrote you about, please use official and current documentation about VSF and Aruba 5400R zl2 to understand all the details, tips and tricks, pros and cons, restrictions and requirements of this solution.

    ------------------------------
    Davide Poletto
    ------------------------------



  • 3.  RE: Management Module for 5400Rzl2

    Posted Oct 11, 2021 08:28 AM
    Hi Davide,
    I came across this thread and thought i'd just encourage the conversation since we are also implementing VSF but without dual management modules. We are on a tight budget and the choice comes to putting redundant management modules OR just clustering two 5400R switches by buying the 10G modules (we currently have only 1G port modules on each chassis).

    If we implement VSF using a single MM in each chassis and the Commander's MM fails, will there be any downtime to the connected users as the MM in the standby chassis takes over?

    All the articles you have mentioned above seem to revolve around dual MMs in both chassis but no one clearly mentions impact if we are just running on a single MM in both VSF members.

    I think GSM also mentioned using single MMs as his first option.

    ------------------------------
    Atif Siddiqui
    ------------------------------



  • 4.  RE: Management Module for 5400Rzl2

    Posted Oct 11, 2021 10:26 AM
    Hello Atif,

    "If we implement VSF using a single MM in each chassis and the Commander's MM fails, will there be any downtime to the connected users as the MM in the standby chassis takes over?"

    No there will be not a "downtime" IF all (upstream/downstream) peers are concurrently connected to both VSF members (Commander and Standby) with dual homed links...in other words if peers are connected to both VSF members by means of LACP links aggregations, loosing half of the VSF stack (it fragments) will not cause particular issues.

    If a Switch (or a Host) is "dual homed" to the VSF via LACP if the VSF Standby (or Commander) member's chassis fails - as example because its single MM suddenly fails (just an example) - then the remaining VSF Commander (or Standby) member will "take over" - well the VSF Commander will not "take over" because it is already the Commander and it is already actively managing the VSF Stack - and switching operations will continue will minimal to no disruption to remaining active VSF member.

    Deploy a MAD (Multi-Active Detection) mechanism supported by the VSF (via OoBM as example) to be able to mitigate the negative effects of a VSF Split scenario when it occurs.

    "All the articles you have mentioned above seem to revolve around dual MMs in both chassis but no one clearly mentions impact if we are just running on a single MM in both VSF members."

    Because this thread is focused in understanding what does it mean deploying an Aruba 5400R zl2 VSF stack when each chassis (or just one of the pair) is deployed with two MMs, that's the reason I linked/cited all those threads.

    ------------------------------
    Davide Poletto
    ------------------------------



  • 5.  RE: Management Module for 5400Rzl2

    Posted Oct 11, 2021 07:41 PM
    Hi David,
    Thanks for your prompt feedback as always. I am close to getting the answer that i need so focusing on just:

    "No there will be not a "downtime" IF all (upstream/downstream) peers are concurrently connected to both VSF members (Commander and Standby) with dual homed links...in other words if peers are connected to both VSF members by means of LACP links aggregations, loosing half of the VSF stack (it fragments) will not cause particular issues."

    What if we have desktop users and they are connected to the Commander switch and the single MM of the commander switch fails. Will there be an outage to those single homed LAN users or what impact do you think they will have.



    This email contains privileged and confidential information. If you are not the intended recipient you must not disseminate, copy or take any action in reliance on it, and we request that you notify our office immediately. This email and its contents are also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner. We do not represent or warrant that this communication is free from computer viruses or other defects. Probe is not liable for any loss, damages, claims, cost demand and expense whatsoever and howsoever arising in connection with or out of the use of data and/or programs supplied in this e-mail transmission. Please consider the environment before printing this email. 





  • 6.  RE: Management Module for 5400Rzl2

    Posted Oct 12, 2021 10:12 AM
    Hello to both Atif and GSM,

    Atif asked:

    "What if we have desktop users and they are connected to the Commander switch and the single MM of the commander switch fails. Will there be an outage to those single homed LAN users or what impact do you think they will have."

    GSM asked:

    "The one mentioned by Atif would be the same setup as ours where workstations will be connected to the switch but not dual homed to Commander and standby. So for example, MM of commander fails, will the other MM(standby) takes over? and will it create a downtime for users that are connected to the switch where it has the defective Management module?"

    In the proposed scenario - where a "single homed" host/peer is connected to VSF Commander OR to VSF Standby and NOT to both concurrently (with LACP) AND both VSF chassis are equipped with just one MM per chassis (the MM is a SPoF for that particular chassis) - the working conditions for any "single homed" hosts/peers are:

    (1) IF the MM on the VSF Commander chassis fails then the VSF Commander member fails and ALL single homed hosts/peers connected ONLY to the VSF Commander member will lose their connectivity to that specific VSF Member (since those hosts/peers aren't concurrently "dual homed" to both VSF Members with LACP).

    (2) IF the MM on the VSF Standby chassis fails then the VSF Standby member fails and ALL single homed hosts/peers connected ONLY to the VSF Standby member will lose their connectivity to that specific VSF Member (since those hosts/peers aren't concurrently "dual homed" to both VSF Members with LACP).

    This is quite simple to visualize: one host, one physical link to a one VSF Member (Commander or Standby, it doesn't really matter) -> if the VSF Member in question fails then the connected host will lose completely its connectivity to that particular VSF Member (which is the only one the host is connected to).

    It also explains why "dual homing" peers is so important when (and where) the VSF approach is seen as necessary to have a resilient setup (distribution/core levels).

    ------------------------------
    Davide Poletto
    ------------------------------



  • 7.  RE: Management Module for 5400Rzl2

    Posted Oct 14, 2021 04:11 AM
    Thanks Dave. Really helps. I am just thinking the benefit of VSF in that case is just to dual-homed users.

    We can invest in dual MMs rather than buying 10G modules to build a VSF and have the switches on an LACP trunk.
    I am sure you have guessed by now that we are using these switches on access layer rather than distribution.

    ------------------------------
    Atif Siddiqui
    ------------------------------



  • 8.  RE: Management Module for 5400Rzl2

    Posted Oct 14, 2021 10:21 AM
    Hello Atif, well...VSF shows its versatility and release its full potentials if directly connected peers (examples: switches, physical servers, NAS, workstations, etc.) are "dual homed", that helps to avoid various SPoF scenarios (if a VSF Member fails, if a link to a VSF Member fails, if a Module on the VSF Member's chassis fails...etc.).

    Using LACP with a minimum of two physical links directly connected to VSF Members, connected peers will be able to balance their egressing traffic to VSF (the same will happen for the egressing traffic from the VSF to Peers) and to be concurrently resilient if a physical connection, a port, a NIC or a Module suddenly fails...with that in mind, the VSF is more reasonable if placed in a Core/Distribution position where peers can be reasonably and easily "dual homed" to it, is less reasonable if deployed in Access positions where peers can't be "dual homed" to it.

    Said so, a single Aruba 5400R zl2 (used and positioned as an Access switch where connected peers are mostly "single homed" clients) will be best suited when equipped with redundant MMs (so Dual MMs configured with the "NonStop Switching" as the redundancy policy) instead of being deployed as a VSF (you need another identical Aruba 5400R zl2 Switch with single or double MMs <- in case of Dual MMs you will "lose" the Standby MM on each chassis).

    ------------------------------
    Davide Poletto
    ------------------------------



  • 9.  RE: Management Module for 5400Rzl2

    Posted Oct 12, 2021 09:17 AM
    Hi Davide,


    The one mentioned by Atif would be the same setup as ours where workstations will  be connected to the switch but not dual homed to Commander and standby. So for example, MM of commander fails, will the other MM(standby) takes over? and will it create a downtime for users that are connected to the switch where it has the defective Management module?


    ------------------------------
    GSM
    ------------------------------