IGMP Snooping and Multicast Network Playbook

Multicast is not broadcast

Multicast lets one source send traffic to a group of interested receivers. At Layer 2, a switch needs information about which ports have interested receivers. IGMP snooping watches IGMP control messages and uses that information to build forwarding state for multicast groups.

Why the client benefits

Without correct multicast handling, high-rate streams can be flooded to ports that did not ask for them. In CCTV, IPTV and some AV systems, that can waste access-port and uplink capacity and produce confusing performance symptoms.

What IGMP snooping actually depends on

• Receivers must signal membership correctly.
• The VLAN needs an appropriate querier function somewhere in the multicast design.
• Switches must learn the router/querier-facing ports correctly.
• Static multicast MAC or unusual appliance behaviour can bypass the normal learning model.

Field troubleshooting

1. Identify source IP, multicast group and receiver VLAN.
2. Confirm the receiver sends an IGMP membership report.
3. Check the switch's snooping group table for the expected group and port.
4. Confirm the multicast router/querier path is present.
5. Check whether traffic is being flooded to non-member ports.
6. If an appliance uses unusual static multicast behaviour, check the vendor design rather than assuming standard snooping will contain it.

Useful Cisco-style checks

show ip igmp snooping
show ip igmp snooping groups
show ip igmp snooping vlan 30

What works

• Documenting group addresses and source systems.
• Knowing which VLAN carries the multicast service.
• Checking group state while a receiver is actively subscribed.
• Testing uplink utilisation with and without receivers.

What does not work

• Disabling IGMP snooping globally because one multicast application fails.
• Assuming every multicast implementation behaves like ordinary host membership.
• Troubleshooting only the receiver and never checking the switch group table.