Understanding VRRP

VRRP Differences on QFabric Systems

Configuring servers on your network with static routes to a default gateway minimizes configuration effort and complexity and reduces processing overhead. However, a failure of the default gateway normally results in a catastrophic event, isolating the servers. Using Virtual Router Redundancy Protocol (VRRP) enables you to dynamically provide alternative gateways for servers if the primary gateway fails.

Switches configured with VRRP share a virtual IP (VIP) address, which is the address you configure as the default route on the servers. In normal VRRP operation, one of the switches is the VRRP primary, meaning that it owns the VIP and is the active default gateway. The other devices are backups. The switches dynamically assign primary and backup roles based on priorities that you configure. If the primary fails, the backup switch with the highest priority becomes the primary and takes ownership of the VIP within a few seconds. This is done without any interaction with the servers.

You can configure two QFabric systems to participate in a VRRP configuration as if they were two standalone switches. However, in normal VRRP operation, only one system can be the primary for a given VRRP group at any one time, which means that only one system can act as a default gateway using the VIP configured for the group. When running VRRP over two QFabric systems, you might want both systems to simultaneously use the VIP to act as a gateway and forward traffic. To achieve this, you can configure a firewall filter to block the VRRP advertisement packets between the QFabric systems on the link between the two network Node groups. When you do this, both QFabric systems act as primary and forward traffic received by the VIP (which is the default gateway address that you configure on servers connected to both QFabric systems). If you use VMware’s vMotion, this configuration allows virtual machines to transition between servers connected to the QFabric systems without updating their default gateway information. For example, a virtual machine running on a server connected to a QFabric system in data center A can transition to a server connected to a QFabric system in data center B without needing to resolve a new gateway IP address and MAC address because both QFabric systems use the same VIP.

Configuration Details

Configuring a VRRP group across two QFabric systems is similar to configuring VRRP on two switches. The main differences are listed here:

• All the interfaces in both QFabric systems that participate in VRRP must be members of the same VLAN.

• You must create routed VLAN interfaces (RVIs) in that VLAN on both QFabric systems.

• The IP addresses that you assign to both RVIs must be in the same subnet.

• You must configure VRRP on the RVIs.

• Both RVIs must be members of the same VRRP group. This is what allows the two QFabric systems to share a virtual IP address.

The following tables list the elements of an example VRRP configuration running on two QFabric systems–QFabric system A and QFabric system B. This example is configured so that both QFabric systems act as the VRRP primary for VIP 10.1.1.50/24 and assumes that a firewall filter blocks the VRRP advertisements between the systems. Table 1 lists the required characteristics of the RVIs in the example configuration.

You must configure VRRP on the RVIs on both QFabric systems.Table 2 lists the elements of a sample VRRP configuration on each RVI. Note that with the exception of the priority, the parameters must be the same on both systems.

Table 3 lists the all the interfaces on QFabric system A in the example configuration and identifies what they connect to.

Table 4 lists the all the interfaces on QFabric system B in the example configuration and identifies what they connect to.

Junos OS VRRP Support

In releases earlier than Release 12.2, Junos OS supported RFC 3768, Virtual Router Redundancy Protocol (VRRP) (for IPv4) and Internet draft draft-ietf-vrrp-ipv6-spec-08, Virtual Router Redundancy Protocol for IPv6.

VRRPv3 is not supported on routers that use releases earlier than Junos OS Release 12.2 and is also not supported for IPv6 on QFX10000 switches.

Starting with Release 12.2, Junos OS supports:

• RFC 3768, Virtual Router Redundancy Protocol (VRRP)

• RFC 5798, Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6

• RFC 6527, Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3)

IPv6 VRRP Checksum Behavioral Differences

You must consider the following checksum differences when enabling IPv6 VRRP networks:

• In releases earlier than Junos OS Release 12.2, when VRRP for IPv6 is configured, the VRRP checksum is calculated according to section 5.3.8 of RFC 3768, Virtual Router Redundancy Protocol (VRRP).

• Starting with Junos OS Release 12.2, when VRRP for IPv6 is configured, irrespective of VRRPv3 being enabled or not, the VRRP checksum is calculated according to section 5.2.8 of RFC 5798, Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6.

  Moreover, the pseudoheader is included only when calculating the IPv6 VRRP checksum. The pseudoheader is not included when calculating the IPv4 VRRP checksum.

  To make the router with Junos OS Release 12.2 (or later Junos OS releases) IPv6 VRRP interoperate with the router running a Junos OS release earlier than Release 12.2, include the checksum-without-pseudoheader configuration statement at the [edit protocols vrrp] hierarchy level in the router running Junos OS Release 12.2 or later.

• The tcpdump utility in Junos OS Release 12.2 and later calculates the VRRP checksum according to RFC 5798, Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6. Therefore, when tcpdump parses IPv6 VRRP packets that are received from older Junos OS releases (earlier than Junos OS Release 12.2), the bad vrrp cksum message is displayed:

  You can ignore this message because it does not indicate VRRP failure.

VRRP Interoperability

In releases earlier than Junos OS Release 12.2, VRRP (IPv6) followed Internet draft draft-ietf-vrrp-ipv6-spec-08, but checksum was calculated based on RFC 3768 section 5.3.8. Starting with Release 12.2, VRRP (IPv6) follows RFC 5798 and checksum is calculated based on RFC 5798 section 5.2.8. Because of the differences in VRRP checksum calculations, IPv6 VRRP configured on routers that use Junos OS Release 12.2 and later releases does not interoperate with IPv6 VRRP configured in releases before Junos OS Release 12.2.

To make the router with Junos OS Release 12.2 (or later Junos OS releases) IPv6 VRRP interoperate with the router running Junos OS releases earlier than Release 12.2, include the checksum-without-pseudoheader configuration statement at the [edit protocols vrrp] hierarchy level in the router with Junos OS Release 12.2 or later.

Here are some general points to know about VRRP interoperability:

• If you have configured VRRPv3 (IPv4 or IPv6) on routers that use Junos OS Release 12.2 or later releases, it will not operate with routers that use Junos OS Release 12.1 or earlier releases. This is because only Junos OS Release 12.2 and later releases support VRRPv3.

• VRRP (IPv4 or IPv6) configured on routers that use Junos OS Release 12.2 and later releases interoperate with VRRP (IPv4 or IPv6) configured on routers that use releases earlier than Junos OS Release 12.2.

• VRRPv3 for IPv4 does not interoperate with the previous versions of VRRP. If VRRPv2 IPv4 advertisement packets are received by a router on which VRRPv3 is enabled, the router transitions itself to the backup state to avoid creating multiple primaries in the network. Due to this behavior, you must be cautious when enabling VRRPv3 on your existing VRRPv2 networks. See Upgrading from VRRPv2 to VRRPv3 for more information.

  Note:

  VRRPv3 advertisement packets are ignored by the routers on which previous versions of VRRP are configured.

Upgrading from VRRPv2 to VRRPv3

Enable VRRPv3 in your network only if VRRPv3 can be enabled on all the VRRP routers in your network.

Enable VRRPv3 on your VRRPv2 network only when upgrading from VRRPv2 to VRRPv3. Mixing the two versions of VRRP is not a permanent solution.

Upgrading from VRRPv2 to VRRPv3 must be done very carefully to avoid traffic loss, due to these considerations:

• It is not possible to configure VRRPv3 on all routers simultaneously.

• During the transition period, both VRRPv2 and VRRPv3 operate in the network.

• Changing VRRP versions restarts the state machine for all VRRP groups.

• VRRPv3 (for IPv4) routers default to the backup state when they get VRRPv2 (for IPv4) advertisement packets.

• VRRPv2 (for IPv4) packets are always given the highest priority.

• Checksum differences between VRRPv2 and VRRPv3 (for IPv6) can create multiple primary routers.

  Disable VRRPv3 (for IPv6) on the backup routers while upgrading to avoid creating multiple primary routers.

Table 5 illustrates the steps and events that take place during a VRRPv2 to VRRPv3 transition. In Table 5, two VRRPv2 routers, R1 and R2, are configured in two groups, G1 and G2. Router R1 acts as the primary for G1, and Router R2 acts as the primary for G2.

When enabling VRRPv3, make sure that VRRPv3 is enabled on all the VRRP routers in the network because VRRPv3 (IPv4) does not interoperate with the previous versions of VRRP. For example, if VRRPv2 IPv4 advertisement packets are received by a router on which VRRPv3 is enabled, the router transitions itself to the backup state to avoid creating multiple primaries in the network.

You can enable VRRPv3 by configuring the version-3 statement at the [edit protocols vrrp] hierarchy level (for IPv4 or IPv6 networks). Configure the same protocol version on all VRRP routers on the LAN.

Functionality of VRRPv3 Features

Some Junos OS features differ in VRRPv3 from previous VRRP versions.

• VRRPv3 Authentication
• VRRPv3 Advertisement Intervals
• Unified ISSU for VRRPv3

When failover-delay Is Not Configured

Without failover-delay configured, the sequence of events for VRRP sessions operated from the Routing Engine is as follows:

1. When the first VRRP group detected by the Routing Engine changes state, and the new state is primary, the Routing Engine generates appropriate VRRP announcement messages. The Packet Forwarding Engine is informed about the state change, so that hardware filters for that group are reprogrammed without delay. The new primary then sends gratuitous ARP message to the VRRP groups.

2. The delay in failover timer starts. By default, failover-delay timer is:

   • 500 miliseconds—when the configured VRRP announcement interval is less than 1 second.

   • 2 seconds—when the configured VRRP announcement interval is 1 second or more, and the total number of VRRP groups on the router is 255.

   • 10 seconds—when the configured VRRP announcement interval is 1 second or more, and the number of VRRP groups on the router is more than 255.

3. The Routing Engine performs one-by-one state change for subsequent VRRP groups. Every time there is a state change, and the new state for a particular VRRP group is primary, the Routing Engine generates appropriate VRRP announcement messages. However, communication toward the Packet Forwarding Engine is suppressed until the failover-delay timer expires.

4. After failover-delay timer expires, the Routing Engine sends message to the Packet Forwarding Engine about all VRRP groups that managed to change the state. As a consequence, hardware filters for those groups are reprogrammed, and for those groups whose new state is primary, gratuitous ARP messages are sent.

This process repeats until state transition for all VRRP groups is complete.

Thus, without configuring failover-delay, the full state transition (including states on the Routing Engine and the Packet Forwarding Engine) for the first VRRP group is performed immediately, while state transition on the Packet Forwarding Engine for remaining VRRP groups is delayed by at least 0.5-10 seconds, depending on the configured VRRP announcement timers and the number of VRRP groups. During this intermediate state, receiving traffic for VRRP groups for state changes that were not yet completed on the Packet Forwarding Engine might be dropped at the Packet Forwarding Engine level due to deferred reconfiguration of hardware filters.

When failover-delay Is Configured

When failover-delay is configured, the sequence of events for VRRP sessions operated from the Routing Engine is modified as follows:

1. The Routing Engine detects that some VRRP groups require a state change.

2. The failover-delay starts for the period configured. The allowed failover-delay timer range is 50 through 100000 miliseconds.

3. The Routing Engine performs one-by-one state change for the VRRP groups. Every time there is a state change, and the new state for a particular VRRP group is primary, the Routing Engine generates appropriate VRRP announcement messages. However, communication toward the Packet Forwarding Engine is suppressed until the failover-delay timer expires.

4. After failover-delay timer expires, the Routing Engine sends message to the Packet Forwarding Engine about all VRRP groups that managed to change the state. As a consequence, hardware filters for those groups are reprogrammed, and for those groups whose new state is primary, gratuitous ARP messages are sent.

This process repeats until state transition for all VRRP groups is complete.

Thus, when failover-delay is configured even the Packet Forwarding Engine state for the first VRRP group is deferred. However, the network operator has the advantage of configuring a failover-delay value that best suits the need of the network deployment to ensure minimal outage during VRRP state change.

failover-delay influences only VRRP sessions operated by the VRRP process (vrrpd) running on the Routing Engine. For VRRP sessions distributed to the Packet Forwarding Engine, failover-delay configuration has no effect.