Protocol Atlas

L3 · multicast · reviewed

Bidir-PIM

Bidirectional Protocol Independent Multicast

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.

Presenter modeEmbed this figure

IntroductionRFC 5015 · PROPOSED STANDARD · October 2007Data Packet Forwarding RulesRFC 5015 · PROPOSED STANDARD · October 2007PIM Join/Prune MessagesRFC 5015 · PROPOSED STANDARD · October 2007Designated Forwarder (DF) ElectionRFC 5015 · PROPOSED STANDARD · October 2007

Why it exists

PIM-SM builds (S,G) state and may switch every group onto a shortest-path tree. That is right for few sources and many receivers. It is expensive when thousands of sources talk in one many-to-many group.

Bidirectional PIM (RFC 5015) keeps only (*,G) shared-tree state. Traffic flows up to the Rendezvous Point Address and down to receivers on the same tree. There is no Register and no SPT switchover. IntroductionRFC 5015 · PROPOSED STANDARD · October 2007

Shared tree both ways, no Register

Receivers join (*,G) toward the RPA. Sources send native multicast; the Designated Forwarder on each hop forwards toward the RP and down toward receivers. No router builds (S,G) or encapsulates a Register.

SourceR1 · DF uplinkDF elected per linkDF on src LAN: yesToward RPAR2 · last hopDF toward RP: yesReceiver
  • Link
  • Blocking
  • Packet in flight
  • Discarded
  • Emphasis
Select a device to read its state. Arrow keys walk the topology.
Text equivalent of this diagram
Devices and links at this step
ElementKindState
Sourcehost—
R1 · DF uplinkrouterDF on src LAN: yes
Toward RPArouter—
R2 · last hoprouterDF toward RP: yes
Receiverhost—
Source — R1 · DF uplinklinkup
R1 · DF uplink — Toward RPAlinkup
Toward RPA — R2 · last hoplinkup
R2 · last hop — Receiverlinkup
1 / 3

On every link, routers elect a Designated Forwarder for the Rendezvous Point Address. The DF is the only router that forwards bidir traffic onto that link — toward the RP and away from it.

What changed

  • R1 · DF uplink: DF on src LAN → yes
  • R2 · last hop: DF toward RP → yes
  • DF elected per link

How it works

Receivers still join (*,G) toward the RPA. Sources send native multicast; the Designated Forwarder on each hop forwards toward the RP without encapsulation. PIM Join/Prune MessagesRFC 5015 · PROPOSED STANDARD · October 2007

On every link, routers elect a DF using unicast metrics toward the RPA. Only the DF forwards bidir packets onto that link. Because the tree is bidirectional, that election — not an SM-style RPF drop — is what prevents loops. Designated Forwarder (DF) ElectionRFC 5015 · PROPOSED STANDARD · October 2007

The RPA need not be a router interface. A phantom RP — a reachable address nothing owns — is normal: the address is an election and tree root, not a Register target. Cisco IOS XE 17.x — Configuring Basic IP Multicast §Bidir-PIM Overview

On the wire

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

A shared-tree join. The wildcard and RPT bits are both set, so the address in the source field is the RP, not a source — one bit is the entire difference from the message below.

IPv4
Protocol 103, multicast to 224.0.0.13 (ALL-PIM-ROUTERS) with TTL 1. The source is the link-local address of the sending interface. RFC 7761
PIM header
Version, type, reserved and checksum — common to every PIM message. RFC 7761
Join/Prune body
Upstream neighbour, holdtime, and one group set per group, each with its joined and pruned source lists. RFC 7761

Configure it

Bidirectional PIM for an administratively scoped range, with a static bidir RP mapping on every router.

Cisco IOS-XE 17.x · Catalyst 8500, ASR 1000, ISR 4451draft

  1. ip multicast-routing distributed

    Nothing multicast works without it. Absence is silence, not an error.

  2. interface GigabitEthernet1
 ip pim sparse-mode

    Interfaces still use sparse-mode as the PIM mode keyword; bidir is selected per group range via the RP mapping, not a per-interface “bidir-mode.”

    Cisco IOS XE 17.x — Configuring Basic IP Multicast §Configuring Bidirectional PIM

  3. ip pim bidir-enable

    Turns on bidirectional PIM processing on this router. Required on every router in the domain — not only on the RP.

    Common mistake: Enabling bidir only on routers near sources. A single sparse-mode holdout on the path waits for Registers that never arrive.

    Cisco IOS XE 17.x — Configuring Basic IP Multicast §Configuring Bidirectional PIM

  4. ip access-list standard BIDIR-GROUPS
 permit 239.1.0.0 0.0.255.255
ip pim rp-address 10.255.0.1 BIDIR-GROUPS bidir

    Maps the range to an RPA and marks it bidirectional. The address may be a phantom — reachable, not necessarily hosted on a router interface. Repeat identically on every router.

    Common mistake: Omitting the `bidir` keyword. The same RP address without it is sparse mode for that range, and the modes silently disagree.

    RFC 5015 §3.5

Verify

show ip pim rp mapping
10.255.0.1 shown for the group range with bidir indicated.
show ip pim interface df
A DF elected per interface toward the RPA.
show ip mroute 239.1.1.1
(*,G) state only — no (S,G) and no Register flag from SM habits.

Caveats

  • Mode and RP mapping must match on every router a join or packet traverses.
  • Phantom RPs are normal; unicast reachability to the RPA is what DF election needs.
  • Do not diagnose a bidir group by looking for Register packets — there are none.

When it breaks

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

  1. Sources can send and receivers get nothing, on a group configured for bidirectional mode.

    Narrow it down

    1. Check whether the group range is bidirectional on every router in the path.
    2. Confirm DF election completed on each segment (`show ip pim interface df` on IOS-XE).
    3. Look for a router still treating the group as sparse mode.

    Cause

    A router that disagrees builds sparse-mode expectations, waits for a Register, and never receives one. Mode mismatch produces silence.

    Fix

    Configure the bidir range and RP mapping identically everywhere.

    IntroductionRFC 5015 · PROPOSED STANDARD · October 2007

  2. Traffic loops on a segment with more than one router, or duplicates arrive.

    Narrow it down

    1. Check which router won the DF election on that segment.
    2. Confirm every router has a consistent unicast route to the RPA.
    3. Look for an election that has not converged.

    Cause

    Bidir has no SM-style RPF backstop on the shared tree. If DF election has not settled, nothing else stops a loop.

    Fix

    Fix RPA reachability and let one DF win; do not “debug Registers” on a bidir group.

    Designated Forwarder (DF) ElectionRFC 5015 · PROPOSED STANDARD · October 2007

  3. The rendezvous point address is configured and no router has a physical interface with it.

    Narrow it down

    1. Check whether the address is meant to be a phantom RP.
    2. Confirm every router has a route toward it.
    3. Look at which router the route points to and whether that is intended.

    Cause

    This is often deliberate. Bidir needs a reachable address for the election, not a host that terminates Registers.

    Fix

    Verify routing toward the RPA — that routing decides the tree.

    Cisco IOS XE 17.x — Configuring Basic IP Multicast §Bidir-PIM Overview

  4. RP unreachable kills all sources and receivers.

    Narrow it down

    1. RP reachability
    2. DF path to RP

    Cause

    Shared tree depends on RP directionality.

    Fix

    Verify DF paths and RP reachability.

  5. Group works in SM lab but fails when remapped to bidir.

    Narrow it down

    1. Group-mode mapping
    2. Confirm the related configuration and counters.

    Cause

    Mode mismatch between routers.

    Fix

    Align bidir group ranges everywhere.

Design notes

Paths follow the shared tree, not the shortest path to each source. Bidir wins on state; it can lose on latency and link usage when sources are few.

Mode is per group range and must match on every router a packet or join traverses. A single sparse-mode holdout produces silence, not a clear error. Cisco IOS XE 17.x — Configuring Basic IP Multicast §Configuring Bidirectional PIM

Misconceptions

“Bidirectional PIM is sparse mode with an optimisation.”
It builds no source-specific state. There is no Register, no SPT, and no switchover — traffic always uses the shared tree both ways. IntroductionRFC 5015 · PROPOSED STANDARD · October 2007
“The rendezvous point must be a real router.”
It must be a reachable address. A phantom RP is a normal deployment because nothing terminates Register tunnels at the RP in bidir.
“Bidirectional mode is always more efficient.”
It trades optimal paths for state. It wins with many sources and many receivers; it loses when a few high-rate sources would prefer an SPT.

More walkthroughs

When the DF election has not settledfailure

Two routers on a LAN both forward bidir traffic because neither has won the DF election — or both believe they have. Without an RPF check on the shared tree, that is a loop or a duplicate path.

R1 · claims DFRPF on shared tree: not the SM ruleR2 · claims DFShared LANNo SM-style RPF backstop
  • Link
  • Blocking
  • Packet in flight
  • Discarded
  • Emphasis
Select a device to read its state. Arrow keys walk the topology.
Text equivalent of this diagram
Devices and links at this step
ElementKindState
R1 · claims DFrouterRPF on shared tree: not the SM rule
R2 · claims DFrouter—
Shared LANhost—
R1 · claims DF — Shared LANlinkup
R2 · claims DF — Shared LANlinkup
1 / 3

On a bidirectional tree, traffic is accepted both toward and away from the RPA. The reverse-path check that protects PIM-SM cannot apply the same way — the DF is the loop prevention.

What changed

  • No SM-style RPF backstop
  • R1 · claims DF: RPF on shared tree → not the SM rule

Bidir range meets a sparse-mode routerfailure

Most of the path treats 239.1.0.0/16 as bidirectional. One router still maps it as sparse mode, waits for a Register that never comes, and receivers stay silent — with no error that says “mode mismatch.”

SourceR1 · bidirNo Register expectedMode: bidir for 239.1/16R2 · sparse!ReceiverNative
  • Link
  • Blocking
  • Packet in flight
  • Discarded
  • Emphasis
Select a device to read its state. Arrow keys walk the topology.
Text equivalent of this diagram
Devices and links at this step
ElementKindState
Sourcehost—
R1 · bidirrouterMode: bidir for 239.1/16
R2 · sparse!router—
Receiverhost—
Source — R1 · bidirlinkup
R1 · bidir — R2 · sparse!linkup
R2 · sparse! — Receiverlinkup
1 / 3

R1 is bidir. The source’s traffic is forwarded natively toward the RPA. There is no Register to look for on this side — correctly.

What changed

  • Emphasis: Native
  • R1 · bidir: Mode → bidir for 239.1/16
  • No Register expected

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.

Check yourself

  • What state does bidirectional PIM not build?
  • What prevents loops on a LAN with two bidir routers?
  • An RPA that no device owns is configured. Is that wrong?
  • You capture no PIM Register packets for a working bidir group. What does that mean?
  • One router treats a group as sparse while the rest treat it as bidir. What happens?
  • When does bidir lose to sparse mode?
  • Why can you not lean on the usual PIM-SM RPF failure playbook for bidir loops?
  • How do receivers get onto a bidir group tree?