PIM-DM

Why it exists

Dense mode answers the question "where should this stream go?" with "everywhere, unless told otherwise". Building a distribution tree that way needs no rendezvous point, no registration and no shared tree — the tree is whatever is left after the uninterested branches have pruned themselves off. RFC 3973 §3PIM-DM Protocol OverviewRFC 3973 · EXPERIMENTAL · January 2005

That is a real simplification, and it is the right trade only when receivers genuinely are dense — a campus where every segment wants the stream. Everywhere else the cost is paid by every branch that does not want it, repeatedly.

RFC 3973 is Experimental, not Standards Track. The mode still appears in production for one specific reason: Auto-RP floods its announce and discovery groups, 224.0.1.39 and 224.0.1.40, in dense mode, which is why sparse-dense mode exists.

Flood first, ask later

Dense mode assumes every router wants the group, sends it there, and prunes back the branches that say no. Then the prunes expire.

How it works

A datagram is accepted only on the interface the unicast route to its source points out of, and flooded out every other PIM interface. That is the same RPF rule sparse mode uses and it is what keeps the flood from looping. RFC 3973 §4.2Data Packet Forwarding RulesRFC 3973 · EXPERIMENTAL · January 2005

A router with nothing downstream sends a Prune upstream. Prune state is timed — 210 seconds by default — so the branch is re-flooded and re-pruned on a cycle unless State Refresh is running. A Graft rejoins a pruned branch immediately, and it is the one message that is acknowledged. RFC 3973 §4.4PIM-DM Prune, Join, and Graft MessagesRFC 3973 · EXPERIMENTAL · January 2005

On a shared segment two routers can both consider themselves the forwarder. Assert resolves it on administrative distance, then metric, then highest IP address — and the loser keeps its state so it can take over when the winner goes away. RFC 3973 §4.6.1Assert MetricsRFC 3973 · EXPERIMENTAL · January 2005

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 quiet link carries a burst of multicast every three minutes for a group nobody on it has asked for.

   Narrow it down

   1. Check whether the group is running in dense mode rather than sparse.
   2. Look at the prune expiry timer on the upstream router.
   3. Check whether State Refresh is being originated and forwarded along the whole path.

   Cause

   Prune state is timed. When it expires the upstream forwards again and the downstream re-prunes, which is the protocol working as specified.

   Fix

   Enable State Refresh on every router in the path, or move the group to sparse mode, which never floods to a router that did not ask.

   RFC 3973 §4.4PIM-DM Prune, Join, and Graft MessagesRFC 3973 · EXPERIMENTAL · January 2005

2. State Refresh is configured and part of the network still re-floods.

   Narrow it down

   1. Walk the path hop by hop and check the State Refresh Capable option in each Hello.
   2. Confirm the first-hop router is originating rather than only forwarding.
   3. Find the first router that does not forward the message — everything past it re-floods.

   Cause

   The capability is per-hop. One router that does not forward the refresh reinstates prune expiry for the whole subtree behind it.

   Fix

   Upgrade or replace the router that breaks the chain. There is no way to tunnel the refresh past it.

   RFC 3973 §4.7.5.4State Refresh Capable OptionRFC 3973 · EXPERIMENTAL · January 2005

3. Receivers on a shared segment see every multicast packet twice.

   Narrow it down

   1. Check how many routers on that LAN have the group in a forwarding state.
   2. Look for Assert messages on the segment.
   3. Compare the two routers’ administrative distance and metric to the source.

   Cause

   Two routers both treated the LAN as a downstream branch. Assert resolves it, but only once each has seen the other’s traffic on its own downstream interface.

   Fix

   Let Assert settle it, and if the wrong router keeps winning, change the metric rather than the addresses. The address is only the last tie-break.

   RFC 3973 §4.6.1Assert MetricsRFC 3973 · EXPERIMENTAL · January 2005

4. Multicast is dropped on a router that clearly has a route to the source.

   Narrow it down

   1. Compare the incoming interface with the interface the unicast route to the source points out of.
   2. Check for asymmetric routing or a separate multicast RIB.
   3. Confirm which table the RPF lookup uses on that platform.

   Cause

   The RPF check failed. Having a route is not enough — the datagram has to arrive on the interface that route points out of.

   Fix

   Fix the asymmetry, or add a static multicast route so the RPF lookup resolves toward the interface the traffic actually uses.

   RFC 3973 §4.2Data Packet Forwarding RulesRFC 3973 · EXPERIMENTAL · January 2005

5. A group appears on a link to a partner or a DMZ that was never meant to carry multicast.

   Narrow it down

   1. List every interface with PIM enabled and compare against the intended domain.
   2. Check for a multicast boundary or scope on the interfaces at the edge.
   3. Confirm whether the group is running dense mode rather than sparse.

   Cause

   A dense-mode group floods out every PIM-enabled interface by default. There is no join to be absent — the traffic arrives first and waits to be pruned, and a partner who does not run PIM will never prune it.

   Fix

   Put a multicast boundary on every edge interface. Enabling PIM on an interface is enabling flooding to it, which is the part that does not read that way in the configuration.

   RFC 3973 §3PIM-DM Protocol OverviewRFC 3973 · EXPERIMENTAL · January 2005

Design notes

Do not choose dense mode because it looks simpler to configure. The configuration is simpler and the behaviour is not: the flood-and-prune cycle is invisible until someone captures a quiet link and finds a burst of unwanted multicast every three minutes.

If dense mode is unavoidable, enable State Refresh on every router in the path. It is a per-hop capability advertised in the Hello, so one router without it silently reinstates the cycle for everything downstream. RFC 3973 §4.5State RefreshRFC 3973 · EXPERIMENTAL · January 2005

Sparse-dense mode was the common compromise for Auto-RP: sparse for real groups, dense for the two Auto-RP groups. BSR carries RP information inside PIM itself and removes the need for it, which is the better answer where both are available.

Misconceptions

“Dense mode is the simple choice for a small network.”

Its configuration is simpler; its behaviour is not. It floods to every router and depends on prune state that expires, so a small network with a few uninterested branches pays a permanent, invisible cost that sparse mode never incurs.

“Nobody runs dense mode any more.”

Auto-RP announces itself on 224.0.1.39 and 224.0.1.40 in dense mode, which is why sparse-dense mode exists and why the flood-and-prune behaviour still turns up in networks whose operators believe they run pure sparse mode.

“The Assert winner is the router with the lowest IP address.”

It is the highest, and only as a final tie-break after administrative distance and metric. Assuming it matches the DR election or the STP root is a reliable way to predict the wrong winner. RFC 3973 §4.6.1Assert MetricsRFC 3973 · EXPERIMENTAL · January 2005

“Enabling State Refresh on the first-hop router stops the flooding.”

Only the first hop originates it, but every router on the path has to forward it. The first router that does not puts everything behind it back on prune expiry. RFC 3973 §4.5.1Forwarding of State Refresh MessagesRFC 3973 · EXPERIMENTAL · January 2005

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.

Flood and prune

The dense-mode model: send the group to every router, and remove the branches that object. Prune state is timed, so the flood repeats until State Refresh keeps it alive.

State Refresh

A message originated by the first-hop router and forwarded hop by hop, resetting prune timers so a pruned branch never re-floods. Every router on the path has to forward it.

PIM Assert

The election that picks one forwarder when two routers send the same group onto a shared LAN. Administrative distance, then metric, then highest IP address — not lowest.

Check yourself

• What does dense mode assume about receivers?

  • That they are rare and must ask
  • That they are everywhere, so traffic is sent everywhere until a branch objects
  • That they register with a rendezvous point
  • That they are learned from IGMPv3 source lists
• A pruned branch carries a burst of multicast every three minutes. What is happening?

  • A routing loop
  • Prune state expired and the branch was re-flooded, then re-pruned
  • IGMP snooping timed out
  • The RPF check is failing intermittently
• State Refresh is enabled on the first-hop router and part of the network still re-floods. Why?

  • The refresh interval is too long
  • A router on the path does not forward State Refresh, so everything behind it falls back to prune expiry
  • The group is in the SSM range
  • The receivers are using IGMPv2
• Two routers with identical metrics both forward a group onto one LAN. Which wins the Assert?

  • The one with the lowest IP address
  • The one with the highest IP address
  • The designated router
  • Neither — both stop forwarding
• Why does dense mode still appear in networks that are configured for sparse mode?

  • Sparse mode falls back to dense when the RP is unreachable
  • Auto-RP floods its announce and discovery groups in dense mode, which is what sparse-dense mode is for
  • IGMPv3 requires it
  • It is the default for administratively scoped groups
• Which PIM-DM message is acknowledged, and why only that one?

  • Prune, because losing it wastes bandwidth
  • Graft, because losing it would leave a receiver waiting minutes for the prune to expire
  • Hello, because the adjacency depends on it
  • State Refresh, because it carries prune state
• What stops the initial flood from looping?

  • A hop limit on the datagram
  • The reverse-path check — a datagram is accepted only on the interface the route toward its source points out of
  • The prune timer
  • Assert
• A capture shows a PIM message of type 6. What does that tell you?

  • The group is running in sparse mode
  • It is a Graft, which exists only in dense mode — so this group is dense
  • The RP is unreachable
  • The message is malformed

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.

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