IGMP

IGMP stands for Internet Group Management Protocol. It is a control protocol used by IP hosts (such as computers, cameras, or decoders) and routers to manage multicast group memberships on a local network (Layer 3).

IGMP and multicast go hand-in-hand in networking, especially for video applications like SMPTE ST 2110, IPTV, or streaming contribution systems

  When you want to receive a multicast stream (e.g., a video feed sent to 239.0.0.1), your device tells the local router or switch: “I want to join multicast group 239.0.0.1.” That message is an IGMP Join.

  How Multicast Works

1. Unicast: one sender → one receiver (1:1)
2. Broadcast: one sender → everyone on the subnet (1:all)
3. Multicast: one sender → many interested receivers (1:many)

Example multicast address ranges:
IPv4: 224.0.0.0 – 239.255.255.255
Common for private/streaming/video use: 239.0.0.0/8 (organization-local scope)

Instead of sending one copy of the video stream per viewer (as in unicast), the sender transmits a single copy to the multicast IP address. Switches and routers replicate packets only to interfaces (ports) that have joined that group.

IGMP is a Layer 3 (Network layer) protocol and manages multicast group membership between hosts and routers. Layer 2 switches do not natively understand IP multicast, but if equipped with IGMP Snooping, they listen to IGMP messages to optimize forwarding. IGMP itself does not live at Layer 2.

  IGMP in Action (Simplified)

1. Host (receiver) sends:
     IGMP Membership Report (Join) →Switch/router records that the port (physical/logical interface) connected to the host has joined group 239.0.0.1. Switch/router notes that port and group.
2. Source (sender) sends stream to multicast address 239.0.0.1.
3. The multicast address acts as a shared virtual destination for all members of the group.
4. The network (routers/switches) handles replication so packets reach only joined receivers.
5. The IGMP message is local (sent to the nearest router/switch) — it is not sent to the sender.
6. When documentation mentions “port” in multicast contexts, it usually refers to the switch port, VLAN interface, or router interface where the receiver is connected—not a UDP/TCP port number.
7. Switch forwards multicast packets only to ports that have joined the group.
8. When the receiver no longer wants the stream, it sends an IGMP Leave message (or stops sending periodic reports, depending on version).

Additional SSM SSM (Source-Specific Multicast) is a bit like switching from an "open party" to a "private guest list."
Traditionally, multicasting used Any-Source Multicast (ASM), where a receiver would join a group and get traffic from anyone broadcasting to it. SSM changes the game by requiring the receiver to specify exactly which sender they want to hear from.

How SSM Works with IGMP
SSM relies specifically on IGMPv3 (for IPv4) or MLDv2 (for IPv6). Earlier versions of IGMP simply didn't have the "fields" in their packets to carry source information.
The "Include" List: When a host wants to receive a stream, it

Key Advantage	Benefit
Address Uniqueness	Different sources can use the same multicast group address without interfering with each other, because the (S, G) pair uniquely identifies the stream.
Security	Prevents denial-of-service attacks from rogue sources; the receiver only accepts traffic from the source it explicitly requested.
Simplified Routing	Eliminates the need for complex protocols such as MSDP (Multicast Source Discovery Protocol), since the receiver already knows the source.
Efficiency	The network does not flood traffic to discover receivers; it builds a direct path from the receiver to the known source immediately.

Why use it?
Think of it like a Podcast subscription vs. a CB Radio. In a CB radio (ASM), you tune to a channel and hear everyone talking. In a Podcast (SSM), you specify the exact show (Group) and the exact host (Source) you want to download from. It’s cleaner, safer, and much easier for ISPs to manage info.

Modern multicast video systems (SMPTE 2110, IPTV, etc.) typically use IGMPv3.

IGMP Snooping IGMP Snooping is a Layer 2 switch feature that optimizes multicast traffic forwarding in Ethernet networks. Normally, a Layer 2 switch treats multicast frames like broadcast frames and floods them to all ports in the VLAN.

With IGMP Snooping enabled, the switch listens (snoops) to IGMP messages (Membership Reports/Joins and Leaves) exchanged between hosts and routers.

It builds a table mapping multicast group addresses (e.g., 239.0.0.1) to specific switch ports that have joined those groups.

The switch then forwards multicast packets only to the ports that have subscribed to the group, instead of flooding them everywhere.

Key benefits:
• Dramatically reduces unnecessary multicast traffic on the network.
• Prevents bandwidth waste and performance degradation (especially important for high-bandwidth applications like video streaming, SMPTE ST 2110, IPTV, or IP audio).
• Improves network efficiency in VLANs with many devices.

Requirements for full effectiveness:
• Usually needs an IGMP Querier (often a router or a designated switch) to periodically ask hosts which groups they are still interested in. Without a querier, snooping may not work reliably (some switches can act as querier themselves).
• In short: IGMP Snooping makes multicast behave more like unicast (delivered only where needed) at Layer 2, rather than flooding like broadcast. It's a standard and essential feature on managed switches in any multicast-heavy environment.   (Layer 2 Switch Feature)

  Layer 2 switches normally treat multicast like broadcast and flood it to all ports.
With IGMP Snooping enabled, the switch listens to IGMP Join/Leave messages and builds a table mapping multicast groups to specific ports.
This dramatically reduces unnecessary traffic: multicast packets are forwarded only to subscribed ports.

In SMPTE 2110 or IPTV systems Broadcast/Media Applications:

1. Senders (e.g., cameras, encoders) transmit to a multicast group address.
2. Receivers (e.g., production switchers, monitors, playout servers) send IGMP Joins to subscribe.
3. Network switches with IGMP Snooping (and usually an IGMP Querier IGMP Querier is a device (usually a router, but sometimes a switch or Layer 3 device) that actively asks hosts on a local network segment which multicast groups they are still interested in joining or remaining in.
   
   In a multicast network, hosts send IGMP Membership Reports (Joins) when they want to receive a group, but they don't continuously announce membership. Without periodic queries, the router/switch wouldn't know when hosts have left a group (e.g., user closed a video stream), leading to unnecessary multicast traffic continuing to be forwarded.
   
   • The Querier periodically sends IGMP Query messages to the all-systems multicast address (224.0.0.1) on the subnet/VLAN.
   • All hosts that are members of any multicast group must respond with an IGMP Membership Report listing the groups they still want.
   • The Querier uses these reports to update its group membership table.
   • If a host wants to leave a group, it sends an IGMP Leave message (IGMPv2/v3); the Querier may send a group-specific query to confirm no one else is interested before stopping forwarding that group.
   • If no response comes for a group after timeouts, the Querier assumes no hosts are interested and stops forwarding that multicast stream.
   
   Only one Querier should be active per subnet/VLAN to avoid duplicate queries (IGMPv2/v3 use an election process based on lowest IP address). In many modern managed switches with IGMP Snooping enabled, the switch can act as the Querier if no multicast router is present (this is called a "Querier-enabled switch").
   
   The IGMP Querier is the "pollster" that keeps asking "Who still wants this multicast channel?" so the network can stop sending it when nobody is watching anymore. ) track memberships and forward streams only to interested ports.

This allows:

1. Dozens (or hundreds) of high-bandwidth video feeds to coexist on the same network
2. Without overloading links,
3. While delivering only the needed streams to each destination

Think of multicast like cable TV over IP:

1. The “channels” are multicast addresses (239.x.x.x).
2. IGMP is the remote control telling the router, “Tune me to channel 239.0.0.1.”
3. IGMP Snooping is the network making sure only "TVs" that tuned in get that channel’s data.

  In a properly configured multicast domain:

1. Multicast streams are only forwarded to ports with active receivers
2. Edge ports that are not subscribed see near-zero multicast
3. Uplink ports carry aggregate multicast
4. CPU utilization on the switch stays low
5. Broadcast + unknown multicast remains negligible

IGMP is the control plane mechanism that enforces this.

Troubleshooting

If IGMP snooping is disabled or not functioning the switch treats multicast as broadcast. Floods multicast to every port in the VLAN.

  Symptoms:

• Port counters show uniform RX bandwidth across many ports
• Ports with no receivers show high RX Mbps
  This is the biggest red flag
• Multicast counters climb on unrelated ports
• Multicast streams at ports connected to KVMs, Control panels, Management PCs. These would normally show no multicast
• Uplink ports show roughly the expected multicast rate, while Access ports show the same rate. Normally, uplinks should be “hot” and access ports “cold” Key Visual Analogy
  
  Access port = a regular apartment door: only one household (VLAN) uses it, and packages (frames) arrive without special labels.
  
  Uplink/trunk port = a building lobby elevator: carries traffic for many apartments (multiple VLANs), and each package has a floor label (VLAN tag) so the elevator knows where to deliver it.
  
  Modern Notes
  Many modern managed switches label high-speed ports (e.g., SFP+ or 10G/25G) as "uplink" or "stacking/uplink" ports in the hardware/marketing, even if they can be configured as access ports.
  
  In small/flat networks with no VLANs, the distinction is minimal — all ports behave like access ports.
  
  In VLAN-aware environments (most enterprise, broadcast, or SMPTE 2110 setups), uplink ports are almost always configured as trunks to carry multiple VLANs between switches.
  
  In short:
  Access ports → single VLAN, untagged, end devices
  
  Uplink ports → multiple VLANs, tagged (trunk), inter-switch links
  Table that compares Access & Uplink ports.

Even if IGMP snooping is enabled, but there is no IGMP querier:
(This is extremely common in broadcast plants) this is what the switch does:

• Initially learns multicast memberships
• Memberships age out (typically 60–260 seconds)
• After timeout, switch no longer knows who wants the stream
• Reverts to flooding
• This produces intermittent, confusing failures.
  “Works for a while, then explodes”
  Classic symptoms:
• System behaves normally after reboot or stream start
• 1–5 minutes later:
• Multicast floods
• Bandwidth spikes everywhere
• Endpoints glitch or freeze
• This timing corresponds exactly to IGMP membership expiration.

If there are no periodic queries, memberships cannot be refreshed.
IGMP packet counters tell the story:
On managed switches: IGMP Queries: zero or very low, IGMP Reports: present, IGMP Leaves: present.

If there are no periodic queries, memberships cannot be refreshed.

Its possible to have a Querier present on one VLAN, and missing on others. That might be the case if a VLAN floods after a few minutes

What happens if you have partial snooping or mis-scoped VLANs?
This is common in 2110 systems with management + media VLANs.
Symptoms:

• Multicast floods only on certain ports
• Some receivers work, others don’t
• Bandwidth asymmetry between similar ports
• Counters show:
• Multicast RX on ports that should be control-only
• Zero IGMP activity on the affected VLAN
• Often caused by:
• Snooping enabled globally but not per-VLAN
• Querier on wrong VLAN
• Trunk ports missing VLAN membership
• Specific counters to check (vendor-agnostic), per port and per VLAN:
• Multicast packets RX / TX
• Unknown multicast
• Broadcast packets
• Flooded packets
• IGMP queries sent
• IGMP reports received
• IGMP leaves received
• Port RX bandwidth over time (not just instantaneous)
• If your switch supports it:
• Multicast forwarding table size
• Group membership count per VLAN
• Practical “field test” without deep CLI access
• If you’re onsite and short on time:
• Pick a port with nothing multicast-aware attached
• Check its RX bandwidth
• Start a known 2110 multicast stream
• If that port’s RX jumps significantly → multicast flooding
• Repeat after 2–3 minutes:
    If it suddenly jumps later → missing querier

Why this matters in ST 2110 environments:

• 3–12 Gbps per stream
• Dozens of streams per VLAN
• Flooding can saturate NICs, PCIe buses, and switch fabrics
• PTP is usually still “fine,” which misleads people
• The result is:
    “The network is up, but everything is broken.”
  Which is exactly what missing IGMP infrastructure produces.

Short summary

• Uniform high multicast RX across many ports → snooping missing or broken
• Multicast works briefly then floods → querier missing
• Only uplinks should be hot; access ports should be quiet