IGMP is the only part of multicast a host ever speaks. Before PIM builds a single tree, before an RP hears a single register, a receiver has to raise its hand on the local segment and say "I want group 239.1.1.10". This article covers how that conversation works in IGMPv2 and IGMPv3, what the querier does, how joins and leaves age out, and the version-mismatch trap that silently breaks SSM. All output is real, captured from a CML lab where a Debian VM is the receiver. Part of the IP multicast guide.
What IGMP Does (and Does Not Do)
IGMP runs between hosts and their first-hop router, on one segment only. It answers exactly one question: which groups have interested receivers on this interface? It carries no routing information, never crosses a router, and knows nothing about sources or trees. The router translates IGMP state into PIM joins upstream (covered in PIM sparse mode); IGMP itself stops at the first hop.
The protocol has exactly two message flows: hosts send membership reports (joins, and in v3, source-filtered subscriptions), and one router per segment, the querier, sends periodic queries to check that members still exist. Leaves are the third piece, handled differently per version.
The Querier: One Router Asks, Everyone Answers
If a segment has multiple routers, only one sends queries: the querier, elected as the lowest IP address on the segment (in both v2 and v3). Everything about the querier's behavior is visible in one command. This is the lab's edge router, fresh after a host joined a group:
R1# show ip igmp interface Ethernet0/0
Internet address is 192.168.99.1/24
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
IGMP activity: 1 joins, 0 leaves
Multicast designated router (DR) is 192.168.99.1 (this system)
IGMP querying router is 192.168.99.1 (this system)Every 60 seconds the querier sends a general query to 224.0.0.1. Hosts answer with reports for each group they belong to, after a random delay up to the max response time (10 seconds) so a hundred receivers do not answer simultaneously. In v2, hosts also suppress their report if another host answers first for the same group; the router only needs one member to keep forwarding. Membership state expires after roughly (robustness x query interval) + max response time, here about 130 seconds, visible as the Expires timer:
R1# show ip igmp groups
Group Address Interface Uptime Expires Last Reporter
239.1.1.10 Ethernet0/0 00:00:21 00:02:39 169.254.147.59Note the DR line as well. On multi-router segments the IGMP querier (lowest IP) and the PIM DR (highest priority/IP, responsible for sending PIM joins upstream) can be different routers. Exam writers love that distinction.
IGMPv2: Join, Stay, Leave
IGMPv2 is the simple lifecycle. A host joins by sending an unsolicited membership report to the group address itself. It stays by answering general queries. It leaves by sending a leave message to 224.0.0.2 (all routers), which triggers the querier to send a group-specific query: "anyone still here for 239.1.1.10?" It asks twice (the last member query count above), one second apart, and if nobody answers, the group is removed and the router prunes upstream. Worst-case leave latency is about two seconds, a big improvement over v1, which had no leave at all and simply aged out.
What v2 cannot do: say anything about sources. A v2 join means "any source sending to G". That is ASM (any-source multicast), and it is why ASM needs a rendezvous point to introduce sources and receivers.
IGMPv3: Source Filtering Changes the Model
IGMPv3 (RFC 3376) adds one capability that changes multicast architecture: reports carry a source filter. A host can join in INCLUDE mode ("only these sources") or EXCLUDE mode ("everything except these"; an empty exclude list is the v2-equivalent any-source join). Mechanically, v3 also changes where reports go: to 224.0.0.22 (all IGMPv3 routers) instead of the group address, and one report can carry multiple group records, so suppression is gone; every host reports.
Source filtering is the enabler for SSM: if the receiver names the source, the network can build the (S,G) tree directly with no RP. Here is the lab's edge router after the Debian VM sent a v3 INCLUDE join for group 232.1.1.10, source 10.0.30.10:
R1# show ip igmp groups 232.1.1.10 detail
Interface: Ethernet0/0
Group: 232.1.1.10
Flags: SSM
Group mode: INCLUDE
Last reporter: 169.254.147.59
Source Address Uptime v3 Exp CSR Exp Fwd Flags
10.0.30.10 00:00:08 00:02:51 stopped Yes RGroup mode INCLUDE with an explicit source list: that is the entire difference between v2 and v3 in one capture. The router now knows not just "someone wants G" but "someone wants G from exactly this S".
v2 vs v3 Side by Side
The Compatibility Trap That Breaks SSM
IGMPv3 is backward compatible, and the fallback has a sharp edge. When a v3 host sees a v2 query on the segment, it drops into v2 compatibility mode and stays there for the "older version querier present" interval, roughly two query cycles, even after the querier upgrades. In compat mode the host sends v2 reports, and a v2 report carries no source list.
This happened live while building this lab. R1's receiver interface started at v2 while the Debian VM issued a source-specific join for 232.1.1.10. Result, straight off the wire:
j@llmbits:~$ sudo tcpdump -i ens224 -c 3 -n igmp
10:41:03.46 IP 192.168.99.1 > 224.0.0.1: igmp query v3
10:41:05.06 IP 169.254.147.59 > 232.1.1.10: igmp v2 report 232.1.1.10
10:41:07.52 IP 169.254.147.59 > 239.5.5.5: igmp v2 report 239.5.5.5The router is already querying at v3, but the host is still reporting at v2 from compat mode, and IOS XE ignores v2 reports for the SSM range (a sourceless join is meaningless there). The router held zero state for the group until the host was forced back to v3 (on Linux: force_igmp_version=3 sysctl, or wait out the compat timer), after which the INCLUDE join above appeared immediately. If SSM "just doesn't work" for some receivers, check IGMP versions on both ends before anything else, with show ip igmp interface on the router (both host and router version lines) and tcpdump on the host.
Configuration is one line per interface: ip igmp version 3 on everything that should support SSM receivers. IOS XE defaults to v2.
The Timers That Rule the Lifecycle
Every IGMP behavior above is timer-driven, and the defaults visible in the interface output interact in ways worth spelling out. The query interval (60 seconds on IOS XE, 125 in the RFC) sets the heartbeat. The robustness variable (2) is the "how many losses do we tolerate" multiplier baked into every derived timer. Group membership expires after (robustness x query interval) + max response time: 2 x 60 + 10 = 130 seconds of silence before the router stops forwarding. The querier itself is given up on after the querier timeout (2 x query interval = 120 seconds), at which point the next-lowest IP takes over querying.
Leave latency is governed separately: on a v2 leave, the querier sends last-member-query-count (2) group-specific queries at last-member-query-interval (1 second) spacing, so a group with no remaining members stops flowing in about 2 seconds. If your application needs faster cutoff (channel zapping in IPTV is the classic case), ip igmp last-member-query-interval and immediate-leave (ip igmp immediate-leave group-list, safe only when exactly one receiver lives per port) are the knobs. Tightening the general query interval buys faster failure detection at the cost of more control traffic and more report bursts from large segments; most networks should leave it alone.
Joining From the Router Itself: join-group vs static-group
Two interface commands make a router behave like a receiver, and confusing them causes real outages. ip igmp join-group 239.1.1.10 makes the router a full member: it answers queries and, critically, punts every packet for the group to its CPU. It is a test tool (the router responds to pings sent to the group, which makes end-to-end reachability testable without any host), and leaving it configured on a production box is a well-known way to melt a control plane.
ip igmp static-group 239.1.1.10 is the operational sibling: the router forwards the group out the interface unconditionally, in hardware, without becoming a member itself. Use it for segments where hosts cannot speak IGMP (some industrial gear, dumb display endpoints) or where you want traffic pre-pulled to an interface regardless of membership. In the lab you will notice 224.0.1.40 joined on every router's loopback in show ip igmp groups; that is Auto-RP's discovery group, joined automatically, and a reminder that routers themselves are IGMP participants too.
IGMP Snooping: The Switch in the Middle
One layer down, switches flood multicast frames by default because the destination MAC never appears in their learned tables. IGMP snooping fixes that: the switch listens to reports and queries and constrains each group's frames to ports with actual members plus router ports. It is on by default on Cisco switches and generally should stay on; a segment with no querier and snooping enabled is the classic "multicast works for two minutes then dies" failure, because snooped state ages out with no queries to refresh it. On router-less L2 domains, configure an IGMP snooping querier on the switch. The details of L2 forwarding behavior tie into the MAC overlap covered in multicast addressing.
Securing the Membership Plane
IGMP is unauthenticated by design, so the controls are limits and filters. ip igmp access-group <acl> on an interface restricts which groups hosts may join at all, the right tool for segments that should only ever receive the corporate video group and nothing else. ip igmp limit (global or per interface) caps total membership state, blunting both buggy applications that join in a loop and deliberate state-exhaustion attempts. On the switch side, IGMP snooping's report suppression and querier hardening matter more than router config for most attack surfaces; a host spraying bogus reports pollutes L2 forwarding before any router notices. None of this is exotic: the same three commands appear in every hardening baseline, and the pillar's security section puts them alongside the PIM-side controls they complement.
Key Takeaways
- IGMP is host-to-router membership signaling on one segment; PIM does everything between routers.
- The querier (lowest IP) polls 224.0.0.1 every 60 seconds by default; group state expires in about 130 seconds without answers. All of it is visible in
show ip igmp interface. - v2 gives you any-source joins and fast leaves. v3 adds INCLUDE/EXCLUDE source filters, reports to 224.0.0.22, and no suppression.
- SSM requires v3 end to end. Hosts fall back to v2 compat mode when they ever see a v2 query and stay there for minutes; IOS ignores v2 reports in 232/8, so the join silently vanishes.
show ip igmp groups detailshowing Group mode INCLUDE with a source list is your proof that v3 signaling actually works.
Next: PIM sparse mode turns this membership state into trees. The full cluster lives in the complete multicast guide.
