IGMP operates at the network layer (Layer 3) and works
exclusively with IPv4. It allows devices like workstations, servers, and IP
cameras to dynamically register for multicast traffic, enabling the network to
forward data only where it is needed. This conserves bandwidth, reduces
unnecessary traffic, and improves performance across the enterprise LAN.
Alongside protocols like PIM for routing and IGMP snooping for Layer 2
optimization, IGMP is a cornerstone of scalable multicast delivery in both
small business and large-scale enterprise environments.
What is
IGMP?
IGMP (Internet Group Management Protocol) is a Layer
3 protocol used by IPv4 hosts and adjacent multicast routers to
establish and maintain multicast group memberships.
- Defined
by: [RFC 1112 (IGMPv1)], [RFC 2236 (IGMPv2)], and [RFC 3376 (IGMPv3)]
- Works
with: IPv4 (For IPv6, multicast group management is handled by MLD -
Multicast Listener Discovery)
- Transport
layer used: IGMP is not encapsulated in TCP or UDP; it is its
own protocol over IP (protocol number 2)
What is
IGMP Used For?
IGMP is used for managing multicast group memberships
on a local network segment (subnet). It enables efficient delivery of data
to multiple recipients without sending multiple copies of the same data.
Typical Use Cases:
- Streaming
video and audio (e.g., IPTV, online broadcasts)
- Multimedia
conferencing
- Stock
quote distribution
- Push-based
data updates in financial or scientific networks
- Surveillance
systems using multicast-enabled IP cameras
How IGMP
Fits into Enterprise Networks
In an enterprise environment, multicast is used to conserve
bandwidth and improve performance by sending a single stream of data to multiple
clients simultaneously. IGMP is crucial for:
Joining Multicast Groups:
- A
host (such as a workstation or IP camera) sends an IGMP Membership
Report to join a group.
- Multicast
routers listen for these reports and forward multicast traffic only
to segments where there are active members.
When Does a Host Send an IGMP Membership Report?
A host sends an IGMP Membership Report when:
An Application Requests
Multicast Data
When a program (like a video
player, IPTV client, or surveillance software) binds to a multicast address,
the operating system triggers the process.
·
For example, an app wants to receive a multicast
stream at 239.1.1.100:5000.
·
The OS generates an IGMP Membership Report
for group 239.1.1.100 and sends it to 224.0.0.22 (in IGMPv3).
In Response to a General Query
Multicast routers periodically send
IGMP General Queries to check which groups are still needed.
·
The host replies with Membership Reports
for any groups it has joined.
How is the Membership Report
Sent?
·
Sent to: 224.0.0.1 (all-hosts) in
IGMPv1/v2, or 224.0.0.22 in IGMPv3.
·
Contains: The multicast group address the
host wants to join.
·
The TTL (Time-To-Live) is set to 1
(because the report stays within the local subnet).
·
The message is sent to the router or Layer 2
switch listening for IGMP.
What Happens to the Host’s IP Address Configuration?
Here’s the key point:
·
The host does NOT acquire a new IP address in
the 224.x.x.x multicast range.
Here's what happens:
·
The host retains its unicast IP address,
e.g., 192.168.1.25.
·
It adds the multicast group address to its network
interface's multicast receive list.
·
At the Ethernet layer, the host also listens for
multicast MAC addresses derived from the multicast IP.
Example: Multicast IP to MAC Address Mapping
If the application joins group 239.1.1.100,
the host:
·
Maps it to a MAC address: 01:00:5E:01:01:64
·
Begins listening for frames addressed to that
MAC
How it’s done:
·
The lower 23 bits of the multicast IP are used
to form the MAC address.
·
Prefix: 01:00:5E
·
So:
239.1.1.100 = 11101111.00000001.00000001.01100100
Last 23 bits = 00000001.00000001.01100100
MAC = 01:00:5E:01:01:64
IP Addressing During Multicast Membership
|
Component |
Behavior |
|
Host’s IP Address |
Remains unchanged (e.g., 192.168.1.x) |
|
Multicast Group Address |
Not assigned to host; used to filter inbound traffic |
|
Multicast MAC Address |
Derived from group IP, added to NIC receive list |
|
Traffic Routing |
Handled by router/switch if configured for multicast
routing and snooping |
Final Flow Recap
1. Application
on host subscribes to multicast stream.
2. OS
sends IGMP Membership Report to router/switch.
3. Host
adds multicast MAC to interface filters.
4. Router
updates its forwarding table.
5. Switch
(if IGMP snooping enabled) only forwards multicast to interested ports.
Leaving
Multicast Groups:
- The
host sends a Leave Group message (in IGMPv2/v3) when it no longer
wants to receive traffic.
Multicast Snooping in Switches:
- Layer
2 switches can implement IGMP snooping, allowing them to listen in
on IGMP traffic and forward multicast only to ports that have requested
it, instead of flooding.
IGMP
Configuration in Enterprise Networks
On Multicast Routers:
- Enable
IGMP on the interfaces connected to multicast clients.
- Configure
PIM (Protocol Independent Multicast) for multicast routing across
subnets.
- Use access
control lists (ACLs) to manage multicast group access.
Example (Cisco IOS):
interface GigabitEthernet0/1
ip address 192.168.1.1 255.255.255.0
ip igmp version 3
ip pim sparse-mode
On Layer 2 Switches:
- Enable
IGMP snooping to limit multicast traffic to only the interested
ports.
- Often
enabled globally and per VLAN.
Example (Cisco IOS):
ip igmp snooping
ip igmp snooping vlan 10
On Hosts:
- Most
modern operating systems join multicast groups automatically when
applications request multicast data.
- No
manual configuration is usually needed.
Special
Equipment Needed
1. Multicast-Enabled Routers:
- Must
support IGMP and PIM (Sparse/Dense mode) for routing multicast traffic
between subnets.
2. Managed Switches with IGMP Snooping:
- Necessary
to prevent flooding multicast traffic across all ports.
- Helps
scale multicast delivery across larger networks.
3. Multicast-Capable Applications:
- Must
be able to send or receive multicast packets, often on IPs in the 224.0.0.0/4
range.
IGMP
Versions and Differences
|
Version |
Features |
Notes |
|
IGMPv1 |
Basic join functionality |
No leave messages; router uses timeout |
|
IGMPv2 |
Adds leave messages, group-specific queries |
More efficient group management |
|
IGMPv3 |
Adds source filtering (INCLUDE/EXCLUDE lists) |
Allows for SSM (Source-Specific Multicast) |
Multicast
Addressing Overview
|
Address
Range |
Purpose |
|
224.0.0.0 – 224.0.0.255 |
Local subnet scope (e.g., routing protocols like OSPF) |
|
224.0.1.0 – 238.255.255.255 |
Globally scoped multicast |
|
239.0.0.0 – 239.255.255.255 |
Organization-local scope (administratively scoped) |
Security
Considerations
- IGMP
Flooding Attacks: Flooding the network with IGMP join/leave messages
can overwhelm switches.
- Mitigation:
- Enable
IGMP snooping
- Use
access-lists and rate limiting
- Monitor
for abnormal group joins
Summary
