Wired Intelligent Edge

last person joined: yesterday 

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

ArubaOS-CX continuous service mechanisms

This thread has been viewed 12 times
  • 1.  ArubaOS-CX continuous service mechanisms

    Posted Sep 27, 2018 10:41 AM

    Hi community,

    Does anybody know if ArubaOS-CX has mechanisms of continuous service (like SSO and ISSU) in order to avoid interruption of service during maintenance operations and software updates?

    Thanks in advance for any support.

    Regards

    Pedro



  • 2.  RE: ArubaOS-CX continuous service mechanisms
    Best Answer

    EMPLOYEE
    Posted Sep 27, 2018 12:47 PM

    Hello Pedro,

     

    In the context of core or distribution device, the VSX technology includes Multi-Chassis LAG as well as separate control planes. As such, thanks to ECMP and rapid failover/failback of LAG, upgrade of one equipment induces very limited downtime (less than a second).

     

    In the context of a single network node (no VSX), with single attachements, ArubaOS-CX does not provide ISSU currently.

     

    Would you like more information on VSX, please refer to the configuration guide. Would you like more information on VSX upgrade impact and detailed explanation, do not hesitate to reach out to me.

     

    Rgds,



  • 3.  RE: ArubaOS-CX continuous service mechanisms

    Posted Oct 01, 2018 05:15 PM

    Hi Vincent,
    About this post, I think I must clarify my question.
    Talking about Cisco, SSO minimizes the time a network is unavailable to its users following a supervisor switchover (when a redundant supervisor takes over if the primary supervisor fails) while continuing to forward IP packets.
    Talking about Juniper, its platforms have some high availability features like: Graceful Routing Engine Switchover, Nonstop Bridging, Nonstop Active Routing and Graceful Restart, similar to SSO.
    Now, for the case of Aruba 8400, is there any simmilar feature that helps to switchover from a failing management module to a redundant management module transparently at L2 and L3?
    Take note that I am talking about just one chassis 8400 with 2 management modules in 1+1 configuration.

    Now, if we talk about 2 chassis 8400 in VSX configuration, I think that features like MCLAG and separate control planes would help and contribute to high availability during upgrades. But, what about if the are doing an upgrade to just one chassis 8400 (no VSX deployed) with 2 management modules. Is there a way/feature that permits to upgrade one management module first, and after a successfull upgrade of it, to upgrade the second management module, so that the service is not affected?

    Regards

     

    Pedro



  • 4.  RE: ArubaOS-CX continuous service mechanisms

    EMPLOYEE
    Posted Oct 10, 2018 06:10 AM

    By design Management Module failover (active MM getting down and standby MM taking over active role) should not cause any network downtime. We have seen some glitch in early 10.01 versions which are corrected now. 

    I recently tested MM failover with traffic going through a 8400 with OSPF processes and get no traffic drop.

     

    We don't call that SSO, because this is native in the OS which is Database centric. SSDB is mirrored from active to standby module.

    So all processes have their current entries on standby MM anytime.

     

    About upgrading one MM then the other one, we don't support this.

    Upgrade does not touch only MM, it touches as well Line Cards.

     

    I hope this clarifies. Do not hesitate to reach out to your local Aruba contact. All Aruba SEs should be knowledgeable on these aspects.

     

    Regards,

    Vincent Giles

    Aruba TME



  • 5.  RE: ArubaOS-CX continuous service mechanisms

    MVP GURU
    Posted Oct 11, 2018 09:28 AM

    @vincent.giles wrote: About upgrading one MM then the other one, we don't support this.

     

    Upgrade does not touch only MM, it touches as well Line Cards.

    Hello Vincent, can you elaborate the above statements a little bit more (especially this one: "upgrading one MM then the other one, we don't support this")?

     

    I ask that considering we're speaking about a single Aruba 8400 Switch equipped with two MMs when a software update is going to be performed. Thanks.



  • 6.  RE: ArubaOS-CX continuous service mechanisms

    EMPLOYEE
    Posted Oct 15, 2018 03:23 AM

    Single 8400, 2 MMs, we do not support yet In Serive Software Upgrade,

    which is would mean that at a given time, one MM runs Version n and the other one version n+1. That single chassis ISSU is not yet support.

     

    Again, for HA purpose, the best practice is to use 2x CX nodes with VSX,

    which will will garantee minimum downtime during firmware upgrade.



  • 7.  RE: ArubaOS-CX continuous service mechanisms

    Posted Apr 20, 2020 10:16 AM

    hi Vincent, can you update us now on the latest procedures for vsx update-software for 6400, 8400 that have multiple management modules.  is live upgrade supported at this time?  thank you.



  • 8.  RE: ArubaOS-CX continuous service mechanisms

    EMPLOYEE
    Posted Apr 20, 2020 10:42 AM

    VSX live upgrade = vsx update-software is still the way to go for a pair of 6400 / 8320 / 8325/ 8400. Impact is sub-second (much less).

     

    Standalone switch (non VSX), is different story. For time being, there is still no ISSU, so if you need to upgrade a standalone CX switch, you have to rely dynamic protocols to converge. For single-attached endpoint, outage is the duration of the reboot cycle (it depends on the platform).



  • 9.  RE: ArubaOS-CX continuous service mechanisms

    MVP GURU
    Posted Apr 20, 2020 12:05 PM

    Since a switch deployed with two management modules is subject to a reboot cycle during a software update exactly as it happens when it owns just one MM...the fact of having one MM or two MM (Active/Standby-Ready) - without an ISSU mechanism between them (like the Dual MPU ISSU) - provides no benefits in terms of redundancy against the software upgrade process itself.

     

    Still having dual MMs provides true benefits (redundancy and resiliency) against management, live migration of MM, faulty MM hardware, OVSDB synchronization and file-systems replication.

     

    [*] like on Aruba CX 6400 or Aruba 8400X.

     

    There are maybe two other questions that would arise:

     

    • Does a software update incorporate a planned reboot of the Active MM? if so we should expect to see the triggering of a failover between MMs and the Standby-ready MM will take over the Active MM (that's described on HA Guide). That's just a personal assumption...maybe I've misunderstood the HA Guide in reading "Planned reboot of Active MM" in case of a controlled failover.
    • What is the meaning on the HA Guide for the "Software version update" when speaking about the Redundancy Management (see below screenshot)? does it mean that software is automatically updated from the Active MM to the Standby-ready MM or what?

    Screenshot:

     

    HA.png