Configuring MLD·· 1

Overview·· 1

How MLDv1 works 1

MLDv2 enhancements 3

Protocols and standards 4

MLD configuration task list 4

Configuring basic MLD functions 5

Enabling MLD·· 5

Specifying the MLD version· 5

Configuring an interface as a static member interface· 5

Configuring an IPv6 multicast group filter 6

Adjusting MLD performance· 6

Enabling MLD fast-leave processing· 7

Displaying and maintaining MLD·· 7

MLD configuration examples 7

Network requirements 8

Configuration procedure· 8

Verifying the configuration· 9

Troubleshooting MLD·· 10

No member information exists on the receiver-side router 10

Inconsistent membership information on the routers on the same subnet 10

 

Overview  

Multicast Listener Discovery (MLD) establishes and maintains IPv6 multicast group memberships between a Layer 3 multicast device and its directly connected hosts.

MLD has two versions:

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

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

The two MLD versions support the ASM model. In addition, MLDv2 can directly implement the SSM model, but MLDv1 must work with the MLD SSM mapping function to implement the SSM model. For more information about the ASM and SSM models, see "Multicast overview."

How MLDv1 works

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

Electing the MLD querier

All IPv6 multicast routers that run MLD on the same subnet can monitor MLD listener report messages (often called "reports") from hosts, but the subnet needs only one router to act as the MLD querier to send MLD query messages (often called "queries"). A querier election mechanism determines which router acts 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 of the messages is FF02::1.

2.      After receiving a general query, every MLD router compares the source IPv6 address of the query with its own link-local 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 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 want to receive the IPv6 multicast data addressed to IPv6 multicast group G1, and Host A wants to receive the 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 Figure 1) maintains the IPv6 multicast group memberships:

1.      The hosts send unsolicited MLD reports to the IPv6 multicast groups 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 FF02::1) to all hosts and routers on the local subnet.

3.      After receiving a query, Host B or Host C (the delay timer of whichever expires first) sends an MLD report to the IPv6 multicast group G1 to announce its membership for G1. Assume that Host B sends the report. 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) already know 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 G2.

5.      Through the query/report process, the MLD routers learn that G1 and G2 have members on the local subnet, and the IPv6 multicast routing protocol (for example, IPv6 PIM) that is running on the routers generates (*, G1) and (*, G2) multicast forwarding entries. These entries are the basis for subsequent IPv6 multicast forwarding. The asterisk (*) represents any IPv6 multicast source.

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

Leaving an IPv6 multicast group

When a host leaves a multicast group, the following process occurs:

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 IPv6 multicast addresses queried include both the destination address field and the group address field of the message.

3.      One of the remaining members (if any on the subnet) of the group sends a report within the time of the maximum response delay advertised in the query messages.

4.      If the querier receives a report for the group within the maximum response delay time, it maintains the memberships of the IPv6 multicast group. Otherwise, the querier assumes that no hosts on the subnet are interested in IPv6 multicast traffic addressed to that group and stops maintaining the memberships of the group.

MLDv2 enhancements

MLDv2 is based on and backwards-compatible with MLDv1. MLDv2 provides hosts with enhanced control capabilities and enhances the MLD state.

Enhancements in control capability of hosts

MLDv2 has introduced IPv6 multicast source filtering modes (Include and Exclude). These modes allow a host to join a designated IPv6 multicast group and to choose whether to receive or reject multicast data from designated IPv6 multicast sources. When a host joins an IPv6 multicast group, one of the following occurs:

·           If the host 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 the host 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, …)."

 

NOTE: Currently, only the Include mode is available on the switch.

 

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 MLDv1, Host B cannot select IPv6 multicast sources when it joins IPv6 multicast group G, and IPv6 multicast streams from both Source 1 and Source 2 flow to Host B whether it needs them or not.

When MLDv2 runs 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)). Only IPv6 multicast data from Source 1 is delivered to Host B.

Enhancement in MLD state

A multicast router that is running MLDv2 maintains the multicast address state for each multicast address on each attached subnet. The multicast address state consists of the following information:

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

·           List of sources—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.

Protocols and standards

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

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

MLD configuration task list

 

Task at a glance
Configuring basic MLD functions ·       (Required.) Enabling MLD ·       (Optional.) Specifying the MLD version ·       (Optional.) Configuring an interface as a static member interface ·       (Optional.) Configuring an IPv6 multicast group filter
Adjusting MLD performance (Optional.) Enabling MLD fast-leave processing

 

Configuring basic MLD functions

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

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

·           Configure IPv6 PIM.

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

Enabling MLD

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

To enable MLD:

 

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

 

Specifying the MLD version

Because MLD message types and formats vary with MLD versions, configure the same MLD version for all routers on the same subnet. Otherwise, MLD cannot work properly.

To specify an MLD version:

 

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 an interface as a static member interface

You can configure an interface as a static member of an IPv6 multicast group or an IPv6 multicast source and group, so that the interface can receive IPv6 multicast data addressed to that IPv6 multicast group for the purpose of testing IPv6 multicast data forwarding.

Configuration guidelines

·           A static member interface has the following restrictions:

¡  If the interface is MLD and IPv6 PIM-SM enabled, it must be an IPv6 PIM-SM DR.

¡  If the interface is MLD enabled but not IPv6 PIM-SM enabled, it must be an MLD querier.

For more information about IPv6 PIM-SM and DR, see "Configuring IPv6 PIM."

·           A static member interface does not respond to queries from the MLD querier. When you configure an interface as a static member interface or cancel this configuration on the interface, the interface does not send any MLD report or an MLD done message without a request. This is because the interface is not a real member of the IPv6 multicast group or the IPv6 multicast source and group.

Configuration procedure

To configure an interface as a static member 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 as a static member interface.	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.

 

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 specify an IPv6 ACL on the interface as a packet filter so that the interface maintains only the IPv6 multicast groups that match 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 multicast group.

 

NOTE: If you configure the interface as a static member interface for an IPv6 multicast group or an IPv6 multicast source and group, this configuration is not effective for the IPv6 multicast group or the IPv6 multicast source and group.

 

Adjusting MLD performance

Before adjusting MLD performance, complete the following tasks:

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

·           Configure basic MLD functions.

Enabling MLD fast-leave processing

In some applications, such as ADSL dial-up networking, only one multicast receiver host is attached to an interface 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 fast-leave processing on the MLD querier.

With MLD 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. This reduces leave latency and preserves the network bandwidth.

To enable MLD fast-leave processing:

 

Step	Command	Remarks
1.     Enter system view.	system-view	N/A
2.     Enter interface view.	interface interface-type interface-number	N/A
3.     Enable MLD fast-leave processing.	mld fast-leave [ group-policy acl6-number ]	By default, the MLD fast-leave processing is disabled.

 

Displaying and maintaining MLD

 

CAUTION: The reset mld group command might cause IPv6 multicast data transmission failures.

 

Execute display commands in any view and reset command in user view.

 

Task	Command
Display MLD group information.	display mld group [ ipv6-group-address | interface interface-type interface-number ] [ static | verbose ]
Display MLD information.	display mld interface [ interface-type interface-number ] [ verbose ]
Remove all 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 ] ] } }

 

NOTE: The reset mld group command cannot remove static MLD group entries.

 

MLD configuration examples

 

IMPORTANT: By default, Ethernet interfaces, VLAN interfaces, and aggregate interfaces are in the state of DOWN. To configure such an interface, use the undo shutdown command to bring it up first.

 

Network requirements

Receiver hosts receive VOD information through multicast. Receivers of different organizations form stub networks N1 and N2. Host A and Host C are multicast receivers in N1 and N2, respectively.

MLDv1 runs between Switch A and N1, and between the other two switches (Switch B and Switch C) and N2. Switch A acts as the MLD querier in N1. Switch B acts as the MLD querier in N2 because it has a lower IPv6 address. One switch of the three in the IPv6 PIM network acts as the C-BSR and the C-RP.

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

Figure 3 Network diagram

 

Configuration procedure

1.      Assign an IP address and prefix length to each interface as shown in Figure 3. (Details not shown.)

2.      Configure OSPFv3 between the switches to make sure the network-layer is interoperable on the IPv6 PIM network and routing information among the switches can be dynamically updated. (Details not shown.)

3.      Configure a switch as the C-BSR and C-RP. (Details not shown.)

For the configuration procedures, see "Configuring IPv6 PIM."

4.      Enable the IPv6 multicast routing, MLD, and IPv6 PIM-SM:

# On Switch A, enable IPv6 multicast routing globally, enable MLD on VLAN-interface 100, and enable IPv6 PIM-SM on each interface.

<SwitchA> system-view

[SwitchA] ipv6 multicast routing-enable

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] mld enable

[SwitchA-Vlan-interface100] ipv6 pim sm

[SwitchA-Vlan-interface100] quit

[SwitchA] interface vlan-interface 101

[SwitchA-Vlan-interface101] ipv6 pim sm

[SwitchA-Vlan-interface101] quit

# On Switch B, enable IPv6 multicast routing globally, enable MLD on VLAN-interface 200, and enable IPv6 PIM-SM on each interface.

<SwitchB> system-view

[SwitchB] ipv6 multicast routing-enable

[SwitchB] interface vlan-interface 200

[SwitchB-Vlan-interface200] mld enable

[SwitchB-Vlan-interface200] ipv6 pim sm

[SwitchB-Vlan-interface200] quit

[SwitchB] interface vlan-interface 201

[SwitchB-Vlan-interface201] ipv6 pim sm

[SwitchB-Vlan-interface201] quit

# On Switch C, enable IPv6 multicast routing globally, enable MLD on VLAN-interface 200, and enable IPv6 PIM-SM on each interface.

<SwitchC> system-view

[SwitchC] ipv6 multicast routing-enable

[SwitchC] interface vlan-interface 200

[SwitchC-Vlan-interface200] mld enable

[SwitchC-Vlan-interface200] ipv6 pim sm

[SwitchC-Vlan-interface200] quit

[SwitchC] interface vlan-interface 202

[SwitchC-Vlan-interface202] ipv6 pim sm

[SwitchC-Vlan-interface202] quit

5.      Configure an IPv6 multicast group filter on Switch A so that the hosts connected to VLAN-interface 100 can join the IPv6 multicast group FF1E::101 only.

[SwitchA] acl ipv6 number 2001

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

[SwitchA-acl6-basic-2001] quit

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] mld group-policy 2001

[SwitchA-Vlan-interface100] quit

Verifying the configuration

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

[SwitchB] display mld interface vlan-interface 200

Interface information

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

   MLD is enabled.

   MLD version: 1

   Query interval for MLD: 125s

   Other querier present time for MLD: 255s

   Maximum query response time for MLD: 10s

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

  MLD groups reported in total: 1

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 immediate 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. 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 cannot 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 the command does not produce output, the interface is in an abnormal state. The reason might be 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 it is not enabled, use the ipv6 multicast routing-enable command in system view to enable IPv6 multicast routing. In addition, verify that MLD is enabled on the associated interfaces.

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 filter out the reports sent by the host to the IPv6 multicast group G.

Inconsistent membership information on the routers on the same subnet

Symptom

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

Analysis

·           A router running MLD maintains multiple parameters for each interface. Inconsistent MLD interface parameter configurations for routers on the same subnet result in inconsistent MLD memberships.

·           Although routers are partially compatible with hosts that separately run different versions of MLD, all routers on the same subnet must run the same MLD version. Inconsistent MLD versions running on routers on the same subnet lead to inconsistent MLD memberships.

Solution

1.      Use the display current-configuration command to verify the MLD 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.