Anycast RP with MSDP: Redundant Multicast Rendezvous Points

One rendezvous point is a single point of failure for every PIM-SM group on the network, and a PIM-SM flap at the RP is invisible to users until a stream stops. Anycast RP solves it with an elegant trick: run the same RP address on two or more routers and synchronise their state with MSDP so that whichever RP receives a source registration, all of them know about it. This article covers the design and the configuration that makes it work.

How Anycast RP works

1. Each RP has a unique loopback for MSDP peering and a shared RP address advertised into the IGP from every RP.
2. Every router in the domain, including the PIM DRs at the edges, statically configures the same RP address.
3. A first hop router sends its PIM Register to the closest RP (IGP shortest path). If that RP fails, the IGP converges and registers now land on another RP — no configuration change anywhere.
4. MSDP peers exchange Source-Active messages containing (S,G) pairs and the originating RP, so a receiver joining on RP-2 can learn about a source that registered with RP-1.

Three addresses, three jobs

Most broken anycast deployments come from collapsing three logically separate addresses into one because "they are all loopbacks anyway". Keep them distinct:

• Shared RP address - the same /32 on every RP, advertised into the IGP by all of them, configured as a static RP on every PIM router in the domain. Never used for peering or management.
• MSDP peering address - a unique /32 per RP, advertised into the IGP, used as the BGP/IGP router ID and as the MSDP local address. Unique means the TCP session between RPs has a stable, unambiguous source and the MSDP peer-RPF computation has a real target to resolve.
• Management address - a separate address for SSH, SNMP and syslog, so an IGP change for peering does not lock you out of the device you are trying to fix.

The shared address must be reachable from every router in the domain, which means it is normally redistributed into the IGP as a host route. If the shared address is reachable only via a default route on some routers, RP selection becomes topology-dependent and the whole point of the design evaporates.

Configuration skeleton (IOS / NX-OS style)

! Common shared RP address on both RPs
interface Loopback0
 ip address 10.255.255.1 255.255.255.255   ! unique, used for MSDP and BGP/IGP

interface Loopback1
 ip address 10.255.255.100 255.255.255.255 ! shared RP address

ip pim rp-address 10.255.255.100            ! on EVERY router
ip msdp peer 10.255.255.2 connect-source Loopback0 remote-as 65000
ip msdp originator-id Loopback0
ip msdp rpf rfc3618                        ! avoid MSDP peer-RPF loops in anycast designs

! Junos equivalent
set protocols msdp peer 10.255.255.2 local-address 10.255.255.1
set protocols pim rp static address 10.255.255.100

On Junos the MSDP peering is configured at the [edit protocols msdp] hierarchy with a local address, and the shared RP address is configured as a static RP. The MSDP mesh between RPs must be fully connected (or a mesh with a consistent peer list) so that Source-Active messages reach every RP.

Repeat the peer statement on both sides - MSDP is not a client/server protocol, and a one-sided peer statement produces a session that sits in Listen for ever. If the RPs sit in different autonomous systems, add a matching remote-as; if they share an AS, omit it or the session will be refused.

How MSDP actually carries state

MSDP is deliberately small. Two RPs form a single TCP session on port 639, exchange hellos, and then exchange one message type that matters: the Source-Active (SA) message. An SA carries an (S,G) pair, the address of the RP that originated the state, and an encapsulated PIM Register payload. When a source registers with RP-1, RP-1 creates an SA cache entry and floods that entry to its MSDP peers; they store it and flood it onward.

The result is that every RP in the domain holds a complete picture of active sources, and a receiver that joins a group on RP-2 can be served even though the source is registered to RP-1. The data never flows over MSDP - once the receiver's last-hop router has the source address, it joins the source tree directly with PIM. MSDP is pure control-plane state, which is why bandwidth is never a reason to size an RP.

Why RFC 3618 peer-RPF keeps biting

MSDP refuses to accept an SA that could create a loop. The rule is a peer-RPF check: an SA is accepted if it arrived from the MSDP peer that is the next hop toward the RP named in the SA's own originator field. That rule works cleanly when every RP has a distinct address. In an anycast deployment, the originator field contains the shared address, so the RPF lookup points at the IGP path to the shared address - not at the MSDP peer the SA actually came from - and the check fails.

! Two accepted ways to resolve it
! 1. Explicitly select RFC 3618 peer-RPF behaviour
ip msdp rpf rfc3618

! 2. Or make the RP set a mesh group, which disables peer-RPF between mesh members
ip msdp mesh-group ANYCAST-RPS
 ip msdp mesh-group ANYCAST-RPS 10.255.255.2

! Junos
set protocols msdp group ANYCAST-RPS peer 10.255.255.2

The mesh group is simpler and is what most production anycast designs use, because the RPs are by definition a small, trusted, fully meshed set. Either way, do not leave the default in place and hope: the failure is silent - the session shows Established, the SA cache fills on some RPs and stays empty on others, and only groups whose receivers land on the wrong RP are affected.

Verification that means something

show ip msdp summary
show ip msdp peer 10.255.255.2
show ip msdp sa-cache
show ip msdp mesh-group
show ip pim rp mapping
show ip pim rp 10.255.255.100
show ip mroute 239.1.1.1 count
show ip pim tunnel

• show ip msdp sa-cache should list the (S,G) entries learned from the peer. An empty cache on a busy network means the RP peering is broken even though the session shows up.
• show ip pim rp mapping must resolve the shared address to a local interface — if it does not, you have an RP address that no router can reach.
• During a failover test, check that the Register process moves to the surviving RP and that receivers re-join. In practice the switch is fast; the failure mode is not RP loss but asymmetric RP selection in a partially converged IGP.
• Compare show ip msdp summary on every RP side by side. The learned-SA counts should be within a few percent of each other. A large divergence is a peer-RPF or filtering problem, not a capacity problem.

Failover test that actually proves the design

1. Bring up a group with a receiver and a source and confirm traffic flows and the SPT is built (show ip mroute 239.1.1.1).
2. Note which RP holds the registration (show ip pim tunnel or the RP's mroute for the source).
3. Shut the RP interface or withdraw the shared address from that RP only. Do not power the box off - you want the routing event, not a hardware failure.
4. Confirm the IGP reconverges and the new registration lands on the surviving RP. Watch the MSDP SA cache on the survivor fill in.
5. Confirm the receiver keeps receiving. Expect a short interruption of a few hundred milliseconds to a few seconds, dominated by IGP convergence, not by PIM.
6. Repeat in the other direction, then restore. Record the interruption duration as the design's real failover figure.

If the interruption is much longer than the IGP convergence time, suspect that the receivers' last-hop routers still have stale state pointing at the failed RP. Some platforms need the mroute flushed or the group re-joined before traffic is restored.

Filtering and scale controls

An unfiltered MSDP mesh will happily propagate every source in the domain to every RP, including sources that only a handful of groups care about. Two controls are worth configuring from day one:

! Only propagate the groups you actually use
ip msdp sa-filter in 10.255.255.2 list SA-ALLOW
ip msdp sa-filter out 10.255.255.2 list SA-ALLOW
ip access-list standard SA-ALLOW
 permit 239.0.0.0 0.255.255.255

! Cap the cache so a misbehaving application cannot exhaust memory
ip msdp cache-sa-state
ip msdp sa-limit 10.255.255.2 5000

A wildcard source application - one that registers a single (S,G) per receiver connection - is the classic way to blow up an SA cache. If the application is under your control, prefer any-source groups with PIM-SSM where possible, and if it is not, cap the cache and accept that some groups will not be learned.

Where anycast RP does not apply

PIM-SSM does not use an RP at all, so anycast RP is irrelevant to it. ASM deployments that already have a stable, well-provisioned RP and no requirement for control-plane redundancy gain nothing from adding a second one except MSDP to operate. And BIER or Segment Routing multicast designs remove the RP concept entirely - if the roadmap points there, it is worth asking whether investing in an MSDP design today is the right use of a maintenance window.

Common failure modes

Design cautions

Anycast RP is a control-plane redundancy feature, not a bandwidth feature: the RP never carries the data stream once the SPT is built, so capacity is not the reason to deploy it. Keep the MSDP mesh small and stable (RPs only), give MSDP its own loopback so a routing change does not break the peering, and remember that MSDP peers must be RPF-checked consistently — in anycast designs the RPF peer rule often needs to be relaxed deliberately (RFC 3618 behaviour) or your SA messages get dropped by their own loop-prevention logic.

Two RPs are the common minimum and the most common mistake is stopping there. Two RPs give you redundancy against a device failure but not against a rack or a site, and they must not be two line cards in the same chassis. Place them so that a single power, cooling or uplink failure cannot take both out, and document which receivers map to which RP under normal conditions so that a failover test has a known-good baseline to compare against.

Frequently asked questions

Do all routers need the static RP, or only the edge? Every router that runs PIM in the domain needs the same static RP configuration, including the RPs themselves. A router that lacks it cannot build a shared tree and will show an RP mapping failure even though the network carries traffic on the SPT.

Can I run anycast RP across two autonomous systems? Yes, but the MSDP peer statements then need matching remote-as values and the shared address must be reachable across the AS boundary through a stable IGP or BGP advertisement. Most designs keep the RP set inside one AS for exactly this reason.

Does MSDP need to be encrypted or authenticated? Yes, in any deployment where the MSDP peers cross an untrusted path. Configure TCP MD5 (or the platform's equivalent) on both sides; MSDP carries no authentication of its own beyond what TCP provides.

Related reading: PIM sparse mode and RP/RPF verification, IGMP snooping configuration, DMVPN phase 3 and NHRP shortcut and NX-OS OSPF configuration examples.

原文链接：https://www.cisco.com/c/en/us/support/docs/ip/multicast-source-discovery-protocol-msdp/221962-configuring-anycast-rendezvous-point-rp.html