- 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
Configuring PIM-to-IGMP and PIM-to-MLD Message Translation
Understanding PIM-to-IGMP and PIM-to-MLD Message Translation
Routing devices can translate Protocol Independent Multicast (PIM) join and prune messages into corresponding Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) report or leave messages. You can use this feature to forward multicast traffic across PIM domains in certain network topologies.
In some network configurations, customers are unable to run PIM between the customer edge-facing PIM domain and the core-facing PIM domain, even though PIM is running in sparse mode within each of these domains. Because PIM is not running between the domains, customers with this configuration cannot use PIM to forward multicast traffic across the domains. Instead, they might want to use IGMP to forward IPv4 multicast traffic, or MLD to forward IPv6 multicast traffic across the domains.
To enable the use of IGMP or MLD to forward multicast traffic across the PIM domains in such topologies, you can configure the rendezvous point (RP) router that resides between the edge domain and core domain to translate PIM join or prune messages received from PIM neighbors on downstream interfaces into corresponding IGMP or MLD report or leave messages. The router then transmits the report or leave messages by proxying them to one or two upstream interfaces that you configure on the RP router. As a result, this feature is sometimes referred to as PIM-to-IGMP proxy or PIM-to-MLD proxy.
To configure the RP router to translate PIM join or prune messages
into IGMP report or leave messages, include the pim-to-igmp-proxy statement at the [edit routing-options multicast] hierarchy
level. Similarly, to configure the RP router to translate PIM join
or prune messages into MLD report or leave messages, include the pim-to-mld-proxy statement at the [edit routing-options
multicast] hierarchy level. As part of the configuration, you
must specify the full name of at least one, but not more than two,
upstream interfaces on which to enable the PIM-to-IGMP proxy or PIM-to-MLD
proxy feature.
The following guidelines apply when you configure PIM-to-IGMP or PIM-to-MLD message translation:
Make sure that the router connecting the PIM edge domain and the PIM core domain is the static or elected RP router.
Make sure that the RP router is using the PIM sparse mode (PIM-SM) multicast routing protocol.
When you configure an upstream interface, use the full logical interface specification (for example, ge-0/0/1.0) and not just the physical interface specification (ge-0/0/1).
When you configure two upstream interfaces, the RP router transmits the same IGMP or MLD report messages and multicast traffic on both upstream interfaces. As a result, make sure that reverse-path forwarding (RPF) is running in the PIM-SM core domain to verify that multicast packets are received on the correct incoming interface and to avoid sending duplicate packets.
The router transmits IGMP or MLD report messages on one or both upstream interfaces only for the first PIM join message that it receives among all of the downstream interfaces. Similarly, the router transmits IGMP or MLD leave messages on one or both upstream interfaces only if it receives a PIM prune message for the last downstream interface.
Upstream interfaces support both local sources and remote sources.
Multicast traffic received from an upstream interface is accepted as if it came from a host.
See Also
Configuring PIM-to-IGMP Message Translation
You can configure the rendezvous point (RP) routing device
to translate PIM join or prune messages into corresponding IGMP report
or leave messages. To do so, include the pim-to-igmp-proxy statement at the [edit routing-options multicast] hierarchy
level:
[edit routing-options multicast]
pim-to-igmp-proxy {
upstream-interface [ interface-names ];
}
Enabling the routing device to perform PIM-to-IGMP message translation, also referred to as PIM-to-IGMP proxy, is useful when you want to use IGMP to forward IPv4 multicast traffic between a PIM sparse mode edge domain and a PIM sparse mode core domain in certain network topologies.
Before you begin configuring PIM-to-IGMP message translation:
Make sure that the routing device connecting the PIM edge domain and that the PIM core domain is the static or elected RP routing device.
Make sure that the PIM sparse mode (PIM-SM) routing protocol is running on the RP routing device.
If you plan to configure two upstream interfaces, make sure that reverse-path forwarding (RPF) is running in the PIM-SM core domain. Because the RP router transmits the same IGMP messages and multicast traffic on both upstream interfaces, you need to run RPF to verify that multicast packets are received on the correct incoming interface and to avoid sending duplicate packets.
To configure the RP routing device to translate PIM join or prune messages into corresponding IGMP report or leave messages:
See Also
Configuring PIM-to-MLD Message Translation
You can configure the rendezvous point (RP) routing device
to translate PIM join or prune messages into corresponding MLD report
or leave messages. To do so, include the pim-to-mld-proxy statement at the [edit routing-options multicast] hierarchy
level:
[edit routing-options multicast]
pim-to-mld-proxy {
upstream-interface [ interface-names ];
}
Enabling the routing device to perform PIM-to-MLD message translation, also referred to as PIM-to-MLD proxy, is useful when you want to use MLD to forward IPv6 multicast traffic between a PIM sparse mode edge domain and a PIM sparse mode core domain in certain network topologies.
Before you begin configuring PIM-to-MLD message translation:
Make sure that the routing device connecting the PIM edge domain and that the PIM core domain is the static or elected RP routing device.
Make sure that the PIM sparse mode (PIM-SM) routing protocol is running on the RP routing device.
If you plan to configure two upstream interfaces, make sure that reverse-path forwarding (RPF) is running in the PIM-SM core domain. Because the RP routing device transmits the same MLD messages and multicast traffic on both upstream interfaces, you need to run RPF to verify that multicast packets are received on the correct incoming interface and to avoid sending duplicate packets.
To configure the RP routing device to translate PIM join or prune messages into corresponding MLD report or leave messages:
