IP Services Intermediate

IGMP & IGMP Snooping

How hosts join multicast groups (IGMP) and how a switch learns which ports actually want multicast traffic (snooping) — so it stops blasting video streams out every port.

TL;DR

Multicast = one stream, many receivers. Hosts opt in to a group address (e.g. 239.1.1.1) using IGMP join messages.
Without IGMP snooping, the switch treats multicast like broadcast — floods to every port. Snooping makes the switch listen to IGMP joins and forward only to ports that asked.
Result: IPTV, video conferencing, market-data feeds, and storage replication don't melt your VLAN.

Mental model

A teacher wants to stream a video to 30 students in the same VLAN. Three options:

Unicast — send 30 copies, one to each student. 30× the bandwidth. Wasteful.
Broadcast — send one copy to 255.255.255.255, every host in the VLAN gets it whether it wanted it or not. Every NIC interrupts the CPU. Wasteful and noisy.
Multicast — send one copy to a group address. Only hosts that joined the group receive it. Switch fabric replicates as needed.

Multicast is the right answer for one-to-many real-time data. But there’s a problem: switches by default treat multicast destinations like broadcasts — they flood multicast frames out every port in the VLAN. Defeats the purpose.

IGMP is how hosts signal “I want this group.” IGMP snooping is how the switch listens to those signals and forwards multicast only where wanted.

IGMP — the host-to-router protocol

IGMP (Internet Group Management Protocol) runs between hosts and the multicast router (the L3 device — usually your default gateway). Three versions:

Version	Notable feature
IGMPv1 (RFC 1112)	Join. No leave. Router polls; host responds.
IGMPv2 (RFC 2236) — most common	Adds explicit Leave message → faster pruning
IGMPv3 (RFC 3376)	Source-specific multicast (SSM) — host can say “I want group X from source Y only”

Three message types you must know:

Message	From → To	Purpose
Membership Query	Router → Hosts (224.0.0.1, all multicast hosts)	“Anyone still want any group?”
Membership Report (Join)	Host → All-routers (224.0.0.2)	“I want group X”
Leave Group	Host → All-routers (224.0.0.2)	“I’m done with group X” — IGMPv2+ only

Periodic IGMP queries are sent by the multicast router every ~60 seconds. Hosts that still want the group respond with reports. If no host reports for a group, the router stops forwarding it after timeout.

IGMP snooping — the switch’s role

The switch is at Layer 2 — it sees Ethernet frames, not IP. So how does it know which port wants which multicast group?

It eavesdrops on IGMP traffic.

The switch examines IGMP join messages as they cross it. It builds a table:

Group        VLAN  Ports
239.1.1.1    10    Fa0/3, Fa0/8, Fa0/15
239.2.5.7    10    Fa0/3

When a multicast frame for 239.1.1.1 arrives, the switch checks the table and forwards only to ports 3, 8, 15. Not to ports 1, 2, 4–7, 9–14, 16+.

The multicast router’s port is treated as a “multicast router (mrouter) port” — all multicast traffic gets forwarded toward it regardless of join state, so the router can see and route the streams.

Configuration — Cisco IOS

IGMP snooping is on by default on most Cisco switches. Verify, don’t blindly trust:

SW1# show ip igmp snooping
Global IGMP Snooping configuration:
-----------------------------------
IGMP snooping              : Enabled
IGMPv3 snooping (minimal)  : Enabled
Report suppression         : Enabled
TCN solicit query          : Disabled
TCN flood query count      : 2
Robustness variable        : 2
Last member query count    : 2
Last member query interval : 1000

Vlan 10:
  IGMP snooping            : Enabled
  Immediate leave          : Disabled
  Multicast router learning mode : pim-dvmrp
  CGMP interoperability mode     : IGMP_ONLY

Per-VLAN enable (if disabled):

SW1(config)# ip igmp snooping
SW1(config)# ip igmp snooping vlan 10

IGMP querier — if you’re running multicast inside a VLAN that has no multicast router (e.g., L2-only segment), the switch can act as the querier itself:

SW1(config)# ip igmp snooping vlan 10 querier
SW1(config)# ip igmp snooping vlan 10 querier address 192.168.10.250

Without a querier, hosts’ join state ages out and snooping starts flooding again. Always have exactly one querier per VLAN.

Verification

SW1# show ip igmp snooping groups
Vlan      Group               Type    Version    Port List
-----------------------------------------------------------
10        239.1.1.1           igmp    v2         Fa0/3, Fa0/8, Fa0/15
10        239.2.5.7           igmp    v2         Fa0/3

SW1# show ip igmp snooping mrouter
SW1# show ip igmp snooping querier
SW1# show ip igmp snooping vlan 10

Common mistakes

No querier in a router-less VLAN. Snooping needs periodic queries to know which hosts still want which groups. No queries → state ages out → switch reverts to flooding. Configure the switch as the querier.
Multiple queriers in the same VLAN. Two routers (or a router + switch acting as querier) both sending queries. They elect one (lowest IP wins) but the loser still floods the network with redundant queries.
Confusing IGMP and PIM. IGMP is host → router. PIM is router ↔ router (the routing protocol that actually moves multicast across the network). They’re separate; CCNA tests both names.
Disabling snooping to “fix” a problem. Slow streaming? Don’t disable snooping — diagnose with show ip igmp snooping groups. Disabling makes the whole VLAN see all multicast traffic.
mrouter port not detected. If the switch can’t auto-learn where the multicast router is, joins and reports won’t reach it. Manually pin it:
```
SW1(config)# ip igmp snooping vlan 10 mrouter interface Gi1/0/1
```
Forgetting that link-local multicast (224.0.0.0/24) is always flooded. Snooping intentionally skips 224.0.0.x — these are control-plane addresses (OSPF hellos, IGMP queries themselves, etc.) and must reach every host.
Storm-control thresholds eating multicast. If you’ve set very aggressive storm control on multicast, legitimate IPTV bursts might be dropped. Tune carefully.

Real-world use cases

IPTV streaming — set-top boxes join the channel’s multicast group; the network delivers one stream multiplexed to thousands of boxes.
Financial market data — multicast feeds (udp/239.x.x.x) carry tick data to trading systems. Snooping is mandatory; flooding would saturate every port.
Cluster heartbeats — VMware, some Oracle RAC, certain HA stacks use multicast for member discovery.
Video conferencing in classrooms — one teacher, many viewers in the same campus.
PIM Bootstrap, OSPF Hellos, etc. — control-plane multicast that just works because of 224.0.0.0/24 always-flood rule.

Lab to try tonight

Two switches, two PCs each, all in VLAN 10. One switch acts as querier (ip igmp snooping vlan 10 querier).
On PC1: start a multicast receiver — vlc listening on udp://@239.1.1.1:5000 or iperf3 -s -B 239.1.1.1.
On a separate sender host: send a multicast stream — vlc → stream to 239.1.1.1:5000.
show ip igmp snooping groups — PC1’s port should appear under 239.1.1.1.
From PC2 (different port, same VLAN), capture with Wireshark. You should not see the multicast frames — snooping is working.
Now no ip igmp snooping vlan 10 and re-capture from PC2 — you’ll see the stream flooded.
Bonus: shut down the querier and watch joins age out. Stream resumes flooding after ~5 minutes.

Cheat strip

Concept	Plain English
Multicast	One source, many receivers, opt-in. Group destination = 224.0.0.0–239.255.255.255
IGMP	Host ↔ multicast router protocol — “I want this group” / “I’m done”
IGMPv2 Leave	Faster pruning vs v1 (which had to wait for query timeout)
IGMP snooping	Switch eavesdrops on IGMP and forwards multicast only to interested ports
mrouter port	Switch port where the multicast router lives — always gets all multicast
Querier	Sends periodic queries. Needed in every VLAN. Router by default; switch can do it
Link-local (224.0.0.0/24)	Always flooded — never snooped (OSPF, IGMP queries, etc.)
PIM	Multicast routing protocol — moves multicast across L3 boundaries. Separate from IGMP
`show ip igmp snooping groups`	The one command that tells you snooping is working

← Previous topic

MTU & Fragmentation

Why packets get fragmented or dropped on links with smaller MTU than expected. Covers MTU vs MSS, the Don't-Fragment bit, ICMP 'Fragmentation Needed,' Path MTU Discovery, and why blocking ICMP breaks the internet.

Next topic →

Access Control Lists (ACLs)

Definitive CCNA-level ACL guide — first-match-wins, implicit deny, wildcard masks, standard vs extended vs named, direction (in vs out), the established keyword, time-based ACLs, named-ACL editing, 9 worked scenarios, and the ACL debug workflow.

Master this on a real network

Want this drilled into reflex?

1:1 weekly sessions, live feedback on your labs, and US interview prep — built around the CCNA® exam blueprint. Free first session. No card on file until you decide.

Claim my free session →

One topic per email, every fortnight

VLANs, OSPF, ACLs, subnetting, automation — written like this. Unsubscribe in one click.

We respect your inbox. One email per week, max. Unsubscribe any time.