Login
- Table of Contents
-
- H3C S9500 Operation Manual-Release2132[V2.03]-04 IP Multicast Volume
- 00-1Cover
- 01-Multicast Overview
- 02-Multicast Routing and Forwarding Configuration
- 03-IGMP Snooping Configuration
- 04-IGMP Configuration
- 05-PIM Configuration
- 06-MSDP Configuration
- 07-IPv6 Multicast Routing and Forwarding Configuration
- 08-MLD Snooping Configuration
- 09-MLD Configuration
- 10-IPv6 PIM Configuration
- 11-Multicast VLAN Configuration
- Related Documents
-
| Title | Size | Download |
|---|---|---|
| 09-MLD Configuration | 178.13 KB |
Table of Contents
1.3 Configuring Basic Functions of MLD
1.3.1 Configuration Prerequisites
1.3.3 Configuring the MLD Version
1.4.1 Configuration Prerequisites
1.4.2 Configuring MLD Message Options
1.4.3 Configuring MLD Queries and Responses
1.5 Displaying and Maintaining MLD Configuration
1.7.1 No Member Information on the Receiver-Side DR
1.7.2 Inconsistent Memberships on Routers on the Same Subnet
Chapter 1 MLD Configuration
& Note:
l The term “router” in this document refers to a router in a generic sense or an S9500 series switch running the MLD protocol.
l At present, for an S9500 series switch, the POS interface does not support IPv6 multicast. In this document, commands to be executed in interface view are not executable in POS interface view.
When configuring MLD, go to the following sections for information you are interested in:
l Displaying and Maintaining MLD Configuration
1.1 MLD Overview
1.1.1 Introduction to MLD
Multicast listener discovery protocol (MLD) is used by an IPv6 router or a routing switch to discover the presence of multicast listeners on directly-attached subnets. Multicast listeners are nodes wishing to receive multicast packets.
Through MLD, the router can learn whether there are any IPv6 multicast listeners on 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.
1.1.2 MLD Version
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.
1.1.3 How MLDv1 Works
MLDv1 implements IPv6 multicast listener management based on the query/response mechanism.
MLDv1 uses two types of query messages:
l General query: an IPv6 multicast router or routing switch sends periodical general queries to determine what IPv6 multicast addresses have active listeners on the local subnet.
l Multicast-address-specific query: an IPv6 multicast router or routing switch sends multicast-address-specific queries to determine whether any listeners for particular IPv6 multicast addresses exist on the local subnet.
I. 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.
II. 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, 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.
III. Leaving an IPv6 multicast group
When a host leaves a multicast group:
1) This host sends a done message to all IPv6 multicast routers (the destination address is FF02::2) on the local subnet.
2) Upon receiving the leave 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 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.
1.1.4 How MLDv2 Works
& Note:
Currently the S9500 series routing switches do not support the Exclude filter mode.
Compared with MLDv1, MLDv2 provides the following new features:
I. 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.
II. 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.
III. Receiver host state listening
1.1.5 MLD Message Types
The following describes the MLDv1 message format. For the description about MLDv2 message format, refer to RFC 3810.
The MLD querier learns the multicast listening states of neighbor interfaces by sending MLD query messages. Figure 1-3 shows the format of an MLDv1 query message.
Figure 1-3 Format of MLDv1 query message
Table 1-1 describes the fields in Figure 1-3.
Table 1-1 Description on fields in an MLD query message
|
Field |
Description |
|
Type |
Message type. 130 stands for query message; 131 stands for report message; 132 for leave group message. |
|
Code |
Code: initialized to 0 by the sender and ignored by receivers |
|
Checksum |
Standard IPv6 checksum |
|
Maximum Response Delay |
Maximum response delay allowed before a host sends a report message |
|
Reserved |
Reserved field: initialized to 0 by the sender and ignored by receivers |
|
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. l It is sent to the IPv6 multicast address that the message sender joins in or leaves |
1.1.6 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
1.2 Configuration Task List
|
Task |
Remarks |
|
|
Required |
||
|
Option |
||
|
Optional |
||
|
Optional |
||
& Note:
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.
1.3 Configuring Basic Functions of MLD
1.3.1 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.
1.3.2 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 VLAN interface view |
interface interface-type interface-number |
— |
|
Enable MLD |
mld enable |
Required Disabled by default |
Caution:
l Hosts can join IPv6 multicast groups only after MLD is enabled on the receiver-side DR. For details of a DR, refer to IPv6 PIM Configuration in the IP Multicast Volume.
l After MLD is enabled on a VLAN interface, it is not allowed to enable MLD Snooping in the corresponding VLAN, and vice versa.
1.3.3 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.
I. Configuring an MLD version globally
Follow these steps to configure the MLD version globally:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter MLD view |
mld |
— |
|
Configure the MLD version |
version version-number |
Optional MLDv1 by default |
II. Configuring an MLD version on an interface
Follow these steps to configure the MLD version on an interface:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter VLAN interface view |
interface interface-type interface-number |
— |
|
Configure the MLD version |
mld version version-number |
Optional MLDv1 by default |
1.4 Adjusting MLD Performance
1.4.1 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 Query interval
l MLD querier robustness variable
l Maximum response delay of MLD general query messages
l MLD other querier present interval
l MLD last listener query interval
1.4.2 Configuring MLD Message Options
As IPv6 multicast groups change dynamically, a device cannot join all IPv6 multicast groups. For this reason, when receiving an IPv6 multicast packet but unable to locate the outgoing interface for the destination multicast group, MLD needs to leverage the Router-Alert option to pass the IPv6 multicast packet to the upper-layer protocol for processing. For details about the Router-Alert option, refer to RFC 2113.
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 contain the Router-Alert option.
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. In this case, when the device receives an MLD message, it checks it for the Router-Alert option, and discards it if it does not carry the Router-Alert option.
I. 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. |
II. 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 VLAN 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. |
1.4.3 Configuring MLD Queries and Responses
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.
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”. 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”. Both startup query count and last listener query count are set to the MLD querier robustness variable. 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 timers 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 message from the querier before the other querier present timer expires, it will assume that the querier has failed and will initiate a new querier election process. Otherwise, the non-querier will reset its timeout time.
I. Configuring MLD queries and responses globally
Follow these steps to configure MLD queries and responses globally:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter MLD view |
mld |
— |
|
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 last listener query interval |
lastlistener-queryinterval interval |
Optional 1 second by default |
|
Configure the other querier present interval |
timer other-querier-present interval |
Optional For the default, see Note below. |
II. Configuring MLD queries and responses on an interface
Follow these steps to configure MLD queries and responses on an interface
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter VLAN interface view |
interface interface-type interface-number |
— |
|
Configure the MLD query interval |
mld 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 |
mld max-response-time interval |
Optional 10 seconds by default |
|
Configure the last listener query interval |
mld lastlistener-queryinterval interval |
Optional 1 second by default |
|
Configure the other querier present interval |
mld timer other-querier-present interval |
Optional For the default, see Note below. |
& Note:
About other querier present interval:
l If not configured manually, 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. By default, the 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 manually configured, the other querier present interval takes the configured value.
Caution:
l Make sure that the other querier present interval is greater than the MLD query interval; otherwise the MLD querier may frequently change.
l 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.
l When a device serves as the MLD querier on multiple subnets attached to it, excessive query tasks will affect the device performance. In this case, you can configure properly longer query intervals than usual.
1.5 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-id ] [ 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 |
|
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 |
Caution:
l The reset mld group command cause an interruption of receivers’ reception of multicast data.
l The reset mld group command cannot clear the MLD multicast group information of static joins.
1.6 MLD Configuration Example
I. 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-DM network through VLAN-interface 101.
l Switch B and Switch C connect to N2 through their respective VLAN-interface 200, and to other devices in the IPv6 PIM network through VLAN-interface 201 and VLAN-interface 202.
l MLDv1 is required between Switch A and N1, and between the other two Switches (Switch B and Switch C) and N2, with Switch B as the MLD querier.
II. Network diagram
Figure 1-4 Network diagram for MLD configuration
III. Configuration procedure
& Note:
In the configuration procedure, only the commands related to the MLD configuration are listed.
1) Enable IPv6 forwarding, and configure IPv6 addresses and IPv6 unicast routing.
Enable IPv6 forwarding on each router and configure an IPv6 address and prefix length for each interface as shown in Figure 1-4. The detailed configuration steps are omitted here.
Configure OSPFv3 for interoperation between the switches. Ensure the network-layer interoperation between Switch A, Switch B, and Switch C on the IPv6 PIM-DM 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 MLD on the host interfaces.
# Enable IPv6 multicast routing on Switch A, enable MLD and IPv6 PIM-DM on VLAN-interface 100, and set the MLD version number to 1.
<SwitchA> system-view
[SwitchA] multicast ipv6 routing-enable
[SwitchA] interface vlan-interface 100
[SwitchA-Vlan-interface100] mld enable
[SwitchA-Vlan-interface100] mld version 1
[SwitchA-Vlan-interface100] pim ipv6 dm
[SwitchA-Vlan-interface100] quit
# Enable IPv6 multicast routing on Switch B, enable MLD and IPv6 PIM-DM on VLAN-interface 200, and set the MLD version number to 1.
<SwitchB> system-view
[SwitchB] multicast ipv6 routing-enable
[SwitchB] interface vlan-interface 200
[SwitchB-Vlan-interface200] mld enable
[SwitchB-Vlan-interface200] mld version 1
[SwitchB-Vlan-interface200] pim ipv6 dm
[SwitchB-Vlan-interface200] quit
# Enable IPv6 multicast routing on Switch C, enable MLD and IPv6 PIM-DM on VLAN-interface 200, and set the MLD version number to 1.
<SwitchC> system-view
[SwitchC] multicast ipv6 routing-enable
[SwitchC] interface vlan-interface 200
[SwitchC-Vlan-interface200] mld enable
[SwitchC-Vlan-interface200] mld version 1
[SwitchC-Vlan-interface200] pim ipv6 dm
[SwitchC-Vlan-interface200] quit
3) Verify the configuration.
Carry out the display mld interface command to display the MLD configuration and running information on each router interface. Example:
# View 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
1.7 Troubleshooting MLD
1.7.1 No Member Information on the Receiver-Side DR
I. Symptom
When a host sends a message for joining IPv6 multicast group G, there is no member information of multicast group G on the receiver-side DR.
II. Analysis
l The correctness of networking and interface connections directly affects the generation of IPv6 group member information.
l IPv6 multicast routing must be enabled on the device.
III. Solution
1) Check that the networking is correct and that interface connections are correct.
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 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.
1.7.2 Inconsistent Memberships on Routers on the Same Subnet
I. Symptom
Different memberships are maintained on different MLD routers or route switches on the same subnet.
II. Analysis
l A router or routing switch 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 or routing switches on the same subnet will surely result in inconsistent MLD memberships.
l If the S9500 series routing switches are working with other devices (third-party routers or networking devices, for example) on the same network, there can be an issue of inconsistent MLD versions. Two MLD versions are currently available. Although routers or routing switches running different MLD versions are compatible with hosts, all devices on the same subnet must run the same MLD version. Inconsistent MLD versions running on routers routing switches on the same subnet will also lead to chaos of MLD memberships.
III. 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 or routing switches on the same subnet to check the MLD timers for consistent configurations.
3) Use the display mld interface command to check that the routers or routing switches are running the same MLD version.
