IGMP Snooping Configuration on Cisco Switches (CLI Guide)

Without IGMP snooping, a Layer 2 switch floods every multicast frame out of every port in the VLAN. One IPTV stream, one PTP or one video conference test and suddenly a whole floor looks like it has a broadcast storm. IGMP snooping makes the switch listen to the membership reports between hosts and their multicast router, then forwards each group only to the ports that actually asked for it. This guide covers the global and per-VLAN commands, the querier, static mrouter ports, immediate-leave for fast channel changes, and the verification commands that prove traffic is no longer flooding.

What snooping actually does

The switch snoops IGMP reports and leaves, builds a per-VLAN group table, adds the host port when it sees a report, removes it on leave or on a timeout, and learns the multicast-router port from queries and PIM hellos. Data forwarding stays in hardware, so the cost is only in control-plane bookkeeping. Snooping is on by default on most Catalyst and Nexus platforms - the interesting work is verifying it and fixing the classic "multicast stopped entirely" failure caused by the absence of a querier.

Two behaviours are worth internalising early. First, snooping only constrains traffic inside the VLAN; it cannot stop the router above from forwarding a stream, and it cannot stop a sender on the same VLAN from flooding if the switch has never learned a router port. Second, the group table is control-plane state driven by timers - if the reports stop arriving, entries age out and traffic starts flooding again. Most "it worked yesterday" multicast incidents are timer or mrouter problems, not configuration problems.

Enable and verify snooping

Switch(config)# ip igmp snooping
Switch(config)# ip igmp snooping vlan 100
Switch# show ip igmp snooping
Switch# show ip igmp snooping groups
Switch# show ip igmp snooping groups vlan 100 detail
Switch# show ip igmp snooping mrouter vlan 100

If the membership table in show ip igmp snooping groups is empty while hosts are clearly receiving streams, snooping is either disabled on that VLAN or the router port was never learned. A missing dynamic mrouter entry is the single most common cause - check that the uplink actually carries PIM hellos or IGMP queries.

On Nexus platforms the same feature is configured in a slightly different place and the verification output is organized differently (show ip igmp snooping groups exists, but VLAN-level settings often live under the VLAN or under ip igmp snooping vlan configuration). Write your runbook against the exact platform you run; a command that works on a Catalyst 2960 will not always paste cleanly into NX-OS. The same warning applies to VLAN baseline verification, which you should establish before touching multicast at all - see VLAN configuration and verification.

IGMP versions, SSM and what the switch actually reads

Snooping is version-aware. IGMPv2 reports carry a group address only, so the switch builds a table keyed on (VLAN, group) and forwards any source. IGMPv3 adds source lists and requires a different table: (VLAN, group, source). If your receivers send IGMPv3 joins for an SSM group such as 232.0.0.0/8 and the switch only maintains v2-style entries, you can end up with correct L2 forwarding but a broken source filter, or a table that never populates at all.

Switch(config-if)# ip igmp version 3
Switch(config)# ip igmp snooping vlan 100
Switch# show ip igmp snooping groups vlan 100 source detail

Compatibility mode matters too: when a v2-only host appears on a v3-enabled VLAN, the switch and the router must both fall back to v2 semantics for that group. If you see intermittent membership loss after adding one older device, look here before you look at cabling.

Static mrouter ports and the querier

When the router port cannot be detected (for example a firewall that blocks PIM, or a third-party router that never sends general queries), pin it manually and run a querier on the switch so the VLAN still has one:

Switch(config)# ip igmp snooping vlan 100 mrouter interface GigabitEthernet1/0/1
Switch(config)# ip igmp snooping querier
Switch(config)# ip igmp snooping vlan 100 querier
Switch(config)# ip igmp snooping querier address 10.10.100.1
Switch(config)# ip igmp snooping querier query-interval 60
Switch(config)# ip igmp snooping querier max-response-time 10
Switch# show ip igmp snooping querier
Switch# show ip igmp snooping querier detail

Only one querier may be active per subnet. When the switch-querier is enabled and it detects a real multicast router sending queries, it drops back to non-querier state automatically, so enabling it globally is usually safe. If there is no IP address available on the VLAN SVI, the querier falls back to another interface's address - configure an explicit address to keep it deterministic. Getting this wrong is the classic failure where multicast works until the L3 router is briefly unavailable, after which every group ages out and the VLAN starts flooding.

MVR: one multicast VLAN, many access VLANs

In an IPTV deployment you usually do not want to extend the source VLAN to every access port. Multicast VLAN Registration (MVR) keeps a single multicast VLAN on the uplink and lets ports in ordinary access VLANs join groups carried in that VLAN:

Switch(config)# mvr
Switch(config)# mvr vlan 100
Switch(config)# mvr group 239.10.10.0 24
Switch(config)# interface GigabitEthernet1/0/20
Switch(config-if)# mvr type receiver
Switch(config-if)# mvr vlan 100 group 239.10.10.10
Switch# show mvr members

MVR is the right tool when receivers live in dozens of access VLANs but the streams originate in one. It also gives you a natural place to apply group limits: cap the number of MVR groups per port so one misbehaving set-top box cannot subscribe to the whole bouquet.

Fast leave, report suppression and limits

Switch(config)# ip igmp snooping vlan 100 immediate-leave
Switch(config)# ip igmp snooping vlan 100 last-member-query-interval 5
Switch(config)# no ip igmp snooping report-suppression
Switch(config)# ip igmp snooping vlan 100 static 239.10.10.10 interface Gi1/0/20
Switch(config-if)# ip igmp max-groups 4
Switch(config-if)# ip igmp max-groups action replace | deny

immediate-leave removes a port as soon as a leave is seen instead of sending group-specific queries - use it only where a single host sits on the port, because it can prune a port that still has live members. Report suppression is on by default and hides duplicate joins, which confuses multicast troubleshooting; disable it while you debug and re-enable it afterwards. Static group entries are the escape hatch for devices that never send reports at all.

Proxy reporting deserves a mention because it looks like a bug the first time you meet it. The switch can be configured to suppress downstream reports and answer queries itself, which keeps the group table stable on flapping access ports but hides individual hosts from the router. If your multicast monitoring reports far fewer receivers than you expect, proxy reporting is usually why.

Timers: what ages out and why

Every entry in the group table has a lifetime, and the switch never refreshes an entry on its own. Hosts refresh it by answering general queries; the router refreshes its knowledge by sending them. If queries stop, the switch removes the entry after the group membership timeout (typically 260 seconds on Catalyst) and the group reverts to flooding - which is exactly the "multicast is now a broadcast storm" symptom reported hours after a maintenance window.

Two timers are worth tuning explicitly. Query interval controls how often general queries go out; shortening it makes membership churn visible faster but costs control-plane CPU. Last-member-query-interval controls how long the switch waits before pruning a port after a leave; shortening it speeds up channel changes but risks pruning a port that still has a second receiver on a hub or an unmanaged switch. If you cannot guarantee that only one host sits on each port, leave immediate-leave off and tune the last-member-query-interval instead.

Protecting the network when snooping is not enough

Snooping reduces flooding; it does not bound it. A sender that blasts 2 Gbps of multicast into a 1 Gbps uplink will still saturate it, and a Layer 2 loop will still defeat the group table entirely. Pair snooping with storm control on access and uplink ports and keep the loop-prevention baseline in place:

Switch(config-if)# storm-control broadcast level 1.00
Switch(config-if)# storm-control multicast level 5.00
Switch(config-if)# storm-control action shutdown

Junos-based gear uses different syntax for the same idea - see Junos storm control for BUM traffic. What happens when a loop bypasses the membership table is covered in loop and broadcast-storm troubleshooting, and the DHCP equivalent of trusted-port design - directly comparable in structure - is in Cisco DHCP snooping.

Common failure patterns

Streams work on one VLAN and not another: snooping configured on one VLAN only, or a different STP topology suppressing the mrouter port. Multicast works until the uplink flaps: the mrouter entry was dynamic and aged out - move to a static configuration. Video stutters on channel change: the last-member-query-interval is too long, or immediate-leave is missing. Group table fills up on an uplink: a single port is subscribing to hundreds of groups - apply ip igmp max-groups at the edge, not the core. Raise the group limit carefully with ip igmp max-groups; on many platforms exceeding it triggers the configured action for the whole port, killing every group on that port rather than just the new one. Everything works but bandwidth graphs do not drop: some other receiver or a downstream switch is still flooding - walk the path with show ip igmp snooping groups and show mac address-table multicast on each hop.

Rolling it out on a live network

Snooping is usually already on, which means your change is the configuration around it. Treat that as production change control: pick a maintenance window for the first VLAN, enable no ip igmp snooping report-suppression temporarily so you can see real joins, verify with show ip igmp snooping groups vlan X that the expected group is present on the expected ports, and only then re-enable suppression. Move VLAN by VLAN, and keep the previous config snippet in the change ticket so a rollback is a paste rather than an investigation.

Where it fits in a healthy design

Keep snooping enabled on every access VLAN, mirror the querier on two switches for redundancy, and monitor the group table size on uplinks. When multicast bugs show up, verify the L2 forwarding table first, then move to Layer 3 with the multicast routing state - our PIM sparse mode configuration guide picks up where snooping ends, and if you later need redundant rendezvous points, Anycast RP with MSDP covers the L3 side. For day-to-day break/fix, the switch troubleshooting command handbook collects the commands that answer "is it forwarding or not".

原文链接：https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15_2_6_e/command_reference/b_1526_2960x_cr/igmp_snooping_and_mvr_commands.html