Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Junos OS Support for VRRPv3

Prior to Junos OS 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.

Starting with Junos OS Release 12.2, Junos OS supports RFC 3768, Virtual Router Redundancy Protocol (VRRP) for IPv4. The support for VRRPv3 is implemented in compliance with RFC 5798, Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv6. Junos OS Release 12.2 also supports VRRP MIB for VRRPv3. The support for VRRP MIB for VRRPv3 is implemented in compliance with RFC 6527, Definitions of Managed Objects for the Virtual Router Redundancy Protocol Version 3 (VRRPv3).

When you configure VRRP for IPv4 or IPv6 networks, you can enable VRRPv3 by configuring the version-3 statement at the [edit protocols vrrp] hierarchy level.

Note: When enabling VRRPv3, you must ensure that VRRPv3 is enabled on all the VRRP routers in the network. This is because VRRPv3 does not interoperate with the previous versions of VRRP.

Understanding VRRPv3 Behavioral Differences

• Prior to Junos OS Release 12.2, when VRRP for IPv6 is configured without enabling VRRPv3, the VRRP checksum is calculated according to section 5.3.8 of RFC 3768, Virtual Router Redundancy Protocol (VRRP). However, when VRRPv3 is enabled, the VRRP checksum is calculated according to section 5.3.7 of draft-ietf-vrrp-ipv6-spec-08.txt, Virtual Router Redundancy Protocol for IPv6. Therefore, when IPv6 VRRP packets are received or transmitted, the VRRP checksum is calculated according to:
  • RFC 3768, when VRRPv3 is not enabled.
  • draft-ietf-vrrp-ipv6-spec-08.txt, when VRRPv3 is enabled.
• Starting with Junos OS Release 12.2, when VRRP for IPv6 is configured without enabling VRRPv3, the VRRP checksum is calculated according to section 5.2.8 of RFC 5798, Virtual Router Redundancy Protocol (VRRP). However, when VRRPv3 is enabled, the VRRP checksum is calculated according to section 5.3.7 of draft-ietf-vrrp-ipv6-spec-08.txt, Virtual Router Redundancy Protocol for IPv6. Therefore, when IPv6 VRRP packets are received or transmitted, the VRRP checksum is calculated according to:
  • RFC 5798, when VRRPv3 is not enabled.
  • draft-ietf-vrrp-ipv6-spec-08.txt, when VRRPv3 is enabled.

  Moreover, when VRRPv3 is enabled, pseudo-header is included only when calculating IPv6 VRRP checksum. Pseudo-header is not included when calculating IPv4 VRRP checksum. Therefore, care must be taken to correctly calculate the IPv4 and IPv6 checksum values when VRRPv3 is enabled.

  Note: 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.

• The tcpdump utility calculates the VRRP checksum according to draft-ietf-vrrp-ipv6-spec-08.txt. Therefore, when tcpdump parses IPv6 VRRP packets that are received from older Junos OS releases (prior to Junos OS Release 12.2), the bad vrrp cksum message is displayed:

  23:20:32.657328 Out
  ...
          -----original packet-----
          00:00:5e:00:02:03 > 33:33:00:00:00:12, ethertype IPv6 (0x86dd), length 94: (class 0xc0, hlim 255, next-header: VRRP (112), length: 40) fe80::224:dcff:fe47:57f > ff02::12: VRRPv3-advertisement 40: vrid=3 prio=100 intvl=100(centisec)  (bad vrrp cksum b4e2!) addrs(2): fe80::200:5eff:fe00:3,2001:4818:f000:14::1
                           3333 0000 0012 0000 5e00 0203 86dd 6c00
                           0000 0028 70ff fe80 0000 0000 0000 0224
                           dcff fe47 057f ff02 0000 0000 0000 0000
                           0000 0000 0012 3103 6402 0064 b4e2 fe80
                           0000 0000 0000 0200 5eff fe00 0003 2001
                           4818 f000 0014 0000 0000 0000 0001
  

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

• When VRRPv3 is enabled, the authentication-type and authentication-key statements (for IPv4 VRRP) cannot be configured for any VRRP groups. Therefore, if authentication is required, you need to configure alternative non-VRRP authentication mechanisms.
• When VRRPv3 is enabled, the advertise-interval statement (for IPv4 VRRP) and the inet6-advertise-interval statement (for IPv6 VRRP) cannot be used to configure advertisement intervals. Instead, use the fast-interval statement to configure advertisement intervals.
• 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 masters in the network. Due to this behavior, you must be cautious when enabling VRRPv3 on your existing VRRPv2 networks. See Understanding VRRPv2 to VRRPv3 Transition for more information.

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

Understanding VRRPv2 to VRRPv3 Transition

You must enable VRRPv3 in your network only if VRRPv3 can be enabled on all the VRRP routers in your network. Even if VRRPv3 can be enabled on all the VRRP routers in your network, care must be taken to avoid traffic loss when you transition your network to VRRPv3. This is because it is practically not possible to configure VRRPv3 on all routers simultaneously. There is a small time frame in the transition period during which VRRPv2 and VRRPv3 coexist in the network. During this period, to avoid having multiple masters in the network, the VRRPv3 IPv4 routers switch to the backup state when they receive a VRRPv2 IPv4 advertisement packet. VRRPv2 IPv4 packets are always given the highest priority. Additionally, to avoid having multiple masters in your IPv6 network due to checksum differences, you need to disable VRRP for IPv6 on the backup routers.

Note: Configuration change from VRRPv2 to VRRPv3 (or VRRPv3 to VRRPv2) restarts the VRRP state machine on all the configured VRRP groups.

The following example illustrates the steps and events that take place during a VRRPv2 to VRRPv3 transition:

Consider a scenario where two VRRPv2 routers, R1 and R2, are configured in two groups, G1 and G2. The R1 router acts as the master for G1 and the R2 router acts as the master for G2. Table 1 lists the transition steps and events for this setup: