Interoperability between the Virtual Router Redundancy Protocol and PIM
Keeping multicast flowing when routers fail over
Zhou, W., "Interoperability between the Virtual Router Redundancy Protocol and PIM", RFC 7910, DOI 10.17487/RFC7910, June 2016, <https://www.rfc-editor.org/info/rfc7910>.
@misc{rfc7910,
series = {Request for Comments},
number = 7910,
howpublished = {RFC 7910},
publisher = {RFC Editor},
doi = {10.17487/RFC7910},
url = {https://www.rfc-editor.org/info/rfc7910},
author = {W. Zhou},
title = {{Interoperability between the Virtual Router Redundancy Protocol and PIM}},
pagetotal = 6,
year = 2016,
month = jun,
} RFC text
Contents
Independent Submission W. Zhou Request for Comments: 7910 Cisco Systems Category: Informational June 2016 ISSN: 2070-1721 Interoperability between the Virtual Router Redundancy Protocol and PIM Abstract This document introduces VRRP-aware PIM, a redundancy mechanism for the Protocol Independent Multicast (PIM) to interoperate with the 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 document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7910. 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 (http://trustee.ietf.org/license-info) 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. 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. Informative References . . . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The 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 become inaccessible. Protocol Independent Multicast (PIM) [RFC7761] has no inherent redundancy capabilities and its operation is completely independent of VRRP group states. As a result, IP multicast traffic is not necessarily forwarded by the same device that 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), the elected PIM designated router (DR) is unaware of the redundancy configuration, and the elected DR and VRRP master router (MR) may not be the same. In order to ensure that the PIM DR is always able to forward a PIM Join/Prune (J/P) message towards Rendezvous Point (RP) or first-hop router, the VRRP MR becomes the PIM DR (if there is only one VRRP group). PIM is responsible for adjusting the 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 that the PIM DR runs on the same router as the VRRP MR and maintains multicast routing (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. This mechanism can be safely deployed into a PIM network without changing the behavior of other routers. When only a specific set of routers enable this feature, a user can configure PIM interfaces to track state-change events of desired VRRP group(s). When a router becomes the VRRP MR, the 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 does not conflict with the participating routers. When deployed in a PIM transit network, downstream routers should configure the static route to use vIP as the next-hop address for PIM J/P messages in order to take advantage of this feature. If dynamic routing is used and the next-hop address is selected by unicast routing information as described in [RFC5294], then these routes 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 a 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 messages with the DR's IP address to upstream routers. A GenID (Generation Identifier) in a 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, the PIM J/P and RP-Set information can be redistributed to the rebooted neighbor. With the VRRP-aware PIM mechanism enabled, the 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 the 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 the user- configured priority value. Upon failover, the PIM component triggers communication between upstream and downstream routers in order to create mroute states on the new VRRP MR. The 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 the VRRP MR. The PIM Hello message with a new GenID will trigger other routers to respond to the VRRP failover event in the same way as the 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 messages based on the VRRP group state. If the PIM J/P next-hop address matches the VRRP vIP, only the current VRRP MR will process the PIM J/P messages. This allows all PIM J/P messages to reach the VRRP group vIP and minimizes changes and configurations at the downstream routers. Alternatively, the implementation can choose to have all VRRP passive routers maintain mroute states and record the GenID of the current MR. When a passive router becomes the 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 will eliminate the requirement of an additional PIM Hello with vIP. There is no change in on-the-wire behavior or in the PIM and VRRP message format. 3. PIM Assert Metric Auto-Adjustment It is possible that, after the VRRP MR switches from router A to B, A would still forward multicast traffic, which will result in duplicate traffic. The PIM Assert mechanism will kick in because PIM Assert with redundancy is enabled. o If there is only one VRRP group, passive routers will send an 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, the 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 in Active state, then the original Assert metric preference will be used. That is, the winner will be selected between routers using their real Assert metric preference with at least one active VRRP Group, as if no VRRP is involved. 4. DF Election for BiDir Group Change to Designated Forwarder (DF) offer/winner metric is handled similarly to PIM Assert handling with VRRP. o If there is only one VRRP group, passive routers will send a large penalty metric preference in an offer (PIM_BIDIR_INFINITY_PREF- 1) and make MR the DF winner. o If there are multiples VRRP groups configured on an interface, the offer metric preference will be (PIM_BIDIR_INFINITY_PREF- 1) if and only if all VRRP groups are in Passive state. o If there is at least one VRRP group in Active state, then the original offer metric preference to RP will be used. That is, the winner will be selected between routers using their real offer metric, as if no VRRP is involved. 5. Tracking Multiple VRRP Groups on an Interface A user can configure a PIM component to track more than one VRRP groups on an interface. This allows other applications to exploit PIM/VRRP interoperability to achieve various goals (e.g., load balancing). Since each VRRP group that is configured on an interface could be in different states at any moment, the DR priority is adjusted. The PIM Assert metric and PIM BiDir DF metric should be adjusted if and only if all VRRP groups that are configured on an interface are in Passive (non-Active) states to ensure that interfaces with all-passive VRRP groups do not win DR, Assert, and DF election. In other words, the DR, Assert, and DF winners will be elected among the interfaces with at least one active VRRP group. 6. Support of HSRP Although there are differences between VRRP and the Hot Standby Router Protocol (HSRP) [RFC2281] -- including the number of backup (standby) routers, virtual IP address, and timer intervals -- the proposed scheme can also enable HSRP-aware PIM with similar failover and the tracking mechanism described in this document. 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 (Source-Specific Multicast) or ASM (Any-Source Multicast) mode. Note that VRRP messages from malicious nodes could cause unexpected behaviors such as multiple MRs 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, an 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 a PIM component and subsequent mroute state changes. Detailed analysis of PIM and VRRP security is provided in [RFC5294] and [RFC5798]. 8. 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, <http://www.rfc-editor.org/info/rfc2281>. [RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol Independent Multicast (PIM)", RFC 5294, DOI 10.17487/RFC5294, August 2008, <http://www.rfc-editor.org/info/rfc5294>. [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, DOI 10.17487/RFC5798, March 2010, <http://www.rfc-editor.org/info/rfc5798>. [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <http://www.rfc-editor.org/info/rfc7761>. Acknowledgments I would like to give a special thank you and appreciation to Stig Venaas for his ideas and comments in this document. Author's Address Wei Zhou Cisco Systems Tasman Drive San Jose, CA 95134 United States Email: zhouweiisu@gmail.com
AI ELI5
On this page
§1The Multicast Failover Problem
The Virtual Router Redundancy Protocol (VRRP) provides redundancy by maintaining a virtual IP address shared by multiple routers. One router is elected the Master Router, which owns the virtual IP and forwards traffic. If the Master fails, another router takes over, automatically and transparently to end hosts.
The Protocol Independent Multicast (PIM) system routes multicast traffic from source to multiple receivers. PIM elects a Designated Router on each LAN segment to forward Join/Prune messages toward the Rendezvous Point. However, PIM has no awareness of VRRP state. When VRRP fails over to a backup router, PIM may still route through the old router, causing duplicate multicast traffic (two routers forwarding the same stream) or interruptions.
VRRP-aware PIM solves this by making PIM listen to VRRP state changes and automatically adjusting its Designated Router election to ensure the VRRP Master Router also becomes the multicast Designated Router.
When a backup router takes over, it becomes the main router for both regular and multicast traffic, so everything flows through the same place.
§2Tracking State and Adjusting Priority
VRRP-aware PIM works by having each router's PIM component subscribe to state-change notifications from VRRP. When a router becomes the VRRP Master Router, PIM automatically applies a high Designated Router priority value to ensure that router wins the DR election.
Upon failover, PIM sends an additional Hello message using the VRRP virtual IP as the source address. This Hello contains a new Generation Identifier (GenID), which signals to other routers that a neighbor has changed. Downstream routers respond by immediately sending triggered Join/Prune messages toward the virtual IP address. Upstream routers process these J/P messages and create multicast routing states on the new Master Router, directing traffic through it.
The RFC also notes an alternative implementation where passive routers maintain multicast route state and remember the Master Router's GenID, allowing the new Master to reuse existing state rather than resending Join/Prune messages.
PIM watches VRRP and gives high priority to whichever router VRRP picks as the main one. When failover happens, PIM sends a hello message to tell everyone a change happened, so downstream routers send their subscription requests to the new main router.
§3Handling Duplicates and Multiple VRRP Groups
After a VRRP failover, the old Master Router may still be forwarding multicast traffic momentarily, creating duplicates. PIM Assert handles this: routers that receive multicast on multiple interfaces compare metrics to determine which should forward. In VRRP-aware PIM, passive routers send a high penalty metric (PIM_ASSERT_INFINITY minus 1) to let the Master Router win the Assert election and stop sending.
The same mechanism applies to Designated Forwarder election in bidirectional PIM groups: passive VRRP routers send a penalty metric in DF offers to ensure the Master Router wins DF election.
If multiple VRRP groups are configured on an interface, the adjustment only takes effect if all groups are in passive state. This allows load balancing: if at least one VRRP group is active on a router, that router may win DR or Assert elections using its normal metric, enabling both active groups to participate in multicast routing.
If the old router is still sending copies of the stream, PIM has routers say stop, and let someone else take over. If multiple backup groups are set up, this only applies when all are waiting, so active groups can still handle traffic.
§4Deployment and Compatibility
VRRP-aware PIM can be safely deployed selectively. Routers that do not support this feature will not break functionality, provided their DR priority does not conflict with participating routers. When deployed in a network with dynamic routing, downstream routers should configure static routes with the VRRP virtual IP as the next-hop address for PIM Join/Prune messages in order to benefit from this mechanism.
The feature works with any redundancy protocol that can provide state-change notifications to the multicast routing system. While designed for VRRP, the same scheme can enable HSRP-aware PIM with similar failover and tracking mechanisms, as HSRP provides similar redundancy functions despite differences in timer intervals and the number of backup routers.
This mechanism requires no changes to the PIM or VRRP message formats, making it transparent and backward-compatible with existing implementations.
Other routers do not need to know about this feature; it works quietly and does not break anything. It can work with other failover systems too, like HSRP. No new message types are needed.