Understanding MLD Snooping
Multicast Listener Discovery (MLD) snooping constrains the flooding of IPv6 multicast traffic on VLANs. When MLD snooping is enabled on a VLAN, a Juniper Networks device examines MLD messages between hosts and multicast routers and learns which hosts are interested in receiving traffic for a multicast group. On the basis of what it learns, the device then forwards multicast traffic only to those interfaces in the VLAN that are connected to interested receivers instead of flooding the traffic to all interfaces.
MLD snooping supports MLD version 1 (MLDv1) and MLDv2. For details on MLDv1 and MLDv2, see the following standards:
MLDv1—See RFC 2710, Multicast Listener Discovery (MLD) for IPv6.
MLDv2—See RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6.
Benefits of MLD Snooping
Optimized bandwidth utilization—The main benefit of MLD snooping is to reduce flooding of packets. IPv6 multicast data is selectively forwarded to a list of ports that want to receive the data, instead of being flooded to all ports in a VLAN.
Improved security—Denial of service attacks from unknown sources are prevented.
How MLD Snooping Works
By default, the device floods Layer 2 multicast traffic on all of the interfaces belonging to that VLAN on the device, except for the interface that is the source of the multicast traffic. This behavior can consume significant amounts of bandwidth.
You can enable MLD snooping to avoid this flooding. When you enable MLD snooping, the device monitors MLD messages between receivers (hosts) and multicast routers and uses the content of the messages to build an IPv6 multicast forwarding table—a database of IPv6 multicast groups and the interfaces that are connected to the interested members of each group. When the device receives multicast traffic for a multicast group, it uses the forwarding table to forward the traffic only to interfaces that are connected to receivers that belong to the multicast group.
Figure 1 shows an example of multicast traffic flow with MLD snooping enabled.
MLD Message Types
Multicast routers use MLD to learn, for each of their attached physical networks, which groups have interested listeners. In any given subnet, one multicast router is elected to act as an MLD querier. The MLD querier sends out the following types of queries to hosts:
General query—Asks whether any host is listening to any group.
Group-specific query—Asks whether any host is listening to a specific multicast group. This query is sent in response to a host leaving the multicast group and allows the router to quickly determine if any remaining hosts are interested in the group.
Group-and-source-specific query—(MLD version 2 only) Asks whether any host is listening to group multicast traffic from a specific multicast source. This query is sent in response to a host indicating that it is no longer interested in receiving group multicast traffic from the multicast source and allows the router to quickly determine any remaining hosts are interested in receiving group multicast traffic from that source.
Hosts that are multicast listeners send the following kinds of messages:
Membership report—Indicates that the host wants to join a particular multicast group.
Leave report—Indicates that the host wants to leave a particular multicast group.
Only MLDv1 hosts use two different kinds of reports to indicate whether they want to join or leave a group. MLDv2 hosts send only one kind of report, the contents of which indicate whether they want to join or leave a group. However, for simplicity’s sake, the MLD snooping documentation uses the term membership report for a report that indicates that a host wants to join a group and uses the term leave report for a report that indicates a host wants to leave a group.
How Hosts Join and Leave Multicast Groups
Hosts can join multicast groups in either of two ways:
By sending an unsolicited membership report that specifies the multicast group that the host is attempting to join.
By sending a membership report in response to a query from a multicast router.
A multicast router continues to forward multicast traffic to an interface provided that at least one host on that interface responds to the periodic general queries indicating its membership. For a host to remain a member of a multicast group, therefore, it must continue to respond to the periodic general queries.
Hosts can leave multicast groups in either of two ways:
By not responding to periodic queries within a set interval of time. This results in what is known as a “silent leave.”
By sending a leave report.
If a host is connected to the device through a hub, the host does not automatically leave the multicast group if it disconnects from the hub. The host remains a member of the group until group membership times out and a silent leave occurs. If another host connects to the hub port before the silent leave occurs, the new host might receive the group multicast traffic until the silent leave, even though it never sent an membership report.
Support for MLDv2 Multicast Sources
In MLDv2, a host can send a membership report that includes a list of source addresses. When the host sends a membership report in INCLUDE mode, the host is interested in group multicast traffic only from those sources in the source address list. If host sends a membership report in EXCLUDE mode, the host is interested in group multicast traffic from any source except the sources in the source address list. A host can also send an EXCLUDE report in which the source-list parameter is empty, which is known as an EXCLUDE NULL report. An EXCLUDE NULL report indicates that the host wants to join the multicast group and receive packets from all sources.
Devices that support MLD snooping support MLDv2 membership reports that are in INCLUDE and EXCLUDE mode. However, SRX Series Firewalls, QFX Series switches, and EX Series switches running MLD snooping, except for EX9200 switches, do not support forwarding on a per-source basis. Instead, the device consolidates all INCLUDE and EXCLUDE mode reports it receives on a VLAN for a specified group into a single route that includes all multicast sources for that group, with the next hop being all interfaces that have interested receivers for the group. As a result, interested receivers on the VLAN can receive traffic from a source that they did not include in their INCLUDE report or from a source they excluded in their EXCLUDE report. For example, if Host 1 wants traffic for group G from Source A and Host 2 wants traffic for group G from Source B, they both receive traffic for group G regardless of whether A or B sends the traffic.
MLD Snooping and Forwarding Interfaces
To determine how to forward multicast traffic, the device with MLD snooping enabled maintains information about the following interfaces in its multicast forwarding table:
Multicast-router interfaces—These interfaces lead toward multicast routers or MLD queriers.
Group-member interfaces—These interfaces lead toward hosts that are members of multicast groups.
The device learns about these interfaces by monitoring MLD traffic. If an interface receives MLD queries, the device adds the interface to its multicast forwarding table as a multicast-router interface. If an interface receives membership reports for a multicast group, the device adds the interface to its multicast forwarding table as a group-member interface.
Table entries for interfaces that the device learns about are subject to aging. For example, if a learned multicast-router interface does not receive MLD queries within a certain interval, the device removes the entry for that interface from its multicast forwarding table.
For the device to learn multicast-router interfaces and group-member interfaces, an MLD querier must exist in the network. For the device itself to function as an MLD querier, MLD must be enabled on the device.
You can statically configure an interface to be a multicast-router interface or a group-member interface. The device adds a static interface to its multicast forwarding table without having to learn about the interface, and the entry in the table is not subject to aging. You can have a mix of statically configured and dynamically learned interfaces on the device.
General Forwarding Rules
Multicast traffic received on the device interface in a VLAN on which MLD snooping is enabled is forwarded according to the following rules.
MLD protocol traffic is forwarded as follows:
MLD general queries received on a multicast-router interface are forwarded to all other interfaces in the VLAN.
MLD group-specific queries received on a multicast-router interface are forwarded to only those interfaces in the VLAN that are members of the group.
MLD reports received on a host interface are forwarded to multicast-router interfaces in the same VLAN, but not to the other host interfaces in the VLAN.
Multicast traffic that is not MLD protocol traffic is forwarded as follows:
An unregistered multicast packet—that is, a packet for a group that has no current members—is forwarded to all multicast-router interfaces in the VLAN.
A registered multicast packet is forwarded only to those host interfaces in the VLAN that are members of the multicast group and to all multicast-router interfaces in the VLAN.
When IGMP and MLD snooping are both enabled on the same VLAN, multicast-router interfaces are created as part of IGMP and MLD snooping configuration. Unregistered multicast traffic is not blocked and can be passed through router interfaces, so due to hardware limitations, unregistered IPv4 multicast traffic might be passed through the multicast router interfaces created as part of MLD snooping configuration, and unregistered IPv6 multicast traffic might pass through multicast-router interfaces created as part of IGMP snooping configuration.
Examples of MLD Snooping Multicast Forwarding
The following examples are provided to illustrate how MLD snooping forwards multicast traffic in different topologies:
- Scenario 1: Device Forwarding Multicast Traffic to a Multicast Router and Hosts
- Scenario 2: Device Forwarding Multicast Traffic to Another Device
- Scenario 3: Device Connected to Hosts Only (No MLD Querier)
- Scenario 4: Layer 2/Layer 3 Device Forwarding Multicast Traffic Between VLANs
Scenario 1: Device Forwarding Multicast Traffic to a Multicast Router and Hosts
In the topology shown in Figure 2, the device acting as a Layer 2 device receives multicast traffic belonging to multicast group ff1e::2010 from Source A, which is connected to the multicast router. It also receives multicast traffic belonging to multicast group ff15::2 from Source B, which is connected directly to the device. All interfaces on the device belong to the same VLAN.
Because the device receives MLD queries from the multicast router on interface P1, MLD snooping learns that interface P1 is a multicast-router interface and adds the interface to its multicast forwarding table. It forwards any MLD general queries it receives on this interface to all host interfaces on the device, and, in turn, forwards membership reports it receives from hosts to the multicast-router interface.
In the example, Hosts A and C have responded to the general queries with membership reports for group ff1e::2010. MLD snooping adds interfaces P2 and P4 to its multicast forwarding table as member interfaces for group ff1e::2010. It forwards the group multicast traffic received from Source A to Hosts A and C, but not to Hosts B and D.
Host B has responded to the general queries with a membership report for group ff15::2. The device adds interface P3 to its multicast forwarding table as a member interface for group ff15::2 and forwards multicast traffic it receives from Source B to Host B. The device also forwards the multicast traffic it receives from Source B to the multicast-router interface P1.
Scenario 2: Device Forwarding Multicast Traffic to Another Device
In the topology show in Figure 3, a multicast source is connected to Device A. Device A in turn is connected to another device, Device B. Hosts on both Device A and B are potential members of the multicast group. Both devices are acting as Layer 2 devices, and all interfaces on the devices are members of the same VLAN.
Device A receives MLD queries from the multicast router on interface P1, making interface P1 a multicast-router interface for Device A. Device A forwards all general queries it receives on this interface to the other interfaces on the device, including the interface connecting Device B. Because Device B receives the forwarded MLD queries on interface P6, P6 is the multicast-router interface for Device B. Device B forwards the membership report it receives from Host C to Device A through its multicast-router interface. Device A forwards the membership report to its multicast-router interface, includes interface P5 in its multicast forwarding table as a group-member interface, and forwards multicast traffic from the source to Device B.
In certain implementations, you might have to configure P6 on Device B as a static multicast-router interface to avoid a delay in a host receiving multicast traffic. For example, if Device B receives unsolicited membership reports from its hosts before it learns which interface is its multicast-router interface, it does not forward those reports to Device A. If Device A then receives multicast traffic, it does not forward the traffic to Device B, because it has not received any membership reports on interface P5. This issue will resolve when the multicast router sends out its next general query; however, it can cause a delay in the host receiving multicast traffic. You can statically configure interface P6 as a multicast-router interface to solve this issue.
Scenario 3: Device Connected to Hosts Only (No MLD Querier)
In the topology shown in Figure 4, the device is connected to a multicast source and to hosts. There is no multicast router in this topology—hence there is no MLD querier. Without an MLD querier to respond to, a host does not send periodic membership reports. As a result, even if the host sends an unsolicited membership report to join a multicast group, its membership in the multicast group will time out.
For MLD snooping to work correctly in this network so that the device forwards multicast traffic to Hosts A and C only, you can either:
Configure interfaces P2 and P4 as static group-member interfaces.
Configure a routed VLAN interface (RVI), also referred to as an integrated routing and bridging (IRB) interface, on the VLAN and enable MLD on it. In this case, the device itself acts as an MLD querier, and the hosts can dynamically join the multicast group and refresh their group membership by responding to the queries.
Scenario 4: Layer 2/Layer 3 Device Forwarding Multicast Traffic Between VLANs
In the topology shown in Figure 5, a multicast source, Multicast Router A, and Hosts A and B are connected to the device and are in VLAN 10. Multicast Router B and Hosts C and D are also connected to the device and are in VLAN 20.
In a pure Layer 2 environment, traffic is not forwarded between VLANs. For Host C to receive the multicast traffic from the source on VLAN 10, RVIs (or IRB interfaces) must be created on VLAN 10 and VLAN 20 to permit routing of the multicast traffic between the VLANs.
