PIM-SM

Why it exists

Dense mode assumes receivers are everywhere and floods until told otherwise. Sparse mode assumes the opposite: build nothing until somebody asks, which is right for almost every real network.

That creates a discovery problem. A receiver knows a group and not a source; a source knows it is sending and not to whom. The rendezvous point is a place they can both be told about in advance, so they can find each other without either knowing the other exists. RFC 7761 §4.4PIM Register MessagesRFC 7761 · INTERNET STANDARD · March 2016

"Protocol independent" means it does not run its own routing protocol — it uses whatever the unicast table already knows. Which is also why a unicast routing problem that causes no unicast symptom breaks multicast completely.

Meeting at a point neither end chose

The receiver knows a group and not a source. The source knows it is sending and not to whom. The rendezvous point is how they find each other.

How it works

Forwarding is decided by where a datagram came from. It is accepted only on the interface the unicast route toward its source points out of, and discarded otherwise — the reverse-path check, and the entire loop-prevention mechanism. RFC 7761 §4.2Data Packet Forwarding RulesRFC 7761 · INTERNET STANDARD · March 2016

Receivers join toward the rendezvous point with a (*,G) join. A source’s designated router, having nowhere to send yet, encapsulates its first packets in unicast Register messages to the RP; the RP joins the source natively and then tells it to stop. RFC 7761 §4.4.1Sending Register Messages from the DRRFC 7761 · INTERNET STANDARD · March 2016

Once the last-hop router has seen a packet it knows the source, and may join the shortest path directly. It joins first and prunes the shared tree second, absorbing the brief duplication with the RPF check. RFC 7761 §4.2.1Last-Hop Switchover to the SPTRFC 7761 · INTERNET STANDARD · March 2016

A (*,G) join and an (S,G) join are the same message with different bits. The wildcard and RPT bits in the encoded source entry decide whether the address in it is a source or the rendezvous point. RFC 7761 §4.9.1Encoded Source and Group Address FormatsRFC 7761 · INTERNET STANDARD · March 2016

Try it

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 receiver joins a group and gets nothing, while the source is definitely sending.

   Narrow it down

   1. Check the RPF interface for the source on every router in the path.
   2. Confirm the unicast route toward the source points out the interface multicast is arriving on.
   3. Look for an asymmetric path, or a static route added for unicast only.

   Cause

   The reverse-path check failed. A router accepts multicast only on the interface its unicast table would use to reach the source, and any asymmetry between the two silently drops the traffic.

   Fix

   Make the unicast path symmetric, or add a static multicast route so the RPF lookup resolves the way the traffic actually arrives.

   RFC 7761 §4.2Data Packet Forwarding RulesRFC 7761 · INTERNET STANDARD · March 2016

2. Multicast works for a moment when a receiver joins and then stops.

   Narrow it down

   1. Check whether the shared tree formed and whether the switch to the shortest path completed.
   2. Do the RPF check for the source separately from the RPF check for the rendezvous point.
   3. Confirm the last-hop router has a route to the source, not only to the RP.

   Cause

   Traffic flowed down the shared tree, then the last-hop router switched to the source tree and the RPF check toward the source failed. The RP was reachable; the source was not, by the path the check demands.

   Fix

   Fix the path to the source, or raise the switchover threshold to keep traffic on the shared tree while the routing is corrected.

   RFC 7761 §4.2.1Last-Hop Switchover to the SPTRFC 7761 · INTERNET STANDARD · March 2016

3. No multicast anywhere, and no router has any state for the group.

   Narrow it down

   1. Check that every router agrees on who the rendezvous point is.
   2. Verify the RP address is reachable from each of them.
   3. If discovery is dynamic, confirm the mapping is being distributed.

   Cause

   Without an RP there is no shared tree and nothing to join. Disagreement about the RP is the same failure as absence: routers build state toward different points and never meet.

   Fix

   Configure the RP consistently, and prefer anycast RP so its loss is not a network-wide outage.

   RFC 7761 §4.7PIM Bootstrap and RP DiscoveryRFC 7761 · INTERNET STANDARD · March 2016

4. Duplicate multicast packets arrive on a segment with more than one router on it.

   Narrow it down

   1. Check whether assert messages are being exchanged on that segment.
   2. Compare the administrative distance and metric each router reports toward the source.
   3. Look for a router that has just restarted and not yet lost the assert.

   Cause

   Two routers are both forwarding onto the shared segment. Assert is supposed to elect one, and it has either not run yet or is being reset repeatedly.

   Fix

   Let assert settle, and investigate why it keeps re-running — usually a flapping route changing the metric being compared.

   RFC 7761 §4.6.3Assert MetricsRFC 7761 · INTERNET STANDARD · March 2016

5. The source’s designated router shows a permanently active register tunnel, and its CPU is high.

   Narrow it down

   1. Check whether the RP is receiving the Register messages at all.
   2. Confirm the RP can build native (S,G) state toward the source — its own RPF check.
   3. Look for Register-Stop messages arriving back at the DR.

   Cause

   Registers stop when the RP has native state toward the source. If the RP’s own RPF check toward the source fails, it never gets that state, so it never sends Register-Stop and the DR encapsulates every packet in software indefinitely.

   Fix

   Fix the RP’s path to the source. The symptom is at the DR and the cause is at the RP, which is what makes this one slow to find.

   RFC 7761 §4.4.2Receiving Register Messages at the RPRFC 7761 · INTERNET STANDARD · March 2016

Design notes

Check RPF before anything else. The commands that show the RPF interface and the arrival interface answer most multicast incidents in two lines, and no amount of looking at the group or the receiver will.

Use anycast RP. The RP carries little traffic after switchover, so its capacity rarely matters and its availability always does — losing it is a network-wide outage for every group that has not yet switched.

Decide the switchover threshold deliberately. Zero is right for a few high-rate groups; keeping everything on the shared tree is right for many low-rate ones, and the trade is path length against state. RFC 7761 §4.2.1Last-Hop Switchover to the SPTRFC 7761 · INTERNET STANDARD · March 2016

If the traffic is one-to-many and receivers can learn the source another way, use SSM instead. It removes the RP, the register, the shared tree and the switchover — and with them most of the failures below. RFC 7761 §4.8Source-Specific MulticastRFC 7761 · INTERNET STANDARD · March 2016

Misconceptions

“Multicast routing follows the unicast routing table.”

It uses the unicast table backwards. Forwarding is decided by checking the interface a packet arrived on against the route toward its source, not by looking up its destination. That inversion is why asymmetric routing breaks multicast and not unicast. RFC 7761 §4.2Data Packet Forwarding RulesRFC 7761 · INTERNET STANDARD · March 2016

“All traffic flows through the rendezvous point.”

Only until the last-hop router learns the source. It then joins the shortest path directly and prunes itself from the shared tree, so the RP carries the first packets and usually nothing after that. RFC 7761 §4.2.1Last-Hop Switchover to the SPTRFC 7761 · INTERNET STANDARD · March 2016

“The rendezvous point must be powerful because all the traffic goes through it.”

It is a control-plane role. After switchover it forwards little or nothing, and the reason to worry about it is availability rather than throughput — which is what anycast RP addresses.

“A router holds either (*,G) state or (S,G) state for a group.”

There is a third: (S,G,rpt), meaning "on the shared tree, except for this source". It is what a last-hop router creates when it moves one source to the shortest path while keeping the rest of the group on the RP tree. RFC 7761 §4.1.4(S,G,rpt) StateRFC 7761 · INTERNET STANDARD · March 2016

More walkthroughs

Terms

RPF check

Forward a multicast datagram only if it arrived on the reverse-path interface toward the source (or the RP for (*,G)). Any other interface is an RPF failure.

Shared tree

The (*,G) tree rooted at the rendezvous point, which every receiver joins before it knows any source. Traffic uses it until a last-hop router learns a source and builds a direct path instead.

SPT threshold

The local policy deciding when a last-hop router leaves the shared tree for the shortest path. Zero means immediately; infinity means never. It is not negotiated, so two routers may legitimately differ.

Check yourself

• A receiver joins and gets nothing, though the source is sending. What do you check first?

  • The IGMP version
  • The RPF check — whether the unicast route toward the source points out the interface the traffic arrives on
  • The multicast group address
  • The TTL
• Traffic flows briefly then stops. What has most likely happened?

  • The group timed out
  • The last-hop router switched to the source tree and the RPF check toward the source failed
  • The receiver left the group
  • The RP crashed
• How much traffic does the rendezvous point carry in steady state?

  • All of it
  • Little or none — receivers switch to the source tree and prune the shared tree
  • Half of it
  • Only control messages, never data
• Two routers on one segment both forward the same group. What resolves it?

  • Spanning tree
  • The PIM assert mechanism, which elects one forwarder for the segment
  • IGMP querier election
  • The lower router ID
• Why does a source’s designated router encapsulate the first packets to the RP?

  • To encrypt them
  • Because no tree exists yet, so there is nothing to carry them natively
  • To measure the path
  • Because the RP requires unicast for all multicast traffic
• What distinguishes a (*,G) join from an (S,G) join on the wire?

  • A different message type
  • The wildcard and RPT bits in the encoded source entry — same message, different bits
  • The destination address
  • The holdtime
• Which router sends the Register messages for a source?

  • Every router on the source’s segment
  • The designated router for that segment
  • The rendezvous point
  • The router with the lowest metric to the RP
• A last-hop router has moved one source to the shortest path but keeps the group on the shared tree. What state is that?

  • (*,G) only
  • (S,G,rpt) — on the shared tree, except for this source
  • Two separate (*,G) entries
  • (S,G) with the RP as next hop

Related

• 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.

• SSM

  The receiver names the source, so there is no rendezvous point, no shared tree and no source discovery problem to solve.

• IGMP

  Hosts report which multicast groups — and, in version 3, which sources — they want; snooping turns those reports into switch forwarding state.

• RP discovery

  Every router in a sparse-mode domain has to agree which rendezvous point serves which group. Four mechanisms answer that, and disagreement is silent.

• PIM-SM versus Bidir-PIM

  Both use an RP and a shared tree. Only SM registers sources and builds (S,G) state. Bidir elects a Designated Forwarder and keeps many-to-many groups on (*,G).