SSM — Source-Specific Multicast

Why it exists

Classic multicast asks the network to find sources on the receiver’s behalf. That is what the rendezvous point, the register, the shared tree and MSDP between domains all exist to do, and each of them is a moving part that can fail on its own.

SSM observes that for one-to-many distribution the receiver already knows the source — it came from a session description, a web page, a configuration file. Naming it in the join deletes the discovery problem instead of solving it.

232.0.0.0/8 is the default SSM range for IPv4 and ff3x::/32 for IPv6. Other ranges can be configured to use SSM semantics; what makes a channel source-specific is the router’s treatment of the range, not the address itself.

Asking for a source, not a group

A receiver names both the source and the group. The last-hop router builds a tree straight to that source and never talks to a rendezvous point.

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
Element	Kind	State
Source · 198.51.100.7	host	—
R1 · first hop	router	—
R2	router	—
R3 · last hop	router	—
Receiver	host	Wants: (198.51.100.7, 232.1.1.1)
Source · 198.51.100.7 — R1 · first hop	link	up
R1 · first hop — R2	link	up
R2 — R3 · last hop	link	up
R3 · last hop — Receiver	link	up

1 / 5

The receiver asks for one channel: source 198.51.100.7, group 232.1.1.1. The pair is the identity — the group address alone means nothing here.

The application had to learn the source address from somewhere — a web page, a session description, configuration. SSM does not solve that; it makes it the application’s problem, which is where it was already being solved.

What changed

Receiver: Wants → (198.51.100.7, 232.1.1.1)
Emphasis on Receiver

How it works

The identity of a stream is the pair (S,G), not the group address. Two sources sending to the same group address in the SSM range are two separate channels that do not interfere — which removes the group-address collision problem that ASM deployments spend real effort managing.

The receiver expresses the channel as an IGMPv3 INCLUDE list, or MLDv2 for IPv6. The last-hop router turns that directly into an (S,G) join sent hop by hop toward the source, following the unicast route.

A router in the SSM range must not build (*,G) state and must not forward a datagram whose source is not one the receiver asked for. There is no shared tree to fall back on and nothing to rendezvous with.

Try it

Check RPF

Change the arrival interface. Only the reverse-path interface toward the source is a pass.

Datagram for 232.1.1.1 from 192.0.2.10Arrived on

RPF failure · expected gi0/0

RPF failure: 192.0.2.10 matches 192.0.2.0/24 out gi0/0, but the datagram arrived on gi0/1. RFC 7761 §4.2 drops it.

On the wire

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

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

```
ip multicast-routing distributed
```
Still required. SSM removes the RP, not multicast routing.
```
ip pim ssm default
```
`default` is 232.0.0.0/8. Use `ip pim ssm range <acl>` for a different range, and put the identical range on every router — a router that disagrees treats the same group as ASM and goes looking for an RP.
Common mistake: Configuring the range on the last-hop routers only. Every router the join traverses has to agree, or the tree stops at the first one that does not.
RFC 4607 §4.3
```
interface GigabitEthernet1
 ip pim sparse-mode
 ip igmp version 3
```
Sparse mode is correct here: SSM uses the same machinery with the shared tree switched off. IGMPv3 is what lets a host name the source, and it is not the default on every platform.
RFC 4607 §4.1
```
! deliberately no `ip pim rp-address` for 232.0.0.0/8
```
An RP configured for the SSM range is inert at best and a sign that someone expected a shared tree. Leaving it out is the configuration.
```
ip igmp ssm-map enable
ip igmp ssm-map static SSM-GROUPS 198.51.100.7
ip access-list standard SSM-GROUPS
 permit 232.1.1.1
```
Only for hosts that cannot do IGMPv3. It tells the router which source a v2 report should have named — a translation table that has to be maintained, and the source-discovery problem SSM had removed.
RFC 4607 §4.2

Verify

show ip pim range-list: The SSM range this router believes in.
show ip mroute 232.1.1.1: An (S,G) and never a (*,G).
show ip igmp groups detail: INCLUDE mode with the source listed.
show ip rpf 198.51.100.7: The interface the RPF check expects the traffic on.

Caveats

The SSM range is per-router configuration. One router that disagrees treats the group as ASM, which produces an application that works from one subnet and not another.
IGMPv3 is required on the host, not just the interface. A v2 host produces a well-formed report the router can do nothing with, and no error anywhere.

When it breaks

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

A receiver joins a group in the SSM range, everything looks healthy, and no traffic ever arrives.
Narrow it down
1. Check the IGMP version the host actually sent, not the version configured on the interface.
2. Look for an INCLUDE list with a source in it.
3. Check whether the mroute table has any entry for the group at all.
Cause
An IGMPv2 report names a group and no source. In the SSM range there is no shared tree and no RP, so the router has nothing to build a tree toward.
Fix
Move the host to IGMPv3. Where that is impossible, configure SSM mapping and accept that the source list is now something you maintain.
The (S,G) join is sent and the tree never completes.
Narrow it down
1. Check for a unicast route to the source on every router along the path.
2. Confirm the RPF lookup resolves out of the interface the traffic would arrive on.
3. Look for a separate multicast RIB that is empty or stale.
Cause
SSM removes the RP, not the RPF check. A join follows the unicast route toward the source and stops where that route does.
Fix
Restore the route, or add a static multicast route so the RPF lookup resolves toward the interface the traffic actually uses.
An application built for SSM works from one subnet and not another, using the same group address.
Narrow it down
1. Compare the configured SSM range on each router.
2. Check whether the group is being treated as ASM somewhere on the path.
3. Look for a (*,G) entry, which should never exist in the SSM range.
Cause
The SSM range is configuration. A router that does not have the group in its range treats it as ASM, looks for an RP, and behaves completely differently for the same address.
Fix
Make the range identical on every router in the domain. A per-device SSM range is a split-brain waiting to be found by one application.
Traffic reaches the last-hop router and floods to every port on the access switch, or reaches none.
Narrow it down
1. Check whether the switch does IGMPv3 snooping or only v2.
2. Confirm a querier exists on the VLAN.
3. Look at the snooping forwarding table for the group.
Cause
A switch that only understands v2 reports cannot read a v3 INCLUDE list. Depending on the platform it either floods the group or drops it.
Fix
Enable IGMPv3 snooping, and make sure a querier exists — without one, snooping state times out and the switch falls back to flooding.
A channel that worked stops after the source is moved or renumbered, and no configuration was changed.
Narrow it down
1. Check whether SSM mapping is in use for that group.
2. Compare the mapped source address against where the source now actually is.
3. If the mapping is DNS-backed, check what the record resolves to now.
Cause
SSM mapping is a table on the router saying which source a version 2 report should have named. It is configuration, and it does not follow the source when the source moves.
Fix
Update the mapping, and treat it as the temporary measure it is. Every deployment that keeps it has reintroduced the source-discovery problem SSM exists to remove.

Design notes

For one-to-many — video, market data, software distribution — SSM should be the default. It is less to configure, less to monitor, and it removes an entire class of outage that has nothing to do with the traffic itself.

The requirement that bites is IGMPv3 on every receiver. Embedded devices, set-top boxes and older stacks frequently do not have it, and the failure is silent: a well-formed v2 report the router can do nothing with.

SSM mapping is the escape hatch for hosts stuck on v2, and it is a translation table on the router that has to be kept in step with reality. It works; it also puts the source-discovery problem back where SSM had removed it from.

Every router on the path still needs a unicast route to the source, because the RPF check has not gone anywhere. SSM removes the rendezvous point, not the reverse-path rule.

Misconceptions

“SSM is a third PIM mode alongside sparse and dense.”: It is a service model. Routers use the ordinary PIM-SM machinery restricted to (S,G) — no shared tree, no register, no RP. Nothing new is running; parts of what was already running are switched off.
“SSM still needs an RP for the initial join.”: It never contacts one. The receiver supplied the source address, so the last-hop router sends the join straight toward it. An RP configured for the SSM range is a sign of a misunderstanding, not a requirement.
“Two applications using the same SSM group address will interfere.”: They will not. The channel is the (S,G) pair, so the same group address with two different sources is two independent streams. Group-address coordination, which ASM deployments spend real effort on, stops being a problem.
“SSM only works in 232.0.0.0/8.”: 232.0.0.0/8 is the default range. SSM semantics can be configured for other ranges, and the risk is that the range is per-router configuration — one router that disagrees treats the same address as ASM.

More walkthroughs

What disappears, and what you must have insteaddesign-choice

SSM removes the RP, the shared tree, the register and MSDP — along with every failure mode they carry. It replaces them with two hard requirements.

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
Element	Kind	State
ASM · any source	zone	—
RP	router	Carries: Register, (*,G), switchover
SSM · named source	zone	—
Source	host	—
ASM · any source — RP	link	up
RP — Source	link	up
SSM · named source — Source	link	up

1 / 5

ASM has to discover sources for the receiver. That is what the rendezvous point, the register, the shared tree and the switchover to the shortest path all exist to do.

What changed

RP: Carries → Register, (*,G), switchover
Emphasis on ASM · any source ↔ RP
Emphasis on RP ↔ Source

The report that was accepted and did nothingfailure

A host sends an IGMPv2 report for a group in the SSM range. Nothing errors, nothing logs, and no traffic ever arrives.

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
Element	Kind	State
Host · IGMPv2	host	Report: IGMPv2 · 232.1.1.1
Last-hop router	router	—
Source · 198.51.100.7	host	—
Host · IGMPv2 — Last-hop router	link	up
Last-hop router — Source · 198.51.100.7	link	up

1 / 4

The host reports membership of 232.1.1.1 using IGMPv2. The report names a group and no source, because v2 has no field for one.

What changed

Host · IGMPv2: Report → IGMPv2 · 232.1.1.1
Emphasis on Host · IGMPv2 ↔ Last-hop router

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.
Channel: The (source, group) pair that identifies a source-specific stream. Two sources on the same group address are two channels and do not interfere.
IGMPv3 INCLUDE list: The membership report that names which sources a receiver wants. It is what makes SSM expressible; IGMPv2 has no field for a source, so a v2 report in the SSM range does nothing.

Check yourself

What identifies a stream in SSM?
Which rendezvous point does a last-hop router contact for an SSM channel?
A host sends an IGMPv2 report for a group in the SSM range. What happens?
Two applications independently choose 232.1.1.1. What is the consequence?
One router in the domain has a different SSM range configured. What breaks?
SSM removes source discovery from the network. Who does it instead?
Which multicast mechanism does SSM keep?
What should a router never create for a group in the SSM range?

Why it exists

Asking for a source, not a group

How it works

Try it

Check RPF

On the wire

Configure it

Verify

Caveats

When it breaks

A receiver joins a group in the SSM range, everything looks healthy, and no traffic ever arrives.

Narrow it down

Cause

Fix

The (S,G) join is sent and the tree never completes.

Narrow it down

Cause

Fix

An application built for SSM works from one subnet and not another, using the same group address.

Narrow it down

Cause

Fix

Traffic reaches the last-hop router and floods to every port on the access switch, or reaches none.

Narrow it down

Cause

Fix

A channel that worked stops after the source is moved or renumbered, and no configuration was changed.

Narrow it down

Cause

Fix

Design notes

Misconceptions

More walkthroughs

What disappears, and what you must have insteaddesign-choice

The report that was accepted and did nothingfailure

Terms

Check yourself

Related

PIM-SM

PIM-DM

IGMP