Wireless Access

 View Only
last person joined: 4 hours ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Back to discussions
Expand all | Collapse all

Master Redundancy - Different hardware model

This thread has been viewed 4 times

  • 1.  Master Redundancy - Different hardware model

    Posted Oct 24, 2015 04:58 PM

     

    Hello, 

     

     

    Looking to move to a Master Redundancy Act-Stby architecture from Master Local deployment.

     

    Current Master is M3 and was wondering if there would be any issues configuring Master Rendundacy parameters and VRRP between two different Master Model. ( running same AOS 6.3.X )

     

    RLN upgrading a Multicontroller Network states : 

     

    For proper operation, all controllers in the network must be upgraded with the same version of ArubaOS software. For redundant (VRRP) environments, the controllers should be of the same model.

     

     

     

    Has someone tried this before? Master act-stby with two different controller model.

     

    Thanks, 

     

    DSP



  • 2.  RE: Master Redundancy - Different hardware model
    Best Answer

    EMPLOYEE
    Posted Oct 24, 2015 05:01 PM
    It’s for scalability reason. You don’t want to failover to a less capable controller.

    Just curious, why are you moving away from master-local? It’s the most flexible architecture.


  • 3.  RE: Master Redundancy - Different hardware model

    Posted Oct 26, 2015 11:20 AM

     

    Hello Tim, 

     

    We are looking to move  from Redundant aggregation to a Fully Redundant architecture : 

     

    Fully Redundant.png

     

    Regards, 

     

    DSP



  • 4.  RE: Master Redundancy - Different hardware model

    Posted Nov 11, 2015 03:28 PM

    My $0.02 -- I generally don't recommend Standby Master deployments.  IME, the fail-back from Standby to the original Master has a bad habit of botching configuration changes made during the outage.

     

    I use VRRP, and HA groups, and tailor the ADP scenario to survive loss of the Master, then tell the admin staff "if your Master controller falls off the planet, you can't make config changes until you promote one of the Locals, or replace the Master."  That seems to suit most people fine.

     

    For the rest... well...  One time of having to reconcile, line-by-line, a config backup and whatever happened to survive in the running config after a failover event is usually enough to convince anyone too enamored with "no single points of failure" to change their tune.