Wireless Access

Occasional Contributor I

VRRP redundancy for master-local-local


I am changing over from a two 3400 configuration running as master/standby to a three 3400 configuration that I plan to operate as master/local/local since the plant is doubling the coverage area.  In the old configuration, either 3400 could go down and the wlan should continue to operate after VRRP does its thing to re-home the APs.  I would like for the wlan to continue working if any one of the three 3400's go down in the new configuration.  All three 3400's are on the same vlan, attached to the same network switch.  All three controllers are running and have identical licenses.  I use DHCP option 60 and option 43 to point the APs to the Master controller for initial configuration.


Proposed setup:

VRRP 1 between Local1 and Master

VRRP 2 between Local2 and Master


How I think it will operate:

What I believe I understand about this is that either Local1 or Local2 could fail and Master would pick up operation of the APs from the failed Local.  If Master fails, APs would continue to operate from their respective Local controllers unless they are rebooted at which point they will not be able to find the Master to determine their initial configuration.  If this is true and the Master is damaged during a power outage, then none of the APs will come online when the power is restored.


My questions:

1) Since it appears that the Local controllers have a full copy of the configuration, could we just set the DHCP option 43 to point to one of the Local controllers until the Master is repaired and back online, realizing that changes would not propagate between Locals and would be overwritten when the Master comes online again?


2) If it is just a matter of the APs needing to find one of the Locals to get their initial config from, could I set up a third VRRP between all three controllers (for which the Master would have the highest priority) where we would direct the DHCP option 43.  If that would work, then one of the Locals could automatically provide the Initial config to the APs.


Please let me know if I am understanding these things correctly and whether these ideas would work.


Thank you.


Frequent Contributor II

Re: VRRP redundancy for master-local-local

Let me put it simple, your questions is about APs finding the master to get the initial  configuration in case the Master went down.


Let me tell you that you need to configure the LMS ip in the system profile then provision the APs. once provisioned the APs will have the configuration and they will reboot and use the LMS IP address of the VRRP link to connect to one of the controllers (depend on priority) , so once the APs connected to the master controller and provisioned they do not need to reconnect to the master to get the configuration because they are already having it.



Aruba Employee

Re: VRRP redundancy for master-local-local

Thats not exactly correct.  An AP MUST get its config from a controller each time it reboots.  It only keeps its name, ap-group and any other information entered when provisioned.  It does not keep the entire configuration.


I have never pointed an AP at a "local" controller user DHCP option 43, but it should work. 


Your VRRP setup is correct.  Make two groups, have the master be back for each VLAN VRRP group, then in the AP sytem profile, point the LMS-IP to the VIP for each group.  You should wind up with 2 VRRP instances, two AP system profiles and two AP groups.


I know ADP will work to a local controller, but again, I am not sure about option 43.

Frequent Contributor II

Re: VRRP redundancy for master-local-local

WHAT !!! I really did not expect so !!


I thought it will keep the LMS at least !!... but in order to use the LMS it will reboot !! and then if the controller were in an other subnet and the Master controller is down then we will have an issue, unless if the AP is going to do a bootstrap only!


Ok, one question if controller goes down the AP will reboot complety and look for a master controller to get config or will it retain its config. and just vreate a new GRE tunnel in case of VRRP red. and use LMS-backup-ip incase of L3-redundancy ?

Aruba Employee

Re: VRRP redundancy for master-local-local

If you don't provision the AP with the server IP or master IP, it has to do discovery to find them.  If you put those values in during the provisioning, then the AP will "remember" them.


That is all the AP will keep in NVRAM.  The configuration (LMS-IP, Backup LMS-IP, WLANs, AAA profiles, etc) are all temporary.


If the AP is using LMS-IP and Backup LMS-IP for redundancy, it will bootstrap to switch from one to the other, not reboot.  


If the AP loses contact with it's controller and doesn't have redundancy configured, it will reboot and try to discover the master again.


If the AP reboots, it must discover another controller unless you have configured the server/master IP during provisioning (in which case it is saved in NVRAM and available after a reboot).


If the controller is using VRRP and the AP is using the VIP as the controller IP, it will not reboot or bootstrap since the VIP is always available.


I know I have repeated my self a couple times in this email, but this is VERY important to understand so that rendundancy can be setup correctly.

Aruba Employee

Re: VRRP redundancy for master-local-local

By the way, if you want to know what is and isnt stored on an AP, plug into the console port on the AP (using a serial console cable), boot the AP and hit a key when prompted to stop the boot process.  At the boot prompt, type "printenv" (or just "print").  You will see all of the NVRAM parameters saved on the AP.  Then, type "boot" to finish the boot.

Frequent Contributor II

Re: VRRP redundancy for master-local-local

Thanks Olino,


It seems I have to make a small modification on my customer design and add the IP address (for aruba-master) of the VRRP-IP in which the Master Controller is active instead of using the management IP address of the controller it self.


As long as you around can you have a look on my issue here:





Occasional Contributor I

Re: VRRP redundancy for master-local-local

So is there any reason to not make the third VRRP (as in question 2) which would be prioritized to the master for DHCP option 43?  If option 43 to a local will indeed work, then this third VRRP should mean that I won't have to change the DHCP settings for the APs to be able to find a local for configuration when the master is down - right?


Here is a diagram of what I am thinking:

MLL Redundancy.gif


Thank you.

Aruba Employee

Re: VRRP redundancy for master-local-local

I honestly dont know if that will work or not.  I will let someone reply with a definitive answer.

Occasional Contributor I

Re: VRRP redundancy for master-local-local

I was finally able to run a live test.  I thought I would share my findings here.


Just for clarification, the controller that would be Local1 in the diagram previously posted was still serving production while I ran these tests, so it will not appear in any of the testing descriptions.



Using only LMS and Backup-LMS  (no VRRP defined)


* Two 3400 controllers running (one as Master, the other as Local)

* Two AP-105 APs connected to a different VLAN than the controllers

* APs are assigned to a test group with LMS=Local2 IP address, Backup-LMS=Master IP address, LMS preemption enabled

* The AP VLAN has DHCP option 43 set to the Master IP address


> Controllers online and configured

> Plugged in APs: wireless network came online with APs tunneled to Local2

> Unplugged Local2 ethernet: APs switched to Master after about 10 seconds

> Plugged in Local2 ethernet: APs did not switch back to Local2 after 5 minutes (they remained tunneled into Master)

> Unplugged Master ethernet: APs went into endless boot cycle (wireless network down)

> Plugged in Master ethernet: Aps booted and tunneled through Local2


Conclusions from LMS / Backup-LMS test:

* I do not know why the APs did not revert back to the LMS when LMS Preemption was checked (enabled) unless I didn't give them enough time (5 minutes) to see that Local2 was available again.  Even then, I think they still should have reverted to Local2 when Master went offline instead of rebooting.

* The APs obviously did not retain their LMS / Backup-LMS settings when rebooted (ie. they behaved as olino stated).

* In a power-outage scenario, if the master controller failed during the outage or the the APs restarted after the master failed , the wireless network would not come back online without intervention.



 Using VRRP for Local and Master controllers (no Backup-LMS)


* Same two 3400 controllers running (one as Master, the other as Local)

* Two AP-105 APs connected to a different VLAN than the controllers

* VRRP_M: primary=Master, secondary=Local2

* VRRP_L2: primary=Local2, secondary=Master

* The AP VLAN has DHCP Option 43 set to VRRP_M IP address

* APs are assigned to a test group with LMS=VRRP_L2 IP address


> Controllers online and configured

> Plugged in APs: wireless network came online with APs tunneled to Local2

> Unplugged Local2 ethernet: Aps switched to Master with only 2 lost pings

> Plugged in Local2 ethernet: APs switched back to Local2 with only 1 lost ping

> Unplugged Master ethernet: APs continued to operate

> Unplugged APs: wireless network went down (of course)

> Plugged in APs (Master still down): APs boot up and tunnel through Local2

> Plugged in Master ethernet: APs continued to operate


Conclusions from the VRRP test:

* APs have no problem with DHCP Option 43 being set to a VRRP address that is being controlled by a local controller.

* VRRP allows the APs to switch between controllers much quicker than using LMS/Backup-LMS.

* Any one controller can fail and the wireless network will continue to operate even if the APs are rebooted.



One last comment:

* I thought I saw something somewhere that made it sound like DHCP Option 43 could be used to specify more than one IP address for multiple master controllers, but there were no instructions or examples that showed how those addresses should be coded (separated with comma, space, or some other method).   If so, the LMS/Backup-LMS scenario might not have behaved so poorly.  However, since VRRP made the transition so much more quickly, I have no desire to pursue using the Backup-LMS setting.


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