IP Multicast: LSM Configuration Guide, Cisco IOS XE Release 3S (Cisco ASR 1000)
MLD Group Limits
MLD Group Limits
Last Updated: November 20, 2012
The IPv6 Multicast Listener Discovery (MLD) group limits feature provides global and per-interface MLD join limits.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Information About MLD Group Limits
Multicast Listener Discovery Protocol for IPv6
To start implementing multicasting in the campus network, users must first define who receives the multicast. The MLD protocol is used by IPv6 devices to discover the presence of multicast listeners (for example, nodes that want to receive multicast packets) on their directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. It is used for discovering local group and source-specific group membership. The MLD protocol provides a means to automatically control and limit the flow of multicast traffic throughout your network with the use of special multicast queriers and hosts.
The difference between multicast queriers and hosts is as follows:
A set of queriers and hosts that receive multicast data streams from the same source is called a multicast group. Queriers and hosts use MLD reports to join and leave multicast groups and to begin receiving group traffic.
MLD uses the Internet Control Message Protocol (ICMP) to carry its messages. All MLD messages are link-local with a hop limit of 1, and they all have the alert option set. The alert option implies an implementation of the hop-by-hop option header.
MLD has three types of messages:
Group-specific and multicast-address-specific queries are the same. A group address is a multicast address.
An MLD report must be sent with a valid IPv6 link-local source address, or the unspecified address (::), if the sending interface has not yet acquired a valid link-local address. Sending reports with the unspecified address is allowed to support the use of IPv6 multicast in the Neighbor Discovery Protocol.
For stateless autoconfiguration, a node is required to join several IPv6 multicast groups in order to perform duplicate address detection (DAD). Prior to DAD, the only address the reporting node has for the sending interface is a tentative one, which cannot be used for communication. Therefore, the unspecified address must be used.
MLD states that result from MLD version 2 or MLD version 1 membership reports can be limited globally or by interface. The MLD group limits feature provides protection against denial of service (DoS) attacks caused by MLD packets. Membership reports in excess of the configured limits will not be entered in the MLD cache, and traffic for those excess membership reports will not be forwarded.
MLD provides support for source filtering. Source filtering allows a node to report interest in listening to packets only from specific source addresses (as required to support SSM), or from all addresses except specific source addresses sent to a particular multicast address.
When a host using MLD version 1 sends a leave message, the device needs to send query messages to reconfirm that this host was the last MLD version 1 host joined to the group before it can stop forwarding traffic. This function takes about 2 seconds. This "leave latency" is also present in IGMP version 2 for IPv4 multicast.
How to Implement MLD Group Limits
Implementing MLD Group Limits Globally
Implementing MLD Group Limits per Interface
Configuration Examples for MLD Group Limits
Example: Implementing MLD Group Limits
This example shows the groups and channels that are being accounted when the MLD group limit function is active:
Device# show ipv6 mld groups FF03::1 detail Interface: FastEthernet5/1 Group: FF03::1 Uptime: 00:00:05 Router mode: EXCLUDE (Expires: 00:04:14) Host mode: INCLUDE Last reporter: FE80::20A:8BFF:FE4D:6039 State accounted Source list is empty Interface: FastEthernet5/1 Group: FF33::1 Uptime: 00:00:03 Router mode: INCLUDE Host mode: INCLUDE Last reporter: FE80::20A:8BFF:FE4D:6039 Group source list: Source Address Uptime Expires Fwd Flags 2001:DB8:0::1 00:00:03 00:04:16 Yes Remote Ac 4
The following example shows all of the groups joined by Fast Ethernet interface 2/1, including link-local groups used by network protocols.
Device# show ipv6 mld groups FastEthernet 2/1 MLD Connected Group Membership Group Address Interface Uptime Expires FF02::2 FastEthernet2/1 3d18h never FF02::D FastEthernet2/1 3d18h never FF02::16 FastEthernet2/1 3d18h never FF02::1:FF00:1 FastEthernet2/1 3d18h 00:00:27 FF02::1:FF00:79 FastEthernet2/1 3d18h never FF02::1:FF23:83C2 FastEthernet2/1 3d18h 00:00:22 FF02::1:FFAF:2C39 FastEthernet2/1 3d18h never FF06:7777::1 FastEthernet2/1 3d18h 00:00:26
The following is sample output from the show ipv6 mld groups summary command:
Device# show ipv6 mld groups summary MLD Route Summary No. of (*,G) routes = 5 No. of (S,G) routes = 0
Feature Information for MLD Group Limits
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2012 Cisco Systems, Inc. All rights reserved.