SPBM Multicast and a Replacement Plan That Assumed the Wrong Protocol

A hospital system spanning several states runs its live IPTV distribution out of a single metro region’s headend: DirecTV and BlonderTongue encoder headends feeding 60+ active multicast streams. When the core node serving that region was rip-and-replaced, removing legacy Avaya-era SPBM hardware out, standing up new Cisco hardware: multicast went down hard across the region it served. The cutover plan wasn’t wrong about the hardware. It was wrong about SPBM multicast, and how the protocol was doing the work the plan assumed didn’t need replacing.

SPBM multicast has no PIM in the interior

Shortest Path Bridging (SPBM, 802.1aq) doesn’t run PIM inside the fabric. There’s no RP, no (*,G) flooding, no PIM neighbor state to inherit. IS-IS is not just the unicast routing protocol here; it’s the multicast routing protocol too. Every active (S,G) stream gets a dynamically allocated data I-SID out of the reserved 16M range, and that I-SID’s membership (which nodes are sourcing, which are receiving, on which B-VID) lives in the IS-IS link-state database alongside ordinary topology information. The IS-IS extensions that make this possible are documented in RFC 6329. The mechanism isn’t vendor lock-in; it’s a standards-track protocol choice.

That’s the detail a PIM-centric replacement plan has no reason to know, because nothing about a PIM-based network prepares you to expect multicast state inside your IGP.

Diagnosis, in the order it actually happened

The first command ruled out the protocol everyone assumed was there:

show ip spb-pim-gw mroute

Empty. No PIM gateway state anywhere in the fabric interior. That result alone reframed the problem: this wasn’t a PIM misconfiguration, because PIM wasn’t in the path at all.

The second command showed where the state actually lived:

show isis spbm ip-multicast-route all

200+ active (S,G) entries, all sourced from a single source BEB, in the 239.193.200.x range, with data I-SIDs in the 16M range alternating across two B-VIDs for load balancing. Multicast wasn’t missing. It was fully operational: hiding in plain sight, inside IS-IS.

The third command was the one that mattered most for anyone trying to build a mental model of the fabric fast:

show isis lsdb detail

Run from any node, this returns the complete fabric topology in a single output: every node’s I-SID memberships, transmit/receive flags, the entire multicast distribution tree. There is no equivalent single command in a PIM/IGMP world, since you’d normally reconstruct that picture from RP mapping, IGMP snooping tables, and PIM neighbor state across multiple devices. SPBM collapses all of it into one LSDB query because the control plane and the multicast state are the same database.

What a correct replacement design actually requires

Replacing SPBM’s multicast function with PIM is a protocol-model change, not a hardware refresh. New boxes don’t inherit the old fabric’s multicast behavior just because they occupy the same place in the topology. The gap-closing requirements:

• PIM-SM or PIM-SSM hop-by-hop on every SVI carrying video traffic; SPBM never needed PIM adjacencies because I-SID membership was already fabric-wide knowledge via IS-IS; a PIM-based replacement has to build that adjacency structure from nothing.
• IGMPv3 on subscriber-facing segments – SPBM’s I-SID model doesn’t distinguish subscriber join/leave the way IGMP does at the edge; this has to be added, not migrated.
• OSPF adjacencies, not passive redistribution – RPF correctness for PIM depends on a real unicast routing adjacency, not a static or redistributed route pointing in the right direction.
• An spb-pim-gw handoff during transition – a boundary device translating between the two multicast models while both fabrics coexist, rather than a hard cutover.

The lesson underneath the fix

The failure here wasn’t a misconfigured command or a missed line in a migration checklist. It was an assumption so foundational that neither vendor team’s engineers, working the problem independently from their own platform’s perspective, thought to name it out loud: that “multicast” meant PIM-based multicast, because that’s what multicast has meant in every network either team had built before.

SPBM doesn’t advertise that assumption is wrong. It just doesn’t produce PIM state, silently, until something depends on state that was never there.

This diagnostic work is one entry in a longer CDW engagement — more detail on /resume.