Junos PIM SSM: Source-Specific Multicast Configuration

Source-specific multicast (SSM) removes the rendezvous point from the equation: instead of joining a group and accepting traffic from any source, a receiver asks for one specific (S,G) channel. This article walks through the SSM configuration on Junos — the PIM sparse-mode prerequisite, the IGMPv3 receiver setting, extending the SSM group range beyond 232.0.0.0/8, and the RPF policy that decides which sources are even eligible. It also covers the mixed case where some groups remain any-source (ASM) and need an RP while others are strictly SSM. The commands below are taken from Juniper's documented SSM example and can be pasted into a lab with only address changes.

Why SSM Changes the Design

ASM needs a rendezvous point, an RP redundancy scheme, and MSDP if you cross domain boundaries. SSM needs none of that. The receiver signals the exact source with IGMPv3 (or MLDv2 for IPv6), the last-hop router sends an (S,G) join straight up the reverse path toward that source, and the shortest-path tree is built immediately. There is no shared tree, no RP, and no source discovery protocol.

The default SSM address range is 232.0.0.0 through 232.255.255.255. That range is deliberately carved out of the old ASM space, so most enterprises can start using it without renumbering anything.

Step 1 — PIM Sparse Mode Everywhere

SSM still runs on top of PIM sparse mode. If PIM is not explicitly enabled on both the source-facing and the receiver-facing interfaces, multicast packets are silently not forwarded.

set protocols pim interface all mode sparse
set protocols pim interface ge-0/0/0.0 mode sparse
set protocols pim interface ge-0/0/2.0 mode sparse

Step 2 — IGMPv3 on the Receiver LAN

The join for a specific source only exists in IGMPv3. IGMPv2 cannot express it, so the receiver interface must be pinned to version 3.

set protocols igmp interface ge-0/0/2.0 version 3

Step 3 — Extending the SSM Group Range

If you want to use group addresses outside 232.0.0.0/8, add them explicitly. This is also the step that lets you run ASM and SSM at the same time on the same router.

set routing-options multicast ssm-groups 233.0.0.0/8
set routing-options multicast ssm-groups 234.5.0.0/16

When ASM groups still exist elsewhere, keep an RP configured for them — the SSM range and the ASM range are independent once you add these statements.

set protocols pim rp static address 10.0.0.1
set protocols pim rp local address 10.0.0.1

Step 4 — Restrict the Sources with an RPF Policy

SSM will accept a join for any (S,G) inside the configured range. If you want to guarantee that only your own content servers can ever be joined, attach an RPF check policy. Traffic from any source not matched by the policy is dropped before it is replicated.

set policy-options policy-statement RPF-SSM from route-filter 198.51.100.2/32 exact
set policy-options policy-statement RPF-SSM from route-filter 198.51.100.3/32 exact
set policy-options policy-statement RPF-SSM then accept
set routing-options multicast rpf-check-policy RPF-SSM

Verification

show pim joins
show pim source
show multicast route
show igmp group detail
show route 198.51.100.2/32

show igmp group detail should show the group in include mode with the source list populated. If it shows exclude mode instead, the receiver asked for ASM and the host stack is not using IGMPv3.

Common Failure Modes

• Join accepted, no traffic. Almost always an RPF failure — the unicast route back to the source does not point out the interface the group arrived on. Check with show multicast rpf 198.51.100.2.
• IGMPv2 host on an SSM group. The join is interpreted as an ASM (*,G) request and, without an RP, goes nowhere.
• SSM range not extended. Groups such as 233.x are treated as ASM and require an RP that may not exist.

For related control-plane topics on this site, see MC-LAG ICCP Failure Scenarios: Liveness and LACP System ID Behavior and our Anycast RP with MSDP: Redundant Multicast Rendezvous Points configuration notes. If you are debugging a session that comes up but never passes traffic, the flow tracing workflow in Junos SRX Flow Session Debugging: Commands in Order applies the same RPF logic.

原文链接：https://juniper.net/documentation/us/en/software/junos/multicast/topics/example/mcast-ssm-groups-asm-override.html