The Multicast Listener Discovery protocol (MLD) is used by an IPv6 router to discover the presence of multicast listeners on the directly attached subnets. Multicast listeners are nodes wishing to receive IPv6 multicast packets.

Through MLD, the router can learn whether there are any IPv6 multicast listeners on the directly connected subnets, put corresponding records in the database, and maintain timers related to IPv6 multicast addresses.

Routers running MLD use an IPv6 unicast link-local address as the source address to send MLD messages. MLD messages are Internet Control Message Protocol for IPv6 (ICMPv6) messages. All MLD messages are confined to the local subnet, with a hop count of 1.

MLD Versions

So far, two MLD versions are available:

l MLDv1 (defined in RFC 2710), which is derived from IGMPv2.

l MLDv2 (defined in RFC 3810), which is derived from IGMPv3.

All MLD versions support the Any-Source Multicast (ASM) model. In addition, MLDv2 can be directly deployed to implement the Source-Specific Multicast (SSM) model, while MLDv1 needs to work with the MLD SSM mapping function to implement SSM service.

For more information about the ASM and SSM models, see Multicast Overview in the IP Multicast Volume.

How MLDv1 Works

MLDv1 implements IPv6 multicast listener management based on the query/response mechanism.

MLD querier election

Of multiple IPv6 multicast routers on the same subnet, all the routers can hear MLD listener report messages (often referred to as reports) from hosts, but only one router is needed for sending MLD query messages (often referred to as queries). So, a querier election mechanism is required to determine which router will act as the MLD querier on the subnet.

1) Initially, every MLD router assumes itself as the querier and sends MLD general query messages (often referred to as general queries) to all hosts and routers on the local subnet (the destination address is FF02::1).

2) Upon hearing a general query, every MLD router compares the source IPv6 address of the query message with its own interface address. After comparison, the router with the lowest IPv6 address wins the querier election and all other routers become non-queriers.

3) All the non-queriers start a timer, known as “other querier present timer”. If a router receives an MLD query from the querier before the timer expires, it resets this timer; otherwise, it assumes the querier to have timed out and initiates a new querier election process.

Joining an IPv6 multicast group

Figure 1-1 MLD queries and reports

Assume that Host B and Host C are expected to receive IPv6 multicast data addressed to IPv6 multicast group G1, while Host A is expected to receive IPv6 multicast data addressed to G2, as shown in Figure 1-1. The following describes how the hosts join the IPv6 multicast groups and the MLD querier (Router B in the figure) maintains the IPv6 multicast group memberships:

1) The hosts send unsolicited MLD reports to the addresses of the IPv6 multicast groups that they want to join, without having to wait for the MLD queries from the MLD querier.

2) The MLD querier periodically multicasts MLD queries (with the destination address of FF02::1) to all hosts and routers on the local subnet.

3) Upon receiving a query message, Host B or Host C (the delay timer of whichever expires first) sends an MLD report to the IPv6 multicast group address of G1, to announce its membership for G1. Assume it is Host B that sends the report message. Upon hearing the report from Host B, Host C, which is on the same subnet with Host B, suppresses its own report for G1, because the MLD routers (Router A and Router B) already know that at least one host on the local subnet is interested in G1. This mechanism, known as MLD report suppression applied on hosts, helps reduce traffic on the local subnet.

4) At the same time, because Host A is interested in G2, it sends a report to the IPv6 multicast group address of G2.

5) Through the above-mentioned query/report process, the MLD routers learn that members of G1 and G2 are attached to the local subnet, and the IPv6 multicast routing protocol (IPv6 PIM for example) running on the routers generates (*, G1) and (*, G2) multicast forwarding entries, which will be the basis for subsequent IPv6 multicast forwarding, where * represents any IPv6 multicast source.

6) When the IPv6 multicast data addressed to G1 or G2 reaches an MLD router, because the (*, G1) and (*, G2) multicast forwarding entries exist on the MLD router, the router forwards the IPv6 multicast data to the local subnet, and then the receivers on the subnet receive the data.

Leaving an IPv6 multicast group

When a host leaves a multicast group:

1) This host sends an MLD done message to all IPv6 multicast routers (the destination address is FF02::2) on the local subnet.

2) Upon receiving the MLD done message, the querier sends a configurable number of multicast-address-specific queries to the group being left. The destination address field and group address field of the message are both filled with the address of the IPv6 multicast group being queried.

3) One of the remaining members, if any on the subnet, of the group being queried should send a report within the time of the maximum response delay set in the query messages.

4) If the querier receives a report for the group within the maximum response delay time, it will maintain the memberships of the IPv6 multicast group; otherwise, the querier will assume that no hosts on the subnet are still interested in IPv6 multicast traffic addressed to that group and will stop maintaining the memberships of the group.

How MLDv2 Works

Compared with MLDv1, MLDv2 provides the following new features:

IPv6 multicast group filtering

MLDv2 has introduced IPv6 multicast source filtering modes (Include and Exclude), so that a host not only can join a designated IPv6 multicast group but also can explicitly specify to receive or reject IPv6 multicast data from a designated IPv6 multicast source. When a host joins an IPv6 multicast group G:

l If it needs to receive IPv6 multicast data from specific IPv6 multicast sources like S1, S2, …, it sends a report with the Filter-Mode denoted as “Include Sources (S1, S2, ……).

l If it needs to reject IPv6 multicast data from specific IPv6 multicast sources like S1, S2, …, it sends a report with the Filter-Mode denoted as “Exclude Sources (S1, S2, ……).

As shown in Figure 1-2, the network comprises two IPv6 multicast sources, Source 1 (S1) and Source 2 (S2), both of which can send IPv6 multicast data to IPv6 multicast group G. Host B is interested only in the IPv6 multicast data that Source 1 sends to G but not in the data from Source 2.

Figure 1-2 Flow paths of source-and-group-specific multicast traffic

In the case of MLDv1, Host B cannot select IPv6 multicast sources when it joins IPv6 multicast group G. Therefore, IPv6 multicast streams from both Source 1 and Source 2 will flow to Host B whether it needs them or not.

When MLDv2 is running on the hosts and routers, Host B can explicitly express its interest in the IPv6 multicast data Source 1 sends to G (denoted as (S1, G)), rather than the IPv6 multicast data Source 2 sends to G (denoted as (S2, G)). Thus, only IPv6 multicast data from Source 1 will be delivered to Host B.

MLD state

A multicast router running MLDv2 maintains the multicast address state per multicast address per attached subnet. The multicast address state consists of the following:

l Filter mode: The router keeps tracing the Include or Exclude state.

l List of sources: The router keeps tracing the newly added or deleted IPv6 multicast source.

l Timers: Filter timer (the time the router waits before switching to the Include mode after an IPv6 multicast address times out), source timer (for source recording), and so on.

Receiver host state listening

By listening to the state of receiver hosts, a multicast router running MLDv2 records and maintains information of hosts joining the source group on the attached subnet.

MLD Message Types

The following descriptions are based on MLDv2 messages.

MLD query message

An MLD querier learns the multicast listening state of neighbor interfaces by sending MLD query messages. Figure 1-3 shows the format of an MLD query message. The dark blue area in the figure shows the format of an MLDv1 message.

Figure 1-3 Format of MLDv2 query message

Table 1-1 describes the fields in Figure 1-3.

Table 1-1 Description on fields in an MLDv2 query message

Field	Description
Type = 130	Message type. For a query message, this field is set to 130.
Code	Initialized to zero
Checksum	Standard IPv6 checksum
Maximum Response Delay	Maximum response delay allowed before a host sends a report message
Reserved	Reserved field and initialized to zero
Multicast Address	l This field is set to 0 in a general query message. l It is set to a specific IPv6 multicast address in a multicast-address-specific query message or multicast-address-and-source-specific query message.
S	Flag indicating whether a router updates the timer for suppression after receiving a query message.
QRV	Querier’s Robustness Variable
QQIC	Querier’s Query Interval Code
Number of Sources	l This field is set to 0 in a general query message or a multicast-address-specific query message. l This field represents the number of source addresses in a multicast-address-and-source-specific query message
Source Address( i )	IPv6 multicast source address in a multicast-address-specific query message (i = 1, 2, .., n, where n represents the number of multicast source addresses.)

MLD report message

A host sends an MLD report message to report the current multicast listening state Figure 1-4 shows the format of an MLD report message.

Figure 1-4 Format of MLDv2 report message

Table 1-2 describes the fields in Figure 1-4.

Table 1-2 Description on fields in an MLDv2 report message

Field	Description
Type = 143	Message type. For a report message, this field is set to 143.
Reserved	The Reserved fields are set to 0 on transmission and ignored on reception.
Checksum	Standard IPv6 checksum
Number of Multicast Address Records	This field indicates how many IPv6 multicast address records are present in this report message.
Multicast Address Record(i)	This field represents information of each IPv6 multicast address the host listens to on the interface from which the report message is sent, including record type, IPv6 multicast address, and IPv6 multicast source address on the sender (i= 1, 2, ... m, where m represents the number of IPv6 multicast address records).

Introduction to MLD SSM Mapping

The MLD SSM mapping feature allows you to configure static MLD SSM mappings on the last hop router to provide SSM support for receiver hosts running MLDv1. The SSM model assumes that the last hop router is aware of the desired IPv6 multicast sources when receivers join IPv6 multicast groups.

l When a host running MLDv2 joins a multicast group, it can explicitly specify one or more multicast sources in its MLDv2 report.

l A host running MLDv1, however, cannot specify multicast source addresses in its MLDv1 report. In this case, you need to configure the MLD SSM mapping feature to translate the (*, G) information in the MLDv1 report into (G, INCLUDE, (S1, S2...)) information.

Figure 1-5 Network diagram for MLD SSM mapping

As shown in Figure 1-5, on an IPv6 SSM network, Host A and Host B are running MLDv1 and Host C is running MLDv2. To provide SSM service for all the hosts while it is infeasible to run MLDv2 on Host A and Host B, you need to configure the MLD SSM mapping feature on Router A.

With the MLD SSM mapping feature configured, when Router A receives an MLDv1 report, it checks the IPv6 multicast group address G carried in the message:

l If G is not in the IPv6 SSM group range, Router A cannot provide the SSM service but the ASM service.

l If G is in the IPv6 SSM group range but no MLD SSM mappings corresponding to the IPv6 multicast group G have been configured on Router A, Router A cannot provide SSM service and drops the packet.

l If G is in the IPv6 SSM group range, and the MLD SSM mappings have been configured on Router A for multicast group G, Router A translates the (*, G) information in the MLD report into (G, INCLUDE, (S1, S2...)) information based on the configured MLD SSM mappings and provides SSM service accordingly.

l The MLD SSM mapping feature does not process MLDv2 reports.

l For more information about the IPv6 SSM group range, refer to IPv6 PIM Configuration in the IP Multicast Volume.

Protocols and Standards

MLD-related specifications are described in the following documents:

l RFC 2710: Multicast Listener Discovery (MLD) for IPv6

l RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6

Configuration Task List

Task		Remarks
Configuring Basic Functions of MLD	Enabling MLD	Required
	Configuring the MLD Version	Option
	Configuring Static Joining	Optional
	Configuring an IPv6 Multicast Group Filter	Optional
Adjusting MLD Performance	Configuring MLD Message Options	Optional
	Configuring MLD Query and Response Parameters	Optional
	Configuring MLD Fast Leave Processing	Optional
Configuring MLD SSM Mapping	Enabling MLD SSM Mapping	Optional
Configuring MLD SSM Mapping	Configuring MLD SSM Mappings	Optional

l Configurations performed in MLD view are globally effective, while configurations performed in interface view are effective on the current interface only.

l If no configuration is performed in interface view, the global configurations performed in MLD view will apply to that interface. Configurations performed in interface view take precedence over those performed in MLD view.

Configuring Basic Functions of MLD

Configuration Prerequisites

Before configuring the basic functions of MLD, complete the following tasks:

l Configure any IPv6 unicast routing protocol so that all devices in the domain can be interoperable at the network layer.

l Configure IPv6 PIM-DM or IPv6 PIM-SM.

In addition, prepare the following data:

l MLD version

l IPv6 multicast group address and IPv6 multicast source address for static group member configuration

l ACL rule for IPv6 multicast group filtering

Enabling MLD

Enable MLD on the interface on which IPv6 multicast group memberships are to be created and maintained.

Follow these steps to enable MLD:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enable IPv6 multicast routing	multicast ipv6 routing-enable	Required Disable by default
Enter interface view	interface interface-type interface-number	—
Enable MLD	mld enable	Required Disabled by default

For details about the multicast ipv6 routing-table command, see IPv6 Multicast Routing and Forwarding Commands in the IP Multicast Volume.

Configuring the MLD Version

Because MLD message types and formats vary with MLD versions, the same MLD version should be configured for all routers on the same subnet before MLD can work properly.

Configuring an MLD version globally

Follow these steps to configure an MLD version globally:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter MLD view	mld	—
Configure an MLD version globally	version version-number	Optional MLDv1 by default

Configuring an MLD version on an interface

Follow these steps to configure an MLD version on an interface:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter interface view	interface interface-type interface-number	—
Configure an MLD version on the interface	mld version version-number	Optional MLDv1 by default

Configuring Static Joining

After an interface is configured as a static member of an IPv6 multicast group or an IPv6 multicast source and group, it will act as a virtual member of the IPv6 multicast group to receive IPv6 multicast data addressed to that IPv6 multicast group for the purpose of testing IPv6 multicast data forwarding.

Follow these steps to configure a static member of an IPv6 multicast group or an IPv6 multicast source and group:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter interface view	interface interface-type interface-number	—
Configure a static member of an IPv6 multicast group or an IPv6 multicast source and group	mld static-group ipv6-group-address [ source ipv6-source-address ]	Required By default, an interface is not a static member of any IPv6 multicast group or IPv6 multicast source and group.

l Before you can configure an interface of an IPv6 PIM-SM device as a static member of an IPv6 multicast group or an IPv6 multicast source and group, if the interface is IPv6 PIM-SM enabled, it must be an IPv6 PIM-SM DR; if this interface is MLD enabled but not IPv6 PIM-SM enabled, it must be an MLD querier. For more information about IPv6 PIM-SM and a DR, refer to IPv6 PIM Configuration in the IP Multicast Volume.

l As a static member of an IPv6 multicast group or an IPv6 multicast source and group, an interface does not respond to the queries from the MLD querier, nor does it send an unsolicited MLD membership report or a MLD done message when it joins or leaves an IPv6 multicast group or an IPv6 source and group. In other words, the interface will not become a real member of the IPv6 multicast group or the IPv6 multicast and source group.

Configuring an IPv6 Multicast Group Filter

To restrict the hosts on the network attached to an interface from joining certain IPv6 multicast groups, you can set an IPv6 ACL rule on the interface as a packet filter to limit the range of multicast groups that the interface serves.

Follow these steps to configure an IPv6 multicast group filter:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter interface view	interface interface-type interface-number	—
Configure an IPv6 multicast group filter	mld group-policy acl6-number [ version-number ]	Required By default, no IPv6 multicast filter is configured.

Adjusting MLD Performance

For the configuration tasks described in this section,

l Configurations performed in MLD view are globally effective, while configurations performed in interface view are effective on the current interface only.

l If the same function or parameter is configured in both PIM view and interface view, the configuration performed in interface view is given priority, regardless of the configuration sequence.

Configuration Prerequisites

Before adjusting MLD performance, complete the following tasks:

l Configure any IPv6 unicast routing protocol so that all devices in the domain can be interoperable at the network layer.

l Configure basic functions of MLD.

In addition, prepare the following data:

l Startup query interval

l Startup query count

l MLD query interval

l MLD querier robustness variable

l Maximum response delay of MLD general query messages

l MLD last listener query interval

l MLD other querier present interval

Configuring MLD Message Options

MLD queries include multicast-address-specific queries and multicast-address-and-source-specific queries, and IPv6 multicast groups change dynamically, so a device cannot maintain the information for all IPv6 multicast sources and groups. Therefore, a router may receive IPv6 multicast packets addressed to IPv6 multicast groups that have no members on the local subnet. In this case, the Router-Alert option carried in the IPv6 multicast packets is useful for the router to make a decision whether to deliver the IPv6 multicast packets to the upper-layer protocol for processing. For details about the Router-Alert option, refer to RFC 2113.

An MLD message is processed differently depending whether it carries the Router-Alert option in the IPv6 header:

l By default, in consideration of compatibility, the device does not check the Router-Alert option, that is, it processes all received MLD messages. In this case, the device passes MLD messages to the upper layer protocol for processing, no matter whether the MLD messages carry the Router-Alert option or not.

l To enhance the device performance, avoid unnecessary costs, and ensure the protocol security, you can configure the device to discard MLD messages without the Router-Alert option.

Configuring the Router-Alert option for MLD messages globally

Follow these steps to configure the Router-Alert option for MLD messages globally:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter MLD view	mld	—
Configure the interface to discard any MLD message without the Router-Alert option	require-router-alert	Optional By default, the device does not check MLD messages for the Router-Alert option.
Enable the insertion of the Router-Alert option into MLD messages	send-router-alert	Optional By default, MLD messages carry the Router-Alert option.

Configuring the Router-Alert option on an interface

Follow these steps to configure the Router-Alert option on an interface:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter interface view	interface interface-type interface-number	—
Configure the interface to discard any MLD message without the Router-Alert option	mld require-router-alert	Optional By default, the device does not check MLD messages for the Router-Alert option.
Enable the insertion of the Router-Alert option into MLD messages	mld send-router-alert	Optional By default, MLD messages carry the Router-Alert option.

Configuring MLD Query and Response Parameters

On startup, the MLD querier sends “startup query count” MLD general queries at the “startup query interval”, which is 1/4 of the “MLD query interval”.

The MLD querier periodically sends MLD general queries at the “MLD query interval” to determine whether any IPv6 multicast group member exists on the network. You can modify the query interval based on the actual condition of the network.

Upon receiving an MLD done message, the MLD querier sends “last listener query count” MLD multicast-address-specific queries at the “MLD last listener query interval”. MLD is robust to “robustness variable minus 1” packet losses on a network. Therefore, a greater value of the robustness variable makes the MLD querier “more robust”, but results in a longer IPv6 multicast group timeout time.

Upon receiving an MLD query (general query or multicast-address-specific query) message, a host starts a timer for each IPv6 multicast group it has joined. The timer is initialized to a random value in the range of 0 to the maximum response delay (the host obtains the maximum response delay from the Maximum Response Delay field in the MLD query message it received). When the timer value drops to 0, the host sends an MLD membership report message to the corresponding IPv6 multicast group.

Proper setting of the maximum response delay of MLD query messages not only allows hosts to respond to MLD query messages quickly, but also avoids bursts of MLD traffic on the network caused by reports simultaneously sent by a large number of hosts when corresponding timers expire simultaneously.

l For MLD general queries, you can configure the maximum response delay to fill their Maximum Response Delay field.

l For MLD multicast-address-specific query messages, you can configure the last listener query interval to fill their Maximum Response Delay field. That is to say, the maximum response time of MLD general query messages equals the last listener query interval.

When multiple multicast routers exist on the same subnet, the MLD querier is responsible for sending MLD query messages. If a non-querier router receives no MLD query from the querier within the “other querier present interval”, it will assume that the querier has failed and a new querier election process is launched. Otherwise, the non-querier will reset “other querier present timer”.

Configuring MLD query and response parameters globally

Follow these steps to configure MLD query and response parameters globally:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter MLD view	mld	—
Configure the startup query interval	startup-query-interval interval	Optional For the system default, see “Note” below.
Configure the startup query count	startup-query-count value	Optional For the system default, see “Note” below.
Configure the MLD query interval	timer query interval	Optional 125 seconds by default.
Configure the MLD querier robustness variable	robust-count robust-value	Optional 2 times by default
Configure the maximum response delay for MLD general query messages	max-response-time interval	Optional 10 seconds by default
Configure the MLD last listener query interval	last-listener-query-interval interval	Optional 1 second by default
Configure the MLD other querier present interval	timer other-querier-present interval	Optional For the system default, see “Note” below.

Configuring MLD query and response parameters on an interface

Follow these steps to configure MLD query and response parameters on an interface:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter interface view	interface interface-type interface-number	—
Configure the startup query interval	mld startup-query-interval interval	Optional For the system default, see “Note” below.
Configure the startup query count	mld startup-query-count value	Optional For the system default, see “Note” below.
Configure the MLD query interval	mld timer query interval	Optional 125 seconds by default.
Configure the MLD querier robustness variable	mld robust-count robust-value	Optional 2 times by default
Configure the maximum response delay for MLD general query messages	mld max-response-time interval	Optional 10 seconds by default
Configure the MLD last listener query interval	mld last-listener-query-interval interval	Optional 1 second by default
Configure the MLD other querier present interval	mld timer other-querier-present interval	Optional For the system default, see “Note” below.

l If not statically configured, the startup query interval is 1/4 of the “MLD query interval”. By default, the MLD query interval is 125 seconds, so the startup query interval = 125 / 4 = 31.25 (seconds).

l If not statically configured, the startup query count is set to the MLD querier robustness variable. By default, the MLD querier robustness variable is 2, so the startup query count is also 2.

l If not statically configured, the other querier present interval is determined by the formula: Other querier present interval (in seconds) = [ MLD query interval ] times [ MLD querier robustness variable ] plus [ maximum response delay for MLD general query ] divided by two. The default values of these three parameters are 125, 2, and 10 respectively, so the other querier present interval = 125 x 2 + 10 / 2 = 255 (seconds).

l If statically configured, the startup query interval, the startup query count, and the other querier present interval take the configured values.

Make sure that the other querier present interval is greater than the MLD query interval; otherwise the MLD querier may frequently change.

Make sure that the MLD query interval is greater than the maximum response delay for MLD general queries; otherwise, multicast group members may be wrongly removed.

Configuring MLD Fast Leave Processing

MLD fast leave processing is implemented by MLD Snooping. For details, refer to MLD Snooping Configuration in the IP Multicast Volume.

Configuring MLD SSM Mapping

Due to some possible restrictions, some receiver hosts on an SSM network may run MLDv1. To provide SSM service support for these receiver hosts, you need to configure the MLD SSM mapping feature on the last hop router.

Configuration Prerequisites

Before configuring the MLD SSM mapping feature, complete the following tasks:

l Configure any IPv6 unicast routing protocol so that all devices in the domain can be interoperable at the network layer.

l Configure MLD basic functions

Enabling MLD SSM Mapping

Follow these steps to enable the MLD SSM mapping feature:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter interface view	interface interface-type interface-number	—
Enable the MLD SSM mapping feature	mld ssm-mapping enable	Required Disabled by default

To ensure SSM service for all hosts on a subnet, regardless of the MLD version running on the hosts, enable MLDv2 on the interface that forwards IPv6 multicast traffic onto the subnet.

Configuring MLD SSM Mappings

By performing this configuration multiple times, you can map an IPv6 multicast group to different IPv6 multicast sources.

Follow these steps to configure an MLD SSM mapping:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter MLD view	mld	—
Configure an MLD SSM mapping	ssm-mapping ipv6-group-address prefix-length ipv6-source-address	Required No MLD mappings are configured by default.

If MLDv2 is enabled on a VLAN interface of a switch that supports both MLD Snooping and MLD, and if a port in that VLAN is configured as a simulated host, the simulated host will send MLDv2 reports even if you did not specify an IPv6 multicast source when configuring simulated joining with the mld-snooping host-join command. In this case, the corresponding IPv6 multicast group will not be created based on the configured MLD SSM mappings. For details about the mld-snooping host-join command, refer to MLD Snooping Commands in the IP Multicast Volume.

Displaying and Maintaining MLD Configuration

To do…	Use the command…	Remarks
View MLD multicast group information	display mld group [ ipv6-group-address \| interface interface-type interface-number ] [ static \| verbose ]	Available in any view
View Layer 2 port information about MLD multicast groups	display mld group port-info [ vlan vlan-id ] [ slot slot-number ] [ verbose ]	Available in any view
View MLD configuration and running information on the specified interface or all MLD-enabled interfaces	display mld interface [ interface-type interface-number ] [ verbose ]	Available in any view
View the information of the MLD routing table	display mld routing-table [ ipv6-source-address [ prefix-length ] \| ipv6-group-address [ prefix-length ] ] *	Available in any view
View MLD SSM mappings	display mld ssm-mapping ipv6-group-address	Available in any view
View the IPv6 multicast group information created based on the configured MLD SSM mappings	display mld ssm-mapping group [ ipv6-group-address \| interface interface-type interface-number ] [ verbose ]	Available in any view
Clear MLD multicast group information	reset mld group { all \| interface interface-type interface-number { all \| ipv6-group-address [ prefix-length ] [ ipv6-source-address [ prefix-length ] ] } }	Available in user view
Clear Layer 2 port information about MLD multicast groups	reset mld group port-info { all \| ipv6-group-address } [ vlan vlan-id ]	Available in user view
Clear MLD SSM mappings	reset mld ssm-mapping group { all \| interface interface-type interface-number { all \| ipv6-group-address [ prefix-length ] [ ipv6-source-address [ prefix-length ] ] } }	Available in user view

l You cannot use the reset mld group command to clear the MLD multicast group information of static joins.

l The reset mld group port-info command cannot clear Layer 2 port information about MLD multicast groups of static joins.

l The support for the display mld group port-info and reset mld group port-info commands varies with devices.

The reset mld group command cause an interruption of receivers’ reception of multicast data.

MLD Configuration Examples

Basic MLD Functions Configuration Example

Network requirements

l Receivers receive VOD information in the multicast mode. Receivers of different organizations form stub networks N1 and N2, and Host A and Host C are multicast receivers in N1 and N2 respectively.

l Switch A in the IPv6 PIM network connects to N1, and Switch B and Switch C connect to N2.

l Switch A connects to N1 through VLAN-interface 100, and to other devices in the IPv6 PIM network through VLAN-interface 101.

l Switch B and Switch C connects to N2 through their own VLAN-interface 200, and to other devices in the IPv6 PIM network through VLAN-interface 201 and VLAN-interface 202 respectively.

l MLDv1 is required between Switch A and N1. MLDv1 is also required between the other two switches (Switch B and Switch C) and N2, Switch B serves as the MLD querier in N2 because its IP address is lower.

Network diagram

Figure 1-6 Network diagram for basic MLD functions configuration

Configuration procedure

1) Enable IPv6 forwarding and configure IPv6 addresses and IPv6 unicast routing

Enable IPv6 forwarding on each switch and configure an IP address and prefix length for each interface as shown in Figure 1-6. The detailed configuration steps are not discussed in this document.

Configure OSPFv3 for interoperation between the switches. Ensure the network-layer interoperation among the switches on the IPv6 PIM network and dynamic update of routing information between the switches through a unicast routing protocol. The detailed configuration steps are omitted here.

2) Enable the IPv6 multicast routing, and enable IPv6 PIM-DM and MLD.

# Enable IPv6 multicast routing on Switch A, enable IPv6 PIM-DM on each interface, and enable MLD on VLAN-interface 100.

<SwitchA> system-view

[SwitchA] multicast ipv6 routing-enable

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] mld enable

[SwitchA-Vlan-interface100] pim ipv6 dm

[SwitchA-Vlan-interface100] quit

[SwitchA] interface vlan-interface 101

[SwitchA-Vlan-interface101] pim ipv6 dm

[SwitchA-Vlan-interface101] quit

# Enable IPv6 multicast routing on Switch B, enable IPv6 PIM-DM on each interface, and enable MLD on VLAN-interface 200.

<SwitchB> system-view

[SwitchB] multicast ipv6 routing-enable

[SwitchB] interface vlan-interface 200

[SwitchB-Vlan-interface200] mld enable

[SwitchB-Vlan-interface200] pim ipv6 dm

[SwitchB-Vlan-interface200] quit

[SwitchB] interface vlan-interface 201

[SwitchB-Vlan-interface201] pim ipv6 dm

[SwitchB-Vlan-interface201] quit

# Enable IPv6 multicast routing on Switch C, enable IPv6 PIM-DM on each interface, and enable MLD on VLAN-interface 200.

<SwitchC> system-view

[SwitchC] multicast ipv6 routing-enable

[SwitchC] interface vlan-interface 200

[SwitchC-Vlan-interface200] mld enable

[SwitchC-Vlan-interface200] pim ipv6 dm

[SwitchC-Vlan-interface200] quit

[SwitchC] interface vlan-interface 202

[SwitchC-Vlan-interface202] pim ipv6 dm

[SwitchC-Vlan-interface202] quit

3) Verify the configuration

Carry out the display mld interface command to display the MLD configuration and running information on each switch interface. Example:

# Display MLD information on VLAN-interface 200 of Switch B.

[SwitchB] display mld interface vlan-interface 200

Vlan-interface200(FE80::200:5EFF:FE66:5100):

MLD is enabled

Current MLD version is 1

Value of query interval for MLD(in seconds): 125

Value of other querier present interval for MLD(in seconds): 255

Value of maximum query response time for MLD(in seconds): 10

Querier for MLD: FE80::200:5EFF:FE66:5100 (this router)

Total 1 MLD Group reported

MLD SSM Mapping Configuration Example

Network requirements

l On the IPv6 PIM-SSM network shown in Figure 1-7, the receiver host receives VOD information through multicast. The receiver runs MLDv1, so it cannot specify the expected IPv6 multicast sources in its reports.

l It is required that MLD SSM mapping be configured on Switch D so that the receiver host will receive IPv6 multicast data from Source 1 and Source 3 only.

Network diagram

Figure 1-7 Network diagram for MLD SSM mapping configuration

Device	Interface	IP address	Device	Interface	IP address
Source 1	—	1001::1/64	Source 3	—	3001::1/64
Source 2	—	2001::1/64	Receiver	—	4001::1/64
Switch A	Vlan-int100	1001::2/64	Switch C	Vlan-int300	3001::2/64
	Vlan-int101	1002::1/64		Vlan-int103	3002::1/64
	Vlan-int104	1003::1/64		Vlan-int102	2002::2/64
Switch B	Vlan-int200	2001::2/64	Switch D	Vlan-int400	4001::2/64
	Vlan-int101	1002::2/64		Vlan-int103	3002::2/64
	Vlan-int102	2002::1/64		Vlan-int104	1003::2/64

Configuration procedure

1) Enable IPv6 forwarding and configure IPv6 addresses and IPv6 unicast routing

Enable IPv6 forwarding on each switch and configure an IPv6 address and prefix length for each interface as shown in Figure 1-7. The detailed configuration steps are omitted.

Configure OSPFv3 for interoperability among the switches. Ensure the network-layer interoperation on the IPv6 PIM-SSM network and dynamic update of routing information among the switches through a unicast routing protocol. The detailed configuration steps are omitted here.

2) Enable IPv6 multicast routing, enable IPv6 PIM-SM on each interface and enable MLD and MLD SSM mapping on the host-side interface.

# Enable IPv6 multicast routing on Switch D, enable IPv6 PIM-SM on each interface, and enable MLD (version 2) and MLD SSM mapping on VLAN-interface 400.

<SwitchD> system-view

[SwitchD] multicast ipv6 routing-enable

[SwitchD] interface vlan-interface 400

[SwitchD-Vlan-interface400] mld enable

[SwitchD-Vlan-interface400] mld version 2

[SwitchD-Vlan-interface400] mld ssm-mapping enable

[SwitchD-Vlan-interface400] pim ipv6 sm

[SwitchD-Vlan-interface400] quit

[SwitchD] interface vlan-interface 103

[SwitchD-Vlan-interface103] pim ipv6 sm

[SwitchD-Vlan-interface103] quit

[SwitchD] interface vlan-interface 104

[SwitchD-Vlan-interface104] pim ipv6 sm

[SwitchD-Vlan-interface104] quit

# Enable IPv6 multicast routing on Switch A, and enable IPv6 PIM-SM on each interface.

<SwitchA> system-view

[SwitchA] multicast ipv6 routing-enable

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] pim ipv6 sm

[SwitchA-Vlan-interface100] quit

[SwitchA] interface vlan-interface 101

[SwitchA-Vlan-interface101] pim ipv6 sm

[SwitchA-Vlan-interface101] quit

[SwitchA] interface vlan-interface 104

[SwitchA-Vlan-interface104] pim ipv6 sm

[SwitchA-Vlan-interface104] quit

The configuration on Switch B and Switch C is similar to that on Switch A.

3) Configure the IPv6 SSM group range

# Configure the IPv6 SSM group range FF3E::/64 on Switch D.

[SwitchD] acl ipv6 number 2000

[SwitchD-acl6-basic-2000] rule permit source ff3e:: 64

[SwitchD-acl6-basic-2000] quit

[SwitchD] pim ipv6

[SwitchD-pim6] ssm-policy 2000

[SwitchD-pim6] quit

The configuration on Switch A, Switch B and Switch C is similar to that on Switch D.

4) Configure MLD SSM mappings

# Configure MLD SSM mappings on Switch D.

[SwitchD] mld

[SwitchD-mld] ssm-mapping ff3e::101 64 1001::1

[SwitchD-mld] ssm-mapping ff3e::101 64 3001::1

[SwitchD-mld] quit

5) Verify the configuration

Use the display mld ssm-mapping command to view MLD SSM mappings on the switch.

# View the MLD SSM mapping information for IPv6 multicast group FF3E::101 on Switch D.

[SwitchD] display mld ssm-mapping ff3e::101

Group: FF3E::101

Source list:

1001::1

3001::1

Use the display mld ssm-mapping group command to view information of the MLD multicast groups created based on the configured MLD SSM mappings.

# View the IPv6 multicast group information created based on the configured MLD SSM mappings on Switch D.

[SwitchD] display mld ssm-mapping group

Total 1 MLD SSM-mapping Group(s).

Interface group report information

Vlan-interface400 (4001::2):

Total 1 MLD SSM-mapping Group reported

Group Address: FF3E::101

Last Reporter: 4001::1

Uptime: 00:02:04

Expires: off

Use the display pim ipv6 routing-table command to view the IPv6 PIM routing table information on each switch.

# View the IPv6 PIM routing table information on Switch D.

[SwitchD] display pim ipv6 routing-table

Total 0 (*, G) entry; 2 (S, G) entry

(1001::1, FF3E::101)

Protocol: pim-ssm, Flag:

UpTime: 00:13:25

Upstream interface: Vlan-interface104

Upstream neighbor: 1003::1

RPF prime neighbor: 1003::1

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface400

Protocol: mld, UpTime: 00:13:25, Expires: -

(3001::1, FF3E::101)

Protocol: pim-ssm, Flag:

UpTime: 00:13:25

Upstream interface: Vlan-interface103

Upstream neighbor: 3002::1

RPF prime neighbor: 3002::1

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface400

Protocol: mld, UpTime: 00:13:25, Expires: -

Troubleshooting MLD

No Member Information on the Receiver-Side Router

Symptom

When a host sends a message for joining IPv6 multicast group G, there is no member information of multicast group G on the immediate router.

Analysis

l The correctness of networking and interface connections and whether the protocol layer of the interface is up directly affect the generation of IPv6 group member information.

l IPv6 multicast routing must be enabled on the router and MLD must be enabled on the interface connecting to the host.

l If the MLD version on the router interface is lower than that on the host, the router will not be able to recognize the MLD report from the host.

l If the mld group-policy command has been configured on an interface, the interface cannot receive report messages that fail to pass filtering.

Solution

1) Check that the networking, interface connections, and IP address configuration are correct. Check the interface information with the display mld interface command. If there is no information output, the interface is in an abnormal state. This is usually because you have configured the shutdown command on the interface, the interface is not properly connected, or the IPv6 address configuration is not correctly done.

2) Check that the IPv6 multicast routing is enabled. Carry out the display current-configuration command to check whether the multicast ipv6 routing-enable command has been executed. If not, carry out the multicast ipv6 routing-enable command in system view to enable IPv6 multicast routing. In addition, enable MLD on the corresponding interface.

3) Check the MLD version on the interface. You can use the display mld interface command to check whether the MLD version on the interface is lower than that on the host.

4) Check that the interface is normal and that a correct IPv6 address has been configured. Carry out the display mld interface command to display the interface information. If no interface information is output, the interface is abnormal. Typically this is because the shutdown command has been executed on the interface, or the interface connection is incorrect, or no correct IPv6 address has been configured on the interface.

5) Check that no ACL rule has been configured to restrict the host from joining IPv6 multicast group G. Carry out the display current-configuration interface command to check whether the mld group-policy command has been executed. If an IPv6 ACL is configured to restrict the host from joining IPv6 multicast group G, the ACL must be modified to allow IPv6 multicast group G to receive report messages.

Inconsistent Memberships on Routers on the Same Subnet

Symptom

Different memberships are maintained on different MLD routers on the same subnet.

Analysis

l A router running MLD maintains multiple parameters for each interface, and these parameters influence one another, forming very complicated relationships. Inconsistent MLD interface parameter configurations for routers on the same subnet will surely result in inconsistent MLD memberships.

l Two MLD versions are currently available. Although routers running different MLD versions are compatible with hosts, all routers on the same subnet must run the same MLD version. Inconsistent MLD versions running on routers on the same subnet will also lead to inconsistent MLD memberships.

Solution

1) Check MLD configurations. Carry out the display current-configuration command to display the MLD configuration information on the interface.

2) Carry out the display mld interface command on all routers on the same subnet to check the MLD timers for consistent configurations.

3) Use the display mld interface command to check that the routers are running the same MLD version.

04-IP Multicast Volume

MLD Overview

MLD querier election

Joining an IPv6 multicast group

Leaving an IPv6 multicast group

How MLDv2 Works

IPv6 multicast group filtering

MLD state

Receiver host state listening

MLD Message Types

MLD query message

MLD report message

Configuring Basic Functions of MLD

Enabling MLD

Configuring the MLD Version

Configuring an MLD version globally

Configuring an MLD version on an interface

Configuring Static Joining

Configuring an IPv6 Multicast Group Filter

Adjusting MLD Performance

Configuring MLD Message Options

Configuring the Router-Alert option for MLD messages globally

Configuring the Router-Alert option on an interface

Configuring MLD Query and Response Parameters

Configuring MLD query and response parameters globally

Configuring MLD Fast Leave Processing

Configuring MLD SSM Mapping

MLD Configuration Examples

Network requirements

Network diagram

Configuration procedure

MLD SSM Mapping Configuration Example

Network requirements

Network diagram

Configuration procedure

Symptom

Analysis

Solution

Symptom

Analysis

Solution

Cloud & AI

InterConnect

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Resources

Partner Business Management

Company Information

News & Events

Contact Us