13.2 Protocol Independent Multicast (PIM-SM, PIM-SSM & Bidir-PIM)

13.2 Protocol Independent Multicast (PIM-SM & PIM-SSM)

Core Blueprint Focus: Cisco 350-401 ENCOR v1.2 topic 3.3.d requires candidates to configure and verify Protocol Independent Multicast (PIM), including PIM Sparse Mode (PIM-SM) operations, Source Tree (SPT) vs. Shared Tree (RPT) distribution models, Reverse Path Forwarding (RPF) check mechanics, Designated Router (DR) election, SPT switchover, and Source-Specific Multicast (PIM-SSM).

While IGMP manages multicast membership between receiver hosts and local routers, Protocol Independent Multicast (PIM) operates between routers to build loop-free multicast distribution trees across the enterprise Layer 3 topology. PIM is "protocol independent" because it does not maintain its own routing topology; instead, it leverages the existing Unicast Routing Table (RIB)—populated by OSPF, EIGRP, BGP, or static routes—to perform loop prevention and tree construction.

---

1. Multicast Distribution Trees: Source Tree (SPT) vs. Shared Tree (RPT)

Multicast forwarding structures are modeled as tree graphs connecting sources to receivers without loops.

+-----------------------------------------------------------------------------------+
|                    SOURCE TREE (SPT) VS. SHARED TREE (RPT)                        |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  SOURCE TREE / SHORTEST PATH TREE (SPT)     SHARED TREE / ROOT PATH TREE (RPT)    |
|  Notation: (S, G)                           Notation: (*, G)                      |
|                                                                                   |
|         [ Source S1 ]                              [ Rendezvous Point (RP) ]      |
|               |                                            /         \            |
|         [ Router A ]                                 [ Router B ]   [ Router C ]  |
|          /        \                                      |               |        |
|    [ Router B ]  [ Router C ]                      [ Router D ]    [ Router E ]   |
|        |              |                                  |               |        |
|    [ Receiver 1 ] [ Receiver 2 ]                   [ Receiver 1 ]  [ Receiver 2 ] |
|                                                                                   |
|  • Rooted directly at Source S1             • Rooted at Centralized RP            |
|  • Optimal path & lowest latency            • Suboptimal path (Triangle routing)  |
|  • High router memory (per-source state)    • Low router memory (1 state per group)|
+-----------------------------------------------------------------------------------+

Architectural Comparison

2. Reverse Path Forwarding (RPF) Check Mechanics

In standard unicast routing, a router forwards a packet toward its destination based on destination IP address lookup. In multicast routing, the destination address is an abstract group, and the source transmits to unknown destinations.

To prevent catastrophic multicast loops and packet replication storms, multicast routers rely on Reverse Path Forwarding (RPF). Instead of asking "Where is this packet going?", the router asks: $\text{"Did this packet arrive on the interface I would use to reach the sender?"}$

+-----------------------------------------------------------------------------------+
|                         REVERSE PATH FORWARDING (RPF) LOGIC                       |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|                          [ Source: 10.1.1.50 ]                                    |
|                                    |                                              |
|                                    v                                              |
|                          [ Upstream Router ]                                      |
|                               /          \                                        |
|                   Gi0/0/1    /            \   Gi0/0/2                             |
|                             v              v                                      |
|                      +----------------------------+                               |
|                      |      Receiving Router      |                               |
|                      |                            |                               |
|                      | Unicast Routing Table (RIB)|                               |
|                      | 10.1.1.0/24 via Gi0/0/1    |                               |
|                      +----------------------------+                               |
|                             /              \                                      |
|        Packet arrives on Gi0/0/1:       Packet arrives on Gi0/0/2:                |
|        [ RPF CHECK PASSES ]             [ RPF CHECK FAILS ]                       |
|        -> Forward out OIL               -> SILENTLY DROP PACKET                   |
+-----------------------------------------------------------------------------------+

The RPF Calculation Algorithm

1. When a multicast packet arrives on an ingress interface, the router extracts the Source IP ($S$) from the packet header (for SPT forwarding) or the RP IP (for Shared Tree forwarding).
2. The router queries its Unicast Routing Table (or dedicated Multicast RIB) for the longest prefix match to that IP.
3. The outgoing interface in the unicast routing table is designated as the RPF Interface for that source/RP.
4. The next-hop router in the unicast routing table is designated as the RPF Neighbor.
5. Evaluation:
   • If the packet arrived on the RPF Interface: RPF Check Passes. The router replicates and forwards the packet out all interfaces in its Outgoing Interface List (OIL).
   • If the packet arrived on any non-RPF interface: RPF Check Fails. The router silently drops the packet.

3. PIM Sparse Mode (PIM-SM) Control Plane & Message Types

PIM Sparse Mode (RFC 7761) utilizes an explicit join model: multicast traffic is never sent to a subnet unless a downstream receiver has explicitly requested it via an IGMP report.

PIM runs directly on top of IP using IP Protocol 103, sending link-local messages to 224.0.0.13 (All-PIM-Routers) with TTL=1.

+-----------------------------------------------------------------------------------+
|                             CORE PIM-SM MESSAGE TYPES                             |
+-----------------------------------------------------------------------------------+
| Type | Message Name       | Transport / Destination | Purpose                     |
| ---- | ------------------ | ----------------------- | --------------------------- |
|  0   | **Hello**          | Multicast `224.0.0.13`   | Neighbor discovery, DR      |
|      |                    | (Hop-by-hop, 30s timer) | election, GenID tracking    |
|  1   | **Register**       | Unicast to RP IP        | FHR encapsulates source data|
|  2   | **Register-Stop**  | Unicast to FHR IP       | RP halts FHR encapsulation  |
|  3   | **Join / Prune**   | Multicast `224.0.0.13`   | Builds/tears down tree state|
|  4   | **Bootstrap (BSM)**| Multicast `224.0.0.13`   | Dynamic RP distribution     |
|  5   | **Assert**         | Multicast `224.0.0.13`   | Eliminates duplicate streams|
|  8   | **Candidate-RP-Adv**| Unicast to BSR IP      | C-RP announces to BSR       |
+-----------------------------------------------------------------------------------+

PIM Designated Router (DR) Election

On multi-access broadcast LANs (e.g., shared Ethernet subnets with multiple routers), electing a single Designated Router (DR) prevents duplicate control messages and duplicate traffic streams.

• DR Responsibilities:
  • On Receiver Subnets: The DR acts on IGMP Membership Reports and sends PIM (*, G) or (S, G) Joins upstream toward the RP/Source.
  • On Source Subnets: The DR receives multicast packets from local sources, encapsulates them into PIM Register unicast messages, and transmits them to the RP.
• Election Criteria:
  1. Highest DR Priority (ip pim dr-priority <value>, default = 1, range 0 to 4294967295).
  2. Tie-Breaker: Highest IPv4 address on the interface.

PIM Assert Mechanism

If two routers on a multi-access LAN both forward the same multicast stream down to hosts, receivers receive duplicate packets. The routers detect this collision and immediately exchange PIM Assert messages:

1. Routers compare their Unicast Administrative Distance (AD) to the source.
2. If AD is tied, routers compare their Unicast Metric to the source.
3. If metric is tied, the router with the Highest IP Address wins.
4. The winner continues forwarding; the loser removes the interface from its OIL and stops transmitting.

4. End-to-End PIM-SM Lifecycle & SPT Switchover

The complete operational lifecycle of PIM-SM involves three sequential phases: Shared Tree Join, Source Registration, and Shortest Path Tree (SPT) Switchover.

+-----------------------------------------------------------------------------------+
|                         PIM-SM FULL OPERATIONAL LIFECYCLE                         |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  [Source S] ---> (1. Multicast) ---> [ FHR / DR ] === 2. PIM Register (Unicast)==> [ RP ]
|                                            |                                        |
|                                            |                                        |
|                                   4. Direct SPT (S,G)                      3. Shared Tree
|                                            |                                  (*, G)
|                                            v                                        v
|  [Receiver] <--- (IGMP Report) <--- [ LHR / DR ] <=== 5. PIM Prune (*, G) <=== [ Router ]
+-----------------------------------------------------------------------------------+

Step-by-Step Execution

1. Phase 1: Receiver Joins Shared Tree (*, G):
   • A host sends an IGMP Membership Report for group $G$ to Last-Hop Router (LHR).
   • LHR creates a (*, G) mroute entry and sends a PIM (*, G) Join hop-by-hop toward the Rendezvous Point (RP).
   • Intermediate routers add the downstream interface to their (*, G) Outgoing Interface List (OIL).
2. Phase 2: Source Registers with the RP:
   • Source $S$ begins transmitting multicast packets to group $G$.
   • First-Hop Router (FHR) intercepts the packets. Because FHR does not yet have an SPT to the receivers, it encapsulates the entire multicast packet inside a unicast PIM Register packet and unicasts it directly to the RP.
   • RP decapsulates the packet and forwards native multicast data down the Shared Tree (*, G) to the LHR and receivers.
   • Simultaneously, RP sends a native (S, G) Join back toward the FHR to build a native SPT between FHR and RP.
   • Once native (S, G) data arrives at the RP, the RP unicasts a PIM Register-Stop message to FHR, instructing FHR to cease software encapsulation.
3. Phase 3: Shortest Path Tree (SPT) Switchover:
   • As soon as the LHR receives the very first data packet from Source $S$ forwarded over the Shared Tree, the LHR learns the source's unicast IP address.
   • In Cisco IOS-XE, the default SPT threshold is 0 kbps (ip pim spt-threshold 0).
   • LHR performs an RPF lookup for Source $S$ and sends a PIM (S, G) Join directly toward Source $S$.
   • As soon as multicast traffic arrives at LHR via the optimal (S, G) path, LHR sends a PIM (S, G) Prune (with the RP-bit set) upstream toward the RP on the Shared Tree to eliminate duplicate packet delivery.

5. Source-Specific Multicast (PIM-SSM)

Source-Specific Multicast (PIM-SSM), standardized in RFC 4607, is a streamlined evolution of PIM that eliminates Shared Trees, Rendezvous Points (RPs), Register encapsulation, and MSDP entirely.

• Dedicated Address Range: 232.0.0.0/8 (232.0.0.0 to 232.255.255.255).
• Operation:
  1. The receiver application learns the Source IP ($S$) and Group IP ($G$) out-of-band (e.g., via web portal, DNS, or SDP file).
  2. The receiver uses IGMPv3 to signal an explicit INCLUDE (S, G) join to the Last-Hop Router.
  3. LHR immediately sends a PIM (S, G) Join directly upstream toward Source $S$.
  4. The Shortest Path Tree is built immediately—no Shared Tree, no RP lookup, no Register messages.

+-----------------------------------------------------------------------------------+
|                         PIM-SM VS. PIM-SSM ARCHITECTURE                           |
+-----------------------------------------------------------------------------------+
| Feature                    | PIM Sparse Mode (PIM-SM)   | PIM Source-Specific (SSM)|
| -------------------------- | -------------------------- | ------------------------ |
| Address Range              | 224.0.0.0/4 (Any Group)    | 232.0.0.0/8 (Dedicated)  |
| Signaling Protocol         | IGMPv2 or IGMPv3           | **IGMPv3 Strictly**      |
| Rendezvous Point (RP)      | **Required**               | **None (No RP Needed)**  |
| Distribution Trees Built   | Shared (*, G) then (S, G)  | **Direct (S, G) SPT Only**|
| Denial of Service Risk     | High (Rogue sources to RP) | Zero (Receiver selects S)|
+-----------------------------------------------------------------------------------+

6. Cisco IOS-XE Configuration & Verification CLI

1. Configuring PIM-SM and PIM-SSM

! Globally enable multicast routing
ip multicast-routing

! Enable PIM-SSM with default 232.0.0.0/8 range
ip pim ssm default

! Enable PIM Sparse Mode and tune DR priority on interfaces
interface GigabitEthernet0/0/1
 description DOWNLINK-TO-RECEIVERS
 ip address 10.10.10.1 255.255.255.0
 ip pim sparse-mode
 ip pim dr-priority 100
 ip igmp version 3
!
interface GigabitEthernet0/0/2
 description CORE-UPLINK
 ip address 10.20.20.1 255.255.255.0
 ip pim sparse-mode

2. Tuning SPT Switchover Threshold

! Default behavior: Switchover immediately on 1st packet (0 kbps)
ip pim spt-threshold 0

! Force router to remain on Shared Tree (*, G) permanently (never switch to SPT)
ip pim spt-threshold infinity

3. Verification Commands & Diagnostics

Router# show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, SS - SSM Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
10.20.20.2        GigabitEthernet0/0/2     02:14:05/00:01:25 v2    1 / S
10.10.10.2        GigabitEthernet0/0/1     00:45:12/00:01:32 v2    100 / DR S SS

Router# show ip rpf 172.16.1.100
RPF information for ? (172.16.1.100)
  RPF interface: GigabitEthernet0/0/2
  RPF neighbor: ? (10.20.20.2)
  RPF route/mask: 172.16.1.0/24
  RPF type: unicast (ospf 1)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

Router# show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
       J - Join SPT, M - MSDP created entry, E - Extranet

(*, 239.1.1.1), 00:04:15/00:02:44, RP 10.255.255.1, flags: SJC
  Incoming interface: GigabitEthernet0/0/2, RPF nbr 10.20.20.2
  Outgoing interface list:
    GigabitEthernet0/0/1, Forward/Sparse, 00:04:15/00:02:44

(172.16.1.100, 239.1.1.1), 00:00:18/00:03:11, flags: T
  Incoming interface: GigabitEthernet0/0/2, RPF nbr 10.20.20.2
  Outgoing interface list:
    GigabitEthernet0/0/1, Forward/Sparse, 00:00:18/00:03:11

7. Bidirectional PIM (Bidir-PIM, RFC 5015)

ENCOR v1.2 expanded topic 3.3.d to name multicast protocols "such as RPF check, PIM SM, IGMP v2/v3, SSM, bidir, and MSDP." Bidirectional PIM was not called out by name in v1.1, so it is one of the genuinely new items on the v1.2 blueprint.

7.1 The Problem Bidir-PIM Solves

PIM-SM and PIM-SSM both end up building source trees, which means every router on the path holds an (S, G) entry for every active source. For one-to-many distribution — a video stream, a market data feed — that is fine, because S is small.

Now consider a many-to-many application: a trading floor where 800 workstations are simultaneously senders and receivers of the same group, or a large conferencing deployment. State scales as O(S x G), so 800 sources in one group means 800 (S, G) entries on every router in the path. Multiply that across groups and the multicast routing table becomes the constraint.

Bidir-PIM removes source state entirely. It builds one bidirectional shared tree per group and holds only (*, G) state, so consumption is O(G) regardless of how many sources exist. Adding the 801st sender adds zero new state anywhere.

7.2 What Bidir-PIM Removes

Traffic flows in both directions on the same tree. A source simply forwards its traffic up the shared tree toward the RP on the same branches that carry traffic down toward receivers — hence "bidirectional". There is no encapsulated Register message, so the RP never touches the data plane.

7.3 Designated Forwarder Election

Because traffic travels upstream on the shared tree, the ordinary RPF check cannot be used for loop prevention — an incoming packet may legitimately arrive on the interface pointing toward the RP. Bidir-PIM replaces it with the Designated Forwarder (DF).

On every link, for every RP, the routers elect exactly one DF:

1. The router advertising the best unicast routing metric to the RP address wins (lowest administrative distance first, then lowest metric).
2. Ties are broken by the highest IP address on the link.

Only the DF may forward traffic onto that link toward the RP, and only the DF may forward traffic off the tree onto that link. Because exactly one router per link performs both jobs, a packet can never be duplicated or looped, which is precisely the guarantee the RPF check provides in PIM-SM.

The DF is elected per link and per RP, not per group. A router can be DF on one interface and a non-DF on another simultaneously.

7.4 The Phantom RP

The RP in Bidir-PIM performs no data-plane work at all — it never decapsulates a Register, never joins a source tree, and never forwards on behalf of a source. Its address exists only as the root of the shared tree and the target of the DF metric comparison.

That allows the phantom RP design: the RP address is a routable address that no device actually owns. Two candidate routers advertise it as a loopback with different prefix lengths (for example a /30 on the primary and a /29 on the secondary covering the same address). Longest-prefix match steers every router to the primary, and if the primary fails the /29 takes over automatically — RP redundancy with no protocol, no MSDP, and no state synchronisation. Contrast this with Anycast RP in PIM-SM (Section 13.3), which needs MSDP or PIM Anycast RP precisely because the RP there does learn source state.

7.5 Configuration and Verification

! Bidir must be explicitly enabled globally before any bidir RP can be configured
ip multicast-routing distributed
ip pim bidir-enable
!
! Define which group range uses the bidirectional shared tree
ip access-list standard BIDIR-GROUPS
 permit 239.200.0.0 0.0.255.255
!
ip pim rp-address 10.255.255.10 BIDIR-GROUPS bidir
!
interface GigabitEthernet0/0/1
 ip pim sparse-mode
!
! ---- Verification ----
Router# show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 239.200.0.0/16, Static, Bidir Mode
    RP: 10.255.255.10 (?)
!
Router# show ip pim interface df
 Interface          RP               DF Winner        Metric  State
 GigabitEthernet0/0/1  10.255.255.10  10.1.12.1        20      DF
 GigabitEthernet0/0/2  10.255.255.10  10.1.23.3        10      Non-DF
!
Router# show ip mroute 239.200.1.1
(*, 239.200.1.1), 00:12:41/00:02:52, RP 10.255.255.10, flags: BC
  Bidir-Upstream: GigabitEthernet0/0/1, RPF nbr 10.1.12.1
  Incoming interface list:
    GigabitEthernet0/0/1, Bidir-Upstream/Sparse
  Outgoing interface list:
    GigabitEthernet0/0/3, Forward/Sparse, 00:12:41/00:02:52

How to read that output: the B flag in show ip mroute marks a Bidir group and the Bidir-Upstream line names the interface toward the RP. The decisive confirmation that Bidir-PIM is working is that there are no (S, G) entries at all, no matter how many hosts are sending. If you see (S, G) entries for a group you configured as bidir, the bidir keyword is missing from the RP statement, ip pim bidir-enable was never applied, or a router in the path does not support Bidir-PIM and has silently fallen back to sparse mode.