An IGMP flood attack is a protocol-based denial-of-service technique that sends a high volume of Internet Group Management Protocol messages — typically membership reports or join requests — to exhaust the multicast group state tables and CPU resources of routers and switches on the path to a target. Unlike volumetric floods that saturate bandwidth, an IGMP flood targets the finite memory that networking devices allocate to track multicast group membership.
TL;DR: IGMP (Internet Group Management Protocol) lets hosts tell routers and switches which multicast groups they want to receive traffic for. An IGMP flood abuses this by sending large volumes of join or membership report messages, often with spoofed or randomized group addresses, forcing devices to create and track large numbers of multicast state entries until memory or CPU is exhausted. It is a legacy-leaning Layer 3 protocol attack, most impactful against older routers and switches with small multicast state tables or unrestricted IGMP snooping configurations; modern network gear with IGMP rate limiting and group limits is largely resistant, but misconfigured multicast environments remain exposed.
Last updated: 2026-08-27
How the Attack Works
IGMP (defined in RFC 3376 for version 3) is the protocol hosts use to join and leave IP multicast groups. When a host wants to receive multicast traffic for a group, it sends an IGMP Membership Report; routers and switches use this to build and maintain multicast forwarding state, and switches use IGMP snooping to decide which ports should receive which multicast streams.
Normal IGMP operation:Host ──IGMP Membership Report (join group 239.1.1.1)──▶ Router/SwitchRouter/Switch: creates multicast state entry for 239.1.1.1 on that port
IGMP flood:Attacker ──IGMP Report (group 239.1.1.1)──▶ RouterAttacker ──IGMP Report (group 239.1.1.2)──▶ RouterAttacker ──IGMP Report (group 239.1.1.3)──▶ Router... [thousands to millions of distinct or spoofed group joins] │ ▼Router/switch multicast state table fills; CPU spent processingeach report; legitimate multicast and unicast forwarding degradeBecause each IGMP report can request a different multicast group, a flood forces the device to allocate a new state table entry per group rather than reusing an existing one, which exhausts table capacity far faster than repeating the same request would. On switches, this also stresses IGMP snooping tables, which map group memberships to physical ports; a saturated snooping table can force the switch to flood multicast traffic to all ports, degrading the broader network in addition to the multicast service itself.
Historical Context
IGMP flood attacks emerged as multicast deployments (used for IPTV, video conferencing, and financial market data distribution) became more common in the early-to-mid 2000s, alongside broader interest in protocol-state-exhaustion attacks following the visibility of SYN floods in the late 1990s. Early router and switch implementations often used fixed-size multicast group tables without per-source or per-port limits, making them straightforward to exhaust with a modest volume of crafted IGMP traffic. Vendors subsequently added IGMP rate limiting, maximum-group-count enforcement per port, and stricter snooping controls as standard features in enterprise-grade networking equipment.
IGMP Flood vs. General Protocol Floods
| Aspect | IGMP Flood | General Protocol Flood (e.g., SYN Flood) |
|---|---|---|
| Exploited resource | Multicast group state table, switch CPU | Connection state table, kernel memory |
| Protocol layer | Layer 3 (network/control plane) | Layer 4 (transport) |
| Typical target | Routers, switches, multicast-enabled networks | Any TCP-handling host or middlebox |
| Prevalence today | Low — mostly relevant to multicast-heavy networks | Still common across the internet |
| Primary defense | IGMP rate limiting, group count limits, snooping controls | SYN cookies, connection rate limiting |
| Deployment scope | Enterprise, ISP, and IPTV multicast networks | Any internet-facing infrastructure |
Why Modern Systems Are Largely Immune
Modern routers and switches implement per-port and per-device limits on the number of multicast groups they will track, along with IGMP query and report rate limiting, which caps how quickly an attacker can create new state entries. IGMP snooping implementations in current enterprise switches also validate report rates and can drop excessive requests from a single port or source before they exhaust the snooping table.
Residual risk concentrates in:
- Legacy or consumer-grade switches without configurable multicast group limits
- ISP and IPTV multicast infrastructure where large numbers of subscriber-facing ports must process real IGMP traffic, making rate limiting harder to tune without affecting legitimate viewers
- Misconfigured enterprise networks that leave IGMP snooping and query limits at permissive defaults
Detection and Mitigation
- IGMP rate limiting — cap the number of IGMP messages processed per second, per port or per source, at routers and switches
- Multicast group count limits — enforce a maximum number of concurrent multicast group memberships per port to bound state table growth
- IGMP snooping hardening — configure switches to validate and rate-limit snooping table updates rather than accepting unlimited joins
- Access control on multicast-enabled interfaces — restrict which interfaces or VLANs are allowed to send IGMP reports, particularly on untrusted or user-facing segments
- Monitoring multicast state table utilization — alert on unusual growth in group membership counts or IGMP message rates relative to baseline
How to Implement on Azion
IGMP flood targets multicast-specific network infrastructure rather than typical HTTP/HTTPS-facing web and API workloads, so mitigation is primarily a network-design and router/switch-configuration concern for organizations running multicast services. For internet-facing applications and APIs sitting behind Azion, DDoS Protection and Network Shield can help filter anomalous Layer 3 protocol traffic and malformed packets before they reach origin infrastructure, reducing exposure from protocol-abuse attacks generally. Firewall rules can be used to restrict which protocols and traffic patterns are allowed to reach origin, adding a policy layer for environments where multicast traffic is not expected.
Related Resources
- What Is a DDoS Attack?
- DDoS Attack Types
- What Is DDoS Protection and Mitigation?
- What Is an ICMP Flood Attack?
- Azion DDoS Protection
Frequently Asked Questions
What is an IGMP flood attack? An IGMP flood sends a high volume of Internet Group Management Protocol messages, usually membership reports for many different multicast groups, to exhaust the multicast state tables and CPU of routers and switches along the path to a target.
Is IGMP flood still a threat today? It is a low-prevalence threat today. Modern enterprise networking equipment enforces IGMP rate limiting and per-port group count limits, leaving legacy switches, misconfigured multicast networks, and large-scale IPTV or ISP multicast deployments as the main residual exposure.
How is IGMP flood different from an ICMP flood? An ICMP flood sends volumes of ping-related traffic to exhaust bandwidth or CPU on a target host. An IGMP flood instead targets the multicast group membership state maintained by routers and switches, a narrower and more specialized attack surface tied to multicast-enabled networks.
What is IGMP used for in normal operation? IGMP lets hosts inform local routers and switches which IP multicast groups they want to receive traffic for, which is the basis for delivering multicast content like IPTV, live video streams, and some financial market data feeds efficiently to only the interested receivers.
Does IGMP flood require IP spoofing? No. Because the attack targets state table capacity rather than relying on unanswered responses, an attacker can generate large volumes of distinct group-join requests from real or spoofed source addresses; spoofing can help obscure the source but is not required for the flood to be effective.
Can a firewall stop an IGMP flood? A firewall or router with IGMP-aware filtering can rate-limit or drop excessive IGMP messages per source or per interface, which is effective against many IGMP floods. It is less effective if the flood originates from many distinct, legitimate-looking hosts across a large network.
What kind of devices are most exposed to IGMP flood? Legacy or consumer-grade routers and switches without configurable multicast group limits, along with ISP and IPTV infrastructure that must process large volumes of genuine subscriber IGMP traffic, are the most exposed device categories.
How do multicast networks defend against IGMP flood without blocking legitimate viewers? Operators typically set per-port maximum group counts based on expected legitimate usage, apply IGMP query and report rate limits tuned above normal peak demand, and monitor for sudden anomalous growth in group membership rather than blocking IGMP outright.
Does IGMP flood affect unicast traffic on the same network? Yes, indirectly. If a switch’s multicast snooping table is exhausted, some switches fall back to flooding multicast traffic to all ports, consuming additional bandwidth and switch CPU that can degrade unicast traffic sharing the same infrastructure.
Is IGMP flood classified as a volumetric or protocol attack? It is generally classified as a protocol (state-exhaustion) attack rather than a volumetric one, since its primary effect is exhausting the finite state table capacity and processing resources of network devices rather than saturating link bandwidth.
What RFC defines IGMP? IGMPv3, the current version, is defined in RFC 3376. Earlier versions IGMPv1 and IGMPv2 are defined in RFC 1112 and RFC 2236 respectively.
Sources
- IETF. “Internet Group Management Protocol, Version 3.” RFC 3376. 2002.
- IETF. “Host Extensions for IP Multicasting.” RFC 1112. 1989.
- IETF. “Internet Group Management Protocol, Version 2.” RFC 2236. 1997.
- NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.