← All posts

Multicast failure-mode lab series · 1 of 3 · Companion post: Multicast Scoping — Solution Analysis & EVE-NG Lab Guide · Based on: NetworkLessons Multicast lessons “IGMP Snooping” & “IGMP Snooping without Router” (member content) · Target platform: EVE-NG (Cisco IOL / IOL-L2), Cisco IOS commands · Prepared: 2026-10-03

Contents

1. The Exercise
2. Solution Analysis — why snooping needs a querier
3. EVE-NG Lab Design — topology, images, cabling, addressing
4. Complete Node Configurations
5. Lab Procedure (three acts) and Verification
6. Troubleshooting Notes
7. One-Page Summary

Knowledge points covered

• IGMPv2 membership report / general query / querier election (RFC 2236)
• Group Membership Interval: GMI = robustness × query-interval + query-response-interval = 2 × 125 s + 10 s = 260 s with RFC defaults
• IGMP snooping (RFC 4541): report interception, group CAM entries, report suppression overrule
• mrouter port discovery: switch learns router ports from IGMP general queries, PIMv2 hellos (224.0.0.13), DVMRP, OSPF hello MACs
• IGMP snooping querier: switch-generated queries when no multicast router exists
• Platform-dependent failure behavior: drop-report-and-flood vs accept-then-age-out
• Why a real market-data incident looks like “the feed just stopped a few minutes after a change” (the public multicast incidents notes, Montreal 2019 flavor)

---

1 The Exercise

A market-data receiver works fine when it joins the feed, then stops receiving a few minutes later — with no change to the source, no change to the receiver, nothing in the unicast routing table. The switch shows IGMP snooping enabled everywhere. Find the mechanism, reproduce it in EVE-NG, and fix it.

Real-world shape of this trap (from the multicast failure-modes notes): a maintenance change removes (or disconnects) the only multicast router on a VLAN — or moves the receiver to a VLAN where no querier exists. Snooping switches keep the group entry only as long as they see membership reports; reports are only refreshed in response to queries; with no querier on the segment, the entry ages out and the constrained forwarding turns into silence (or, on other platforms, into flooding).

2 Solution Analysis — why snooping needs a querier

The dependency chain that makes this failure:

1. A host/receiver joining a group sends one unsolicited IGMPv2 membership report. The snooping switch learns “group 239.1.1.1 → port X” from it. Traffic flows — this is why the trap always works at first.
2. The switch entry is refreshed only by further reports on that port. To avoid duplicates, IGMPv2 report suppression means hosts normally stay silent when they hear other reports — and the snooping switch intercepts reports anyway (igmp-snooping lesson: snooping “overrules the membership report suppression mechanism” so it hears every port).
3. Reports are only sent in response to general queries. Queries come from the elected IGMP querier — normally the multicast router on the segment.
4. Remove the router → no queries → no reports → the entry ages out. The timers: GMI = robustness × query-interval + QRI. RFC 2236 defaults (125 s / 2 / 10 s) give the famous ~260 s. Cisco snooping querier defaults to a 60 s query interval, so an IOS lab typically ages entries in roughly 2 × 60 + 10 ≈ 130 s — measure it in Act 3b rather than trusting either number.

Two platform behaviors when there is no mrouter port (the igmp-snooping-without-router lesson documents both on Catalyst 3560 / IOS 12.2(55)SE10):

Behavior	What the switch does with the re-join report	What you observe
Drop report, flood traffic	Debug: IGMPSN: No mroute detected: Drop IGMPv2 report — the report is discarded, no group entry created	Multicast is flooded like broadcast; pings still work, snooping is pointless, every host gets the feed (CPU exposure — the microburst angle from the microburst & buffer notes)
Accept report, then age out	Report accepted, entry created, but never refreshed (no queries)	Works at first, then silence after ~GMI — the classic “feed died on its own” incident

Cross-switch detail that matters: even in the flooding case, a second switch never learns a router port, so it never forwards a receiver’s report upstream — on platforms that constrain unknown multicast, the remote receiver gets nothing at all.

The fix: make something send periodic queries. Ranked for production (lesson Solutions 1–5):

Fix	Command	Trade-off
IGMP snooping querier (best)	ip igmp snooping querier (per VLAN)	Switch acts as querier, no routing needed; lowest risk
PIM on the SVI	ip pim sparse-mode under interface Vlan N	Turns the L2 switch into a multicast router; hidden/unsupported on some platforms
Static mrouter port	ip igmp snooping vlan N mrouter interface <if>	Per-switch manual config; does not scale
Static CAM entry	mac address-table static 0100.5e01.0101 vlan N interface ...	Manual per-group; does not scale
Disable snooping	no ip igmp snooping	Flood everywhere; last resort only

Takeaway: IGMP snooping is a proxy for the querier. No queries in the VLAN = no reliable snooping, one way or another.

3 EVE-NG Lab Design

3.1 Design rationale

• Every host is an IOL L3 router with a plain IP address — the course trick: ip igmp join-group <G> on an interface makes an IOS router behave as a group member (sends the initial report, answers queries with reports) without ip multicast-routing, so it never speaks PIM and never becomes a querier. That is exactly the “no multicast router anywhere” condition.
• The source is also a plain router that only pings the group — like a feed’s send-only source, it never joins, so nothing it does refreshes the switches.
• R1 exists only for Act 1 (the working baseline): ip multicast-routing + PIM on one interface is enough to make it the elected querier. Shutting its interface in Act 2 removes the querier without touching the receivers.
• Two switches, because the cross-switch report-propagation failure is half of the lesson.

3.2 Images

Role	EVE-NG image	Note
SW1, SW2	Cisco IOL-L2	L2 image; IGMP snooping on by default
R1	Cisco IOL (L3)	Only node with multicast routing
H1, H2, S1	Cisco IOL (L3)	Host-style: plain IP + (join-group on H1/H2)

3.3 Cabling

From	Port	To	Port
S1	E0/0	SW1	E0/1
H1	E0/0	SW1	E0/2
R1	E0/0	SW1	E0/3
SW1	E0/0	SW2	E0/0
H2	E0/0	SW2	E0/1

3.4 Addressing (VLAN 1)

Node	Interface	IP	Role
S1	E0/0	192.168.1.3/24	Source (send-only, pings 239.1.1.1)
H1	E0/0	192.168.1.1/24	Receiver, joins 239.1.1.1
H2	E0/0	192.168.1.2/24	Receiver (behind SW2), joins 239.1.1.1
R1	E0/0	192.168.1.254/24	Multicast router / querier in Act 1
SW1	Vlan1	192.168.1.250/24	Becomes the snooping querier in Act 3
SW2	Vlan1	192.168.1.251/24	Management only

4 Complete Node Configurations

! === S1 (source, host-style) ===
hostname S1
!
interface Ethernet0/0
 ip address 192.168.1.3 255.255.255.0
!
end

! === H1 (receiver, host-style) ===
hostname H1
!
interface Ethernet0/0
 ip address 192.168.1.1 255.255.255.0
 ip igmp join-group 239.1.1.1
!
end

! === H2 (receiver behind SW2, host-style) ===
hostname H2
!
interface Ethernet0/0
 ip address 192.168.1.2 255.255.255.0
 ip igmp join-group 239.1.1.1
!
end

! === R1 (multicast router = querier in Act 1; no RP needed, it only queries) ===
hostname R1
!
ip multicast-routing
!
interface Ethernet0/0
 ip address 192.168.1.254 255.255.255.0
 ip pim sparse-mode
!
end

! === SW1 (access switch) ===
hostname SW1
!
interface Vlan1
 ip address 192.168.1.250 255.255.255.0
 no shutdown
!
interface Ethernet0/0
 switchport mode access
!
interface Ethernet0/1
 switchport mode access
!
interface Ethernet0/2
 switchport mode access
!
interface Ethernet0/3
 switchport mode access
!
end

! === SW2 ===
hostname SW2
!
interface Vlan1
 ip address 192.168.1.251 255.255.255.0
 no shutdown
!
interface Ethernet0/0
 switchport mode access
!
interface Ethernet0/1
 switchport mode access
!
end

Do not configure ip igmp snooping querier in the startup configs — Act 3 adds it deliberately. Snooping itself is enabled by default; verify with show ip igmp snooping | include snoop.

5 Lab Procedure and Verification

Useful debugs before you start (turn off after each act):

SW1# debug ip igmp snooping router
SW1# debug ip igmp snooping 239.1.1.1
H1#  debug ip igmp

Act 1 — Baseline with a multicast router (works)

1. Start everything. On H1/H2: ip igmp join-group 239.1.1.1.
2. From S1: ping 239.1.1.1 repeat 9999.
3. Collect on both switches.

Expected (both switches):

Check	Expected
show ip igmp snooping querier	Vlan 1, 192.168.1.254, port = R1’s / SW1’s port
show ip igmp snooping groups	239.1.1.1 with H1’s port and the mrouter/uplink port on SW1; H2’s port + uplink on SW2
SW1 debug on H1’s join	Received IGMPv2 report for group 239.1.1.1 … Forwarding … report to router ports
Ping from S1	Replies from 192.168.1.1 and 192.168.1.2

Act 2 — Remove the querier, re-join, and record your platform’s behavior

1. Kill R1’s interface: on R1, interface Ethernet0/0 → shutdown.
2. Force fresh joins on H1 and H2: no ip igmp join-group 239.1.1.1 then ip igmp join-group 239.1.1.1 (the initial report happens once — without queries there will be no more).
3. From S1, restart ping 239.1.1.1 repeat 9999.
4. Record which of the two documented behaviors your IOL-L2 shows:

Observation	Behavior (a): drop report + flood	Behavior (b): accept + age out
SW1 debug at re-join	IGMPSN: No mroute detected: Drop IGMPv2 report for group 239.1.1.1	Report accepted, group created
show ip igmp snooping groups	No 239.1.1.1 entry	Entry present initially, vanishes after ~2–5 min
S1 ping	Both hosts still reply (traffic flooded)	Replies stop after the aging time — the incident
Cross-switch	H2 may still get flooded traffic; report propagation is dead	H2 loses the feed; SW2 never forwards its report upstream (no router port)

Either way the lab has reproduced the trap: snooping is now unreliable — silent death or pointless flooding. Note the exact age-out time if you see behavior (b).

Act 3 — Fix with the IGMP snooping querier

1. On SW1 (the switch with the receivers’ reports to propagate — either access switch works; course convention: the one closest to the “core”):

SW1(config)# ip igmp snooping querier

2. Within one query interval, both switches recover.

Expected:

Check	Expected
SW1 debug	IGMPQR: vlan_id 1: leaving Disabled state and entering Querier state, GQ with src addr 192.168.1.250 sent
SW1 show ip igmp snooping querier	1 192.168.1.250 v2 Switch
SW2 show ip igmp snooping querier	1 192.168.1.250 v2 <uplink port> — SW2 learned the router port from SW1’s queries
show ip igmp snooping groups (both)	239.1.1.1 with member port(s) + uplink, refreshed every query interval
S1 ping	Replies from both receivers; now with constrained forwarding (flooding gone)

Act 3b (optional) — Measure the aging trap on your image

With Act 3 working: no ip igmp snooping querier on SW1 → stop the pings, then start a tight ping 239.1.1.1 every 30 s and note when replies stop; re-enable the querier and note recovery. Compare the measured value with GMI = robustness × query-interval + QRI (RFC defaults 260 s; IOS snooping querier default QI 60 s → ≈130 s). Unverified: which value IOL-L2 implements — that is the point of measuring.

6 Troubleshooting Notes

Symptom	Check	Likely cause
Pings work but show ip igmp snooping groups is empty	Debug on re-join	Platform dropped the report and is flooding (behavior (a)) — snooping is decorative
Worked for minutes, then died, nothing changed	Was there a querier at join time? show ip igmp snooping querier	Behavior (b): entries aged out with no queries — the 260 s/130 s trap
Remote-switch receiver dead, local receiver fine	show ip igmp snooping groups on both switches	Report never propagated — no router port learned on the upstream switch
Querier configured but nothing recovers	SVI exists and is up? `show ip igmp snooping	include snoop`
show ip igmp snooping querier shows another IP than expected	—	Querier election = lowest IP wins; a stray PIM router or lower SVI IP took over

Key mechanism: the snooping switch is only as healthy as the query cycle it piggybacks on. No mroute detected in the debug is the smoking gun for “I have reports but nowhere to send them”.

7 One-Page Summary

Receiver joins ──► one unsolicited Report ──► switch learns entry ──► traffic flows (works at first!)
                                                                       │
No querier on the VLAN ──► no Queries ──► no refreshed Reports ──► entry ages out (GMI ≈ 2×QI+10s)
                                                                       │
                          platform A: report dropped + traffic FLOODED  │  platform B: entry ages out
                                       (snooping pointless, CPU harm)   │  (feed dies ~260s/130s later)

• Interview one-liner: “IGMP snooping constrains forwarding using membership state, and membership state is only maintained by query/report cycles — remove the querier and snooping either floods or silently ages out. It’s the ‘works for five minutes, then the market-data feed is gone’ incident.”
• Fix ranking: snooping querier > PIM on SVI > static mrouter > static CAM > disable snooping.
• Numbers to quote: GMI = robustness × QI + QRI; RFC 2236 defaults → 260 s; IOS snooping-querier default QI 60 s → ≈130 s (measure in lab).
• Cross-references: the multicast failure-modes notes trap #1 · the public multicast incidents notes (Montreal 2019) · the microburst & buffer notes (why flooding hurts more than it looks) · RFC 4541 §2.1.1, RFC 2236 §8.