This article describes how to dampen the Virtual Router Redundancy Protocol (VRRP) flags.

Normally, VRRP is seen to assume the primary role faster and before other protocols such as BGP, OSPF, and ISIS converge.

However, some customers prefer to leave the new VRRP as primary for a while for different reasons, such as uplink restoration, preference change, reboot, and so on, even though the previous VRRP primary comes back into production.

Additionally, it has also been found that depending on the scale of configured interfaces, routes, and so on, the installation of routes from the Routing Engine to the Packet Forwarding Engine (PFE) may be delayed. This means that the installation of the route (224.0.0.18) that receives the VRRP Hello may be delayed as well.

In other words, after vrrpd starts processing, vrrpd will not receive the VRRP Hello until the 224.0.0.18 route is active on the PFE due to which it may transition to being the primary.

So, it may be necessary to dampen the new primary for a certain amount of time, before the previous primary router assumes the primary role again.

VRRP's assuming the primary role is pre-emptive. So, when a VRRP router gets the highest priority value, it instantly becomes the primary, which results in a forced switchover from the present primary.

Junos OS has the following configuration options to dampen the restoration of VRRP's primary role from the new primary router to the previous primary router.

lab@mx960-re0# help topic vrrp startup-silent-period

Configuring the Startup Period for VRRP Operations

To configure the startup period for VRRP operations, include the startup-silent-period statement at the [edit protocols vrrp] hierarchy level:

[edit protocols vrrp]
startup-silent-period seconds; 

2022-05-10: Added information about delay in installation of routes depending on scale of configured interfaces, routes and so on.