WeOSIGMP/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:
- treat multicast traffic as broadcast – always flood on all ports
- flood until subscribers appear, then limiting specific flows
- (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 + QRIWhere 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/2Where 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
Multicast Snooping Boundary
The device supports the ability to specify specific ports as a boundary for IGMP/MLD snooping, referred to as a multicast snooping boundary. This is a setting that is applied on a per-port basis and can be used to limit the scope of IGMP/MLD snooping to a specific set of ports.
When a port is specified to act as a multicast snooping boundary, it will
drop any IGMP/MLD control traffic on ingress, egress, or both, controlled
by the multicast-snooping-boundary-direction setting. The control traffic
that will be dropped includes IGMP/MLD queries, reports, and leave messages.
A few examples where the multicast snooping boundary can be useful:
- Define multiple IGMP/MLD snooping domains in the same layer 2 network domain, i.e., to have multiple queriers in the same layer 2 network.
- Isolate sections of the network where IGMP/MLD snooping is not desired.
Note
The multicast snooping boundary setting only affects IGMP/MLD control traffic. Regular multicast traffic can still pass through the port.
Configuration
The configuration of the multicast snooping boundary is done in the IP configuration context:
example:/#> configure example:/config/#> ip example:/config/ip/#>
[no] multicast-snooping-boundary [PORTS]-
Specify port(s) to act as a boundary for IGMP/MLD signaling.
Using this option it is possible to define IGMP/MLD boundaries in the same layer 2 domain. This can allow for multiple queriers to exist at the same time, or to limit the scope of IGMP/MLD snooping to a specific set of ports.
When a port is defined as a boundary, it will by default drop IGMP/MLD control traffic on both ingress and egress. This means that the port will not forward IGMP/MLD queries, reports or leave messages.
If for any reason IGMP/MLD control traffic should only be dropped on either ingress or egress, this can be specified using the
multicast-snooping-boundary-directionoption.Note
When a port is defined as a boundary, it is still possible for regular multicast traffic to pass through the port. The boundary setting only affects IGMP/MLD control traffic.
Default: Disabled
Example Enable the multicast snooping boundary for a single port:
example:/config/ip/#> multicast-snooping-boundary eth1
Enable the multicast snooping boundary for a range of ports:
example:/config/ip/#> multicast-snooping-boundary eth1, eth2, eth3
Enable the multicast snooping boundary for a range of ports:
example:/config/ip/#> multicast-snooping-boundary eth1..eth3
Enable the multicast snooping boundary for all ports:
example:/config/ip/#> multicast-snooping-boundary all
All the above examples can be prefixed with the
nokeyword to disable the multicast snooping boundary for the specified ports in the same way.no- Disable the multicast snooping boundary for all ports or any specific port(s).
PORTS-
Specific physical port or range of ports. The port(s) can be specified as a single port, a comma separated list of ports, or a range of ports using a
...It is also possible to specify the
allkeyword to apply the setting to all ports.
[no] multicast-snooping-boundary-direction [ingress][egress]-
Specify the direction of the boundary for IGMP/MLD signaling.
This option will specify which directions, either ingress, egress or both, that the boundary will drop IGMP/MLD control traffic.
Note
The
multicast-snooping-boundary-directionsetting is only applicable when themulticast-snooping-boundarysetting is enabled for at least one port.Default: Both Ingress and Egress
Example Specify the boundary to drop IGMP/MLD control traffic on ingress only:
example:/config/ip/#> multicast-snooping-boundary-direction ingress
Specify the boundary to drop IGMP/MLD control traffic on egress only:
example:/config/ip/#> multicast-snooping-boundary-direction egress
Specify the boundary to drop IGMP/MLD control traffic on both ingress and egress:
example:/config/ip/#> multicast-snooping-boundary-direction ingress egress
The
nokeyword can be prefixed to the command to disable the setting.no-
Disable the multicast snooping boundary direction setting for the specified direction.
Note
At least one direction must always be enabled.
ingress- Drop IGMP/MLD control traffic on ingress, i.e., traffic entering the switch.
egress- Drop IGMP/MLD control traffic on egress, i.e., traffic leaving the switch.
Example: Basic scenario
The following example just intend to illustrate the basic usage of the multicast snooping boundary. Consider the simplified network topology in Figure 5 below:
.--.-. IGMP Domain 1 : IGMP Domain 2 .--.-.
( ( )__ : ( ( )__
(_, \ ) ,_) : (_, \ ) ,_)
'-'--`--' : '-'--`--'
| : |
| 10.0.0.0/24 : 10.0.0.0/24 |
| : |
.----+----. .---------. : .---------. .----+----.
| | eth2| |eth1 : eth1| |eth2 | |
| S1 +-----------+ S2 +-----------+ S3 +-----------+ S4 |
| | | | : | | | |
'---------' '---------' : '---------' '---------'
10.0.0.10 10.0.0.11 : 10.0.0.21 10.0.0.20
:
:
Figure 5: Basic network topology, depicting four switches (S1-S4) connected together to a larger layer 2 network. Where a multicast snooping boundary is configured on ports eth1 on switches S2 and S3. In this scenario it results in two separate IGMP domains, IGMP Domain 1 and IGMP Domain 2, located on the same layer 2 network.
Given the above example, we assume that everything is already configured and working as expected, except for the multicast snooping boundary. Before the multicast snooping boundary is configured, the switch S1 should be the elected IGMP querier for the entire layer 2 network, since it has the lowest IP address. In this case, if we check the reported querier on switch S3, for example, it should be reporting S1 (10.0.0.10) as the IGMP querier:
S3:/#> show ip igmp S3:/#> show ip igmp Multicast Overview Query Interval : 12 sec Robustness Value : 2 Router Timeout : 29 Fast Leave Ports : Router Ports : eth1 Flood Ports : eth0, eth1, eth2, eth3, eth4, eth5, eth6, eth7 Interface State Querier Timeout Ver vlan1 Up 10.0.0.10 23 3 VID Multicast MAC Multicast Group Ports 1 01:00:5E:7F:FF:FA 239.255.255.250 br0, eth1, eth2
In order to create two separate IGMP domains, IGMP Domain 1 and IGMP Domain 2, we will configure both switch S2 and S3 to have a multicast snooping boundary enabled on port eth1:
Note
It could be enough to configure the boundary on only one of the switches, but since we control both switches in this example, we will configure both of them.
S2:/#> configure S2:/config/#> ip S2:/config/ip/#> multicast-snooping-boundary eth1 S2:/config/ip/#> leave S2:/#>
S3:/#> configure S3:/config/#> ip S3:/config/ip/#> multicast-snooping-boundary eth1 S3:/config/ip/#> leave S3:/#>
If we now check the reported querier on switch S3, it should no longer report S1 (10.0.0.10) as the IGMP querier, but it should now report switch S4 (10.0.0.20) as the IGMP querier:
Note
It may be necessary to wait up to the entire multicast router timeout period before the querier election process is completed.
S3:/#> show ip igmp S3:/#> show ip igmp Multicast Overview Query Interval : 12 sec Robustness Value : 2 Router Timeout : 29 Fast Leave Ports : Router Ports : eth2 Flood Ports : eth0, eth1, eth2, eth3, eth4, eth5, eth6, eth7 Interface State Querier Timeout Ver vlan1 Up 10.0.0.20 23 3 VID Multicast MAC Multicast Group Ports 1 01:00:5E:7F:FF:FA 239.255.255.250 br0, eth1, eth2
However, if we check the reported querier on switch S2, it should still report S1 (10.0.0.10) as the IGMP querier:
S2:/#> show ip igmp S2:/#> show ip igmp Multicast Overview Query Interval : 12 sec Robustness Value : 2 Router Timeout : 29 Fast Leave Ports : Router Ports : eth2 Flood Ports : eth0, eth1, eth2, eth3, eth4, eth5, eth6, eth7 Interface State Querier Timeout Ver vlan1 Up 10.0.0.10 18 3 VID Multicast MAC Multicast Group Ports 1 01:00:5E:7F:FF:FA 239.255.255.250 br0, eth2, eth1
Effectively, we have now created two separate IGMP domains: IGMP Domain 1 and IGMP Domain 2, located on the same layer 2 network. All the switches to the “left” of and including S2 will belong to IGMP Domain 1, while all the switches to the “right” of and including S3 will belong to IGMP Domain 2. Where switch S1 is the IGMP querier for IGMP Domain 1, and switch S4 is the IGMP querier for IGMP Domain 2.
Note
This example used IGMP snooping to illustrate the concept of a multicast snooping boundary. However, the same principles apply to MLD snooping and MLD snooping boundaries. It is the same setting.
In addition to query frames being dropped on the boundary port, the boundary port will also not forward any IGMP/MLD reports or leave messages. So, if we have a specific group that we want to be able to traverse the boundary port, static FDB entries could be used.
Note
The specific group we want to be able to traverse the boundary must also reach that device in that domain. Depending on the placement of the querier, static FDB entries may be needed on several devices in order to reach the boundary device.
Alternatively, multicast router ports could be configured in the direction leading to the boundary device. However, this could result in more multicast traffic being forwarded to the boundary device than intended.
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.
-
In IGMPv2 the terms are join and leave, with the collective name IGMP report. In IGMPv3 only report is used. ↩
-
The querier with the lowest IP address on each LAN is elected. Usually the gateway or multicast router. ↩
-
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. ↩