Wireless Access

Reply
DSP
Contributor II
Posts: 37
Registered: ‎03-25-2013

Master Redundancy - Different hardware model

 

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

Guru Elite
Posts: 8,632
Registered: ‎09-08-2010

Re: Master Redundancy - Different hardware model

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.

Tim Cappalli | Aruba Security TME
@timcappalli | timcappalli.me | ACMX #367 / ACCX #480
DSP
Contributor II
Posts: 37
Registered: ‎03-25-2013

Re: Master Redundancy - Different hardware model

[ Edited ]

 

Hello Tim, 

 

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

 

Fully Redundant.png

 

Regards, 

 

DSP

Occasional Contributor II
Posts: 18
Registered: ‎12-10-2014

Re: Master Redundancy - Different hardware model

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.

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