Why does a VRRP master with preemption disabled regain master state after the reboot ?

MVP Expert
MVP Expert

Why does a VRRP master with preemption disabled regain master state after the reboot?






This issue is found in the following scenarios:

1. When spanning tree is disabled on either of the VRRP controllers but enabled on upstream switch(es).
2. When the controller(any one VRRP controller) and upstream device(s) run different versions of STP.
3. STP convergence time is different across the VRRP controllers.


In these scenarios, rebooted vrrp master is expected to come back as vrrp MASTER as the link takes some time to converge and fail to receive VRRP advertisement packets from its peer and may roll back to MASTER.
Trigger for this is, since STP is enabled on intermediate switch and disabled on controller, switch is taking some time ~30 secs to converge the link while port on the controller has become UP and fail-over to Master due to 
not receiving VRRP advertisement packets

In all these cases, it is advised to enable holdtime to mitigate issue. Holdtime has been introduced to tackle this issue in the "preemption disabled scenario".


Configuration via CLI:

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


The VRRP virtual router does not begin listening to advertisements until the holdtime expires. If your deployment includes a VRRP master with preemption disabled and an uplink switch is running RSTP, a higher value will prevent the VRRP master from regaining the master state after it reboots.
Range: 30 - 120 seconds
Default: 45 seconds

Version history
Revision #:
3 of 3
Last update:
‎07-30-2015 03:04 AM
Updated by:
Labels (1)
Search Airheads
Showing results for 
Search instead for 
Did you mean: