IP Multicast: The Complete Guide

IP multicast is how you deliver one stream of traffic to many receivers without sending a separate copy to each one. Market data feeds, IPTV, live video distribution, and network imaging all depend on it, and it sits squarely in the ENCOR blueprint because it changes almost every assumption you carry over from unicast routing. Forwarding decisions run backwards, group membership is dynamic, and a single misconfigured router can silently blackhole an entire stream.

This guide is the hub for the PingLabz multicast cluster. It covers what multicast solves, how distribution trees and PIM sparse mode actually work, the address ranges you need to recognize on sight, a minimum viable IOS XE configuration with real lab output, hardening, and the failure patterns you will actually hit. Every capture in this cluster comes from a live CML lab with a real Debian Linux host joining groups as the receiver, not from memory or vendor slides.

What IP Multicast Solves

Unicast delivery scales linearly with receiver count. If a market data server pushes a 5 Mbps feed to 200 subscribers over unicast, the server and its first-hop link carry 1 Gbps of duplicated traffic. Broadcast solves the duplication but floods every host in the segment whether it wants the data or not, and it cannot cross a router.

Multicast splits the difference: the source sends one copy to a group address, and the network replicates packets only where the paths to interested receivers diverge. The server sends 5 Mbps, each link carries at most one copy of the stream, and hosts that never asked for the feed never see it. Receivers opt in by joining a group with IGMP (covered in IGMP explained: v2 vs v3), and routers build delivery trees with PIM. The full economics of this, and why unicast falls over, are in What is IP multicast?

How IP Multicast Works

Four mechanisms cooperate to move a multicast packet from source to receivers, and each one has a dedicated deep-dive in this cluster:

Group addressing. Sources send to a class D address (224.0.0.0/4). A group address identifies a service, not a host, and maps to a MAC address in the 01:00:5e range so switches can flood or constrain it at layer 2. The ranges that matter are in multicast addressing.

Membership signaling. Hosts tell their first-hop router which groups they want using IGMP. The router tracks membership per interface and answers periodic queries. IGMPv3 adds source filtering, which is what makes SSM possible.

Tree building. Routers run PIM (Protocol Independent Multicast) to build a distribution tree between sources and receivers. PIM sparse mode builds an explicit-join shared tree rooted at a rendezvous point, then switches to a shortest-path tree per source. That state machine, with real before-and-after output, is in PIM sparse mode explained.

Loop prevention. Every multicast packet is subject to a reverse path forwarding check: if it does not arrive on the interface the router would use to reach the source, it is dropped. RPF is the reason multicast never loops and also the number one reason it mysteriously fails. See the RPF check.

PIM is "protocol independent" because it borrows the unicast routing table for its RPF decisions instead of computing its own topology. That means your multicast overlay is only as healthy as the underlay IGP beneath it; in this cluster's lab the underlay is OSPF area 0.

Reference: Multicast Address Ranges

These are the assignments you need to recognize on sight (full breakdown in multicast addressing explained):

Shared Trees, Source Trees, and the RP

Multicast forwarding state is a tree, and IOS XE shows you the tree directly in show ip mroute as two entry types. A (*,G) entry is the shared tree: "any source, group G", rooted at the rendezvous point. A (S,G) entry is a source tree: the shortest path from one specific source to the receivers.

PIM sparse mode uses both. Receivers join the shared tree toward the RP because it is the one place every router can find sources it has never heard of. The moment real traffic flows, the last-hop router learns the source address and joins the shortest-path tree directly, then prunes the shared tree. This SPT switchover happens by default on the first packet on IOS XE (ip pim spt-threshold 0). Here is real state from the lab, on the last-hop router while pinned to the shared tree and immediately after switchover:

R1# show ip mroute 239.1.1.10          ! pinned to shared tree
(*, 239.1.1.10), 00:03:04/00:02:24, RP 2.2.2.2, flags: SC
  Incoming interface: Ethernet0/1, RPF nbr 10.0.12.2

R1# show ip mroute 239.1.1.10          ! after SPT switchover
(*, 239.1.1.10), 00:03:34/stopped, RP 2.2.2.2, flags: SJC
(10.0.30.10, 239.1.1.10), 00:00:05/00:02:54, flags: JT
  Incoming interface: Ethernet0/1, RPF nbr 10.0.12.2

The J flag is the join-SPT decision, the T flag confirms traffic is arriving on the source tree. The full walk-through, including registration at the RP, is in PIM sparse mode: RPs, shared trees, and the SPT switchover.

Reference: PIM Modes and When to Use Them

Minimum Viable Multicast on Cisco IOS XE

This is the smallest PIM-SM configuration that moves real traffic, taken from the cluster lab (four IOL-XE routers, OSPF area 0 underlay, R2 as static RP, and a real Debian VM as the receiver behind R1):

! On every router in the multicast domain
ip multicast-routing

interface Ethernet0/1
 ip pim sparse-mode        ! on EVERY interface in the multicast path

! On every router: who the RP is (static, simplest option)
ip pim rp-address 2.2.2.2

! Enable the SSM range while you are at it
ip pim ssm default

Three rules cause most first-lab failures: ip multicast-routing is required globally or nothing forwards, ip pim sparse-mode must be on every transit interface including the ones facing receivers and sources, and every router must agree on the RP. Verify with real output:

R2# show ip pim neighbor
Neighbor          Interface                Uptime/Expires    Ver   DR
10.0.12.1         Ethernet0/0              00:02:06/00:01:36 v2    1 / S P G
10.0.23.2         Ethernet0/1              00:02:04/00:01:39 v2    1 / DR S P G

R1# show ip pim rp mapping
Group(s): 224.0.0.0/4, Static
    RP: 2.2.2.2 (?)

And the part that matters, a real Linux host receiving the stream end to end:

j@llmbits:~$ python3 /tmp/mcast_recv.py 239.1.1.10 5001
joined 239.1.1.10:5001 on 192.168.99.100 (IGMP membership active)
rx 32 bytes from 10.0.30.10: PingLabz mcast 239.1.1.10 pkt 53
rx 32 bytes from 10.0.30.10: PingLabz mcast 239.1.1.10 pkt 54
rx 32 bytes from 10.0.30.10: PingLabz mcast 239.1.1.10 pkt 55

One sender TTL gotcha: the default multicast TTL on most host stacks is 1, which dies at the first router. Set it explicitly (in Python, IP_MULTICAST_TTL) or your perfectly configured network will deliver nothing.

RP Engineering: Static, BSR, Auto-RP, Anycast

The rendezvous point is configuration, not election. You have four ways to tell routers where it is. Static assignment (ip pim rp-address) is explicit and predictable but must be touched on every router to change. BSR is the standards-based dynamic option: candidate RPs advertise to a bootstrap router, which floods the RP set hop by hop. Auto-RP is the older Cisco-proprietary equivalent using groups 224.0.1.39/40. Anycast RP gives you redundancy by putting the same RP address on multiple routers and syncing their source knowledge with MSDP.

Here is the lab showing static and BSR mappings coexisting on R1 (bootstrap-learned entries take precedence over static without the override keyword):

R1# show ip pim rp mapping
Group(s) 224.0.0.0/4
  RP 2.2.2.2 (?), v2
    Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Group(s): 224.0.0.0/4, Static
    RP: 2.2.2.2 (?)

Cross-domain and redundancy designs (MSDP peering, SA caches, anycast RP) get their own article: Bidirectional PIM and MSDP.

Multicast at Layer 2: Snooping and the Querier

Routers see none of this without the switches cooperating. A multicast destination MAC never appears in a switch's learned address table, so the default behavior is flooding the frame to every port in the VLAN, which turns a 500 Mbps video feed into a 500 Mbps tax on every access port. IGMP snooping fixes it: the switch eavesdrops on IGMP reports and queries, learns which ports have members and which lead to routers, and constrains each group's frames accordingly. It is enabled by default on Cisco switches and belongs on.

The dependency to remember: snooped state only survives while queries keep flowing, because member ports are re-learned from the answers. On a VLAN with no multicast router (a pure L2 lab segment, a storage replication VLAN), there is no querier, state ages out, and multicast dies a few minutes after it started working. The fix is one line on the switch: ip igmp snooping querier. The related MAC-level subtlety, 32 IP groups sharing each multicast MAC so snooping cannot fully distinguish them, is covered in multicast addressing, and it is one more reason to plan group assignments instead of picking them at random.

Securing Multicast

Multicast expands your attack surface in specific ways: any host can send to any group by default, IGMP state can be exhausted, and rogue RPs can hijack group ranges. The practical hardening set:

• Scope 239/8 at your edges. Apply ip multicast boundary ACLs on external interfaces so organization-local groups never leak, in either direction.
• Filter who can register sources. ip pim accept-register list on the RP rejects register messages from unauthorized sources before state is created.
• Constrain RP learning. With BSR or Auto-RP, filter candidate RP announcements (ip pim rp-announce-filter, BSR border) so a rogue device cannot claim RP duty.
• Limit IGMP state. ip igmp limit and per-interface access groups (ip igmp access-group) cap what receivers can join and how much state they can create.
• Prefer SSM where you control receivers. No RP and no shared tree means the register and RP hijack attack classes simply do not exist. QoS-marking the stream properly also keeps it from starving control traffic; see the QoS guide.

Troubleshooting: The Three Failure Patterns

Almost every "multicast is broken" ticket reduces to one of three signatures, each demonstrated with real broken state in troubleshooting IP multicast:

RPF failure. Traffic arrives on an interface that does not match the unicast route back to the source, so the router drops it silently. The tell is an (S,G) with the wrong incoming interface and a Null outgoing list. show ip rpf <source> is the first command to run; a static ip mroute is the surgical fix. Details in the RPF check.

Silent receiver. The source is registering, the RP has (S,G) state, but the OIL is Null everywhere because no IGMP join ever arrived. Check show ip igmp groups on the last-hop router before you touch PIM.

Missing or mismatched RP. A receiver-side router with no RP mapping shows the giveaway RP 0.0.0.0 in its (*,G) entry and never sends a join upstream. show ip pim rp mapping on every router in the path settles it.

The Full Multicast Cluster, in Reading Order

Foundations

The routing core

Operations

FAQ

Does multicast work over the public internet?

Effectively no. Interdomain multicast (MSDP plus MBGP) exists and powers some research and exchange fabrics, but consumer ISPs do not forward it. Internet-scale streaming uses unicast CDNs instead; multicast dominates inside enterprises, service provider cores, and financial extranets where the operator controls every hop.

Do I need an RP for all multicast?

No. The RP exists only for any-source multicast (ASM), where receivers do not know sources in advance. SSM removes the RP entirely: the receiver names the source in its IGMPv3 join and the last-hop router builds the (S,G) tree directly. If your application can learn source addresses out of band, SSM is less state and fewer failure modes.

What is the difference between (*,G) and (S,G)?

(*,G) is shared-tree state, "any source sending to G", rooted at the RP. (S,G) is source-tree state for one specific sender, following the shortest unicast path from S. In standard PIM-SM you see both on the last-hop router after the SPT switchover; in SSM you only ever see (S,G).

Why does my multicast stop at the first router?

Usually sender TTL. Most operating systems default the multicast TTL to 1, so the first router decrements it to zero and drops it. Set the TTL on the sending socket. If TTL is fine, check ip multicast-routing and per-interface ip pim sparse-mode next.

Is IGMP a routing protocol?

No. IGMP runs only on the host-facing segment between receivers and their first-hop router; it signals membership, not reachability. PIM does the router-to-router work, and it leans on your unicast IGP for every RPF decision.

Key Takeaways

• Multicast delivers one copy per link instead of one copy per receiver; the network replicates at divergence points and only interested hosts receive traffic.
• Three protocols share the work: IGMP between hosts and routers, PIM between routers, and your unicast IGP underneath feeding the RPF check.
• PIM-SM meets unknown sources through an RP-rooted shared tree, then cuts over to the shortest-path tree per source. The J and T flags in show ip mroute tell you exactly where in that lifecycle you are.
• Minimum viable IOS XE config: ip multicast-routing, ip pim sparse-mode on every interface in the path, and an agreed RP. Miss any of the three and traffic silently dies.
• SSM (232/8 plus IGMPv3) removes the RP, the register process, and two entire failure classes. Prefer it when receivers can learn source addresses.
• When multicast breaks, it is almost always one of three signatures: RPF failure, silent receiver, or missing RP. show ip mroute, show ip rpf, and show ip pim rp mapping resolve all three.