Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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.

Figure 1: Routing Devices Start Up on a SubnetRouting Devices Start Up on a Subnet

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.

Note:

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.

Figure 2: Querier Routing Device Is DeterminedQuerier Routing Device Is Determined

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.

Figure 3: General Query Message Is IssuedGeneral Query Message Is Issued

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.

Figure 4: Reports Are Received by the Querier Routing DeviceReports Are Received by the Querier Routing Device

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

Figure 5: Host Has No Interested Receivers and Sends a Done Message to Routing DeviceHost Has No Interested Receivers and Sends a Done Message to Routing Device

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

Figure 6: Host Address Timer Expires and Address Is Removed from Multicast Address ListHost Address Timer Expires and Address Is Removed from Multicast Address List

Configuring MLD

To configure the Multicast Listener Discovery (MLD) Protocol, include the mld statement:

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:

  1. If PIM and DVMRP are not running on the interface, explicitly enable MLD by including the interface name.
  2. Check to see if MLD is disabled on any interfaces. In the following example, MLD is disabled on a Gigabit Ethernet interface.
  3. Enable MLD on the interface by deleting the disable statement.
  4. Verify the configuration.
  5. Verify the operation of MLD by checking the output of the show mld interface command.

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:

  1. Configure the MLD interface.
  2. Verify the configuration by checking the version field in the output of the show mld interface command. The show mld statistics command has version-specific output fields, such as the counters in the MLD Message type field.

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:

  1. Configure the interval.

    The value can be from 1 through 1024 seconds.

  2. Verify the configuration by checking the MLD Query Interval field in the output of the show mld interface command.
  3. Verify the operation of the query interval by checking the Listener Query field in the output of the show mld statistics command.

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:

  1. Configure the interval.
  2. Verify the configuration by checking the MLD Query Response Interval field in the output of the show mld interface command.
  3. Verify the operation of the query interval by checking the Listener Query field in the output of the show mld statistics command.

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:

  1. Configure the time (in seconds) that the routing device waits for a report in response to a group-specific query.
  2. Verify the configuration by checking the MLD Last Member Query Interval field in the output of the show igmp interfaces command.
Note:

You can configure the last-member query count by configuring the robustness variable. The two are always equal.

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.

Note:

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:

  1. Configure immediate leave on the MLD interface.
  2. Verify the configuration by checking the Immediate Leave field in the output of the show mld interface command.

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:

  1. Configure an MLDv1 policy.
  2. Configure an MLDv2 policy.
  3. Apply the policies to the MLD interfaces where you prefer not to receive specific group or (source, group) reports. In this example, ge-0/0/0.1 is running MLDv1 and ge-0/1/1.0 is running MLDv2.
  4. Verify the operation of the filter by checking the Rejected Report field in the output of the show mld statistics command.

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:

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.

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:

  1. Configure the robust count.

  2. If you are done configuring the device, commit the configuration.

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

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.

  1. Configure the static groups to be created by including the static statement and group statement and specifying which IPv6 multicast address of the group to be created.
  2. After you commit the configuration, use the show configuration protocol mld command to verify the MLD protocol configuration.
  3. After you have committed the configuration and after the source is sending traffic, use the show mld group command to verify that static group ff0e::1:ff05:1a8d has been created.
    Note:

    You must specify a unique address for each group.

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.

  1. Configure the number of static groups to be created by including the group-count statement and specifying the number of groups to be created.
  2. After you commit the configuration, use the show configuration protocol mld command to verify the MLD protocol configuration.
  3. After you have committed the configuration and the source is sending traffic, use the show mld group command to verify that static groups ff0e::1:ff05:1a8d, ff0e::1:ff05:1a8e, and ff0e::1:ff05:1a8f have been created.

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.

  1. Configure the group address increment by including the group-increment statement and specifying the number by which the address should be incremented for each group. The increment is specified in a format similar to an IPv6 address.
  2. After you commit the configuration, use the show configuration protocol mld command to verify the MLD protocol configuration.
  3. After you have committed the configuration and the source is sending traffic, use the show mld group command to verify that static groups ff0e::1:ff05:1a8d, ff0e::1:ff05:1a8f, and ff0e::1:ff05:1a91 have been created.

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.

  1. Configure the source address by including the source statement and specifying the IPv6 address of the source host.
  2. After you commit the configuration, use the show configuration protocol mld command to verify the MLD protocol configuration.
  3. After you have committed the configuration and the source is sending traffic, use the show mld group command to verify that static group ff0e::1:ff05:1a8d has been created and that source fe80::2e0:81ff:fe05:1a8d has been accepted.

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.

  1. Configure the number of multicast source addresses to be accepted by including the source-count statement and specifying the number of sources to be accepted.
  2. After you commit the configuration, use the show configuration protocol mld command to verify the MLD protocol configuration.
  3. After you have committed the configuration and the source is sending traffic, use the show mld group command to verify that static group ff0e::1:ff05:1a8d has been created and that sources fe80::2e0:81ff:fe05:1a8d, fe80::2e0:81ff:fe05:1a8e, and fe80::2e0:81ff:fe05:1a8f have been accepted.

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.

  1. Configure the number of multicast source addresses to be accepted by including the source-increment statement and specifying the number of sources to be accepted.
  2. After you commit the configuration, use the show configuration protocol mld command to verify the MLD protocol configuration.
  3. After you have committed the configuration and the source is sending traffic, use the show mld group command to verify that static group ff0e::1:ff05:1a8d has been created and that sources fe80::2e0:81ff:fe05:1a8d, fe80::2e0:81ff:fe05:1a8f, and fe80::2e0:81ff:fe05:1a91 have been accepted.

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.

  1. Configure a multicast static group to operate in exclude mode by including the exclude statement and specifying which IPv6 source address to be excluded.
  2. After you commit the configuration, use the show configuration protocol mld command to verify the MLD protocol configuration.
  3. After you have committed the configuration and the source is sending traffic, use the show mld group detail command to verify that static group ff0e::1:ff05:1a8d has been created and that the static group is operating in exclude mode.

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:

Overview

Table 1 describes the recordable MLD join and leave events.

Table 1: MLD Event Messages

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.

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:

  1. Enable accounting globally or on an MLD interface. This example shows the interface configuration.

  2. Configure the events to be recorded, and filter the events to a system log file with a descriptive filename, such as mld-events.

  3. Periodically archive the log file.

    This example rotates the file every 24 hours (1440 minutes) when it reaches 100 KB and keeps three files.

  4. If you are done configuring the device, commit the configuration.

Verification

You can view the system log file by running the file show command.

You can monitor the system log file as entries are added to the file by running the monitor start and monitor stop commands.

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:

  1. Access the logical interface at the MLD protocol hierarchy level.
  2. Specify the group limit for the interface.
  3. (Optional) Configure the threshold at which a warning message is logged.
  4. (Optional) Configure the amount of time between log messages.

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.

Disabling MLD

To disable MLD on an interface, include the disable statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols mld]

  • [edit logical-systems logical-system-name protocols mld]

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
12.2
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.