Wireless Access

Hey AirHeads Community,

So here's the scenario:

Two 7210 controllers in an Active-Master (Master1) / Backup-Master (Master2) VRRP redundancy configuration. Pre-emption is NOT checked in the VRRP addresses. Master1 has a priority of 110, Master2 has a priority of 100. When testing failover, the APs failed from Master1 to Master2 perfectly. However, when Master1 came back online, the APs went back to Master1. Again, Pre-emption is NOT checked and I cannot figure out why the APs went back to Master1. First time rebooting, I did it from GUI, second time rebooting I pulled the power cords from controller. Same result, APs came back to Master1.

Controllers are running 6.2.1.3 code

I do not want the APs to go back to Master1 in a failover scenario. Any ideas why this might be happening?

Thanks! 

Ps. Attached is a picture of VRRP configuration to show that Pre-emption is NOT checked.

Despite having preemption disabled, does the first controller regain "master" status of the VRRP when coming back online?  

You can also shutdown the VRRP intances on the master (rather than rebooting) to test this failover.   

config t

vrrp <id>

shut

show vrrp (verify it is in INT state)

verify that the other controller is master for this IP

show vrrp (verify it is Master)

bring the master back online

config t

vrrp <id>

no shut

show vrrp (verify status; should stay Backup)

Also, can you confirm what you have set for your primary/backup LMS in the AP System profile for those APs?

Yes, the controller takes the Master role back although preemption is not checked.

No LMS IP defined in AP system profile.

Thanks!

Just some more detailed info:

Active-Master 172.30.10.27

Backup-Master 172.30.10.28

VRRP 172.30.10.26

just to clarify, you have no IP in the LMS field?  your primary LMS in your case should be 172.30.10.26; the VRRP address.  If it is blank, they will terminate on the controller from discovery by default.  Please confirm your setting.

Yes LMS is blank. That wouldn't cause the active-master to take back the virtual IP for the VRRP, would it?

no it should not, but it may account for the APs going back.   these are master/master, correct?

can you run the following on each controller:

show vrrp

show master-redundancy

Yes they are master/master setup.

I currently don't have access to the controllers, but I'm going to paste the config below:

Active-Master:

master-redundancy
master-vrrp 10
peer-ip-address 172.30.10.28 ipsec 77db8ba3817b029922e150f79fcbbeeb8d68ca677bb30755
!
vrrp 10
priority 110
authentication aruba123
ip address 172.30.10.26
vlan 10
tracking master-up-time 30 add 20
no shutdown

Backup-Master:

master-redundancy
master-vrrp 10
peer-ip-address 172.30.10.27 ipsec 0464b861ed6ff4f3cc1c00dafa967be7f4bba843c12c78a7
!
vrrp 10
authentication aruba123
ip address 172.30.10.26
description "Backup-Master"
vlan 10
tracking master-up-time 30 add 20
no shutdown

the configuration looks correct from what you copied.   there should be an entry in the logs for the VRRP transition.   Can you check the logs on both; it should show up in the system log;  show log system all | include vrrp

show vrrp <id> statistics on both will also show details about priorities received, etc.  It may help tracking it down.

if there is not enough try turning on debugging

logging level debugging system subcat messages process fpapps

don't foget to turn it off later

no logging level debugging system subcat messages process fpapps

Hi MHaring,

I got exactly the same issue. Did you find any solution ot fix it?

Thanks you

Hi,

Found any solution ?

Does the same occur if you remove the tracking from the VRRP configuration?