- Information About MLD
- Licensing Requirements for MLD
- Prerequisites for MLD
- Guidelines and Limitations for MLD
- Default Settings for MLD
- Configuring MLD Parameters
- Verifying the MLD Configuration
- Configuration Example for MLD Example Configuration
- Where to Go Next
- Additional References
- Feature History for MLD
Configuring MLD
This chapter describes how to configure the Multicast Listener Discovery (MLD) on Cisco NX-OS devices for IPv6 networks.
This chapter includes the following sections:
- Information About MLD
- Licensing Requirements for MLD
- Prerequisites for MLD
- Guidelines and Limitations for MLD
- Default Settings for MLD
- Configuring MLD Parameters
- Verifying the MLD Configuration
- Configuration Example for MLD Example Configuration
- Where to Go Next
- Additional References
- Feature History for MLD
Information About MLD
MLD is an IPv6 protocol that a host uses to request multicast data for a particular group. Using the information obtained through MLD, the software maintains a list of multicast group or channel memberships on a per-interface basis. The devices that receive MLD packets send the multicast data that they receive for requested groups or channels out the network segment of the known receivers.
MLDv1 is derived from IGMPv2, and MLDv2 is derived from IGMPv3. IGMP uses IP Protocol 2 message types, while MLD uses IP Protocol 58 message types, which is a subset of the ICMPv6 messages.
The MLD process is started automatically on the device. You cannot enable MLD manually on an interface. MLD is automatically enabled when you perform one of the following configuration tasks on an interface:
This section includes the following topics:
MLD Versions
The device supports MLDv1 and MLDv2. MLDv2 supports MLDv1 listener reports.
By default, the software enables MLDv2 when it starts the MLD process. You can enable MLDv1 on interfaces where you want only its capabilities.
MLDv2 includes the following key changes from MLDv1:
- Support for Source-Specific Multicast (SSM), which builds shortest path trees from each receiver to the source, through the following features:
– Host messages that can specify both the group and the source.
– The multicast state that is maintained for groups and sources, not just for groups as in MLDv1.
- Hosts no longer perform report suppression, which means that hosts always send MLD listener reports when an MLD query message is received.
For detailed information about MLDv1, see RFC 2710. For detailed information about MLDv2, see RFC 3810.
MLD Basics
The basic MLD process of a router that discovers multicast hosts is shown in Figure 1-1. Hosts 1, 2, and 3 send unsolicited MLD listener report messages to initiate receiving multicast data for a group or channel.
Figure 1-1 MLD Query-Response Process
In Figure 1-1, router A, which is the MLD designated querier on the subnet, sends a general query message to the link-scope all-nodes multicast address FF02::1 periodically to discover what multicast groups hosts want to receive. The group-specific query is used to discover whether a specific group is requested by any hosts. You can configure the group membership timeout value that the router uses to determine that no members of a group or source exist on the subnet. For more information about configuring the MLD parameters, see the “Configuring MLD Interface Parameters” section.
In Figure 1-1, host 1’s listener report is suppressed, and host 2 sends its listener report for group FFFE:FFFF:90::1 first. Host 1 receives the report from host 2. Because only one listener report per group needs to be sent to the router, other hosts suppress their reports to reduce network traffic. Each host waits for a random time interval to avoid sending reports at the same time. You can configure the query maximum response time parameter to control the interval in which hosts randomize their responses.
Note MLDv1 membership report suppression occurs only on hosts that are connected to the same port.
In Figure 1-2, router A sends the MLDv2 group-and-source-specific query to the LAN. Hosts 2 and 3 respond to the query with listener reports that indicate that they want to receive data from the advertised group and source. This MLDv2 feature supports SSM. For information about configuring SSM translation to support SSM for MLDv1 hosts, see the “Configuring an MLD SSM Translation” section.
Note In MLDv2, all hosts respond to queries.
Figure 1-2 MLDv2 Group-and-Source-Specific Query
The software elects a router as the MLD querier on a subnet if it has the lowest IP address. As long as a router continues to receive query messages from a router with a lower IP address, it remains a nonquerier and resets a timer that is based on its querier timeout value. If the querier timer of a router expires, it becomes the designated querier. If that router later receives a host query message from a router with a lower IP address, it drops its role as the designated querier and sets its querier timer again.
Messages sent by the designated querier have a time-to-live (TTL) value of 1, which means that the messages are not forwarded by the directly connected routers on the subnet, and you can configure the frequency and number of query messages sent specifically for MLD startup. You can configure a short query interval at startup so that the group state is established as quickly as possible. Although usually unnecessary, you can tune the query interval used after startup to a value that balances responsiveness to host group membership and the traffic created on the network.
When a multicast host leaves a group, it should send a done message for MLDv1, or a listener report that excludes the group to the link-scope all-routers multicast address FF02::2. To check if this host is the last host to leave the group, the software sends an MLD query message and starts a timer that you can configure called the last member query response interval. If no reports are received before the timer expires, the software removes the group state. The router continues to send multicast traffic for a group until its state is removed.
You can configure a robustness value to compensate for the packet loss on a congested network. The robustness value is used by the MLD software to determine the number of times to send messages.
Link local addresses in the range FF02::0/16 have link scope, as defined by the Internet Assigned Numbers Authority (IANA). Network protocols on a local network segment use these addresses; routers do not forward these addresses because they have a TTL of 1. By default, the MLD process sends listener reports only for nonlink local addresses, but you can configure the software to send reports for link local addresses.
For more information about configuring the MLD parameters, see the “Configuring MLD Interface Parameters” section.
Virtualization Support
A virtual device context (VDC) is a logical representation of a set of system resources. Within each VDC, you can define multiple virtual routing and forwarding (VRF) instances. One MLD process can run per VDC. The MLD process supports all VRFs in that VDC.
You can use the show commands with a VRF argument to provide a context for the information displayed. The default VRF is used if no VRF argument is supplied.
For information about configuring VDCs, see the Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide, Release 4.2.
For information about configuring VRFs, see the Cisco Nexus 7000 Series NX-OS Unicast Routing Configuration Guide, Release 5.x.
Licensing Requirements for MLD
The following table shows the licensing requirements for this feature:
Prerequisites for MLD
MLD has the following prerequisites:
- You are logged onto the device.
- You are in the correct virtual device context (VDC). A VDC is a logical representation of a set of system resources. You can use the switchto vdc command with a VDC number.
- For global configuration commands, you are in the correct virtual routing and forwarding (VRF) mode. The default configuration mode shown in the examples in this chapter applies to the default VRF.
Guidelines and Limitations for MLD
Default Settings for MLD
Table 1-1 lists the default settings for MLD parameters.
|
|
---|---|
Configuring MLD Parameters
You can configure the MLD global and interface parameters to affect the operation of the MLD process.
Note Before you can access the MLD commands, you must enable the MLD feature.
This section includes the following topics:
Note If you are familiar with the Cisco IOS CLI, be aware that the Cisco NX-OS commands for this feature might differ from the Cisco IOS commands that you would use.
Configuring MLD Interface Parameters
You can configure the optional MLD interface parameters described in Table 1-2 .
|
|
---|---|
MLD version that is enabled on the interface. MLDv2 supports MLDv1. The MLD version can be 1 or 2. The default is 2. |
|
Multicast groups that are statically bound to the interface. You can configure the groups to join the interface with the (*, G) state or specify a source IP to join with the (S, G) state. You can specify a route-map policy name that lists the group prefixes, group ranges, and source prefixes to use with the match ip multicast command. Note Although you can configure the (S, G) state, the source tree is built only if you enable MLDv2. For information about SSM translation, see the “Configuring an MLD SSM Translation” section. You can configure a multicast group on all the multicast-capable routers on the network so that pinging the group causes all the routers to respond. |
|
Multicast groups that are statically bound to the output interface. You can configure the groups to join the output interface with the (*, G) state or specify a source IP to join with the (S, G) state. You can specify a route-map policy name that lists the group prefixes, group ranges, and source prefixes to use with the match ip multicast command. Note Although you can configure the (S, G) state, the source tree is built only if you enable MLDv2. For information about SSM translation, see the “Configuring an MLD SSM Translation” section. |
|
Startup query interval. By default, this interval is shorter than the query interval so that the software can establish the group state as quickly as possible. Values range from 1 to 18,000 seconds. The default is 30 seconds. |
|
Number of queries sent at startup that are separated by the startup query interval. Values range from 1 to 10. The default is 2. |
|
Robustness variable that you can tune to reflect expected packet loss on a congested network. You can increase the robustness variable to increase the number of times that packets are resent. Values range from 1 to 7. The default is 2. |
|
Number of seconds that the software waits after the previous querier has stopped querying and before it takes over as the querier. Values range from 1 to 65,535 seconds. The default is 255 seconds. |
|
Maximum response time advertised in MLD queries. You can tune the burstiness of MLD messages on the network by setting a larger value so that host responses are spread out over a longer time. This value must be less than the query interval. Values range from 1 to 25 seconds. The default is 10 seconds. |
|
Frequency at which the software sends MLD host query messages. You can tune the number of MLD messages on the network by setting a larger value so that the software sends MLD queries less often. Values range from 1 to 18,000 seconds. The default is 125 seconds. |
|
Query interval for response to an MLD query that the software sends after receiving a host leave message from the last known active host on the subnet. If no reports are received in the interval, the group state is deleted. You can use this value to tune how quickly the software stops transmitting on the subnet. The software can detect the loss of the last member of a group or source more quickly when the values are smaller. Values range from 1 to 25 seconds. The default is 1 second. |
|
Number of times that the software sends an MLD query, separated by the last member query response interval, in response to a host leave message from the last known active host on the subnet. Values range from 1 to 5. The default is 2. |
|
Group membership interval that must pass before the router decides that no members of a group or source exist on the network. Values range from 3 to 65,535 seconds. The default is 260 seconds. |
|
Option that enables sending reports for groups in FF02::0/16. Link local addresses are used only by protocols on the local network. Reports are always sent for nonlink local groups. The default is disabled. |
|
Access policy for MLD reports that is based on a route-map policy1. |
|
Option that configures a route-map policy 1 to control the multicast groups that hosts on the subnet serviced by an interface can join. |
|
Option that minimizes the leave latency of MLDv1 group memberships on a given MLD interface because the device does not send group-specific queries. When immediate leave is enabled, the device will remove the group entry from the multicast routing table immediately upon receiving a leave message for the group. The default is disabled. Note Use this command only when there is one receiver behind the interface for a given group. |
1.To configure route-map policies, see the Cisco Nexus 7000 Series NX-OS Unicast Routing Configuration Guide, Release 5.x. |
For information about configuring multicast route maps, see the “Configuring Route Maps to Control RP Information Distribution” section.
SUMMARY STEPS
ipv6 mld join-group { group [ source source ] | route-map policy-name }
ipv6 mld static-oif { group [ source source ] | route-map policy-name }
ipv6 mld startup-query-interval seconds
ipv6 mld startup-query-count count
ipv6 mld robustness-variable value
ipv6 mld querier-timeout seconds
ipv6 mld query-timeout seconds
ipv6 mld query-max-response-time seconds
ipv6 mld query-interval interval
ipv6 mld last-member-query-response-time seconds
ipv6 mld last-member-query-count count
ipv6 mld group-timeout seconds
ipv6 mld report-link-local-groups
4. (Optional) show ipv6 mld interface [ interface ] [ vrf vrf-name | all ] [ brief ]
DETAILED STEPS
Configuring an MLD SSM Translation
You can configure an SSM translation to provide SSM support when the router receives MLDv1 listener reports. Only MLDv2 provides the capability to specify group and source addresses in listener reports. By default, the group prefix range is FF3x/96. To modify the PIM SSM range, see the “Configuring SSM” section.
Table 1-3 lists the example SSM translations.
|
|
---|---|
Table 1-4 shows the resulting M6RIB routes that the MLD process creates when it applies an SSM translation to the MLD v1 listener report. If more than one translation applies, the router creates the (S, G) state for each translation.
|
|
---|---|
(2001:0DB8:0:ABCD::1, FF30:10::10) |
SUMMARY STEPS
2. ipv6 [ icmp ] mld ssm-translate group-prefix source-addr
DETAILED STEPS
Verifying the MLD Configuration
To display the MLD configuration information, perform one of the following tasks:
For detailed information about the fields in the output from these commands, see the Cisco Nexus 7000 Series NX-OS Multicast Routing Command Reference, Release 5.x.
Configuration Example for MLD Example Configuration
The following example shows how to configure the MLD parameters:
Where to Go Next
You can configure the MBGP feature that works with PIM6 and MLD:
Additional References
For additional information related to implementing IGMP, see the following sections:
Related Documents
|
|
---|---|
Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide, Release 4.2 |
|
Cisco Nexus 7000 Series NX-OS Multicast Routing Command Reference, Release 5.x |
Standards
|
|
---|---|
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature. |
Feature History for MLD
Table 1-5 lists the release history for this feature.
|
|
|
---|---|---|
Minimizes the leave latency of IGMPv2 or MLDv1 group memberships on a given IGMP or MLD interface because the device does not send group-specific queries. |