Configuring VRRP

Mandatory parameters to configure a VRRP group are as follows (examples will follow):

1. Configure the group identifier (mandatory).

2. Configure the group:

   • Configure the virtual IP address of one or more virtual routers that are members of the VRRP group (mandatory).

   • Configure the virtual link-local address (VRRP for IPv6 only). The virtual link-local address is autogenerated when you enable VRRPv3 on the interface. You may explicitly define a virtual link-local address for each VRRP for the IPv6 group. The virtual link-local address must be on the same subnet as the physical interface address.

When choosing a VRRP group identifier, consider the following:

• In Junos OS releases prior to 17.3R1, you should not use the same VRRP group identifier on more than one subinterface on a given physical interface. This causes the VRRP virtual MAC address to be deleted from the packet forwarding engine, resulting in packet drops due to unknown MAC address. If your VRRP configuration needs to scale beyond 255 groups, consider configuring VRRP over an integrated routing and bridging (IRB) interface, since this restriction does not apply to IRB interfaces.

• Starting in Junos OS release 17.3R1, if network-services is configured in IP mode, don't configure the same VRRP group ID for multiple VRRP sessions on the same physical interface unless VRRP delegation is disabled. If multiple VRRP sessions are configured on the same physical interface with the same VRRP group ID while VRRP delegation is enabled, the other VRRP virtual IP addresses become unreachable when one of the logical interfaces is deleted.

• Starting in Junos OS release 17.3R1, if network-services is configured in enhanced-ip mode, you can use the same VRRP group ID for multiple VRRP sessions.

When configuring a virtual IP address, consider the following:

• The virtual IP address must be the same for all routing platforms in the VRRP group.

• If you configure a virtual IP address to be the same as the physical interface’s address, the interface becomes the primary virtual router for the group. In this case, you must configure the priority to be 255, and you must configure preemption by including the preempt statement.

• If the virtual IP address you choose is not the same as the physical interface’s address, you must ensure that the virtual IP address does not appear anywhere else in the routing platform’s configuration. Verify that you do not use this address for other interfaces, for the IP address of a tunnel, or for the IP address of static ARP entries.

• You cannot configure a virtual IP address to be the same as the interface’s address for an aggregated Ethernet interface. This configuration is not supported.

• For VRRP for IPv6, the EUI-64 option cannot be used. In addition, the Duplicate Address Detection (DAD) process will not run for virtual IPv6 addresses.

• You cannot configure the same virtual IP address on interfaces that belong to the same logical system and routing instance combination. However, you can configure the same virtual IP address on interfaces that belong to different logical systems and routing instance combinations.

In determining what priority will make a given routing platform in a VRRP group a primary or backup, consider the following:

• You can force assignment of primary and backup routers using priorities from 1 through 255, where 255 is the highest priority.

• The priority value for the VRRP router that owns the IP address(es) associated with the virtual router must be 255.

• VRRP routers backing up a virtual router must use priority values from 1 through 254.

• The default priority value for VRRP routers backing up a virtual router is 100.

• Are there tracked interfaces or routes with priority costs?

  The priority cost is the value associated with a tracked logical interface or route that is to be subtracted from the configured VRRP priority when the tracked logical interface or route goes down, forcing a new primary router election. The value of a priority cost can be from 1 through 254. The sum of the priority costs for all tracked logical interfaces or routes must be less than or equal to the configured priority of the VRRP group.

Here are specific examples of configuring a VRRP group.

Configuring for VRRP IPv4 Groups

To configure basic VRRP (IPv4) groups on interfaces:

To configure VRRP or VRRP for IPv6, include the vrrp-group or vrrp-inet6-group statement, respectively. These statements are available at the following hierarchy levels:

• [edit interfaces interface-name unit logical-unit-number family inet address address]

• [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family inet address address]

The VRRP and VRRP IPv6 configuration statements are as follows:

You can configure VRRP IPv6 with a global unicast address.

To trace VRRP and VRRP for IPv6 operations, include the traceoptions statement at the [edit protocols vrrp] hierarchy level:

When there are multiple VRRP groups, there is a few seconds delay between the time the first gratuitous ARP is sent out and the rest of the gratuitous ARP are sent. Configuring failover-delay compensates for this delay. To configure the failover delay from 500 to 2000 milliseconds for VRRP and VRRP for IPv6 operations, include the failover-delay milliseconds statement at the [edit protocols vrrp] hierarchy level:

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

To enable VRRPv3, set the version-3 statement at the [edit protocols vrrp] hierarchy level:

By configuring the Virtual Router Redundancy Protocol (VRRP) on EX Series switches, you can enable hosts on a LAN to make use of redundant routing platforms on that LAN without requiring more than the static configuration of a single default route on the hosts. You can configure VRRP for IPv6 on Gigabit Ethernet, 10-Gigabit Ethernet, and logical interfaces.

To configure VRRP for IPv6:

VRRP (IPv4 only) protocol exchanges can be authenticated to guarantee that only trusted routing platforms participate in routing in an autonomous system (AS). By default, VRRP authentication is disabled. You can configure one of the following authentication methods. Each VRRP group must use the same method.

• Simple authentication—Uses a text password included in the transmitted packet. The receiving routing platform uses an authentication key (password) to verify the packet.

• Message Digest 5 (MD5) algorithm—Creates the authentication data field in the IP authentication header. This header is used to encapsulate the VRRP PDU. The receiving routing platform uses an authentication key (password) to verify the authenticity of the IP authentication header and VRRP PDU.

To enable authentication and specify an authentication method, include the authentication-type statement:

authentication can be simple or md5. The authentication type must be the same for all routing platforms in the VRRP group.

You can include this statement at the following hierarchy levels:

• [edit interfaces interface-name unit logical-unit-number family inet address address vrrp-group group-id]

• [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family inet address address vrrp-group group-id]

If you include the authentication-type statement, you can configure a key (password) on each interface by including the authentication-key statement:

key (the password) is an ASCII string. For simple authentication, it can be from 1 through 8 characters long. For MD5 authentication, it can be from 1 through 16 characters long. If you include spaces, enclose all characters in quotation marks (“ ”). The key must be the same for all routing platforms in the VRRP group.

You can include this statement at the following hierarchy levels:

• [edit interfaces interface-name unit logical-unit-number family inet address address vrrp-group group-id]

• [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family inet address address vrrp-group group-id]

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

By default, a higher-priority backup router preempts a lower-priority primary router. To explicitly enable the primary router to be preempted, include the preempt statement:

You can include this statement at the following hierarchy levels:

• [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-id]

• [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (Inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-id]

To prohibit a higher-priority backup router from preempting a lower-priority primary router, include the no-preempt statement:

By default, a switch configured to be a VRRP backup but acting as the primary does not process packets sent to the virtual IP address—that is, packets in which the destination address is the virtual IP address. To configure a backup switch to process packets sent to the virtual IP address while it is acting as the primary, include the accept-data statement on the backup:

You can include this statement at the following hierarchy level:

• [edit interfaces interface-name unit logical-unit-number family inet address address vrrp-group] group-id

To explicitly prohibit the backup from accepting packets destined for the virtual IP address while acting as primary, include the no-accept-data statement:

If you include the accept-data statement, configure the connected hosts so that they:

• Process gratuitous ARP requests.

• Do not use packets other than ARP replies to update their ARP cache.

This statement is disabled by default. If you enable it, your configuration does not comply with RFC 3768.

To restrict incoming IP packets to ICMP only, you must configure firewall filters to accept only ICMP packets.

The hold time is the maximum number of seconds that can elapse before a higher-priority backup router preempts the primary router. You might want to configure a hold time so that all Junos OS components converge before preemption.

By default, the hold-time value is 0 seconds. A value of 0 means that preemption can occur immediately after the backup router comes online. Note that the hold time is counted from the time the backup router comes online. The hold time is only valid when the VRRP router is just coming online.

To modify the preemption hold-time value, include the hold-time statement:

The hold time can be from 0 through 3600 seconds.

You can include this statement at the following hierarchy levels:

• [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-id preempt]

• [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (Inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-id preempt]

In Junos OS Release 9.5 and later, the asymmetric-hold-time statement at the [edit protocols vrrp] hierarchy level enables you to configure a VRRP primary router to switch over to the backup router immediately—that is, without waiting for the priority hold time to expire—when a tracked interface or route goes down or when the bandwidth of a tracked interface decreases. Such events can cause an immediate reduction in the priority based on the configured priority cost for the event, and trigger a primary-role election.

However, when the tracked route or interface comes up again, or when the bandwidth for a tracked interface increases, the backup (original primary) router waits for the hold time to expire before it updates the priority and initiates the switchover if the priority is higher than the priority for the VRRP primary (original backup) router.

If the asymmetric-hold-time statement is not configured, the VRRP primary waits for the hold time to expire before it initiates a switchover when a tracked route goes down or when the bandwidth of a tracked interface decreases.

Example: Configuring Asymmetric Hold Time

By default, the backup VRRP router drops ARP requests for the VRRP-IP to VRRP-MAC address translation. This means that the backup router does not learn the ARP (IP-to-MAC address) mappings for the hosts sending the requests. When it detects a failure of the primary router and transitions to become the new primary router, the backup router must re-learn all the entries that were present in the ARP cache of the primary router. In environments with many directly attached hosts, such as metro Ethernet environments, the number of ARP entries to learn can be high. This can cause a significant transition delay, during which the traffic transmitted to some of the hosts might be dropped.

Passive ARP learning enables the ARP cache in the backup router to hold approximately the same contents as the ARP cache in the primary router, thus preventing the problem of learning ARP entries in a burst. To enable passive ARP learning, include the passive-learning statement at the [edit system arp] hierarchy level:

We recommend setting passive learning on both the backup and primary VRRP routers. Doing so prevents the need to manually intervene when the primary router becomes the backup router. While a router is operating as the primary router, the passive learning configuration has no operational impact. The configuration takes effect only when the router is operating as a backup router.

For information about configuring gratuitous ARP and the ARP aging timer, see the Junos OS Administration Library for Routing Devices.

VRRP can track whether a logical interface is up, down, or not present, and can also dynamically change the priority of the VRRP group based on the state of the tracked logical interface, triggering a new primary router election. VRRP can also track the operational speed of a logical interface and dynamically update the priority of the VRRP group when the speed crosses a configured threshold.

When interface tracking is enabled, you cannot configure a priority of 255 (a priority of 255 designates the primary router). For each VRRP group, you can track up to 10 logical interfaces.

To configure a logical interface to be tracked, include the following statements:

You can include these statements at the following hierarchy levels:

• [edit interfaces interface-name unit logical-unit-number family inet address address vrrp-group group-id]

• [edit interfaces interface-name unit logical-unit-number family inet6 address address vrrp-inet6-group group-id]

• [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family inet address address vrrp-group group-id]

• [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family inet6 address address vrrp-inet6-group group-id]

The interface specified is the interface to be tracked for the VRRP group. The priority hold time is the minimum length of time that must elapse between dynamic priority changes. A tracking event, such as an interface state change (up or down) or a change in bandwidth, triggers one of the following responses:

• The first tracking event initiates the priority hold timer, and also initializes the pending priority based on the current priority and the priority cost. However, the current priority remains unchanged.

• A tracking event or a manual configuration change that occurs while the priority hold timer is on triggers a pending priority update. However, the current priority remains unchanged.

This ensures that Junos OS does not initiate primary role elections every time a tracked interface flaps.

When the priority hold time expires, the current priority inherits the value from the pending priority, and the pending priority ceases.

There are two priority-cost statements that show at this hierarchy level. The bandwidth-threshold statement specifies a threshold for the tracked interface. When the bandwidth of the tracked interface drops below the configured bandwidth threshold value, the VRRP group uses the bandwidth threshold priority cost. You can track up to five bandwidth threshold statements for each tracked interface. Just under the interface statement there is a priority-cost statement that gives the value to subtract from priority when the interface is down.

The sum of the priority costs for all tracked logical interfaces must be less than or equal to the configured priority of the VRRP group. If you are tracking more than one interface, the router applies the sum of the priority costs for the tracked interfaces (at most, only one priority cost for each tracked interface) to the VRRP group priority.

Prior to Junos OS Release 15.1, an adjusted priority could not be zero. If the difference between the priority costs and the configured priority of the VRRP group was zero, the adjusted priority would become 1.

The priority value zero (0) indicates that the current primary router has stopped participating in VRRP. Such a priority value is used to trigger one of the backup routers to quickly transition to the primary router without having to wait for the current primary to time out.

If you are tracking more than one interface, the router applies the sum of the priority costs for the tracked interfaces (at most, only one priority cost for each tracked interface) to the VRRP group priority. However, the interface priority cost and bandwidth threshold priority cost values for each VRRP group are not cumulative. The router uses only one priority cost to a tracked interface as indicated in Table 1.

You must configure an interface priority cost only if you have configured no bandwidth thresholds. If you have not configured an interface priority cost value, and the interface is down, the interface uses the bandwidth threshold priority cost value of the lowest bandwidth threshold.

VRRP can track whether a route is reachable (that is, the route exists in the routing table of the routing instance included in the configuration) and dynamically change the priority of the VRRP group based on the reachability of the tracked route, triggering a new primary router election.

To configure a route to be tracked, include the following statements:

You can include these statements at the following hierarchy levels:

• [edit interfaces interface-name unit logical-unit-number family inet address address vrrp-group group-id]

• [edit interfaces interface-name unit logical-unit-number family inet6 address address vrrp-inet6-group group-id]

• [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family inet address address vrrp-group group-id]

• [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family inet6 address address vrrp-inet6-group group-id]

The route prefix specified is the route to be tracked for the VRRP group. The priority hold time is the minimum length of time that must elapse between dynamic priority changes. A route tracking event, such as adding a route to or removing a route from the routing table, might trigger one or more of the following:

• The first tracking event initiates the priority hold timer, and also initializes the pending priority based on the current priority and the priority cost. However, the current priority remains unchanged.

• A tracking event or a manual configuration change that occurs while the priority hold timer is on triggers a pending priority update. However, the current priority remains unchanged.

When the priority hold time expires, the current priority inherits the value from the pending priority, and the pending priority ceases.

This ensures that Junos OS does not initiate primary role elections every time a tracked route flaps.

The routing instance is the routing instance in which the route is to be tracked. If the route is in the default, or global, routing instance, specify the instance name as default.

The priority cost is the value to be subtracted from the configured VRRP priority when the tracked route goes down, forcing a new primary router election. The value can be from 1 through 254.

The sum of the priority costs for all tracked routes must be less than or equal to the configured priority of the VRRP group. If you are tracking more than one route, the router applies the sum of the priority costs for the tracked routes (at most, only one priority cost for each tracked route) to the VRRP group priority.

Prior to Junos OS Release 15.1, an adjusted priority could not be zero. If the difference between the priority costs and the configured priority of the VRRP group was zero, the adjusted priority would become 1.

The priority value zero (0) indicates that the current primary router has stopped participating in VRRP. Such a priority value is used to trigger one of the backup routers to quickly transition to the primary router without having to wait for the current primary to time out.

Junos OS enables you to configure VRRP groups on the various subnets of a VLAN to inherit the state and configuration of one of the groups, which is known as the active VRRP group. When the vrrp-inherit-from configuration statement is included in the configuration, only the active VRRP group, from which the other VRRP groups are inheriting the state, sends out frequent VRRP advertisements, and processes incoming VRRP advertisements. The groups that are inheriting the state do not process any incoming VRRP advertisement because the state is always inherited from the active VRRP group. However, the groups that are inheriting the state do send out VRRP advertisements once every 2 to 3 minutes to facilitate MAC address learning on the switches placed between the VRRP routers.

If the vrrp-inherit-from statement is not configured, each of the VRRP primary groups in the various subnets on the VLAN sends out separate VRRP advertisements and adds to the traffic on the VLAN.

To configure inheritance for a VRRP group, include the vrrp-inherit-from statement at the [edit interfaces interface-name unit logical-unit-number family inet address address vrrp-group group-id] hierarchy level.

When you configure a group to inherit a state from another group, the inheriting groups and the active group must be on the same physical interface and logical system. However, the groups do not need to necessarily be on the same routing instance (as was in Junos OS releases earlier than 9.6), VLAN, or logical interface.

When you include the vrrp-inherit-from statement for a VRRP group, the VRRP group inherits the following parameters from the active group:

• advertise-interval

• authentication-key

• authentication-type

• fast-interval

• preempt | no-preempt

• priority

• track interfaces

• track route

However, you can configure the accept-data | no-accept-data statement for the group to specify whether the interface should accept packets destined for the virtual IP address.

In VRRP implementations where the router acting as the primary router is not the IP address owner—the IP address owner is the router that has the interface whose actual IP address is used as the virtual router’s IP address (virtual IP address)— the primary router accepts only the ARP packets from the packets that are sent to the virtual IP address. Junos OS enables you to override this limitation with the help of the accept-data configuration. When the accept-data statement is included in the configuration, the primary router accepts all packets sent to the virtual IP address even when the primary router is not the IP address owner.

To configure an interface to accept all packets sent to the virtual IP address, include the accept-data statement:

You can include this statement at the following hierarchy levels:

• [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-id]

• [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (Inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-id]

To prevent a primary router that is the IP address owner or has its priority set to 255 from accepting packets other than the ARP packets addressed to the virtual IP address, include the no-accept-data statement:

The silent period starts when the interface state is changed from down to up. During this period, the Primary Down Event is ignored. Configure the silent period interval to avoid alarms caused by the delay or interruption of the incoming VRRP advertisement packets during the interface startup phase.

To configure the silent period interval that the Primary Down Event timer ignores, include the startup-silent-period statement at the [edit protocols vrrp] hierarchy level:

When you have configured startup-silent-period, the Primary Down Event is ignored until the startup-silent-period expires.

For example, configure a VRRP group, vrrp-group1, with an advertise interval of 1 second, startup silent period of 10 seconds, and an interface interface1 with a priority less than 255.

When interface1 transitions from down to up:

• The vrrp-group1 group moves to the backup state, and starts the Primary Down Event timer (3 seconds; three times the value of the advertise interval, which is 1 second in this case).

• If no VRRP PDU is received during the 3-second period, the startup-silent-period (10 seconds in this case) is checked, and if the startup silent period has not expired, the Primary Down Event timer is restarted. This is repeated until the startup-silent-period expires. In this example, the Primary Down Event timer runs four times (12 seconds) by the time the 10-second startup silent period expires.

• If no VRRP PDU is received by the end of the fourth 3-second cycle, vrrp-group1 takes over the primary role.

Typically, VRRP advertisements are sent by the VRRP process (vrrpd) on the primary VRRP router at regular intervals to let other members of the group know that the VRRP primary router is operational.

When the vrrpd process is busy and does not send VRRP advertisements, the backup VRRP routers might assume that the primary router is down and take over as the primary router, causing unnecessary flaps. This takeover might occur even though the original primary router is still active and available and might resume sending advertisements after the traffic has decreased. To address this problem and to reduce the load on the vrrpd process, Junos OS uses the periodic packet management process (ppmd) to send VRRP advertisements on behalf of the vrrpd process. However, you can further delegate the job of sending VRRP advertisements to the distributed ppmd process that resides on the Packet Forwarding Engine.

The ability to delegate the sending of VRRP advertisements to the distributed ppmd process ensures that the VRRP advertisements are sent even when the ppmd process—which is now responsible for sending VRRP advertisements—is busy. Such delegation prevents the possibility of false alarms when the ppmd process is busy. The ability to delegate the sending of VRRP advertisements to distributed ppmd also adds to scalability because the load is shared across multiple ppmd instances and is not concentrated on any single unit.

To configure the distributed ppmd process to send VRRP advertisements, include the delegate-processing statement at the [edit protocols vrrp] hierarchy level:

To configure the distributed ppmd process to send VRRP advertisements over aggregated Ethernet and IRB interfaces, include the delegate-processing ae-irb statement at the [edit protocols vrrp] hierarchy level:

To trace VRRP operations, include the traceoptions statement at the [edit protocols vrrp] hierarchy level.

By default, VRRP logs the error, data carrier detect (DCD) configuration, and routing socket events in a file in the /var/log directory. By default, this file is named /var/log/vrrpd. The default file size is 1 megabyte (MB), and three files are created before the first one gets overwritten.

To change the configuration of the logging file, include the traceoptions statement at the [edit protocols vrrp] hierarchy level:

You can specify the following VRRP tracing flags:

• all—Trace all VRRP operations.

• database—Trace all database changes.

• general—Trace all general events.

• interfaces—Trace all interface changes.

• normal—Trace all normal events.

• packets—Trace all packets sent and received.

• state—Trace all state transitions.

• timer—Trace all timer events.