RFC 7910

Interoperability between the Virtual Router Redundancy Protocol and PIM

📅 published June 2016, from ietf

Interoperability between the Virtual Router Redundancy Protocol and PIM 🎀

okay bestie, let's get the paperwork out of the way first 💅

  • Stream: Independent Submission
  • RFC: 7910
  • Category: Informational
  • Date: June 2016
  • ISSN: 2070-1721
  • Author: W. Zhou, Cisco Systems
  • Obsoletes / Updates: nothing listed. The title block doesn't claim to replace or update any other RFC 🦋

Abstract ✨

okay so this doc introduces VRRP-aware PIM 🌸, a redundancy mechanism that lets the Protocol Independent Multicast (PIM) play nicely with the Virtual Router Redundancy Protocol (VRRP). the vibe is that PIM can track VRRP state and keep multicast traffic flowing when a failover happens, in a redundant network where virtual routing groups are turned on. and the whole mechanism is based on the Cisco IOS software implementation 💖

Status of This Memo ✨

this one is not an Internet Standards Track spec. it's just published for informational purposes, no cap 🧚

it's a contribution to the RFC Series, independent of any other RFC stream. the RFC Editor picked to publish it at their discretion and makes no statement about how useful it is for implementation or deployment. docs the RFC Editor approves for publication aren't candidates for any level of Internet Standard (see Section 2 of RFC 7841) 🍓

if you want the current status, any errata, or a way to send feedback, check http://www.rfc-editor.org/info/rfc7910 🫶

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) as they stand on the date of publication. read those carefully, bestie, because they explain 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 🦋

okay so VRRP [RFC5798] is the redundancy protocol for setting up a fault-tolerant default router 💅. it builds a framework between network devices so the default device can fail over if the primary devices become inaccessible 🫶.

PIM [RFC7761] has no inherent redundancy, and it operates completely independently of VRRP group states 😭. the result? IP multicast traffic isn't necessarily forwarded by the same device VRRP elected. the VRRP-aware PIM feature fixes that vibe and gives you consistent IP multicast forwarding in a redundant network with virtual routing groups enabled ✨.

on a multi-access segment (like a LAN), the elected PIM designated router (DR) is totally unaware of the redundancy configuration 🙈. so the elected DR and the VRRP master router (MR) might not be the same device, and that's the main problem. to make sure the PIM DR can always forward a PIM Join/Prune (J/P) message toward the Rendezvous Point (RP) or the first-hop router, the VRRP MR becomes the PIM DR (if there's only one VRRP group) 👑. PIM adjusts the DR priority based on the group state. when a failover happens, multicast states get created on the new MR elected by the VRRP group, and the MR takes over routing and forwarding for all traffic addressed to the VRRP virtual IP address (vIP) 🌸. this means the PIM DR runs on the same router as the VRRP MR and keeps its multicast routing (mroute) states. multicast traffic gets forwarded through the VRRP MR, so PIM can lean on VRRP redundancy, avoid potential duplicate traffic, and handle failover, all depending on the VRRP states in the router 💖.

this mechanism can be deployed safely into a PIM network without changing the behavior of other routers 🧚. when only a specific set of routers enable the feature, a user can configure PIM interfaces to track state-change events for the VRRP group(s) they want. when a router becomes the VRRP MR, the PIM component applies the user-defined DR priority value to the interface so it becomes the PIM DR 👑. other routers won't break this feature, as long as their configured DR priority doesn't conflict with the participating routers 🎀.

in a PIM transit network, downstream routers should configure a static route that uses the vIP as the next-hop address for PIM J/P messages, so they can 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], those routes can't leverage the VRRP redundancy and failover mechanism 💀. the good news is those downstream routers don't have to support this new feature, and there's no extra configuration or coordination needed from a manageability point of view 🫶. this mechanism doesn't change any bit on the wire, and it has been implemented on Cisco IOS software ✨.

2. Tracking and Failover 🌈

without the mechanisms in this document, a PIM component sends 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 it stays the same as long as the router is up 🎀. so a PIM neighbor reboot is easy to detect if its GenID is different from before. in that case, the PIM J/P and RP-Set information can be redistributed to the rebooted neighbor 🔁.

with VRRP-aware PIM enabled, the PIM component listens to state-change notifications from VRRP 👂. it automatically adjusts the priority of the PIM DR based on the VRRP state, and it makes sure the VRRP MR becomes the DR of the LAN (if there's only one VRRP group) 👑. 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 so mroute states get created 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 🌸. that PIM Hello carries a new GenID, which triggers other routers to respond to the VRRP failover event the same way they would to a PIM neighbor reboot, as described in [RFC5294] 🧚. specifically, when a downstream router gets this PIM Hello, it adds the source IP address (in this case the VRRP vIP) to its PIM neighbor list and immediately sends triggered PIM J/P messages toward the vIP ✨. upstream routers process those 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 processes the PIM J/P messages 👑. this way, all PIM J/P messages reach the VRRP group vIP, and it minimizes changes and configuration at the downstream routers 🫶.

there's also an alternative. 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 avoids resending PIM J/P messages upon failover, and it gets rid of the need for an additional PIM Hello with the vIP 🎀. there's no change in on-the-wire behavior, and no change to the PIM or VRRP message format 💖.

3. PIM Assert Metric Auto-Adjustment 💅

so after the VRRP MR switches from router A to router B, A would still forward multicast traffic, and that causes duplicate traffic 😭. the PIM Assert mechanism kicks in to fix this, because PIM Assert with redundancy is enabled 🌸.

  • if there's only one VRRP group, passive routers send an arbitrary penalty metric preference (PIM_ASSERT_INFINITY - 1) and make the MR the Assert winner 👑.
  • if there are multiple VRRP groups configured on an interface, the Assert metric preference is (PIM_ASSERT_INFINITY - 1) if and only if all VRRP groups are in Passive state 🦋.
  • if at least one VRRP group is in Active state, the original Assert metric preference is used. that means the winner is picked between routers using their real Assert metric preference with at least one active VRRP group, as if no VRRP were involved at all ✨.

7. Security Considerations 🔐

okay bestie, security time, and it's giving serious but also kinda spicy 🌶️. The proposed tracking mechanism does not add authentication to the protocols, and it doesn't introduce any new negative impact or threats to PIM security, whether you're in SSM (Source-Specific Multicast) or ASM (Any-Source Multicast) mode. ✨

BUT, the vibe check is that VRRP messages from malicious nodes could cause unexpected behaviors, like having multiple MRs and PIM DRs at the same time 😭. Those are linked to VRRP-specific security issues, so it's not me, it's VRRP 💀.

To protect against frequent VRRP and PIM DR state changes caused by a malicious attack, an implementation can turn on VRRP preemption 🛡️. With preemption, a higher-priority VRRP backup router won't take over from a lower-priority MR. Why does that help? It cuts down the state-change notifications sent to the PIM component, and that means fewer mroute state changes too. Iconic move 👑.

If you want the full tea on PIM and VRRP security, the detailed analysis is in [RFC5294] and [RFC5798]. Go read those, periodt 📚🫶.

8. Informative References 📚

Here are the informative references, bestie 🎀. Copy them exactly:

[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 🌸

Huge shoutout to Stig Venaas 💖 for his ideas and comments on this document. Thank you, queen 👑🫶.

Author's Address 💜

Wei Zhou
Cisco Systems
Tasman Drive
San Jose, CA  95134
United States

Email: zhouweiisu@gmail.com

That's the whole RFC, bestie! 🌈✨💅

📦 where this page comes from