Multicast fails silently. No ICMP unreachable, no log message, no down interface: the stream just is not there. The good news is that nearly every "multicast is broken" ticket collapses into one of three signatures, and each one is identifiable from show output in under a minute once you know what to look for. This article works through all three with genuinely broken state, captured live in a CML lab that was deliberately sabotaged one failure at a time. Part of the IP multicast guide.
The Debugging Model: Follow the Tree
A multicast stream needs three things end to end: membership at the receiver edge (IGMP), a delivery tree between first-hop and last-hop routers (PIM state that passes RPF), and agreement on the RP for shared-tree groups. The efficient workflow checks the two ends first, because they localize the fault immediately:
- Last-hop router:
show ip igmp groups. Is the receiver's join actually registered? - First-hop router:
show ip mroute <G>. Is the source actually sending, and is its (S,G) forwarding or pruned? - Then walk the middle with
show ip mrouteandshow ip rpf, upstream from the receiver, hunting for a Null OIL or a wrong incoming interface.
The three cases below are the three ways that walk ends.
Case 1: The Silent Receiver (No IGMP Join)
Symptom: the application team swears the receiver is subscribed; no traffic arrives. In the lab, a source was started for 239.2.2.20 with no receiver joined anywhere. First hop (R3) shows the source is real and registering:
R3# show ip mroute 239.2.2.20
(*, 239.2.2.20), 00:00:27/stopped, RP 2.2.2.2, flags: SPF
Incoming interface: Ethernet0/0, RPF nbr 10.0.23.1
Outgoing interface list: Null
(10.0.30.10, 239.2.2.20), 00:00:27/00:02:32, flags: PFT
Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0
Outgoing interface list: NullThe RP (R2) also knows the source, and is equally starved of receivers:
R2# show ip mroute 239.2.2.20
(*, 239.2.2.20), 00:00:18/stopped, RP 2.2.2.2, flags: SP
Outgoing interface list: Null
(10.0.30.10, 239.2.2.20), 00:00:18/00:02:41, flags: PA
Incoming interface: Ethernet0/1, RPF nbr 10.0.23.2
Outgoing interface list: NullRead the signature: source-side state exists everywhere it should (F flag at the first hop, (S,G) at the RP), but every OIL is Null and every entry is P (pruned). The network is working perfectly; nobody asked for the traffic. Meanwhile the last-hop router has no IGMP membership for the group at all, which is the confirming check: show ip igmp groups 239.2.2.20 returns nothing.
Root causes, in observed frequency order: the application never actually joined (wrong group, wrong port, bound to the wrong NIC), a host firewall dropping IGMP, IGMP snooping eating reports on a querier-less L2 segment, or an IGMP version mismatch (a v2 report for an SSM group is silently ignored, the trap documented in IGMP explained). Fix the join, and the tree builds itself within a second; the healthy contrast is in PIM sparse mode explained.
Case 2: RPF Failure (State Exists, Traffic Dies Midpath)
Symptom: joins are fine, source is fine, and somewhere in the middle a router drops every packet without logging a thing. This is the multicast-specific failure, and its fingerprint is unmistakable. The lab breaks it with a bad static route on the last-hop router (full walkthrough in the RPF check), producing this:
R1# show ip rpf 10.0.30.10
RPF interface: Ethernet0/0
RPF neighbor: ? (192.168.99.100)
RPF type: unicast (static)
R1# show ip mroute 239.1.1.10
(10.0.30.10, 239.1.1.10), 00:00:43/00:02:15, flags: PJX
Incoming interface: Ethernet0/0, RPF nbr 192.168.99.100
Outgoing interface list: NullThe tells, in order of diagnostic value: the (S,G) incoming interface points somewhere the stream cannot possibly arrive from (here, out the receiver-facing edge), the OIL is Null with a P flag despite an active receiver, and show ip rpf resolves to an interface that contradicts the physical topology. Traffic arrives on Ethernet0/1, the router demands Ethernet0/0, and every packet fails the check silently.
The fix is either repairing unicast routing or, when the asymmetry is intentional, a static mroute that overrides RPF for multicast only:
R1(config)# ip mroute 10.0.30.0 255.255.255.0 10.0.12.2
R1# show ip rpf 10.0.30.10
RPF interface: Ethernet0/1
RPF type: multicast (static)
R1# show ip mroute 239.1.1.10
(10.0.30.10, 239.1.1.10), 00:01:18/00:01:41, flags: JT
Incoming interface: Ethernet0/1, RPF nbr 10.0.12.2, MrouteP became JT, the OIL repopulated, and the stream resumed. Suspect this case first whenever tunnels, ECMP, or asymmetric routing exist anywhere in the path.
Case 3: Missing or Mismatched RP
Symptom: receivers join, sources send, and the two never meet. For shared-tree (ASM) groups, both sides depend on agreeing where the RP is; a router with no RP mapping for a group cannot even send its join upstream. The lab removes the RP configuration from the last-hop router and has the receiver join 239.5.5.5:
R1# show ip pim rp mapping
PIM Group-to-RP Mappings
R1# show ip mroute 239.5.5.5
(*, 239.5.5.5), 00:00:16/00:02:45, RP 0.0.0.0, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:00:16/00:02:45RP 0.0.0.0 is the entire diagnosis in four characters. The IGMP join was heard (the group and OIL exist, C flag set), but with no RP to root the shared tree, the incoming interface is Null and the (*,G) join goes nowhere. The receiver waits forever on a tree that was never built.
Check show ip pim rp mapping on every router in the path; they must all resolve the same RP for the group. Partial RP knowledge (some routers static, some learned, one forgotten) produces the maddening variant where multicast works from some sources and not others. Related failure in the same family: the RP is known but unreachable (its loopback missing from the IGP), which shows up as a valid mapping plus an RPF failure toward the RP address itself; show ip rpf 2.2.2.2 catches it. Dynamic distribution (BSR, Auto-RP) removes the per-router touch points but adds its own dependency: Auto-RP's 224.0.1.39/40 groups must themselves be forwarded, the classic chicken-and-egg solved by ip pim autorp listener.
The Supporting Cast: Neighbors, Snooping, and Debugs
Three more checks catch the failures that do not fit the big three cleanly. First, PIM adjacency: a single interface missing ip pim sparse-mode anywhere in the path breaks the join chain at that hop, and everything downstream looks like case 3 (joins going nowhere) while everything upstream looks healthy. show ip pim neighbor hop by hop finds the gap fast, and show ip pim interface shows which interfaces are even playing. In this lab that check looks like:
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
10.0.24.2 Ethernet0/2 00:01:59/00:01:42 v2 1 / DR S P GSecond, layer 2. IGMP snooping without a querier is the classic "works for two minutes, then dies" pattern: snooped state ages out with no queries to refresh it, and the switch quietly stops forwarding the group. show ip igmp snooping groups on the switch, and a snooping querier on router-less segments, close that case. Related and nastier: a snooping switch that drops IGMPv3 reports entirely (old firmware), which downgrades every SSM receiver behind it, per the version trap in IGMP explained.
Third, targeted debugs when show output stalls. debug ip igmp shows joins arriving (or not) in real time at the last hop; debug ip pim shows join/prune and register traffic; both are group-filterable with an ACL so they are safe on busy boxes if scoped. For register problems specifically, debug ip pim on the first hop and the RP simultaneously answers "are registers sent" and "are they answered" in one pass. Turn them off when done; multicast debugs on a router carrying real streams are chatty.
The Command Kit
A Worked Ticket, Start to Finish
Here is how the whole method composes on a realistic ticket: "the 239.1.1.10 dashboard feed stopped for the branch behind R1; other sites are fine." Start at the receiver edge: show ip igmp groups 239.1.1.10 on R1 shows the membership present and refreshing, so the silent-receiver case is eliminated in thirty seconds. Check R1's mroute: (*,G) healthy, but the (S,G) shows P with a Null OIL and an incoming interface that makes no sense for where the source lives. That is case 2's fingerprint, so run show ip rpf 10.0.30.10 and compare against the topology: the RPF interface points at Ethernet0/0, but the stream can only arrive on Ethernet0/1.
Now find out why the unicast table disagrees with reality: show ip route 10.0.30.0 reveals a static route with admin distance 1 shadowing the OSPF route, left over from last month's maintenance. The fix is a one-line removal (or, had the asymmetry been intentional, a static mroute), and the confirmation is watching the (S,G) flags flip from PJX back to JT and the OIL repopulate on the next join refresh. Total elapsed time with the method: minutes. Total elapsed time bisecting with pings and hunches: the rest of your afternoon, because unicast pings to the source worked perfectly the whole time. That last point is the real lesson: unicast reachability proves nothing about multicast health, because the two forwarding planes consult the same table with opposite questions.
One habit worth stealing from the lab bench: sender TTL. Host stacks default the multicast TTL to 1, which the first router burns, producing a perfect imitation of case 1 (source-side state, nothing anywhere else, and even the first hop's F flag missing since packets never leave the segment). Check the sending socket before blaming the network.
Key Takeaways
- Multicast failures reduce to three signatures: silent receiver (source state fine, OILs Null, no IGMP membership), RPF failure (wrong IIF, P flag, Null OIL despite receivers), and missing RP (RP 0.0.0.0 in the (*,G) entry).
- Check the two edges first:
show ip igmp groupsat the last hop,show ip mrouteat the first hop. That splits the search space in half immediately. - The router where
show ip rpfdisagrees with physical arrival is the broken one; fix routing or apply a staticip mroute. - RP agreement is per-router configuration, and partial agreement is worse than none: verify the mapping on every hop, then verify the RP address itself passes RPF.
- Before any of it: confirm the sender's TTL is greater than 1.
The healthy-state baselines these captures were broken from live in PIM sparse mode explained, and the whole cluster is indexed in the complete multicast guide.
