Skip to main content

Interoperability between the Virtual Router Redundancy Protocol and PIM

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7910.
Author Wei Zhou
Last updated 2016-06-16 (Latest revision 2016-03-11)
RFC stream Independent Submission
Intended RFC status Informational
IETF conflict review conflict-review-zhou-pim-vrrp
Stream ISE state Published RFC
Consensus boilerplate Unknown
Document shepherd Eliot Lear
Shepherd write-up Show Last changed 2016-03-15
IESG IESG state Became RFC 7910 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to "Nevil Brownlee" <>
IANA IANA review state IANA OK - No Actions Needed
IANA action state No IANA Actions
Network Working Group                                            W. Zhou
Internet-Draft                                             cisco Systems
Intended status: Informational                         February 23, 2016
Expires: August 26, 2016

                       VRRP PIM Interoperability


   This document introduces VRRP Aware PIM, a redundancy mechanism for
   the Protocol Independent Multicast (PIM) to interoperate with Virtual
   Router Redundancy Protocol (VRRP).  It allows PIM to track VRRP state
   and to preserve multicast traffic upon failover in a redundant
   network with virtual routing groups enabled.  The mechanism described
   in this document is based on Cisco IOS software implementation.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 26, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Zhou                     Expires August 26, 2016                [Page 1]
Internet-Draft          VRRP PIM Interoperability          February 2016

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Tracking and Failover . . . . . . . . . . . . . . . . . . . .   3
   3.  PIM Assert Metric Auto-Adjustment . . . . . . . . . . . . . .   4
   4.  DF Election for BiDir Group . . . . . . . . . . . . . . . . .   4
   5.  Tracking Multiple VRRP Groups on an Interface . . . . . . . .   5
   6.  Support of HSRP . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   10. Informative References  . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Virtual Router Redundancy Protocol (VRRP) [RFC5798] is a redundancy
   protocol for establishing a fault-tolerant default router.  The
   protocol establishes a framework between network devices in order to
   achieve default device failover if the primary devices becomes

   PIM [RFC4601] has no inherent redundancy capabilities and its
   operation is completely independent of VRRP group states.  As a
   result, IP multicast traffic is forwarded not necessarily by the same
   device as is elected by VRRP.  The VRRP Aware PIM feature provides
   consistent IP multicast forwarding in a redundant network with
   virtual routing groups enabled.

   In a multi-access segment (such as LAN), PIM designated router (DR)
   election is unaware of the redundancy configuration, and the elected
   DR and VRRP master router (MR) may not be the same router.  In order
   to ensure that the PIM DR is always able to forward PIM Join/Prune
   (J/P) message towards RP or FHR, the VRRP MR becomes the PIM DR (if
   there is only one VRRP group).  PIM is responsible for adjusting DR
   priority based on the group state.  When a failover occurs, multicast
   states are created on the new MR elected by the VRRP group and the MR
   assumes responsibility for the routing and forwarding of all the
   traffic addressed to the VRRP virtual IP address (vIP).  This ensures
   the PIM DR runs on the same router as the VRRP MR and maintains
   mroute states.  It enables multicast traffic to be forwarded through
   the VRRP MR, allowing PIM to leverage VRRP redundancy, avoid
   potential duplicate traffic, and enable failover, depending on the
   VRRP states in the router.

Zhou                     Expires August 26, 2016                [Page 2]
Internet-Draft          VRRP PIM Interoperability          February 2016

   This mechanism can be safely deployed into a PIM network without
   changing the behavior of other routers.  When only a specific set of
   routers enabled this feature, user can configure PIM interfaces to
   track state change events of desired VRRP group(s).  When a router
   becomes VRRP MR, PIM component applies the user-defined DR priority
   value to the interface in order to make it PIM DR.  Other routers
   will not break the functionality of this feature, as long as their
   configured DR priority do not conflict with the participating
   routers.  When deployed in PIM transit network, downstream routers
   should configure static route to use vIP as next-hop address for PIM
   J/P messages in order to take advantage of this feature.  If dynamic
   routing is used and next-hop address is selected by unicast routing
   information as described in [RFC5294], then they cannot leverage the
   VRRP redundancy and failover mechanism.  These downstream routers,
   however, do not have to support this new feature and there is no
   additional configuration or coordination required from manageability
   point of view.  This mechanism does not change any bit on the wire,
   and it has been implemented on Cisco IOS software.

2.  Tracking and Failover

   Without the mechanisms described in this document, a PIM component
   will send PIM J/P with DR's IP address to upstream routers.  A GenId
   in PIM Hello message is randomly selected when the router boots and
   remains the same as long as the router is up.  A PIM neighbor reboot
   can easily be detected if its GenId is different from before, in this
   case PIM J/P and RP-Set information can be redistributed to the new
   rebooted neighbor.  With VRRP aware PIM mechanism enabled, PIM
   component listens to the state change notifications from VRRP and
   automatically adjusts the priority of the PIM DR based on the VRRP
   state, and ensures VRRP MR (if there is only one VRRP group) becomes
   the DR of the LAN.  If there are multiple VRRP groups, the DR is
   determined by user-configured priority value.

   Upon failover, PIM component triggers communication between upstream
   and downstream routers in order to create mroute states on the new
   VRRP MR.  PIM component sends an additional PIM Hello message using
   the VRRP vIP as the source address for each active VRRP group when a
   router becomes VRRP Master.  The PIM Hello message with new GenID
   will trigger other routers to respond to the VRRP failover event in
   the same way of PIM neighbor reboot event as described in [RFC5294].
   Specifically, when a downstream router receives this PIM Hello
   message, it will add the source IP address (in this case the VRRP
   vIP) into its PIM neighbor list, and immediately send triggered PIM
   J/P messages towards vIP.  Upstream routers will process PIM J/P
   based on VRRP group state.  If PIM J/P next-hop address matches VRRP
   vIP, only the current VRRP MR will process the PIM J/P messages.

Zhou                     Expires August 26, 2016                [Page 3]
Internet-Draft          VRRP PIM Interoperability          February 2016

   This allows all PIM J/P to reach the VRRP group vIP and minimizes
   changes and configurations at the downstream routers.

   Alternatively, implementation can choose to have all VRRP passive
   routers maintain mroute states and record the GenID of current MR.
   When a passive router becomes MR, it uses the existing mroute states
   and the recorded MR GenID in its PIM Hello message.  This will avoid
   resending PIM J/P messages upon failover and eliminates the
   requirement of additional PIM Hello with vIP.  There is no change in
   on-wire behavior or in the PIM and VRRP message format.

3.  PIM Assert Metric Auto-Adjustment

   It is possible that, after VRRP Master switched from A to B; A is
   still forwarding multicast traffic which will result in duplicate
   traffic and PIM Assert mechanism will kick in.  PIM Assert with
   redundancy is enabled.

   o  If only one VRRP group, passive routers will send arbitrary
      penalty metric preference (PIM_ASSERT_INFINITY - 1) and make MR
      the Assert winner.

   o  If there are multiples VRRP groups configured on an interface,
      Assert metric preference will be (PIM_ASSERT_INFINITY - 1) if and
      only if all VRRP groups are in passive state.

   o  If there is at least one VRRP group is in Active, then original
      Assert metric preference will be used.  That is, winner will be
      selected between routers using their real Assert metric preference
      with at least one active VRRP Group, just like no VRRP is

4.  DF Election for BiDir Group

   Change to DF offer/winner metric is handled similarly to PIM Assert
   handling with VRRP.

   o  If only one VRRP group, passive routers will send a large penalty
      metric preference in Offer (PIM_BIDIR_INFINITY_PREF- 1) and make
      MR the DF winner.

   o  If there are multiples VRRP groups configured on an interface,
      Offer metric preference will be (PIM_BIDIR_INFINITY_PREF- 1) if
      and only if all VRRP groups are in passive.

   o  If there is at least one VRRP group is in Active, then original
      Offer metric preference to RP will be used.  That is, winner will

Zhou                     Expires August 26, 2016                [Page 4]
Internet-Draft          VRRP PIM Interoperability          February 2016

      be selected between routers using their real Offer metric, just as
      no VRRP is involved.

5.  Tracking Multiple VRRP Groups on an Interface

   User can configure PIM component to track more than one VRRP groups
   on an interface.  This allows other applications to exploit the PIM/
   VRRP interoperability to achieve various goals (e.g., load
   balancing).  Since each VRRP groups configured on an interface could
   be in different states at any moment, the DR priority is adjusted.
   PIM Assert metric and PIM Bidir DF metric if and only if all VRRP
   groups configured on an interface are in passive (non-Active) states
   to ensure that interfaces with all-passive VRRP groups will not win
   in DR, Assert and DF election.  In other words, DR, Assert, DF winner
   will be elected among the interfaces with at least one Active VRRP

6.  Support of HSRP

   Although there are differences between VRRP and Hot Standby Router
   Protocol (HSRP) [RFC2281] including number of backup (standby)
   routers, virtual IP address and timer intervals, the proposed scheme
   can also enable HSRP aware PIM with similar failover and tracking
   mechanism described in this draft.

7.  Security Considerations

   The proposed tracking mechanism does not discuss adding
   authentication to the protocols and introduces no new negative impact
   or threats on security to PIM in either SSM or ASM mode.  Note that
   VRRP messages from malicious nodes could cause unexpected behaviors
   such as multiple Masters and PIM DRs which are associated with VRRP
   specific security issues.  To mitigate the vulnerability of frequent
   VRRP and PIM DR state change from malicious attack, implementation
   can choose to enable VRRP preemption such that a higher-priority VRRP
   backup router does not take over for a lower-priority MR, this will
   reduce the state change notifications to PIM component and subsequent
   mroute state change.  Detailed analysis of PIM and VRRP security is
   provided in [RFC5294] and [RFC5798].

8.  IANA Considerations

   This document has no IANA actions.

Zhou                     Expires August 26, 2016                [Page 5]
Internet-Draft          VRRP PIM Interoperability          February 2016

9.  Acknowledgments

   I would like to give a special thank you and appreciation to Stig
   Venaas for his ideas and comments in this draft.

10.  Informative References

   [RFC2281]  Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot
              Standby Router Protocol (HSRP)", RFC 2281,
              DOI 10.17487/RFC2281, March 1998,

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601,
              DOI 10.17487/RFC4601, August 2006,

   [RFC5294]  Savola, P. and J. Lingard, "Host Threats to Protocol
              Independent Multicast (PIM)", RFC 5294,
              DOI 10.17487/RFC5294, August 2008,

   [RFC5798]  Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
              Version 3 for IPv4 and IPv6", RFC 5798,
              DOI 10.17487/RFC5798, March 2010,

Author's Address

   Wei Zhou
   cisco Systems
   Tasman Drive
   San Jose, CA  95134


Zhou                     Expires August 26, 2016                [Page 6]