RP discovery

Why it exists

Sparse mode meets sources and receivers at a rendezvous point. That only works if the source’s router and the receiver’s router pick the same one, and nothing in PIM makes them — the agreement has to come from somewhere else. RFC 7761 §3.7RP DiscoveryRFC 7761 · INTERNET STANDARD · March 2016

Four mechanisms answer it. Static configuration on every router; BSR, which elects a bootstrap router that publishes an RP set inside PIM; Auto-RP, which is Cisco’s earlier answer using two dense-mode groups; and Anycast RP, which is not a discovery mechanism at all but makes one address resolve to several routers. RFC 5059 §1.2Protocol OverviewRFC 5059 · PROPOSED STANDARD · January 2008

Bidir-PIM needs an RP too, and SSM needs none. A domain running SSM for its one-to-many traffic has no RP discovery problem for that traffic at all.

Agreeing on the rendezvous point

Static configuration is the simplest answer and the easiest to get subtly wrong. Where several RPs serve one range, a hash — not a preference — decides.

How it works

However a router learns its candidates, the group-to-RP decision is local and identical everywhere: longest match on the group range first, then highest priority — where a lower number is better — then a hash over the group and RP addresses, then the highest address. RFC 7761 §4.7.1Group-to-RP MappingRFC 7761 · INTERNET STANDARD · March 2016

The hash matters more than it looks. It means several RPs serving one range share the groups deterministically, so every router reaches the same answer without negotiating and different groups land on different RPs. RFC 7761 §4.7.2Hash FunctionRFC 7761 · INTERNET STANDARD · March 2016

BSR separates two jobs. Candidate RPs unicast their willingness to the elected bootstrap router, which assembles an RP set and floods it hop by hop. The BSR never assigns a group to an RP — every router does that itself from the same list. RFC 5059 §3.6Receiving and Using the RP-SetRFC 5059 · PROPOSED STANDARD · January 2008

Anycast RP is orthogonal. Several routers own the same RP address and the IGP picks the nearest, which gives sub-second failover and no shared state — so the RPs have to exchange source information themselves, with MSDP in a mesh group or with PIM register forwarding. RFC 4610 §3MechanismRFC 4610 · PROPOSED STANDARD · August 2006

On the wire

Constructed examples, encoded from the field table below them — not captured traffic.

Configure it

When it breaks

Symptom first, because that is what you have when it happens.

1. A group works between some routers and not others. PIM neighbours are up everywhere and nothing is logged.

   Narrow it down

   1. Ask each router which RP it resolves for the group, and compare — not the configuration, the resolved mapping.
   2. Check for a static entry overriding what BSR advertised.
   3. Check whether a more specific group range points somewhere else.

   Cause

   The source’s router and the receiver’s router resolved different RPs, so the register and the join never meet. A router that is not an RP does not object to a join arriving for one.

   Fix

   Make the resolved mapping identical everywhere, then remove whichever mechanism was not chosen for this domain.

   RFC 7761 §4.7.1Group-to-RP MappingRFC 7761 · INTERNET STANDARD · March 2016

2. BSR is deployed and one router still uses the old rendezvous point.

   Narrow it down

   1. Look for a static RP configuration on that router.
   2. Check whether the platform prefers static over learned by default.
   3. Confirm the router is receiving the RP set at all.

   Cause

   A leftover static entry, which most platforms prefer over anything learned. Every BSR diagnostic looks healthy because BSR is working — it is being ignored.

   Fix

   Remove the static entry, or configure it to yield to a learned mapping where the platform supports that.

3. Part of the domain has an empty RP set and cannot join any group.

   Narrow it down

   1. Trace the Bootstrap message hop by hop and find where it stops.
   2. Check for a PIM adjacency gap or a boundary filter on the path.
   3. Confirm the BSR is actually elected and flooding.

   Cause

   Bootstrap messages are flooded hop by hop through PIM. A gap in PIM adjacency, or a multicast boundary that filters them, stops the RP set at that point.

   Fix

   Restore PIM adjacency along the path, and check that any multicast boundary does not filter the bootstrap traffic.

   RFC 5059 §3.4Forwarding Bootstrap MessagesRFC 5059 · PROPOSED STANDARD · January 2008

4. Anycast RP is deployed and receivers on one side of the network never see sources on the other.

   Narrow it down

   1. Check which anycast RP the source registered with and which one the receiver joined.
   2. Confirm the RPs exchange source state, by MSDP mesh group or PIM register forwarding.
   3. Verify the MSDP session is sourced from a unique loopback rather than the anycast address.

   Cause

   Anycast made the address redundant and did nothing about the state. Without state sharing, each RP knows half the picture.

   Fix

   Add an MSDP mesh group between the RPs, or use RFC 4610 register forwarding. Either way, source the sessions from unique addresses.

   RFC 4610 §3MechanismRFC 4610 · PROPOSED STANDARD · August 2006

5. Two RPs serve one range at equal priority and almost every group lands on the same one.

   Narrow it down

   1. Check the hash mask length the bootstrap router is advertising.
   2. List the groups in use and see how much of the address they have in common.
   3. Compare the resolved RP for several adjacent groups.

   Cause

   The hash covers only the masked bits of the group address. With a short mask and groups that differ only in the low octet, every group hashes the same way — which is deliberate, because it keeps related groups on one RP.

   Fix

   Lengthen the hash mask so more of the group address matters, or allocate group addresses that differ in the bits the mask covers.

   RFC 7761 §4.7.2Hash FunctionRFC 7761 · INTERNET STANDARD · March 2016

Design notes

Choose one mechanism per domain and remove the others. Most RP incidents are not a mechanism failing; they are two mechanisms both working, on different routers, toward different answers.

A static RP usually overrides a dynamically learned one. That default is sensible and it makes a leftover static entry invisible to every BSR or Auto-RP diagnostic — the RP set looks correct and one router ignores it.

Static plus Anycast RP is a defensible modern choice: no discovery protocol to debug, redundancy from the IGP, and failover at IGP speed. Its cost is configuration on every router, so it wants automation rather than an engineer.

Watch the two priorities running in opposite directions. A higher BSR priority is better; a lower RP priority is better. Nothing warns about a value chosen with the wrong sense — the domain simply elects the router nobody meant. RFC 5059 §3.1Bootstrap Router ElectionRFC 5059 · PROPOSED STANDARD · January 2008

Misconceptions

“The BSR assigns groups to rendezvous points.”

It publishes a list. Every router applies the same range, priority and hash rules to that list and reaches the same answer independently, which is what lets the mechanism scale — nothing is recomputed centrally when a group appears. RFC 5059 §3.6Receiving and Using the RP-SetRFC 5059 · PROPOSED STANDARD · January 2008

“With several RPs for a range, the lowest address wins.”

A hash over the group and RP addresses decides, after range specificity and priority. That is deliberate: it spreads groups across the available RPs instead of concentrating all of them on one. RFC 7761 §4.7.2Hash FunctionRFC 7761 · INTERNET STANDARD · March 2016

“Anycast RP is an alternative to BSR.”

It is orthogonal. Anycast makes one address resolve to several routers; the domain still needs to learn that address, statically or through BSR. And the anycast RPs still have to share source state between themselves. RFC 4610 §2OverviewRFC 4610 · PROPOSED STANDARD · August 2006

“Higher priority is better throughout the mechanism.”

A higher BSR priority is better and a lower RP priority is better. The two run in opposite directions inside one design, and a value chosen with the wrong sense produces a silently wrong election. RFC 5059 §3.1Bootstrap Router ElectionRFC 5059 · PROPOSED STANDARD · January 2008

More walkthroughs

Terms

RP set

The list of candidate rendezvous points a BSR floods to the domain. It is a list, not an assignment — each router applies range, priority and hash rules to it and reaches the same answer alone.

Group-to-RP hash

The deterministic function that picks an RP when several serve one range at equal priority. It spreads groups across the available RPs and guarantees every router picks the same one.

Anycast RP

Several routers owning one RP address, with the IGP choosing the nearest. It makes the address redundant and nothing else — the RPs still have to share source state themselves.

Check yourself

• Why does RP discovery need a mechanism at all?

  • To load-balance multicast traffic
  • Because the source’s router and the receiver’s router must resolve the same RP, and PIM alone does not make them
  • To authenticate the RP
  • Because the RP address changes per group by design
• Two RPs serve the same group range at equal priority. Which one does a router use?

  • The nearest by IGP metric
  • The one a deterministic hash over the group and RP addresses selects
  • The lowest address
  • Both, alternating
• What does the elected bootstrap router publish?

  • A group-to-RP assignment for every group
  • An RP set, which every router then applies the same rules to itself
  • The multicast routing table
  • Its own address as the RP
• BSR is deployed and one router still uses the old RP. What is the likely cause?

  • The RP set has not aged out yet
  • A leftover static RP, which most platforms prefer over a learned mapping
  • The router is running a different PIM version
  • The BSR priority is set with the wrong sense
• Anycast RP is configured on two routers. What still has to be arranged?

  • Nothing — anycast handles everything
  • The two RPs must share source state, by MSDP mesh group or PIM register forwarding
  • A BSR election between them
  • Identical group ranges on every other router
• A bootstrap message carries two priorities. Do they work the same way?

  • Yes — higher wins for both
  • No — a higher BSR priority wins the election, and a lower RP priority is preferred
  • Yes — lower wins for both
  • They are the same field read twice
• The bootstrap router fails. What happens to the RP set?

  • It is discarded immediately and multicast stops
  • It ages out over its holdtime while a standby takes over, so the failure is not instant
  • Every router re-elects an RP locally
  • Nothing — the RP set is permanent once distributed
• What is the fragment tag in a bootstrap message for?

  • IP fragmentation of the datagram
  • Tying together the semantic fragments of one RP set, each sent as its own datagram
  • Identifying the bootstrap router
  • Numbering the group ranges

Related

• PIM-SM

  Builds multicast trees only where receivers ask for them, meeting sources and receivers at a rendezvous point and then getting out of the way.

• MSDP

  Lets rendezvous points in separate domains tell each other which sources are active, so a receiver can join a source its own RP has never heard of.

• Bidir-PIM

  Many-to-many multicast on a shared tree only — no Register, no (S,G), no SPT switchover; the DF on each link is what keeps it loop-free.