Everything hard about PIM sparse mode traces back to one assumption: receivers do not know who the sources are. Drop that assumption and the rendezvous point, the register tunnel, the shared tree, and the SPT switchover all become unnecessary. That is Source-Specific Multicast: the receiver names the source, the network builds the (S,G) tree directly, and half the protocol machinery disappears. This article covers the model, the configuration, and live IOS XE captures of SSM state, including a real IGMPv3 gotcha that cost this lab twenty minutes. Part of the IP multicast guide.
ASM vs SSM: The Service Model Difference
Classic any-source multicast (ASM) sells receivers a group: join 239.1.1.10 and receive whatever any source sends to it. The network must discover sources on the receiver's behalf, which is the entire job of the RP in PIM sparse mode.
SSM sells a channel: the pair (S,G). A receiver subscribes to "10.0.30.10 sending to 232.1.1.10", named explicitly in its IGMPv3 membership report. Since the receiver supplies the source address, the last-hop router can send a PIM (S,G) join straight along the shortest path immediately. No RP consulted, no register process, no shared tree, no switchover: the tree is born as the SPT.
The trade: receivers must learn source addresses out of band. For IPTV middleware, market data feed directories, and anything with a control channel, that is trivially available, which is why one-to-many production streams are exactly where SSM dominates.
What SSM Eliminates
Configuration: Two Lines
SSM needs PIM sparse mode on the interfaces (as always), plus a declaration of the SSM range and IGMPv3 on receiver-facing interfaces:
! every router in the domain
ip pim ssm default ! "default" = 232.0.0.0/8
! receiver-facing interfaces (IOS XE defaults to IGMPv2)
interface Ethernet0/0
ip igmp version 3ip pim ssm default tells the router to treat 232/8 by SSM rules: never build (*,G) state for those groups, never consult an RP, and ignore sourceless (v2-style) joins for the range. A custom range is possible (ip pim ssm range <acl>), but 232/8 is IANA-reserved for exactly this and there is rarely a reason to deviate.
Live State: A Real SSM Join
In the lab, the Debian VM subscribes to channel (10.0.30.10, 232.1.1.10) with an IGMPv3 INCLUDE-mode report (in Python: IP_ADD_SOURCE_MEMBERSHIP). The edge router's IGMP table shows source-filtered membership, something IGMPv2 cannot express:
R1# show ip igmp groups 232.1.1.10 detail
Interface: Ethernet0/0
Group: 232.1.1.10
Flags: SSM
Group mode: INCLUDE
Last reporter: 169.254.147.59
Source Address Uptime v3 Exp CSR Exp Fwd Flags
10.0.30.10 00:00:08 00:02:51 stopped Yes RAnd the mroute table holds exactly one entry, source tree only, born fully formed:
R1# show ip mroute 232.1.1.10
(10.0.30.10, 232.1.1.10), 00:00:08/00:02:51, flags: sTI
Incoming interface: Ethernet0/1, RPF nbr 10.0.12.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:00:08/00:02:51Read the flags: lowercase s marks the SSM range, T confirms SPT traffic, I records that the state came from a source-specific host report. No (*,G) exists, and show ip pim rp mapping plays no part in any of it. Upstream at the source's first-hop router, the same story with no F flag, because registration never happens in SSM:
R3# show ip mroute 232.1.1.10
(10.0.30.10, 232.1.1.10), 00:00:30/00:02:59, flags: sT
Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:00:30/00:02:59And the actual receiver, a real Linux host pulling the channel end to end across four routers:
j@llmbits:~$ python3 /tmp/mcast_recv_ssm.py 232.1.1.10 10.0.30.10 5001
SSM join (10.0.30.10, 232.1.1.10):5001 - IGMPv3 source-specific membership active
rx 33 bytes from 10.0.30.10: PingLabz mcast 232.1.1.10 pkt 763
rx 33 bytes from 10.0.30.10: PingLabz mcast 232.1.1.10 pkt 764
rx 33 bytes from 10.0.30.10: PingLabz mcast 232.1.1.10 pkt 765The IGMPv3 Fallback Gotcha (Learned Live)
Building this capture hit a wall worth documenting: the VM's SSM join produced zero state on R1. Nothing in show ip igmp groups, no mroute entry, no errors anywhere. The wire told the story:
j@llmbits:~$ sudo tcpdump -i ens224 -c 3 -n igmp
10:41:03.46 IP 192.168.99.1 > 224.0.0.1: igmp query v3
10:41:05.06 IP 169.254.147.59 > 232.1.1.10: igmp v2 report 232.1.1.10The router queries at v3, but the host reports at v2. The receiver interface had been an IGMPv2 querier earlier in the lab session, and a v3 host that ever sees a v2 query drops into v2 compatibility mode and stays there for minutes, even after the querier upgrades. A v2 report has no source list, and IOS XE correctly ignores sourceless joins in the SSM range, so the subscription evaporated silently. The Linux fix is forcing v3 (echo 3 > /proc/sys/net/ipv4/conf/all/force_igmp_version, same for the interface) or waiting out the compat timer; the INCLUDE state above appeared seconds later. Full IGMP version mechanics are in IGMP explained: v2 vs v3.
The operational lesson generalizes: SSM failures are usually IGMPv3 signaling failures. Any v2-only host, v2-mode switch querier, or middlebox stripping v3 reports downgrades the segment and kills every SSM subscription on it.
SSM Mapping: Dragging Legacy Receivers Along
The IGMPv3 requirement has one escape hatch worth knowing. Plenty of embedded receivers (set-top boxes, industrial controllers, ancient imaging clients) speak only IGMPv2 and will never learn a source list. SSM mapping lets the router fill in the blank: when a v2 report arrives for a group in the SSM range, the router consults a configured map (or DNS) and manufactures the (S,G) join on the host's behalf.
ip igmp ssm-map enable
no ip igmp ssm-map query dns
ip igmp ssm-map static SSM-SOURCES 10.0.30.10
!
ip access-list standard SSM-SOURCES
permit 232.1.1.0 0.0.0.255With that applied on the receiver-facing router, a v2 join for anything in 232.1.1.0/24 behaves as if the host had asked for source 10.0.30.10 explicitly. It is a bridge, not a destination: the mapping is static configuration pretending to be receiver knowledge, so treat it as technical debt with a decommission date attached to the last v2 receiver.
Running SSM and ASM Side by Side
Real networks migrate; they do not flag-day. The good news is that SSM and ASM coexist without interaction, because the split is purely address-driven: ip pim ssm default changes behavior only inside 232/8, and every other group keeps full RP-based sparse-mode machinery. The lab this cluster is built on runs both simultaneously: 239.1.1.10 flows through registration, shared tree, and SPT switchover, while 232.1.1.10 rides a direct (S,G) with no RP involvement, on the same routers at the same time.
A sane migration sequence: enable ip pim ssm default everywhere first (it is inert until someone uses 232/8), roll IGMPv3 onto receiver interfaces, move the highest-volume one-to-many application onto a 232/8 channel with its source published through whatever control channel the app already has, and let the ASM estate shrink at its own pace. Each moved application removes its share of register load and RP dependency; when the last ASM group is gone, the RP configuration simply becomes deletable. The reverse ordering (renumbering groups before receivers speak v3) strands subscribers, per the compatibility trap above.
Where SSM Fits (and Where It Does Not)
SSM is the right default for one-to-many with known sources: IPTV channel lineups, market data (each feed is a published (S,G) channel), live event streaming, one-way telemetry fans. It also crosses domains trivially, since no interdomain source discovery is needed; the receiver already knows the source, making MSDP unnecessary for SSM (the ASM interdomain story is in bidir PIM and MSDP).
SSM fits poorly when sources are genuinely unknown or churn rapidly: many-to-many collaboration, service discovery patterns, or applications where anyone may transmit at any time. That is ASM's home turf, and at large many-to-many scale, bidirectional PIM's. One practical note: hosts subscribe per (S,G), so multi-source redundancy (primary and backup feed) means the application joins two channels and arbitrates, a pattern financial feed handlers implement as A/B feeds.
Verifying an SSM Deployment
The verification set for SSM is short because the moving parts are few. show ip pim ssm confirms the range configuration on each router. On receiver interfaces, show ip igmp interface must report version 3 on both the router and host lines, and show ip igmp groups detail must show INCLUDE mode with the expected sources; EXCLUDE mode for a 232/8 group means a host is sending v2-style joins that will be ignored. In the mroute table, healthy SSM is exactly one (S,G) per channel with the lowercase s flag, and the absence of state is itself diagnostic: no (*,G) should ever exist for an SSM group, so finding one means the range declaration is missing somewhere. End to end, the fastest proof remains a real subscription from a real host, which is precisely thirty seconds of Python on any Linux box you own.
Key Takeaways
- SSM subscribes receivers to (S,G) channels in 232/8. The receiver names the source, so the network needs no RP, no registers, no shared trees, and no switchover.
- Config is
ip pim ssm defaultdomain-wide plusip igmp version 3on receiver interfaces. - Healthy SSM state is unmistakable: only (S,G) entries, lowercase s and I flags, Group mode INCLUDE in the IGMP table.
- SSM's failure domain is IGMPv3 signaling. The v2 compatibility fallback silently discards source-specific joins; verify versions on both router and host before anything else.
- Named sources are also access control: receivers cannot be sprayed by rogue senders to the same group.
The full cluster, including the ASM machinery SSM replaces, lives in the complete multicast guide.
