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 any IPv6 multicast listeners exist 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

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

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

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

NOTE:

For more information about the ASM and SSM models, see the chapter “Multicast overview.”

How MLDv1 works

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

MLD querier election

All IPv6 multicast routers routers on the same subnet can monitor MLD listener report messages—often called “reports”—from hosts, but only one router is needed for sending MLD query messages—often called “queries”. A querier election mechanism determines 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 called “general queries”—to all hosts and routers on the local subnet. The destination address is FF02::1.

2. After receiving 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, called the “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 that the querier has timed out and initiates a new querier election process.

Joining an IPv6 multicast group

Figure 1 MLD queries and reports

Assume that Host B and Host C will receive IPv6 multicast data addressed to IPv6 multicast group G1, and Host A will receive IPv6 multicast data addressed to G2, as shown in Figure 1. The following process describes how the hosts join the IPv6 multicast groups and how 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. After 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 that Host B sends the report message. After hearing the report from Host B, Host C, which is on the same subnet as Host B, suppresses its own report for G1, because the MLD routers (Router A and Router B) have already known that at least one host on the local subnet is interested in G1. This mechanism, known as the “MLD report suppression”, 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 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) that is running on the routers generates (*, G1) and (*, G2) multicast forwarding entries. These entries 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, the following occur:

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

2. After receiving the MLD done message, the querier sends a configurable number of multicast-address-specific queries to the group that the host is leaving. The destination address field and group address field of the message are both filled with the address of the IPv6 multicast group that is 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 specify to receive or reject multicast data from designated IPv6 multicast sources. When a host joins an IPv6 multicast group, one of the following situation occurs:

· If it expects IPv6 multicast data from specific IPv6 multicast sources like S1, S2, …, it sends a report with Filter-Mode denoted as “Include Sources (S1, S2, …)”.

· If it does not expect IPv6 multicast data from specific IPv6 multicast sources like S1, S2, …, it sends a report with Filter-Mode denoted as “Exclude Sources (S1, S2, …)”.

As shown in Figure 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 2 Flow paths of multicast-address-and-source-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 that Source 1 sends to G (denoted as (S1, G)), rather than the IPv6 multicast data that 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 that is running MLDv2 maintains the multicast address state per multicast address per attached subnet. The multicast address state consists of the following information:

· Filter mode—The router keeps tracing the Include or Exclude state.

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

· Timers—Filter timers, including the time that the router waits before switching to the Include mode after an IPv6 multicast address times out, the 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 identifies the multicast listening state of neighbor interfaces by sending MLD query messages. The dark area in Figure 3 shows the format of an MLDv1 message.

Figure 3 Format of MLDv2 query message

Table 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	· This field is set to 0 in a general query message. · 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	· This field is set to 0 in a general query message or a multicast-address-specific query message. · 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 4 shows the format of an MLD report message.

Figure 4 Format of MLDv2 report message

Table 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).

MLD SSM mapping

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

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

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

Figure 5 Network diagram

As shown in Figure 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 if MLDv2 is not available 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:

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

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

· 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.

NOTE:

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

· For more information about the IPv6 SSM group range, see the chapter “Configuring IPv6 PIM.”

MLD proxying

In some simple tree-shaped topologies, you do not need to configure complex IPv6 multicast routing protocols, such as IPv6 PIM, on the boundary devices. Instead, you can configure MLD proxying on these devices. With MLD proxying configured, the device serves as a proxy for the downstream hosts to send MLD messages, maintain group memberships, and implement IPv6 multicast forwarding based on the memberships. In this case, the MLD proxy device is a host but no longer an IPv6 PIM neighbor to the upstream device.

Figure 6 Network diagram

As shown in Figure 6, two types of interfaces are defined on a MLD proxy device:

· Upstream interface—Also called the “proxy interface”. A proxy interface is an interface on which MLD proxying is configured. It is in the direction toward the root of the multicast forwarding tree. An upstream interface acts as a host that is running MLD. Therefore, it is also called a “host interface”.

· Downstream interface—An interface that is running MLD and not in the direction toward the root of the multicast forwarding tree. A downstream interface acts as a router that is running MLD. Therefore, it is also called a “router interface”.

A device with MLD proxying configured maintains a group membership database, which stores the group memberships on all the downstream interfaces in this database. Each entry comprises the multicast address, filter mode, and source list. Such an entry is a collection of members in the same multicast group on each downstream interface.

A proxy device performs host functions on the upstream interface based on the database. It responds to the queries according to the information in the database or sends join/leave messages when the database changes.The proxy device performs router functions on the downstream interfaces by participating in the querier election, sending queries, and maintaining memberships based on the reports.

Protocols and standards

· RFC 2710, Multicast Listener Discovery (MLD) for IPv6

· RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6

· RFC 4605, Internet Group Management Protocol (IGMP)/Multicast Listener Discovery (MLD)-Based Multicast Forwarding (“IGMP/MLD Proxying”)

MLD configuration task list

Complete these tasks to configure MLD:

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
	Setting the maximum number of IPv6 multicast groups that an interface can join	Optional
Adjusting MLD performance	Configuring MLD message options	Optional
	Configuring MLD query and response parameters	Optional
	Configuring MLD fast-leave processing	Optional
	Enabling the MLD host tracking function	Optional
Configuring MLD SSM mapping	Enabling MLD SSM mapping	Optional
Configuring MLD SSM mapping	Configuring MLD SSM mappings	Optional
Configuring MLD proxying	Enabling MLD proxying	Optional
Configuring MLD proxying	Configuring IPv6 multicast forwarding on a downstream interface	Optional

NOTE:

· In MLD view, the configuration is effective globally. In interface view, the configuration is effective on only the current interface.

· If no configuration is performed in interface view, the global configuration in MLD view applies to that interface. Configurations performed in interface view take precedence over those performed in MLD view.

Configuring basic functions of MLD

Configuration prerequisites

Before you configure the basic functions of MLD, complete the following tasks:

· Enable IPv6 forwarding and configure an IPv6 unicast routing protocol so that all devices in the domain can be interoperable at the network layer.

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

· Determine the MLD version.

· Determine the IPv6 multicast group address and IPv6 multicast source address for static group member configuration.

· Determine the ACL rule for IPv6 multicast group filtering.

· Determine the maximum number of IPv6 multicast groups that an interface can join.

Enabling MLD

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

To enable MLD:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable IPv6 multicast routing.	multicast ipv6 routing-enable	Disable by default
3. Enter interface view.	interface interface-type interface-number	N/A
4. Enable MLD.	mld enable	Disabled by default

NOTE:

· Receiver hosts can join IPv6 multicast groups only if MLD is enabled on the receiver-side DRs. For more information about DR, see the chapter “Configuring IPv6 PIM.”

· MLD snooping is not allowed in a VLAN after MLD is enabled on the virtual interface of that VLAN, and vice versa.

NOTE:

For more information about the multicast ipv6 routing-enable command, see IP Multicast Command Reference.

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

To configure an MLD version globally:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MLD view.	mld	N/A
3. Configure an MLD version globally.	version version-number	MLDv1 by default

Configuring an MLD version on an interface

To configure an MLD version on an interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure an MLD version on the interface.	mld version version-number	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.

To configure a static member of an IPv6 multicast group or an IPv6 multicast source and group:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. 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 ]	By default, an interface is not a static member of any IPv6 multicast group or IPv6 multicast source and group.

NOTE:

· 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, see the chapter “Configuring IPv6 PIM.”

· A static member port does not respond to queries from the MLD querier. When you configure an interface as a static member port or remove this configuration on the interface, the interface does not unsolicitedly send any MLD report or an MLD done message. In other words, the interface is not 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 so that the interface maintains only the IPv6 multicast groups matching the criteria.

To configure an IPv6 multicast group filter:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure an IPv6 multicast group filter.	mld group-policy acl6-number [ version-number ]	By default, no IPv6 group filter is configured on the interface. That is, hosts on the current interface can join any valid multicast group.

Setting the maximum number of IPv6 multicast groups that an interface can join

To configure the maximum number of IPv6 multicast groups an interface can join:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure the maximum number of IPv6 multicast groups that the interface can join.	mld group-limit limit	8192 by default

NOTE:

This configuration takes effect for dynamically joined IPv6 multicast groups but not the statically configured multicast groups.

Adjusting MLD performance

NOTE:

· In MLD view, the configuration is effective globally. In interface view, the configuration is effective on only the current interface.

· If the same function or parameter is configured in both MLD 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:

· Enable IPv6 forwarding and configure an IPv6 unicast routing protocol so that all devices in the domain can be interoperable at the network layer.

· Configure basic functions of MLD.

· Determine the startup query interval.

· Determine the startup query count.

· Determine the MLD query interval.

· Determine the MLD querier’s robustness variable.

· Determine the maximum response delay of MLD general query messages.

· Determine the MLD last listener query interval.

· Determine the 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 might 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 determine whether to deliver the IPv6 multicast packets to the upper-layer protocol for processing. For more information about the Router-Alert option, see RFC 2113.

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

· 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, whether the MLD messages carry the Router-Alert option or not.

· To enhance the device performance, avoid unnecessary costs, and ensure protocol security, you can configure the device to discard MLD messages that do not carry the Router-Alert option.

Configuring the Router-Alert option for MLD messages globally

To configure the Router-Alert option for MLD messages globally:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MLD view.	mld	N/A
3. Configure the interface to discard any MLD message without the Router-Alert option.	require-router-alert	By default, the device does not check MLD messages for the Router-Alert option.
4. Enable the insertion of the Router-Alert option into MLD messages.	send-router-alert	By default, MLD messages carry the Router-Alert option.

Configuring the Router-Alert option on an interface

To configure the Router-Alert option on an interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure the interface to discard any MLD message without the Router-Alert option.	mld require-router-alert	By default, the device does not check MLD messages for the Router-Alert option.
4. Enable the insertion of the Router-Alert option into MLD messages.	mld send-router-alert	By default, MLD messages carry the Router-Alert option.

Configuring MLD query and response parameters

The MLD querier’s robustness variable defines the maximum number of attempts for transmitting MLD general queries, multicast-address-specific queries, or multicast-address-and-source-specific queries in case of packet loss due to network problems. A greater value of the robustness variable makes the MLD querier “more robust”, but results in a longer IPv6 multicast group timeout time.

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

The MLDv1/v2 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.

After receiving an MLD done message, the MLDv1 querier sends “last listener query count” MLD multicast-address-specific queries at the “MLD last listener query interval”. After receiving an MLD report that tells relation changes between IPv6 multicast groups and IPv6 multicast sources, the MLDv2 querier sends “last listener query count” MLD multicast-address-and-source-specific queries at the “MLD last listener query interval”. The value of the “last listener query count” equals the value of the robustness variable.

After receiving an MLD query (general query, multicast-address-specific query, or multicast-address-and-source-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. Such bursts can occur when a large number of hosts send reports at the same time when the corresponding timers expire simultaneously.

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

· For MLD multicast-address-specific query and multicast-address-and-source-specific query messages, you can configure the last listener query interval to fill their Maximum Response Delay field. That is, 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 begins. Otherwise, the non-querier restarts the other querier present timer.

Configuring MLD query and response parameters globally

To configure MLD query and response parameters globally:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MLD view.	mld	N/A
3. Configure the MLD querier’s robustness variable.	robust-count robust-value	2 times by default.
4. Configure the startup query interval.	startup-query-interval interval	By default, the startup query interval is 1/4 of the “MLD query interval”.
5. Configure the startup query count.	startup-query-count value	By default, the startup query count is set to the MLD querier’s robustness variable.
6. Configure the MLD query interval.	timer query interval	125 seconds by default.
7. Configure the maximum response delay for MLD general query messages.	max-response-time interval	10 seconds by default.
8. Configure the MLD last listener query interval.	last-listener-query-interval interval	1 second by default.
9. Configure the MLD other querier present interval.	timer other-querier-present interval	By default, the other querier present interval is determined by the formula “Other querier present interval (in seconds) = [ MLD query interval ] × [ MLD querier’s robustness variable ] + [ maximum response delay for MLD general query ] /2”.

Configuring MLD query and response parameters on an interface

To configure MLD query and response parameters on an interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure the MLD querier’s robustness variable.	mld robust-count robust-value	2 times by default.
4. Configure the startup query interval.	mld startup-query-interval interval	By default, the startup query interval is 1/4 of the “MLD query interval”.
5. Configure the startup query count.	mld startup-query-count value	By default, the startup query count is set to the MLD querier’s robustness variable.
6. Configure the MLD query interval.	mld timer query interval	125 seconds by default.
7. Configure the maximum response delay for MLD general query messages.	mld max-response-time interval	10 seconds by default.
8. Configure the MLD last listener query interval.	mld last-listener-query-interval interval	1 second by default.
9. Configure the MLD other querier present interval.	mld timer other-querier-present interval	By default, the other querier present interval is determined by the formula “Other querier present interval (in seconds) = [ MLD query interval ] × [ MLD querier’s robustness variable ] + [ maximum response delay for MLD general query ] /2”.

CAUTION:

· Make sure that the other querier present interval is greater than the MLD query interval. Otherwise the MLD querier might frequently change.

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

Configuring MLD fast-leave processing

In some applications, such as ADSL dial-up networking, only one multicast receiver host is attached to a port of the MLD querier. To allow fast response to the MLD done messages of the host when it switches frequently from one IPv6 multicast group to another, you can enable MLD fast-leave processing on the MLD querier.

With fast-leave processing enabled, after receiving an MLD done message from a host, the MLD querier sends a leave notification to the upstream immediately without first sending MLD multicast-address-specific queries. In this way, the leave latency is reduced on one hand, and the network bandwidth is saved on the other hand.

Configuring MLD fast-leave processing globally

To configure MLD fast-leave processing globally:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MLD view.	mld	N/A
3. Configure MLD fast-leave processing.	fast-leave [ group-policy acl6-number ]	Disabled by default

Configuring MLD fast-leave processing on an interface

To configure MLD fast-leave processing on an interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure MLD fast-leave processing.	mld fast-leave [ group-policy acl6-number ]	Disabled by default

Enabling the MLD host tracking function

With the MLD host tracking function, the switch can record the information of the member hosts that are receiving IPv6 multicast traffic, including the host IPv6 address, running duration, and timeout time. You can monitor and manage the member hosts according to the recorded information.

Enabling the MLD host tracking function globally

To enable the MLD host tracking function globally:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MLD view.	mld	N/A
3. Configure the MLD host tracking function globally.	host-tracking	Disabled by default

Enabling the MLD host tracking function on an interface

To enable the MLD host tracking function on an interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Enable the MLD host tracking function on the interface.	mld host-tracking	Disabled by default

Configuring MLD SSM mapping

Due to some possible restrictions, some receiver hosts on an SSM network might 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 you configure the MLD SSM mapping feature, complete the following tasks:

· Enable IPv6 forwarding and configure an IPv6 unicast routing protocol so that all devices in the domain can be interoperable at the network layer.

· Configure basic MLD functions.

Enabling MLD SSM mapping

To enable the MLD SSM mapping feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Enable the MLD SSM mapping feature.	mld ssm-mapping enable	Disabled by default

NOTE:

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.

To configure an MLD SSM mapping:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MLD view.	mld	N/A
3. Configure an MLD SSM mapping.	ssm-mapping ipv6-group-address prefix-length ipv6-source-address	No MLD mappings are configured by default.

CAUTION:

If MLDv2 is enabled on a VLAN interface, 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 you configure 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 more information about the mld-snooping host-join command, see IP Multicast Command Reference.

Configuring MLD proxying

Configuration prerequisites

Before you configure the MLD proxying feature, complete the following tasks:

· Enable IPv6 forwarding and configure an IPv6 unicast routing protocol so that all devices in the domain are interoperable at the network layer.

· Enable IPv6 multicast routing.

Enabling MLD proxying

You can enable MLD proxying on the interface in the direction toward the root of the multicast forwarding tree to make the device serve as an MLD proxy.

To enable MLD proxying:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Enable the MLD proxying feature.	mld proxying enable	Disabled by default

NOTE:

· Each device can have only one interface serving as the MLD proxy interface.

· You cannot enable MLD on interfaces with MLD proxying enabled. Moreover, only the mld require-router-alert, mld send-router-alert, and mld version commands can take effect on such interfaces.

· You cannot enable other IPv6 multicast routing protocols (such as IPv6 PIM-DM or IPv6 PIM-SM) on interfaces with MLD proxying enabled, or vice versa. However, the source-lifetime, source-policy, and ssm-policy commands configured in IPv6 PIM view can still take effect.

· You cannot enable MLD proxying on a VLAN interface with MLD snooping enabled, or vice versa.

Configuring IPv6 multicast forwarding on a downstream interface

Only queriers can forward IPv6 multicast traffic but non-queriers have no forwarding capabilities, to avoid duplicate multicast flows. It is the same on MLD proxy devices. Only the downstream interfaces acting as a querier can forward IPv6 multicast traffic to downstream hosts.

However, when a downstream interface of a proxy device fails to win the querier election, you need to enable IPv6 multicast forwarding on this interface.

To enable IPv6 multicast forwarding on a downstream interface

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Enable IPv6 multicast forwarding on a non-querier downstream interface.	mld proxying forwarding	Disabled by default

CAUTION:

On a multi-access network with more than one MLD proxy devices, you cannot enable IPv6 multicast forwarding on any other non-querier downstream interface after one of the downstream interfaces of these MLD proxy devices has been elected as the querier. Otherwise, duplicate multicast flows might be received on the multi-access network.

Displaying and maintaining MLD

Task	Command	Remarks
Display MLD group information.	display mld group [ ipv6-group-address \| interface interface-type interface-number ] [ static \| verbose ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display Layer 2 port information about MLD groups.	display mld group port-info [ vlan vlan-id ] [ slot slot-number ] [ verbose ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display information about the hosts tracked by MLD on an interface.	display mld host interface interface-type interface-number group ipv6-group-address [ source ipv6-source-address ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display information about the hosts tracked by MLD on the Layer 2 ports.	display mld host port-info vlan vlan-id group ipv6-group-address [ source ipv6-source-address ] [ vlan vlan-id ] [ slot slot-number ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display MLD configuration and running information on the specified interface or all MLD-enabled interfaces.	display mld interface [ interface-type interface-number ] [ verbose ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display the information of the MLD proxying groups.	display mld proxying group [ group-address ] [ verbose ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display the information of the MLD routing table.	display mld routing-table [ ipv6-source-address [ prefix-length ] \| ipv6-group-address [ prefix-length ] \| flags { act \| suc } ] * [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display MLD SSM mappings.	display mld ssm-mapping ipv6-group-address [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display 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 ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display information about the hosts that join based on the MLD SSM mappings on an interface.	display mld ssm-mapping host interface interface-type interface-number group ipv6-group-address source ipv6-source-address [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Remove the dynamic group entries of a specified MLD group or all MLD groups.	reset mld group { all \| interface interface-type interface-number { all \| ipv6-group-address [ prefix-length ] [ ipv6-source-address [ prefix-length ] ] } }	Available in user view
Remove the dynamic Layer 2 port entries of a specified MLD group or all MLD 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

NOTE:

· The reset mld group command cannot remove dynamic MLD group entries.

· The reset mld group port-info command cannot remove the Layer 2 port entries of MLD groups.

CAUTION:

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

MLD configuration examples

Basic MLD functions configuration example

Network requirements

As shown in Figure 7, 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.

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

MLDv1 runs between Router A and N1. MLDv1 runs between the other two routers (Router B and Router C) and N2. Router B acts as the MLD querier because it has a lower IPv6 address.

The hosts in N1 can join only IPv6 multicast group FF1E::101, and the hosts in N2 can join any IPv6 multicast groups.

Figure 7 Network diagram

Configuration procedure

1. Enable IPv6 forwarding, assign IPv6 addresses, and configure IPv6 unicast routing:

Enable IPv6 forwarding on each router and assign an IPv6 address and prefix length for each interface as shown in Figure 7. (Details not shown)

Configure OSPFv3 for interoperation between the routers on the IPv6 PIM network. Ensure the network-layer interoperation on the IPv6 PIM network and dynamic update of routing information between the routers through a unicast routing protocol. (Details not shown)

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

# Enable IPv6 multicast routing on Router A, enable IPv6 PIM-DM on each interface, and enable MLD on the host-side interface GigabitEthernet 3/1/1.

<RouterA> system-view

[RouterA] multicast ipv6 routing-enable

[RouterA] interface GigabitEthernet 3/1/1

[RouterA-GigabitEthernet3/1/1] mld enable

[RouterA-GigabitEthernet3/1/1] pim ipv6 dm

[RouterA-GigabitEthernet3/1/1] quit

[RouterA] interface pos 5/1/1

[RouterA-Pos5/1/1] pim ipv6 dm

[RouterA-Pos5/1/1] quit

# Enable IPv6 multicast routing on Router B, enable IPv6 PIM-DM on each interface, and enable MLD on the host-side interface GigabitEthernet 3/1/1.

<RouterB> system-view

[RouterB] multicast ipv6 routing-enable

[RouterB] interface GigabitEthernet 3/1/1

[RouterB-GigabitEthernet3/1/1] mld enable

[RouterB-GigabitEthernet3/1/1] pim ipv6 dm

[RouterB-GigabitEthernet3/1/1] quit

[RouterB] interface pos 5/1/1

[RouterB-Pos5/1/1] pim ipv6 dm

[RouterB-Pos5/1/1] quit

# Enable IPv6 multicast routing on Router C, enable IPv6 PIM-DM on each interface, and enable MLD on the host-side interface GigabitEthernet 3/1/1.

<RouterC> system-view

[RouterC] multicast ipv6 routing-enable

[RouterC] interface GigabitEthernet 3/1/1

[RouterC-GigabitEthernet3/1/1] mld enable

[RouterC-GigabitEthernet3/1/1] pim ipv6 dm

[RouterC-GigabitEthernet3/1/1] quit

[RouterC] interface pos 5/1/1

[RouterC-Pos5/1/1] pim ipv6 dm

[RouterC-Pos5/1/1] quit

3. Configure an IPv6 multicast group filter:

# Configure an IPv6 multicast group filter on Router A, so that the hosts connected to GigabitEthernet 3/1/1 can join IPv6 multicast group FF1E::101 only.

[RouterA] acl ipv6 number 2001

[RouterA-acl6-basic-2001] rule permit source ff1e::101 128

[RouterA-acl6-basic-2001] quit

[RouterA] interface GigabitEthernet 3/1/1

[RouterA-GigabitEthernet3/1/1] mld group-policy 2001

4. Verify the configuration:

# Display MLD information on GigabitEthernet 3/1/1 of Router B.

[RouterB] display mld interface GigabitEthernet 3/1/1

GigabitEthernet3/1/1(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

As shown in Figure 8, the IPv6 PIM-SM domain applies both the ASM model and SSM model for IPv6 multicast delivery. Router D’s GigabitEthernet 3/1/3 serves as the C-BSR and C-RP. The SSM group range is FF3E::/64.

MLDv2 runs on Router D’s GigabitEthernet 3/1/1. The receiver host runs MLDv1, and does not support MLDv2. Therefore, the Receiver host cannot specify expected multicast sources in its membership reports.

Source 1, Source 2, and Source 3 send IPv6 multicast packets to multicast groups in the IPv6 SSM group range. You can configure the MLD SSM mapping feature on Router D so that the receiver host will receive IPv6 multicast data from Source 1 and Source 3 only.

Figure 8 Network diagram

Device	Interface	IPv6 address	Device	Interface	IPv6 address
Source 1	—	1001::1/64	Source 3	—	3001::1/64
Source 2	—	2001::1/64	Receiver	—	4001::1/64
Router A	GE3/1/1	1001::2/64	Router C	GE3/1/1	3001::2/64
	GE3/1/2	1002::1/64		GE3/1/2	3002::1/64
	GE3/1/3	1003::1/64		GE3/1/3	2002::2/64
Router B	GE3/1/1	2001::2/64	Router D	GE3/1/1	4001::2/64
	GE3/1/2	1002::2/64		GE3/1/2	3002::2/64
	GE3/1/3	2002::1/64		GE3/1/3	1003::2/64

Configuration procedure

1. Enable IPv6 forwarding, assign IPv6 addresses, and configure IPv6 unicast routing:

Enable IPv6 forwarding on each router and assign an IPv6 address and prefix length for each interface as shown in Figure 8. The detailed configuration steps are not discussed in this document.

Configure OSPF for interoperability among the routers. Ensure the network-layer interoperation among the routers on the IPv6 PIM-SSM domain and dynamic update of routing information among the routers through an IPv6 unicast routing protocol. (Details not shown)

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 Router D, enable IPv6 PIM-SM on each interface and enable MLD (version 2) and MLD SSM mapping on GigabitEthernet 3/1/1.

<RouterD> system-view

[RouterD] multicast ipv6 routing-enable

[RouterD] interface GigabitEthernet 3/1/1

[RouterD-GigabitEthernet3/1/1] mld enable

[RouterD-GigabitEthernet3/1/1] mld version 2

[RouterD-GigabitEthernet3/1/1] mld ssm-mapping enable

[RouterD-GigabitEthernet3/1/1] pim ipv6 sm

[RouterD-GigabitEthernet3/1/1] quit

[RouterD] interface GigabitEthernet3/1/2

[RouterD-GigabitEthernet3/1/2] pim ipv6 sm

[RouterD-GigabitEthernet3/1/2] quit

[RouterD] interface GigabitEthernet3/1/3

[RouterD-GigabitEthernet3/1/3] pim ipv6 sm

[RouterD-GigabitEthernet3/1/3] quit

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

<RouterA> system-view

[RouterA] multicast ipv6 routing-enable

[RouterA] interface GigabitEthernet 3/1/1

[RouterA-GigabitEthernet3/1/1] pim ipv6 sm

[RouterA-GigabitEthernet3/1/1] quit

[RouterA] interface GigabitEthernet 3/1/2

[RouterA-GigabitEthernet3/1/2] pim ipv6 sm

[RouterA-GigabitEthernet3/1/2] quit

[RouterA] interface GigabitEthernet 3/1/3

[RouterA-GigabitEthernet3/1/3] pim ipv6 sm

[RouterA-GigabitEthernet3/1/3] quit

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

3. Configure a C-BSR and a C-RP:

# Configure C-BSR and C-RP interfaces on Router D.

[RouterD] pim ipv6

[RouterD-pim6] c-bsr 1003::2

[RouterD-pim6] c-rp 1003::2

[RouterD-pim6] quit

4. Configure the IPv6 SSM group range:

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

[RouterD] acl ipv6 number 2000

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

[RouterD-acl6-basic-2000] quit

[RouterD] pim ipv6

[RouterD-pim6] ssm-policy 2000

[RouterD-pim6] quit

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

5. Configure MLD SSM mappings:

# Configure MLD SSM mappings on Router D.

[RouterD] mld

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

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

[RouterD-mld] quit

6. Verify the configuration:

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

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

Group: FF3E::101

Source list:

1001::1

3001::1

# Display information about IPv6 multicast groups created based on the configured MLD SSM mappings on Router D.

[RouterD] display mld ssm-mapping group

Total 1 MLD SSM-mapping Group(s).

Interface group report information

GigabitEthernet3/1(4001::2):

Total 1 MLD SSM-mapping Group reported

Group Address: FF3E::101

Last Reporter: 4001::1

Uptime: 00:02:04

Expires: off

# Display IPv6 PIM routing table information on Router D.

[RouterD] 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: GigabitEthernet3/1/3

Upstream neighbor: 1003::1

RPF prime neighbor: 1003::1

Downstream interface(s) information:

Total number of downstreams: 1

1: GigabitEthernet3/1/1

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

(3001::1, FF3E::101)

Protocol: pim-ssm, Flag:

UpTime: 00:13:25

Upstream interface: GigabitEthernet3/1/2

Upstream neighbor: 3002::1

RPF prime neighbor: 3002::1

Downstream interface(s) information:

Total number of downstreams: 1

1: GigabitEthernet3/1/1

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

MLD proxying configuration example

Network requirements

As shown in Figure 9, IPv6 PIM-DM runs on the core network. Host A and Host C in the stub network receive VOD information sent to multicast group FF3E::101.

Configure the MLD proxying feature on Router B so that Router B can maintain group memberships and forward IPv6 multicast traffic without running IPv6 PIM-DM.

Figure 9 Network diagram

Configuration procedure

1. Enable IPv6 forwarding and assign the IPv6 addresses:

Enable IPv6 forwarding on each router and configure the IPv6 address and prefix length of each interface as per Figure 9. (Details not shown)

2. Enable IPv6 multicast routing, IPv6 PIM-DM, MLD, and MLD proxying respectively:

# Enable IPv6 multicast routing on Router A, IPv6 PIM-DM on Serial 4/1/9/1:0, and MLD on GigabitEthernet 3/1/1.

<RouterA> system-view

[RouterA] multicast ipv6 routing-enable

[RouterA] interface Serial 4/1/9/1:0

[RouterA-Serial4/1/9/1:0] pim ipv6 dm

[RouterA-Serial4/1/9/1:0] quit

[RouterA] interface GigabitEthernet 3/1/1

[RouterA-GigabitEthernet3/1/1] mld enable

[RouterA-GigabitEthernet3/1/1] pim ipv6 dm

[RouterA-GigabitEthernet3/1/1] quit

# Enable IPv6 multicast routing on Router B, MLD proxying on GigabitEthernet 3/1/1, and MLD on GigabitEthernet 3/1/2.

<RouterB> system-view

[RouterB] multicast ipv6 routing-enable

[RouterB] interface GigabitEthernet 3/1/1

[RouterB-GigabitEthernet3/1/1] mld proxying enable

[RouterB-GigabitEthernet3/1/1] quit

[RouterB] interface GigabitEthernet 3/1/2

[RouterB-GigabitEthernet3/1/2] mld enable

[RouterB-GigabitEthernet3/1/2] quit

3. Verify the configuration:

# Display MLD information on GigabitEthernet 3/1/1 of Router B.

[RouterB] display mld interface GigabitEthernet 3/1/1 verbose

GigabitEthernet3/1/1(2001::2):

MLD proxy is enabled

Current MLD version is 1

Multicast routing on this interface: enabled

Require-router-alert: disabled

# Display MLD group information on Router A.

[RouterA] display mld group

Total 1 MLD Group(s).

Interface group report information

GigabitEthernet3/1/1(2001::1):

Total 1 MLD Groups reported

Group Address Last Reporter Uptime Expires

ff3e::101 2001::2 00:02:04 00:01:15

The output shows that the MLD reports sent from the hosts are forwarded to Router A through the proxy interface, GigabitEthernet 3/1/1 of Router B.

Troubleshooting MLD

No member information exists on the receiver-side router

Symptom

When a host sends a message to announce its joining IPv6 multicast group G, no member information of multicast group G exists on the intermediate router.

Analysis

· 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.

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

· 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.

· 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. Use the display mld interface command to verify that the networking, interface connections, and IP address configuration are correct. If no information is output, the interface is in an abnormal state. The reason is that you have configured the shutdown command on the interface, that the interface is not properly connected, or that the IPv6 address configuration is not correctly done.

2. Use the display current-configuration command to verify that the IPv6 multicast routing is enabled. If not, use the multicast ipv6 routing-enable command in system view to enable IPv6 multicast routing. In addition, enable MLD on the corresponding interface.

3. Use the display mld interface command to verify that the MLD version on the interface is lower than that on the host.

4. Use the display current-configuration interface command to verify that no ACL rule has been configured to restrict the host from joining IPv6 multicast group G. 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.

Membership information is inconsistent on routers on the same subnet

Symptom

The MLD routers on the same subnet have different membership information.

Analysis

· 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.

· Two MLD versions are 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. Use the display current-configuration command to verify the MLD configuration information on the interface.

2. Use the display mld interface command on all routers on the same subnet to check the MLD timers for inconsistent configurations.

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

07-IP Multicast Configuration Guide

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

Setting the maximum number of IPv6 multicast groups that an interface can join

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 fast-leave processing globally

Configuring MLD fast-leave processing on an interface

Enabling the MLD host tracking function

Enabling the MLD host tracking function globally

Enabling the MLD host tracking function on an interface

MLD configuration examples

Network requirements

Configuration procedure

MLD SSM mapping configuration example

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Symptom

Analysis

Solution

Symptom

Analysis

Solution

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

Company Information

News & Events

Contact Us