Configuring MLD
Understanding MLD
The Multicast Listener Discovery (MLD) Protocol manages the membership of hosts and routers in multicast groups. IP version 6 (IPv6) multicast routers use MLD to learn, for each of their attached physical networks, which groups have interested listeners. Each routing device maintains a list of host multicast addresses that have listeners for each subnetwork, as well as a timer for each address. However, the routing device does not need to know the address of each listener—just the address of each host. The routing device provides addresses to the multicast routing protocol it uses, which ensures that multicast packets are delivered to all subnetworks where there are interested listeners. In this way, MLD is used as the transport for the Protocol Independent Multicast (PIM) Protocol.
MLD is an integral part of IPv6 and must be enabled on all IPv6 routing devices and hosts that need to receive IP multicast traffic. The Junos OS supports MLD versions 1 and 2. Version 2 is supported for source-specific multicast (SSM) include and exclude modes.
In include mode, the receiver specifies the source or sources it is interested in receiving the multicast group traffic from. Exclude mode works the opposite of include mode. It allows the receiver to specify the source or sources it is not interested in receiving the multicast group traffic from.
For each attached network, a multicast routing device can be either a querier or a nonquerier. A querier routing device, usually one per subnet, solicits group membership information by transmitting MLD queries. When a host reports to the querier routing device that it has interested listeners, the querier routing device forwards the membership information to the rendezvous point (RP) routing device by means of the receiver's (host's) designated router (DR). This builds the rendezvous-point tree (RPT) connecting the host with interested listeners to the RP routing device. The RPT is the initial path used by the sender to transmit information to the interested listeners. Nonquerier routing devices do not transmit MLD queries on a subnet but can do so if the querier routing device fails.
All MLD-configured routing devices start as querier routing devices on each attached subnet (see Figure 1). The querier routing device on the right is the receiver's DR.
To elect the querier routing device, the routing devices exchange query messages containing their IPv6 source addresses. If a routing device hears a query message whose IPv6 source address is numerically lower than its own selected address, it becomes a nonquerier. In Figure 2, the routing device on the left has a source address numerically lower than the one on the right and therefore becomes the querier routing device.
In the practical application of MLD, several routing devices on a subnet are nonqueriers. If the elected querier routing device fails, query messages are exchanged among the remaining routing devices. The routing device with the lowest IPv6 source address becomes the new querier routing device. The IPv6 Neighbor Discovery Protocol (NDP) implementation drops incoming Neighbor Announcement (NA) messages that have a broadcast or multicast address in the target link-layer address option. This behavior is recommended by RFC 2461.
The querier routing device sends general MLD queries on the link-scope all-nodes multicast address FF02::1 at short intervals to all attached subnets to solicit group membership information (see Figure 3). Within the query message is the maximum response delay value, specifying the maximum allowed delay for the host to respond with a report message.
If interested listeners are attached to the host receiving the query, the host sends a report containing the host's IPv6 address to the routing device (see Figure 4). If the reported address is not yet in the routing device's list of multicast addresses with interested listeners, the address is added to the list and a timer is set for the address. If the address is already on the list, the timer is reset. The host's address is transmitted to the RP in the PIM domain.
If the host has no interested multicast listeners, it sends a done message to the querier routing device. On receipt, the querier routing device issues a multicast address-specific query containing the last listener query interval value to the multicast address of the host. If the routing device does not receive a report from the multicast address, it removes the multicast address from the list and notifies the RP in the PIM domain of its removal (see Figure 5).
If a done message is not received by the querier routing device, the querier routing device continues to send multicast address-specific queries. If the timer set for the address on receipt of the last report expires, the querier routing device assumes there are no longer interested listeners on that subnet, removes the multicast address from the list, and notifies the RP in the PIM domain of its removal (see Figure 6).
See Also
Configuring MLD
To configure the Multicast Listener Discovery (MLD) Protocol,
include the mld statement:
mld { accounting; interface interface-name { disable; (accounting | no-accounting); group-policy [ policy-names ]; immediate-leave; oif-map [ map-names ]; passive; ssm-map ssm-map-name; static { group multicast-group-address { exclude; group-count number; group-increment increment; source ip-address { source-count number; source-increment increment; } } } version version; } maximum-transmit-rate packets-per-second; query-interval seconds; query-last-member-interval seconds; query-response-interval seconds; robust-count number; }
You can include this statement at the following hierarchy levels:
[edit protocols][edit logical-systems logical-system-name protocols]
By default, MLD is enabled on all broadcast interfaces when you configure Protocol Independent Multicast (PIM) or the Distance Vector Multicast Routing Protocol (DVMRP).
Enabling MLD
The Multicast Listener Discovery (MLD) Protocol manages multicast groups by establishing, maintaining, and removing groups on a subnet. Multicast routing devices use MLD to learn which groups have members on each of their attached physical networks. MLD must be enabled for the router to receive IPv6 multicast packets. MLD is only needed for IPv6 networks, because multicast is handled differently in IPv4 networks. MLD is enabled on all IPv6 interfaces on which you configure PIM and on all IPv6 broadcast interfaces when you configure DVMRP.
MLD specifies different behaviors for multicast listeners and for routers. When a router is also a listener, the router responds to its own messages. If a router has more than one interface to the same link, it needs to perform the router behavior over only one of those interfaces. Listeners, on the other hand, must perform the listener behavior on all interfaces connected to potential receivers of multicast traffic.
If MLD is not running on an interface—either because PIM and DVMRP are not configured on the interface or because MLD is explicitly disabled on the interface—you can explicitly enable MLD.
To explicitly enable MLD:
See Also
Modifying the MLD Version
By default, the router supports MLD version 1 (MLDv1). To enable
the router to use MLD version 2 (MLDv2) for source-specific multicast
(SSM) only, include the version 2 statement.
If you configure the MLD version setting at the individual interface
hierarchy level, it overrides configuring the IGMP version using the interface all statement.
If a source address is specified in a multicast group that is statically configured, the version must be set to MLDv2.
To change an MLD interface to version 2:
See Also
Modifying the MLD Host-Query Message Interval
The objective of MLD is to keep routers up to date with IPv6 group membership of the entire subnet. Routers need not know who all the members are, only that members exist. Each host keeps track of which multicast groups are subscribed to. On each link, one router is elected the querier. The MLD querier router periodically sends general host-query messages on each attached network to solicit membership information. These messages solicit group membership information and are sent to the link-scope all-nodes address FF02::1. A general host-query message has a maximum response time that you can set by configuring the query response interval.
The query response timeout, the query interval, and the robustness variable are related in that they are all variables that are used to calculate the multicast listener interval. The multicast listener interval is the number of seconds that must pass before a multicast router determines that no more members of a host group exist on a subnet. The multicast listener interval is calculated as the (robustness variable x query-interval) + (1 x query-response-interval). If no reports are received for a particular group before the multicast listener interval has expired, the routing device stops forwarding remotely-originated multicast packets for that group onto the attached network.
By default, host-query messages are sent every 125 seconds. You can change this interval to change the number of MLD messages sent on the subnet.
To modify the query interval:
See Also
Modifying the MLD Query Response Interval
The query response interval is the maximum amount of time that can elapse between when the querier router sends a host-query message and when it receives a response from a host. You can change this interval to adjust the burst peaks of MLD messages on the subnet. Set a larger interval to make the traffic less bursty.
The query response timeout, the query interval, and the robustness variable are related in that they are all variables that are used to calculate the multicast listener interval. The multicast listener interval is the number of seconds that must pass before a multicast router determines that no more members of a host group exist on a subnet. The multicast listener interval is calculated as the (robustness variable x query-interval) + (1 x query-response-interval). If no reports are received for a particular group before the multicast listener interval has expired, the routing device stops forwarding remotely-originated multicast packets for that group onto the attached network.
The default query response interval is 10 seconds. You can configure a subsecond interval up to one digit to the right of the decimal point. The configurable range is 0.1 through 0.9, then in 1-second intervals 1 through 999,999.
To modify the query response interval:
See Also
Modifying the MLD Last-Member Query Interval
The last-member query interval (also called the last-listener query interval) is the maximum amount of time between group-specific query messages, including those sent in response to done messages sent on the link-scope-all-routers address FF02::2. You can lower this interval to reduce the amount of time it takes a router to detect the loss of the last member of a group.
When the routing device that is serving as the querier receives a leave-group (done) message from a host, the routing device sends multiple group-specific queries to the group. The querier sends a specific number of these queries, and it sends them at a specific interval. The number of queries sent is called the last-listener query count. The interval at which the queries are sent is called the last-listener query interval. Both settings are configurable, thus allowing you to adjust the leave latency. The IGMP leave latency is the time between a request to leave a multicast group and the receipt of the last byte of data for the multicast group.
The last-listener query count x (times) the last-listener query interval = (equals) the amount of time it takes a routing device to determine that the last member of a group has left the group and to stop forwarding group traffic.
The default last-listener query interval is 1 second. You can configure a subsecond interval up to one digit to the right of the decimal point. The configurable range is 0.1 through 0.9, then in 1-second intervals 1 through 999,999.
To modify this interval:
You can configure the last-member query count by configuring the robustness variable. The two are always equal.
See Also
Specifying Immediate-Leave Host Removal for MLD
The immediate leave setting is useful for minimizing the leave latency of MLD memberships. When this setting is enabled, the routing device leaves the multicast group immediately after the last host leaves the multicast group.
The immediate-leave setting enables host tracking, meaning that the device keeps track of the hosts that send join messages. This allows MLD to determine when the last host sends a leave message for the multicast group.
When the immediate leave setting is enabled, the device removes an interface from the forwarding-table entry without first sending MLD group-specific queries to the interface. The interface is pruned from the multicast tree for the multicast group specified in the MLD leave message. The immediate leave setting ensures optimal bandwidth management for hosts on a switched network, even when multiple multicast groups are being used simultaneously.
When immediate leave is disabled and one host sends a leave group message, the routing device first sends a group query to determine if another receiver responds. If no receiver responds, the routing device removes all hosts on the interface from the multicast group. Immediate leave is disabled by default for both MLD version 1 and MLD version 2.
Although host tracking is enabled for IGMPv2 and MLDv1 when you enable immediate leave, use immediate leave with these versions only when there is one host on the interface. The reason is that IGMPv2 and MLDv1 use a report suppression mechanism whereby only one host on an interface sends a group join report in response to a membership query. The other interested hosts suppress their reports. The purpose of this mechanism is to avoid a flood of reports for the same group. But it also interferes with host tracking, because the router only knows about the one interested host and does not know about the others.
To enable immediate leave:
Filtering Unwanted MLD Reports at the MLD Interface Level
Suppose you need to limit the subnets that can join a certain
multicast group. The group-policy statement enables you
to filter unwanted MLD reports at the interface level.
When the group-policy statement is enabled on a router,
after the router receives an MLD report, the router compares the group
against the specified group policy and performs the action configured
in that policy (for example, rejects the report if the policy matches
the defined address or network).
You define the policy to match only MLD group addresses (for
MLDv1) by using the policy's route-filter statement to
match the group address. You define the policy to match MLD (source,
group) addresses (for MLDv2) by using the policy's route-filter statement to match the group address and the policy's source-address-filter statement to match the source address.
To filter unwanted MLD reports:
See Also
Example: Modifying the MLD Robustness Variable
This example shows how to configure and verify the MLD robustness variable in a multicast domain.
Requirements
Before you begin:
Configure the router interfaces.
Configure an interior gateway protocol or static routing. See the Junos OS Routing Protocols Library for Routing Devices.
Enable IPv6 unicast routing. See the Junos OS Routing Protocols Library for Routing Devices.
Enable PIM. See PIM Overview.
Overview
The MLD robustness variable can be fine-tuned to allow for expected packet loss on a subnet. Increasing the robust count allows for more packet loss but increases the leave latency of the subnetwork.
The value of the robustness variable is used in calculating the following MLD message intervals:
Group member interval—Amount of time that must pass before a multicast router determines that there are no more members of a group on a network. This interval is calculated as follows: (robustness variable x query-interval) + (1 x query-response-interval).
Other querier present interval—Amount of time that must pass before a multicast router determines that there is no longer another multicast router that is the querier. This interval is calculated as follows: (robustness variable x query-interval) + (0.5 x query-response-interval).
Last-member query count—Number of group-specific queries sent before the router assumes there are no local members of a group. The default number is the value of the robustness variable.
By default, the robustness variable is set to 2. The number can be from 2 through 10. You might want to increase this value if you expect a subnet to lose packets.
Configuration
Procedure
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set protocols mld robust-count 5
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.
To change the value of the robustness variable:
Verification
To verify the configuration is working properly, check the MLD Robustness Count field in the output of the show mld interfaces command.
Limiting the Maximum MLD Message Rate
You can change the limit for the maximum number of MLD packets transmitted in 1 second by the router.
Increasing the maximum number of MLD packets transmitted per second might be useful on a router with a large number of interfaces participating in MLD.
To change the limit for the maximum number of MLD packets
the router can transmit in 1 second, include the maximum-transmit-rate statement and specify the maximum number of packets per second to
be transmitted.
Enabling MLD Static Group Membership
- Create a MLD Static Group Member
- Automatically create static groups
- Automatically increment group addresses
- Specify multicast source address (in SSM mode)
- Automatically specify multicast sources
- Automatically increment source addresses
- Exclude multicast source addresses (in SSM mode)
Create a MLD Static Group Member
You can create MLD static group membership to test multicast forwarding without a receiver host. When you enable MLD static group membership, data is forwarded to an interface without that interface receiving membership reports from downstream hosts.
Class-of-service (CoS) adjustment is not supported with MLD static group membership.
When you configure static groups on an interface on which you want to receive multicast traffic, you can specify the number of static groups to be automatically created.
In this example, you create static group ff0e::1:ff05:1a8d.
Automatically create static groups
When you create MLD static group membership to test multicast forwarding on an interface on which you want to receive multicast traffic, you can specify that a number of static groups be automatically created. This is useful when you want to test forwarding to multiple receivers without having to configure each receiver separately.
In this example, you create three groups.
Automatically increment group addresses
When you configure static groups on an interface on which you want to receive multicast traffic and you specify the number of static groups to be automatically created, you can also configure the group address to be automatically incremented by some number of addresses.
In this example, you create three groups and increase the group address by an increment of two for each group.
Specify multicast source address (in SSM mode)
When you configure static groups on an interface on which you want to receive multicast traffic and your network is operating in source-specific multicast (SSM) mode, you can specify the multicast source address to be accepted.
If you specify a group address in the SSM range, you must also specify a source.
If a source address is specified in a multicast group that is statically configured, the MLD version must be set to MLDv2 on the interface. MLDv1 is the default value.
In this example, you create group ff0e::1:ff05:1a8d and accept IPv6 address fe80::2e0:81ff:fe05:1a8d as the only source.
Automatically specify multicast sources
When you configure static groups on an interface on which you want to receive multicast traffic, you can specify a number of multicast sources to be automatically accepted.
In this example, you create static group ff0e::1:ff05:1a8d and accept fe80::2e0:81ff:fe05:1a8d, fe80::2e0:81ff:fe05:1a8e, and fe80::2e0:81ff:fe05:1a8f as the source addresses.
Automatically increment source addresses
When you configure static groups on an interface on which you want to receive multicast traffic, and specify a number of multicast sources to be automatically accepted, you can also specify the number by which the address should be incremented for each source accepted.
In this example, you create static group ff0e::1:ff05:1a8d and accept fe80::2e0:81ff:fe05:1a8d, fe80::2e0:81ff:fe05:1a8f, and fe80::2e0:81ff:fe05:1a91 as the sources.
Exclude multicast source addresses (in SSM mode)
When you configure static groups on an interface on which you want to receive multicast traffic and your network is operating in source-specific multicast (SSM) mode, you can specify that certain multicast source addresses be excluded.
By default the multicast source address configured in a static group operates in include mode. In include mode the multicast traffic for the group is accepted from the configured source address. You can also configure the static group to operate in exclude mode. In exclude mode the multicast traffic for the group is accepted from any address other than the configured source address.
If a source address is specified in a multicast group that is statically configured, the MLD version must be set to MLDv2 on the interface. MLDv1 is the default value.
In this example, you exclude address fe80::2e0:81ff:fe05:1a8d as a source for group ff0e::1:ff05:1a8d.
Similar configuration is available for IPv4 multicast traffic using the IGMP protocol.
Example: Recording MLD Join and Leave Events
This example shows how to determine whether MLD tuning is needed in a network by configuring the routing device to record MLD join and leave events.
Requirements
Before you begin:
Configure the router interfaces.
Configure an interior gateway protocol or static routing. See the Junos OS Routing Protocols Library for Routing Devices.
Enable IPv6 unicast routing. See the Junos OS Routing Protocols Library for Routing Devices.
Enable PIM. See PIM Overview.
Overview
Table 1 describes the recordable MLD join and leave events.
ERRMSG Tag |
Definition |
|---|---|
RPD_MLD_JOIN |
Records MLD join events. |
RPD_MLD_LEAVE |
Records MLD leave events. |
RPD_MLD_ACCOUNTING_ON |
Records when MLD accounting is enabled on an MLD interface. |
RPD_MLD_ACCOUNTING_OFF |
Records when MLD accounting is disabled on an MLD interface. |
RPD_MLD_MEMBERSHIP_TIMEOUT |
Records MLD membership timeout events. |
Configuration
Procedure
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set protocols mld interface fe-0/1/0.2 accounting set system syslog file mld-events any info set system syslog file mld-events match ".*RPD_MLD_JOIN.* | .*RPD_MLD_LEAVE.* | .*RPD_MLD_ACCOUNTING.* | .*RPD_MLD_MEMBERSHIP_TIMEOUT.*" set system syslog file mld-events archive size 100000 set system syslog file mld-events archive files 3 set system syslog file mld-events archive transfer-interval 1440 set system syslog file mld-events archive archive-sites "ftp://user@host1//var/tmp" password "anonymous" set system syslog file mld-events archive archive-sites "ftp://user@host2//var/tmp" password "test"
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.
To configure recording of MLD join and leave events:
Enable accounting globally or on an MLD interface. This example shows the interface configuration.
[edit protocols mld] user@host# set interface fe–0/1/0.2 accounting
Configure the events to be recorded, and filter the events to a system log file with a descriptive filename, such as mld-events.
[edit system syslog file mld-events] user@host# set any info [edit system syslog file mld-events] user@host# set match “.*RPD_MLD_JOIN.* | .*RPD_MLD_LEAVE.* | .*RPD_MLD_ACCOUNTING.* | .*RPD_MLD_MEMBERSHIP_TIMEOUT.*”
Periodically archive the log file.
This example rotates the file every 24 hours (1440 minutes) when it reaches 100 KB and keeps three files.
[edit system syslog file mld-events] user@host# set archive size 100000 [edit system syslog file mld-events] user@host# set archive files 3 [edit system syslog file mld-events] user@host# set archive archive-sites “ftp://user@host1//var/tmp” password “anonymous” [edit system syslog file mld-events] user@host# set archive archive-sites “ftp://user@host2//var/tmp” password “test” [edit system syslog file mld-events] user@host# set archive transfer-interval 1440 [edit system syslog file mld-events] user@host# set archive start-time 2011–01–07:12:30
If you are done configuring the device, commit the configuration.
[edit system syslog file mld-events]] user@host# commit
Verification
You can view the system log file by running the file show command.
user@host> file show mld-events
You can monitor the system log file as entries are added to the file by running the monitor start and monitor stop commands.
user@host> monitor start mld-events
*** mld-events *** Apr 16 13:08:23 host mgd[16416]: UI_CMDLINE_READ_LINE: User 'user', command 'run monitor start mld-events ' monitor
Configuring the Number of MLD Multicast Group Joins on Logical Interfaces
The group-limit statement enables you to limit the
number of MLD multicast group joins for logical interfaces. When this
statement is enabled on a router running MLD version 2, the limit
is applied upon receipt of the group report. Once the group limit
is reached, subsequent join requests are rejected.
When configuring limits for MLD multicast groups, keep the following in mind:
Each any-source group (*,G) counts as one group toward the limit.
Each source-specific group (S,G) counts as one group toward the limit.
Groups in MLDv2 exclude mode are counted toward the limit.
Multiple source-specific groups count individually toward the group limit, even if they are for the same group. For example, (S1, G1) and (S2, G1) would count as two groups toward the configured limit.
Combinations of any-source groups and source-specific groups count individually toward the group limit, even if they are for the same group. For example, (*, G1) and (S, G1) would count as two groups toward the configured limit.
Configuring and committing a group limit on a network that is lower than what already exists on the network results in the removal of all groups from the configuration. The groups must then request to rejoin the network (up to the newly configured group limit).
You can dynamically limit multicast groups on MLD logical interfaces by using dynamic profiles. For detailed information about creating dynamic profiles, see the Junos OS Subscriber Management and Services Library .
Beginning with Junos OS 12.2, you can optionally configure a system log warning threshold for MLD multicast group joins received on the logical interface. It is helpful to review the system log messages for troubleshooting purposes and to detect if an excessive amount of MLD multicast group joins have been received on the interface. These log messages convey when the configured group limit has been exceeded, when the configured threshold has been exceeded, and when the number of groups drop below the configured threshold.
The group-threshold statement enables you to configure
the threshold at which a warning message is logged. The range is 1
through 100 percent. The warning threshold is a percentage of the
group limit, so you must configure the group-limit statement
to configure a warning threshold. For instance, when the number of
groups exceed the configured warning threshold, but remain below the
configured group limit, multicast groups continue to be accepted,
and the device logs a warning message. In addition, the device logs
a warning message after the number of groups drop below the configured
warning threshold. You can further specify the amount of time (in
seconds) between the log messages by configuring the log-interval statement. The range is 6 through 32,767 seconds.
You might consider throttling log messages because every entry added after the configured threshold and every entry rejected after the configured limit causes a warning message to be logged. By configuring a log interval, you can throttle the amount of system log warning messages generated for MLD multicast group joins.
To limit multicast group joins on an MLD logical interface:
To confirm your configuration, use the show protocols mld command. To verify the operation of MLD on the interface, including
the configured group limit and the optional warning threshold and
interval between log messages, use the show mld interface command.