Wireless Access

last person joined: an hour 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

VRRP is preempting upon controller reload, even with preemption disabled

This thread has been viewed 1 times

  • 1.  VRRP is preempting upon controller reload, even with preemption disabled

    Posted Sep 23, 2016 05:54 PM

    I've been observing a VRRP problem on AOS for quite some time and finally decided to open a TAC case for it (case 1949361). I am presently running AOS 6.4.4.9 but I have observed this behavior in earlier versions as well (first observed it a year ago).

     

    I have 2 controllers running as master/standby master, no local controllers involved, all APs terminating to one of the two controllers. VRRP is configured with an identical priority with preemption disabled. Master redundancy is tied to the VRRP instance in question, and APs point to the VIP for their LMS-IP.

     

    Let's say that controller "C2" is the current master. Upon reloading the controller, the APs failover to controller "C1" as expected. At this point, my expectation would be that C1 would remain the active master controller until some sort of failure (crash, reload, power lost, etc.). However, when C2 fully reloads and comes back online, it preempts the VRRP instance even though the priority is equal and preempt is disabled.

     

    So, I raised the priority of C1. C1 did not preempt upon changing the priority. I reloaded C2 so that the APs would failover to C1, then waited for C2 to fully reload. This time, C1 remained the active master. That's good.

     

    So now, I reload C1. C2 becomes active master, all APs failover. When C1 comes back up, it preempts just like C2 was doing before. Reloading C2 does not cause a preemption event at this point.

     

    (Side note: it appears to me that there must be some sort of underlying tie-breaker for equal priority preemption. I think it might be the system MAC address as the unit with the lower MAC address seems to preempt.)

     

    The next test I did was to set the priorities equal, but instead of reloading the controllers, I simply shut down the VRRP instance. In this case, preemption did not occur when I would shut and no shut VRRP on each controller. This is the behavior I expect.

     

    I did find my own workaround by using the command "tracking master-up-time 2 add 10" on both controllers. This prevented a preemption upon reload since the new master would be a higher priority by the time the old master controller fully reloaded.

     

    Nonetheless, VRRP is not acting in accordance with expected behavior. If priorities are equal, preemption should NOT occur upon boot.

     

    I encourage Aruba to verify my findings on their own and correct the behavior of VRRP upon boot.

     

     

     



  • 2.  RE: VRRP is preempting upon controller reload, even with preemption disabled

    Posted Sep 26, 2016 06:42 AM

    I´ve also observed this behaviour. Not sure if it´s VRRP itself that behaves like this when initializing VRRP interfaces after boot up or if it´s ArubaOS doing something sneaky.

     

    I do like the workaround though.

     

    Cheers,



  • 3.  RE: VRRP is preempting upon controller reload, even with preemption disabled
    Best Answer

    Posted Sep 26, 2016 11:52 AM

    If STP/RSTP is enabled in the intermediate switches, we would see this behaviour. This could be due to the delay in STP/RSTP convergence which is causing the controller to miss the VRRP heartbeat and hence it becomes the Master.

     

    Please try with holdtime.

    (Master) (config) #vrrp <id>
    (Master) (config-vrrp)#holdtime

     

    /Abdul Ali Irfaan