IGMP (Internet Group Management Protocol) and MLD (Multicast Listener Discovery) snooping allow the bridge to listen to IGMP/MLD communication and make forwarding decisions for multicast traffic based on the received information. By default, bridges are flooding multicast traffic to all bridge ports just like broadcast traffic, which might not always be the best scenario (e.g. for multicast video traffic). The IGMP/MLD snooping tries to solve the problem by forwarding the multicast traffic only to ports where clients are subscribed to, see an IGMP/MLD network concept below. RouterOS bridge is able to process IGMP v1/v2/v3 and MLD v1/v2 packets. The implemented bridge IGMP/MLD snooping is based on RFC4541, and IGMP/MLD protocols are specified on RFC1112 (IGMPv1) RFC2236 (IGMPv2), RFC3376 (IGMPv3), RFC2710 (MLDv1), RFC3810 (MLDv2).
Source-specific multicast forwarding is not supported for IGMP v3 and MLD v2.
The bridge will process the IGMP/MLD messages only when
igmp-snooping is enabled. Additionally, the bridge should have an active IPv6 address in order to process MLD packets. At first, the bridge does not restrict the multicast traffic and all multicast packets get flooded. Once IGMP/MLD querier is detected by receiving an IGMP/MLD query message (the query message can be received by an external multicast router or locally by bridge interface with enabled
multicast-querier), only then the bridge will start to restrict unknown IP multicast traffic and forward the known multicast from the multicast database (MDB). The IGMP and MLD querier detection is independent, which means that detecting only IGMP querier will not affect IPv6 multicast forwarding and vice versa. The querier detection also does not restrict the forwarding of non-IP and link-local multicast groups, like 220.127.116.11/24 and ff02::1.
CRS3xx series devices with Marvell-98DX3236, Marvell-98DX224S or Marvell-98DX226S switch chip are not able to distinguish non-IP/IPv4/IPv6 multicast packets once IGMP or MLD querier is detected. It means that the switch will stop forwarding all unknown non-IP/IPv4/IPv6 multicast traffic when the querier is detected. This does not apply to certain link-local multicast address ranges, like 18.104.22.168/24 or ff02::1.
This section describes the IGMP and MLD snooping bridge configuration options.
|igmp-snooping (yes | no; Default: no)||Enables IGMP and MLD snooping.|
|igmp-version (2 | 3; Default: 2)||Selects the IGMP version in which IGMP membership queries will be generated when the bridge interface is acting as an IGMP querier. This property only has an effect when |
|last-member-interval (time; Default: 1s)|
When the last client on the bridge port unsubscribes to a multicast group and the bridge is acting as an active querier, the bridge will send group-specific IGMP/MLD query, to make sure that no other client is still subscribed. The setting changes the response time for these queries. In case no membership reports are received in a certain time period (
If the bridge port is configured with fast-leave, the multicast group is removed right away without sending any queries.
This property only has an effect when
|last-member-query-count (integer: 0..4294967295; Default: 2)||How many times should |
|membership-interval (time; Default: 4m20s)||The amount of time after an entry in the Multicast Database (MDB) is removed if no IGMP/MLD membership reports are received on a bridge port. This property only has an effect when |
|mld-version (1 | 2; Default: 1)||Selects the MLD version in which MLD membership queries will be generated, when the bridge interface is acting as an MLD querier. This property only has an effect when the bridge has an active IPv6 address, |
|multicast-querier (yes | no; Default: no)|
Multicast querier generates periodic IGMP/MLD general membership queries to which all IGMP/MLD capable devices respond with an IGMP/MLD membership report, usually a PIM (multicast) router or IGMP proxy generates these queries.
By using this property you can make an IGMP/MLD snooping enabled bridge to generate IGMP/MLD general membership queries. This property should be used whenever there is no active querier (PIM router or IGMP proxy) in a Layer2 network. Without a multicast querier in a Layer2 network, the Multicast Database (MDB) is not being updated, the learned entries will timeout and IGMP/MLD snooping will not function properly.
Only untagged IGMP/MLD general membership queries are generated, IGMP queries are sent with IPv4 0.0.0.0 source address, MLD queries are sent with IPv6 link-local address of the bridge interface. The bridge will not send queries if an external IGMP/MLD querier is detected (see the monitoring values
This property only has an effect when
|multicast-router (disabled | permanent | temporary-query; Default: temporary-query)||A multicast router port is a port where a multicast router or querier is connected. On this port, unregistered multicast streams and IGMP/MLD membership reports will be sent. This setting changes the state of the multicast router for a bridge interface itself. This property can be used to send IGMP/MLD membership reports to the bridge interface for further multicast routing or proxying. This property only has an effect when |
|querier-interval (time; Default: 4m15s)||Changes the timeout period for detected querier and multicast-router ports. This property only has an effect when |
|query-interval (time; Default: 2m5s)||Changes the interval on how often IGMP/MLD general membership queries are sent out when the bridge interface is acting as an IGMP/MLD querier. The interval takes place when the last startup query is sent. This property only has an effect when |
|query-response-interval (time; Default: 10s)||The setting changes the response time for general IGMP/MLD queries when the bridge is active as an IGMP/MLD querier. This property only has an effect when |
|startup-query-count (integer: 0..4294967295; Default: 2)||Specifies how many times general IGMP/MLD queries must be sent when bridge interface is enabled or active querier timeouts. This property only has an effect when |
|startup-query-interval (time; Default: 31s250ms)||Specifies the interval between startup general IGMP/MLD queries. This property only has an effect when |
/interface bridge port
|fast-leave (yes | no; Default: no)||Enables IGMP/MLD fast leave feature on the bridge port. The bridge will stop forwarding multicast traffic to a bridge port when an IGMP/MLD leave message is received. This property only has an effect when |
|multicast-router (disabled | permanent | temporary-query; Default: temporary-query)||A multicast router port is a port where a multicast router or querier is connected. On this port, unregistered multicast streams and IGMP/MLD membership reports will be sent. This setting changes the state of the multicast router for bridge ports. This property can be used to send IGMP/MLD membership reports to certain bridge ports for further multicast routing or proxying. This property only has an effect when |
|unknown-multicast-flood (yes | no; Default: yes)|
Changes the multicast flood option on bridge port, only controls the egress traffic. When enabled, the bridge allows flooding multicast packets to the specified bridge port, but when disabled, the bridge restricts multicast traffic from being flooded to the specified bridge port. The setting affects all multicast traffic, this includes non-IP, IPv4, IPv6 and the link-local multicast ranges (e.g. 22.214.171.124/24 and ff02::1).
Note that when
When using this setting together with
This section describes the IGMP/MLD snooping bridge monitoring and troubleshooting options.
To monitor learned multicast database (MDB) entries, use the
/interface bridge mdb
|bridge (read-only: name)||Shows the bridge interface the entry belongs to.|
|group (read-only: ipv4 | ipv6 address)||Shows a multicast group address.|
|ports (read-only: name)||Shows the bridge ports which are subscribed to the certain multicast group.|
|vid (read-only: integer)||Shows the VLAN ID for the multicast group, only applies when|
[admin@MikroTik] /interface bridge mdb print GROUP VID PORTS BRIDGE 126.96.36.199 10 ether3 bridge1 188.8.131.52 10 ether3 bridge1 ff1e::2010 10 ether3 bridge1 ff1e::2011 10 ether3 bridge1
To monitor the current status of a bridge interface, use the
|igmp-querier (none | interface & IPv4 address)||Shows a bridge port and source IP address from the detected IGMP querier. Only shows detected external IGMP querier, local bridge IGMP querier (including IGMP proxy and PIM) will not be displayed. Monitoring value appears only when |
|mld-querier (none | interface & IPv6 address)||Shows a bridge port and source IPv6 address from the detected MLD querier. Only shows detected external MLD querier, local bridge MLD querier will not be displayed. Monitoring value appears only when |
|multicast-router (yes | no)||Shows if a multicast router is detected on the bridge interface. Monitoring value appears only when |
[admin@MikroTik] /interface bridge monitor bridge1 state: enabled current-mac-address: 64:D1:54:C7:3A:59 root-bridge: yes root-bridge-id: 0x8000.64:D1:54:C7:3A:59 root-path-cost: 0 root-port: none port-count: 3 designated-port-count: 3 fast-forward: no multicast-router: no igmp-querier: ether2 192.168.10.10 mld-querier: ether2 fe80::e68d:8cff:fe39:3824
To monitor the current status of bridge ports, use the
/interface bridge port
|multicast-router (yes | no)||Shows if a multicast router is detected on the port. Monitoring value appears only when |
[admin@MikroTik] > /interface bridge port monitor [find] interface: ether2 ether3 ether4 status: in-bridge in-bridge in-bridge port-number: 1 2 3 role: designated-port designated-port designated-port edge-port: no yes yes edge-port-discovery: yes yes yes point-to-point-port: yes yes yes external-fdb: no no no sending-rstp: yes yes yes learning: yes yes yes forwarding: yes yes yes multicast-router: yes no no hw-offload-group: switch1 switch1 switch1
Below are described the most common configuration examples. Some examples are using a bridge with VLAN filtering, so make sure to understand the filtering principles first - bridge VLAN filtering, bridge VLAN table.
The first example consists only of a single bridge, a single multicast source device, and a couple of multicast client devices. See a network scheme below.
The second example adds some complexity. There are two IGMP snooping switches and we need to isolate the multicast traffic on a different VLAN. See a network scheme below.