Lab 1 — IGMP Snooping with No Querier (the feed that dies on its own)

Provenance: Lab guide written 2026-10-03 (Mac session) from 03-failure-modes.md trap #1 and the NetworkLessons Multicast course lessons IGMP Snooping and IGMP Snooping without Router (member content, originals read 2026-10-03). Full lesson extracts: Mac (local cache, not published). Also planned as Lab 1 in ../prep-plan-2027.md. Companion to the scoping lab guide format (multicast-scoping PDF, 2026-10-01). Platform: EVE-NG, Cisco IOS commands throughout (IOL L3 + IOL-L2 images). Unverified: exact IOL-L2 snooping behavior in Act 2 — it is platform-dependent by design and the lab is built to record which behavior your image shows (see Act 2).

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” (01-incidents.md, 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 03-failure-modes.md): 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):

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):

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

!Lab 1 topology — S1 sends, H1/H2 receive, R1 is the querier; SW1 becomes the snooping querier in Act 3

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

3.3 Cabling

3.4 Addressing (VLAN 1)

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):

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:

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:

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

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: 03-failure-modes.md trap #1 · 01-incidents.md (Montreal 2019) · 02-microburst-buffer.md (why flooding hurts more than it looks) · RFC 4541 §2.1.1, RFC 2236 §8.