IGMP/MLD Snooping

About

This document gives a brief overview of multicast within a LAN, with a focus on IP multicast, and how it can be controlled using IGMP/MLD snooping. It also covers non-IGMP/MLD capable devices and how they can be integrated into a network with IGMP/MLD snooping enabled.

Introduction

Multicast and broadcast, as opposed to unicast, can be used to communicate to more than one receiver. The main difference between multicast and broadcast is that multicast can be controlled. When disabling its control mechanisms, multicast behaves like broadcast.

To control distribution of multicast within a LAN the following main primitives are available:

  • Flood or block per default: It is possible to control per port if traffic to unknown multicast should be flooded or blocked. The default is to flood.
  • Dynamically limit IP multicast: By enabling IGMP/MLD snooping, a switch can learn on which ports subscribers of IP multicast addresses reside. Traffic to these known multicast addresses is only forwarded to ports leading to subscribers (and towards multicast routers/IGMP or, MLD Queriers).
  • Static filters: It is possible to manually specify on which ports to forward a multicast address.

Settings for the first two primities are covered here, while static filters is documented in the transparent bridge configuration guide. With these primitives, switches can distribute IP multicast data within a LAN in the following ways:

  1. treat multicast traffic as broadcast – always flood on all ports
  2. flood until subscribers appear, then limiting specific flows
  3. (always) limit forwarding of multicast only to subscribers

Cases 2 and 3 assumes IGMP/MLD snooping is enabled.

To limit IP multicast requires switches to inspect Internet Group Management Protocol (IGMP), or Multicast Listener Discovery (MLD) control messages, which exchanged by hosts and routers to learn which ports lead to subscribers – this mechanism is referred to as IGMP/MLD snooping, RFC 4541.

                  Switch
                 .------.    MC
                 |      | =======> .---.
                 |  .---+----------+ H |
          MC     | /    |    MC    '---'
.---. =========> |/     | =======> .---.
| H +------------+------+----------+ H |
'---'            |\     |    MC    '---'
                 | \    | =======> .---.
                 |  `---+----------+ H |
                 '------'          '---'

Figure 1: Multicast flow flooded like broadcast traffic. This is the case when flooding of unknown traffic is enabled and when IGMP/MLD snooping is disabled, or it is enabled, but no subscriber has joined.

                  Switch
                 .------.
                 |      |          .---.
                 |      +----------+ H |
          MC     |      |          '---'
.---. =========> |      |          .---.
| H +------------+      +----------+ H |
'---'            |      |          '---'
                 |      |          .---.
                 |      +----------+ H |
                 '------'          '---'

Figure 2: Flow of multicast blocked by switch. IGMP/MLD snooping is enabled, but no subscriber has joined. Flooding of unknown multicast is disabled.

                  Switch
                 .------.    MC
                 |      | =======> .---.
                 |  .---+----------+ H |
          MC     | /    | <---Join '---'
.---. =========> |/     |          .---.
| H +------------+      +----------+ H |
'---'            |      |          '---'
                 |      |          .---.
                 |      +----------+ H |
                 '------'          '---'

Figure 3: Multicast flow forwarded to subscriber (only). IGMP/MLD snooping is enabled and a single subscriber has joined. The switch learns the location of subscribers by sniffing IGMP/MLD join messages.

The IGMP/MLD snooping support also features support for acting as an IGMP/MLD querier – a role which is usually handled by a multicast router. Having switches with IGMP/MLD querier capabilities enables efficient distribution of IP multicast in networks without multicast routers.

Note

Most switches only limit the broadcast effects of multicast on layer-2, i.e. MAC level. It is therefore important to design IP multicast networks so that groups do not overlap. E.g. 225.1.2.3 and 226.1.2.3 map to the same multicast MAC address and will effectively be treated as the same group in the switch fabric. Meaning, both groups will be forwarded by switches and may potentially overload the intended receiver. See RFC 1112 and RFC 6085 for details on how IPv4 and IPv6 multicast groups, respectively, map to MAC multicast addresses.

IGMP/MLD Snooping

With IGMP Snooping enabled, switches continuously track subscribed multicast groups and limit their reach to the abilities of the underlying switch fabric. Devices support limiting up to 2048 groups, but ability to limit is also dependent on the distribution of learnt MAC addresses.

Note

Both unicast and multicast MAC addresses are stored hashed in the switch’s MAC database. When addresses hash to the same location they are stored in one of four “bins”, when all these are occupied the database is exhausted. The fifth MAC address cannot be stored, and an ATU full warning message will appear in syslog. The MAC address continues to be unknown and is thereby subject to flooding policies.

Multicast is either known or unknown. I.e., the switch either has a matching multicast group entry in its MAC database or not.

      Switch               Switch               Switch
   .---------.   MC X   .---------.   MC X   .----------.
   |      .--| -------> |---------|  ------> |--.       |
   |     /   +----------+         +----------+   \      |
   |    /   .| .......> |.........| .......> |.   \     |
   |   /   . |   MC Y   | .       |   MC Y   | .   \    |
   '----+----'          '----+----'          '----+-----'
      ^ | ^                . |                  . | | ^
      | | . MC          MC . |              MC  . | | | Join X
      | | . X,Y          Y . |             X,Y  . | | |
      | | .                v |                  v | v |
    .---+---.            .---+---.             .--+----.
    |   H   |            |   H   |             |   H   |
    '-------'            '-------'             '-------'

Figure 4: Flooding of unknown multicast (Y, dotted) to all, known multicast (X, dashed) only to subscribers.

In WeOS IGMP/MLD snooping allows for the paradigm to flood multicast until the network knows more. Here IP multicast is broadcast until an IGMP/MLD Join1 message from an end device is received, IGMP/MLD snooping in the switch detects this, dynamically installs a MAC entry to reclassify the group as known and then forwards the IGMP/MLD report towards the IGMP/MLD Querier on the LAN. In the event of MAC db exhaustion (see note on ATU full above) in this setup, the multicast will still be forwarded.

Flooding of multicast applies to both IP and MAC multicast alike, IGMP/MLD can only limit IP multicast. For the most part, users will likely opt for either flood on all ports (the safe default), or none:

  • With flooding of unknown multicast enabled on all ports, all multicast traffic is forwarded on all ports in the same VLAN, i.e., like broadcast traffic. Only IP multicast may be limited in this mode, and only while at least one subscriber of an IP multicast group is active. The default is to flood on all ports (excluding CPU).
  • With flooding of unknown multicast disabled on all ports, multicast packets are only forwarded on ports leading to a subscriber of an IP multicast group, ports leading to an IP multicast router (i.e., the elected querier or a statically configured multicast router port.), and ports in static FDB filters.

Enabling and disabling of IGMP/MLD snooping is both controlled globally and per VLAN. By default, IGMP/MLD snooping is enabled both globally and per VLAN.

  • When IGMP/MLD Snooping is disabled globally, the per-VLAN settings are ignored and IGMP/MLD Snooping is completely disabled on the device.
  • When IGMP/MLD Snooping is enabled globally, the per-VLAN settings control multicast filtering per VLAN. E.g., it is possible to disable IGMP/MLD snooping on individual VLANs as shown in the example below.
example:/config/ip/#> show multicast-snooping 
Enabled, can be enabled/disabled per VLAN
example:/config/ip/#> end
example:/config/#> vlan 1
example:/config/vlan-1/#> no multicast-snooping 
example:/config/vlan-1/#> show multicast-snooping 
Disabled
example:/config/vlan-1/

With IGMP/MLD snooping enabled on a VLAN, IP multicast packets are only forwarded to ports leading to a subscriber of that IP multicast group, and to ports leading to an IP multicast router,

With IGMP/MLD snooping disabled on a VLAN, the switch will not inspect IGMP/MLD packets to learn the location of subscribers or Queriers. Thus, IP multicast traffic will treated as unknown multicast traffic.

Ports shared between multiple VLANs may have different IGMP/MLD snooping settings on different VLANs, i.e., one VLAN may have IGMP/MLD snooping enabled and another may have it disabled. As WeOS5 learns MAC address per VLAN, IP multicast traffic can be limited on that port for the VLAN with IGMP/MLD snooping enabled, while multicast traffic on another VLAN is flooded.

Settings for controlling flooding of unknown multicast, and for globally enabling/disabling IGMP/MLD snooping are located in the IP configuration context:

example:/#> config
example:/config/#> ip
example:/config/ip/#>
[no] multicast-snooping

Allow per VLAN IGMP/MLD snooping, or disable it entirely. Default: Enabled

When enabled the per-VLAN ‘multicast-snooping’ setting controls if IGMP/MLD snooping should be enabled. When this setting is disabled all IGMP/MLD snooping is disabled, regardless of the per-VLAN setting

[no] multicast-flood-unknown [PORTS]

Control flooding of unknown multicast.

This setting controls the behavior of unknown multicast. Also called unregistered multicast. When this setting is enabled, by default all ports, both unknown MAC and IP multicast from other ports in the same VLAN is flooded on these ports, in the same VLAN.

When disabled, unknown multicast is blocked, unless the port is also configured as a static multicast-router-port, or IGMP/MLD snooping has registered the port a dynamic multicast router port due to an upstream IGMP/MLD querier or PIM router. To forward IPv4 multicast, or MAC multicast, a static FDB entry must be set or an end-device on that port must send an IGMP membership report for the IPv4 group.

When IGMP snooping is enabled and an end-device reports/joins a multicast group, only that group is filtered. The filtering is per group and per device/VLAN, depending on the underlying HW.

Note

Certain overlapping multicast groups may be hashed to the same “bucket” in the underlying hardware. When the bucket is full, filtering cannot be done. When this happens, the system generates a warning message to the system log and the IGMP status for the given group has a ‘!’ flag. It is recommended to leave this setting at its default value.

The setting to enable/disable IGMP snooping per VLAN is available in the VLAN configuration context:

example:/#> config
example:/config/#> vlan 1
example:/config/vlan-1/#>
[no] multicast-snooping
Enable, or disable IGMP/MLD snooping

IGMP/MLD Querier Settings

As part of the IGMP/MLD snooping functionality, the switch can also act as Querier - a role usually handled by multicast routers. Switches with querier capabilities allow for distribution of IP multicast in networks without multicast routers, using IGMP/MLD to limit the broadcast effects of multicast.

IGMP/MLD Querier settings are located in the IP configuration context.

[no] multicast-querier <auto|proxy>

Auto mode is the default querier mode. It implements the IGMP/MLD standard to elect2 a designated IGMP/MLD querier on each LAN. In this mode all multicast, both known and unknown, is flooded to the elected querier, which acts as a distribution point for the LAN. This is an important aspect when designing networks and calculating the required bandwidth of individual links.

Proxy mode is the alternative querier mode. Useful in networks where the switch should never take part in the querier election and only act as a silent forwarder of IGMP/MLD queries (and reports). However, to prevent loss of multicast distribution on LANs where there is no elected IGMP/MLD querier, the switch by default send proxy queries3. A feature useful for optimizing low-bandwidth setups.

On VLANs where the network interface is not assigned an IP address, the switch will automatically fall back to proxy mode on that VLAN, regardless of the global querier mode setting.

The proxy query feature can confuse IGMP implementations from some vendors. This may result in other switches forwarding all multicast towards the switch originating the proxy query, severely impacting performance by saturating links. Therefore, this feature can be disabled, leaving the switch to only forward any IGMP reports (join/leave messages) and IGMP queries, acting as a pure proxy.

[no] multicast-proxy-query

Allow sending IGMP query with source IP 0.0.0.0 in proxy mode. Default: Enabled

When IGMP/MLD snooping is enabled and the multicast-querier mode is set to ‘proxy’, or the VLAN interface has no address, and no elected IGMP/MLD querier on the LAN exists, then the device initiates IGMP proxy queries using source IP address 0.0.0.0.

In a network with no multicast router this feature speeds up network convergence for multicast. Disabling it means the device will never initiate an IGMP query.

[no] multicast-querier-interval <5-300>

Query interval (QI). Default: 125 seconds

When elected as IGMP/MLD querier, the switch can emit queries in the range 5-300 sec. This interval is also used when timing out multicast to end devices that for some reason stop answering the queries.

[no] multicast-querier-robustness <VALUE>

Control IGMP/MLD querier robustness value, QRV. Default: 2

This setting controls the querier/query robustness value. It in turn controls how multicast routers/queriers and group memberships time out. It is intended to be used sparingly but can be useful in lossy networks to allow for losing query or membership reports. When the QRV is set to a value of 2 (default) max 1 (QRV - 1) query may be lost by an end device, or one membership report lost by the querier before they are considered timed out. A certain jitter is allowed, see for instance the description for the multicast-router-timeout. The membership timeout is calculated according to the following formula:

timeout = QRV * QI + QRI

Where QI is the querier interval and QRI is the hard coded Querier Response Interval (10 sec).

[no] multicast-router-timeout <0|1-2147483647>

Timeout for learned multicast routers. Default: Auto (0)

A functional IGMP/MLD querier, usually a multicast router, on a LAN is critical to successful multicast operation. If the querier dies, or suddenly gets a new IP address, another device must take over. This setting controls the time in seconds before this device can take over.

By default this value is automatically calculated using the currently configured query interval (QI), the robustness value (QRV) and the Query Response Interval (QRI) according to the following formula:

timeout = QRV * QI + QRI/2

Where the Querier Response Interval (QRI) is hard coded to 10 sec.

When a multicast receiver attached to a switch port leaves a multicast group (i.e., stops subscribing to an IP multicast address or is simply disconnected from the port), the IGMP/MLD snooping leave latency (the time until the switch stops forwarding the associated multicast data) is within 2-3 times the configured Query Interval. See IGMP Fast Leave for information on optimising this behavior on access ports.

Multicast Router Ports

With IGMP/MLD snooping enabled, the switch learns on which ports there are interested receivers of multicast. It accomplishes this by listening to IGMP report messages sent by all subscribers. Thus, the switch only forwards IP multicast on ports that are members of multicast groups.

The switch also forwards all multicast traffic, both subscribed (known) and unknown, on ports leading to multicast routers. The following ports are considered as multicast router ports:

  • Ports configured as multicast router ports
  • Ports where IGMP/MLD Queries are received, usually queries are sent by multicast routers, but also by IGMP/MLD snooping aware switches like WeOS.
  • Ports on which Multicast Router Discovery (MRDISC) packets are received, see RFC 4286
  • RiCo uplink ports : To provide fast fail-over of multicast traffic, FRNT Ring Coupling (RiCo) uplinks are added to the list of multicast router ports. This is both done at the Ring Coupling nodes, as well as on switches on the remote side of the uplink.

Ports can be explicitly configured as multicast router ports in the IP configuration context:

example:/config/#> ip 
example:/config/ip/#> multicast-router-ports eth7
example:/config/ip/#>
[no] multicast-router-ports <PORTS>
Set static multicast router ports. Default: Disabled

FRNT ring ports are not considered multicast router ports per se. The Fast Reconnect feature of FRNT is instead handled per multicast group: if a multicast address is learnt on a ring port, the other ring port is automatically added. Similarly, if an IGMP/MLD Query is received on a ring port, both ring ports are considered multicast router ports. WeOS applies this multicast Fast Reconnect feature for MRP too. In case of ring breakage this practice ensures next to zero reconfiguration time for multicast over FRNT and MRP.

IGMP/MLD Fast Leave

IGMP/MLD snooping supports IGMP/MLD Leave by default and IGMP/MLD Fast Leave can be enabled on a per-port basis. The CLI multicast-fast-leave setting allows the keyword all. The Fast Leave feature is recommended only for access ports.

example:/#> configure
example:/config/#> ip
example:/config/ip/#> no multicast-fast-leave
example:/config/ip/#> multicast-fast-leave eth3, eth6
example:/config/ip/#> leave
Configuration activated.  Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start
example:/#> show ip igmp
 Static Multicast ports
-------------------------------------------------------------------------------
 IGMP Fast Leave ports      : eth3, eth6
 Static router ports        : eth5
 Discovered router ports    : ---
 Dual Homing/Coupling ports : ---
 FRNT ring ports            : ---
 Multicast flooded on ports : eth1, eth2, eth3, eth4, eth5, eth6, eth7, eth8

 VID  Querier IP       Querier MAC        Port              Interval  Timeout
-------------------------------------------------------------------------------
   1  10.0.0.1         LOCAL

 VID  Multicast Group  Filtered MAC Addr  Active ports
-------------------------------------------------------------------------------
   1  225.1.2.3        01:00:5E:01:02:03  eth5

-------------------------------------------------------------------------------
Total: 1 filters, max 2048, in 1 VLANs.

When an IGMP Leave is received on a port configured with Fast Leave it issues a group specific query for the group being left and then immediately cuts the multicast stream for that group. With Fast Leave disabled, a standard grace period is honored for the benefit of any multicast receivers attached on downstream port splitters (hubs or unmanaged switches). When no membership report/reply is received the multicast group will time-out within three query intervals.

The setting to control multicast fast leave is available in the IP configuration context:

[no] multicast-fast-leave <PORTS>
IGMP/MLD Fast Leave (access) ports. Default: None

Reserved Multicast Groups

IP multicast in the Local Network Control Block, 224.0.0.X, is reserved for protocols like RIP (224.0.0.9), OSPF (224.0.0.5 and 224.0.0.6), and VRRP (224.0.0.18). Traffic in this range should not be filtered by IGMP Snooping switches RFC 4541. Furthermore, WeOS units filter multicast on the MAC level, and since multiple IP multicast addresses map to the same MAC address, see RFC 1112, this means there is a larger set of ``well-known’’ reserved groups in consecutive ranges that IGMP does not filter. Any packets received for these groups are flooded on all ports in the same VLAN on which they were received, except the port on which the packets entered the switch.

The table below lists the IP multicast address groups excluded from IGMP filtering, i.e., the 32 well-known address groups (8192 total addresses) that IGMP does not filter.

Reserved MC
224.0.0.x 232.0.0.x 224.128.0.x 232.128.0.x
225.0.0.x 233.0.0.x 225.128.0.x 233.128.0.x
226.0.0.x 234.0.0.x 226.128.0.x 234.128.0.x
227.0.0.x 235.0.0.x 227.128.0.x 235.128.0.x
228.0.0.x 236.0.0.x 228.128.0.x 236.128.0.x
229.0.0.x 237.0.0.x 229.128.0.x 237.128.0.x
230.0.0.x 238.0.0.x 230.128.0.x 238.128.0.x
231.0.0.x 239.0.0.x 231.128.0.x 239.128.0.x

Table 1: Reserved RFC 1112 groups. X is any value from 0 to 255.

  1. In IGMPv2 the terms are join and leave, with the collective name IGMP report. In IGMPv3 only report is used. ↩

  2. The querier with the lowest IP address on each LAN is elected. Usually the gateway or multicast router. ↩

  3. Proxy queries use source IP address 0.0.0.0, which is reserved and must never take part in the IGMP querier election process, as clearly stated in RFC 4541. ↩