- play_arrow Overview
- play_arrow Managing Group Membership
- play_arrow Configuring IGMP and MLD
- play_arrow Configuring IGMP Snooping
- IGMP Snooping Overview
- Overview of Multicast Forwarding with IGMP Snooping or MLD Snooping in an EVPN-VXLAN Environment
- Configuring IGMP Snooping on Switches
- Example: Configuring IGMP Snooping on Switches
- Example: Configuring IGMP Snooping on EX Series Switches
- Verifying IGMP Snooping on EX Series Switches
- Changing the IGMP Snooping Group Timeout Value on Switches
- Monitoring IGMP Snooping
- Example: Configuring IGMP Snooping
- Example: Configuring IGMP Snooping on SRX Series Devices
- Configuring Point-to-Multipoint LSP with IGMP Snooping
- play_arrow Configuring MLD Snooping
- Understanding MLD Snooping
- Configuring MLD Snooping on an EX Series Switch VLAN (CLI Procedure)
- Configuring MLD Snooping on a Switch VLAN with ELS Support (CLI Procedure)
- Example: Configuring MLD Snooping on EX Series Switches
- Example: Configuring MLD Snooping on SRX Series Devices
- Configuring MLD Snooping Tracing Operations on EX Series Switches (CLI Procedure)
- Configuring MLD Snooping Tracing Operations on EX Series Switch VLANs (CLI Procedure)
- Example: Configuring MLD Snooping on EX Series Switches
- Example: Configuring MLD Snooping on Switches with ELS Support
- Verifying MLD Snooping on EX Series Switches (CLI Procedure)
- Verifying MLD Snooping on Switches
- play_arrow Configuring Multicast VLAN Registration
-
- play_arrow Configuring Multicast Routing Protocols
- play_arrow Connecting Routing Domains Using MSDP
- play_arrow Handling Session Announcements with SAP and SDP
- play_arrow Facilitating Multicast Delivery Across Unicast-Only Networks with AMT
- play_arrow Routing Content to Densely Clustered Receivers with DVMRP
-
- play_arrow Configuring Multicast VPNs
- play_arrow Configuring Draft-Rosen Multicast VPNs
- Draft-Rosen Multicast VPNs Overview
- Example: Configuring Any-Source Draft-Rosen 6 Multicast VPNs
- Example: Configuring a Specific Tunnel for IPv4 Multicast VPN Traffic (Using Draft-Rosen MVPNs)
- Example: Configuring Source-Specific Draft-Rosen 7 Multicast VPNs
- Understanding Data MDTs
- Example: Configuring Data MDTs and Provider Tunnels Operating in Any-Source Multicast Mode
- Example: Configuring Data MDTs and Provider Tunnels Operating in Source-Specific Multicast Mode
- Examples: Configuring Data MDTs
- play_arrow Configuring Next-Generation Multicast VPNs
- Understanding Next-Generation MVPN Network Topology
- Understanding Next-Generation MVPN Concepts and Terminology
- Understanding Next-Generation MVPN Control Plane
- Next-Generation MVPN Data Plane Overview
- Enabling Next-Generation MVPN Services
- Generating Next-Generation MVPN VRF Import and Export Policies Overview
- Multiprotocol BGP MVPNs Overview
- Configuring Multiprotocol BGP Multicast VPNs
- BGP-MVPN Inter-AS Option B Overview
- ACX Support for BGP MVPN
- Example: Configuring MBGP MVPN Extranets
- Understanding Redundant Virtual Tunnel Interfaces in MBGP MVPNs
- Example: Configuring Redundant Virtual Tunnel Interfaces in MBGP MVPNs
- Understanding Sender-Based RPF in a BGP MVPN with RSVP-TE Point-to-Multipoint Provider Tunnels
- Example: Configuring Sender-Based RPF in a BGP MVPN with RSVP-TE Point-to-Multipoint Provider Tunnels
- Example: Configuring Sender-Based RPF in a BGP MVPN with MLDP Point-to-Multipoint Provider Tunnels
- Configuring MBGP MVPN Wildcards
- Distributing C-Multicast Routes Overview
- Exchanging C-Multicast Routes
- Generating Source AS and Route Target Import Communities Overview
- Originating Type 1 Intra-AS Autodiscovery Routes Overview
- Signaling Provider Tunnels and Data Plane Setup
- Anti-spoofing support for MPLS labels in BGP/MPLS IP VPNs (Inter-AS Option B)
- BGP-MVPN SD-WAN Overlay
- play_arrow Configuring PIM Join Load Balancing
- Use Case for PIM Join Load Balancing
- Configuring PIM Join Load Balancing
- PIM Join Load Balancing on Multipath MVPN Routes Overview
- Example: Configuring PIM Join Load Balancing on Draft-Rosen Multicast VPN
- Example: Configuring PIM Join Load Balancing on Next-Generation Multicast VPN
- Example: Configuring PIM Make-Before-Break Join Load Balancing
- Example: Configuring PIM State Limits
-
- play_arrow General Multicast Options
- play_arrow Bit Index Explicit Replication (BIER)
- play_arrow Prevent Routing Loops with Reverse Path Forwarding
- play_arrow Use Multicast-Only Fast Reroute (MoFRR) to Minimize Packet Loss During Link Failures
- play_arrow Enable Multicast Between Layer 2 and Layer 3 Devices Using Snooping
- play_arrow Configure Multicast Routing Options
- play_arrow Controller-Based BGP Multicast Signaling
-
- play_arrow Troubleshooting
- play_arrow Knowledge Base
-
- play_arrow Configuration Statements and Operational Commands
ON THIS PAGE
Understanding PIM Sparse Mode
A Protocol Independent Multicast (PIM) sparse-mode domain uses reverse-path forwarding (RPF) to create a path from a data source to the receiver requesting the data. When a receiver issues an explicit join request, an RPF check is triggered. A (*,G) PIM join message is sent toward the RP from the receiver's designated router (DR). (By definition, this message is actually called a join/prune message, but for clarity in this description, it is called either join or prune, depending on its context.) The join message is multicast hop by hop upstream to the ALL-PIM-ROUTERS group (224.0.0.13) by means of each router’s RPF interface until it reaches the RP. The RP router receives the (*,G) PIM join message and adds the interface on which it was received to the outgoing interface list (OIL) of the rendezvous-point tree (RPT) forwarding state entry. This builds the RPT connecting the receiver with the RP. The RPT remains in effect, even if no active sources generate traffic.
State—the (*,G) or (S,G) entries—is the information used for forwarding unicast or multicast packets. S is the source IP address, G is the multicast group address, and * represents any source sending to group G. Routers keep track of the multicast forwarding state for the incoming and outgoing interfaces for each group.
When a source becomes active, the source DR encapsulates multicast data packets into a PIM register message and sends them by means of unicast to the RP router.
If the RP router has interested receivers in the PIM sparse-mode domain, it sends a PIM join message toward the source to build a shortest-path tree (SPT) back to the source. The source sends multicast packets out on the LAN, and the source DR encapsulates the packets in a PIM register message and forwards the message toward the RP router by means of unicast. The RP router receives PIM register messages back from the source, and thus adds a new source to the distribution tree, keeping track of sources in a PIM table. Once an RP router receives packets natively (with S,G), it sends a register stop message to stop receiving the register messages by means of unicast.
In actual application, many receivers with multiple SPTs are involved in a multicast traffic flow. To illustrate the process, we track the multicast traffic from the RP router to one receiver. In such a case, the RP router begins sending multicast packets down the RPT toward the receiver’s DR for delivery to the interested receivers. When the receiver’s DR receives the first packet from the RPT, the DR sends a PIM join message toward the source DR to start building an SPT back to the source. When the source DR receives the PIM join message from the receiver’s DR, it starts sending traffic down all SPTs. When the first multicast packet is received by the receiver’s DR, the receiver’s DR sends a PIM prune message to the RP router to stop duplicate packets from being sent through the RPT. In turn, the RP router stops sending multicast packets to the receiver’s DR, and sends a PIM prune message for this source over the RPT toward the source DR to halt multicast packet delivery to the RP router from that particular source.
If the RP router receives a PIM register message from an active source but has no interested receivers in the PIM sparse-mode domain, it still adds the active source into the PIM table. However, after adding the active source into the PIM table, the RP router sends a register stop message. The RP router discovers the active source’s existence and no longer needs to receive advertisement of the source (which utilizes resources).
If the number of PIM join messages exceeds the configured MTU, the messages are fragmented in IPv6 PIM sparse mode. To avoid the fragmentation of PIM join messages, the multicast traffic receives the interface MTU instead of the path MTU.
The major characteristics of PIM sparse mode are as follows:
Routers with downstream receivers join a PIM sparse-mode tree through an explicit join message.
PIM sparse-mode RPs are the routers where receivers meet sources.
Senders announce their existence to one or more RPs, and receivers query RPs to find multicast sessions.
Once receivers get content from sources through the RP, the last-hop router (the router closest to the receiver) can optionally remove the RP from the shared distribution tree (*,G) if the new source-based tree (S,G) is shorter. Receivers can then get content directly from the source.
The transitional aspect of PIM sparse mode from shared to source-based tree is one of the major features of PIM, because it prevents overloading the RP or surrounding core links.
There are related issues regarding source, RPs, and receivers when sparse mode multicast is used:
Sources must be able to send to all RPs.
RPs must all know one another.
Receivers must send explicit join messages to a known RP.
Receivers initially need to know only one RP (they later learn about others).
Receivers can explicitly prune themselves from a tree.
Receivers that never transition to a source-based tree are effectively running Core Based Trees (CBT).
PIM sparse mode has standard features for all of these issues.
Rendezvous Point
The RP router serves as the information exchange point for the other routers. All routers in a PIM domain must provide mapping to an RP router. It is the only router that needs to know the active sources for a domain—the other routers just need to know how to reach the RP. In this way, the RP matches receivers with sources.
The RP router is downstream from the source and forms one end of the shortest-path tree. As shown in Figure 1, the RP router is upstream from the receiver and thus forms one end of the rendezvous-point tree.

The benefit of using the RP as the information exchange point is that it reduces the amount of state in non-RP routers. No network flooding is required to provide non-RP routers information about active sources.
RP Mapping Options
RPs can be learned by one of the following mechanisms:
Static configuration
Anycast RP
Auto-RP
Bootstrap router
We recommend a static RP mapping with anycast RP and a bootstrap router (BSR) with auto-RP configuration, because static mapping provides all the benefits of a bootstrap router and auto-RP without the complexity of the full BSR and auto-RP mechanisms.