Configuring IGMP
Understanding Group Membership Protocols
There is a big difference between the multicast protocols used between host and routing device and between the multicast routing devices themselves. Hosts on a given subnetwork need to inform their routing device only whether or not they are interested in receiving packets from a certain multicast group. The source host needs to inform its routing devices only that it is the source of traffic for a particular multicast group. In other words, no detailed knowledge of the distribution tree is needed by any hosts; only a group membership protocol is needed to inform routing devices of their participation in a multicast group. Between adjacent routing devices, on the other hand, the multicast routing protocols must avoid loops as they build a detailed sense of the network topology and distribution tree from source to leaf. So, different multicast protocols are used for the host-router portion and the router-router portion of the multicast network.
Multicast group membership protocols enable a routing device to detect when a host on a directly attached subnet, typically a LAN, wants to receive traffic from a certain multicast group. Even if more than one host on the LAN wants to receive traffic for that multicast group, the routing device sends only one copy of each packet for that multicast group out on that interface, because of the inherent broadcast nature of LANs. When the multicast group membership protocol informs the routing device that there are no interested hosts on the subnet, the packets are withheld and that leaf is pruned from the distribution tree.
The Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) Protocol are the standard IP multicast group membership protocols: IGMP and MLD have several versions that are supported by hosts and routing devices:
IGMPv1—The original protocol defined in RFC 1112. An explicit join message is sent to the routing device, but a timeout is used to determine when hosts leave a group. This process wastes processing cycles on the routing device, especially on older or smaller routing devices.
IGMPv2—Defined in RFC 2236. Among other features, IGMPv2 adds an explicit leave message to the join message so that routing devices can more easily determine when a group has no interested listeners on a LAN.
IGMPv3—Defined in RFC 3376. Among other features, IGMPv3 optimizes support for a single source of content for a multicast group, or source-specific multicast (SSM).
MLDv1—Defined in RFC 2710. MLDv1 is similar to IGMPv2.
MLDv2—Defined in RFC 3810. MLDv2 similar to IGMPv3.
The various versions of IGMP and MLD are backward compatible. It is common for a routing device to run multiple versions of IGMP and MLD on LAN interfaces. Backward compatibility is achieved by dropping back to the most basic of all versions run on a LAN. For example, if one host is running IGMPv1, any routing device attached to the LAN running IGMPv2 can drop back to IGMPv1 operation, effectively eliminating the IGMPv2 advantages. Running multiple IGMP versions ensures that both IGMPv1 and IGMPv2 hosts find peers for their versions on the routing device.
On MX Series platforms, IGMPv2 and IGMPv3 can or cannot be configured together on the same interface, depending on the Junos OS release at your installation. Configuring both together can cause unexpected behavior in multicast traffic forwarding.
See Also
Understanding IGMP
The Internet Group Management Protocol (IGMP) manages the membership of hosts and routing devices in multicast groups. IP hosts use IGMP to report their multicast group memberships to any immediately neighboring multicast routing devices. Multicast routing devices use IGMP to learn, for each of their attached physical networks, which groups have members.
IGMP is also used as the transport for several related multicast protocols (for example, Distance Vector Multicast Routing Protocol [DVMRP] and Protocol Independent Multicast version 1 [PIMv1]).
A routing device receives explicit join and prune messages from those neighboring routing devices that have downstream group members. When PIM is the multicast protocol in use, IGMP begins the process as follows:
To join a multicast group, G, a host conveys its membership information through IGMP.
The routing device then forwards data packets addressed to a multicast group G to only those interfaces on which explicit join messages have been received.
A designated router (DR) sends periodic join and prune messages toward a group-specific rendezvous point (RP) for each group for which it has active members. One or more routing devices are automatically or statically designated as the RP, and all routing devices must explicitly join through the RP.
Each routing device along the path toward the RP builds a wildcard (any-source) state for the group and sends join and prune messages toward the RP.
The term route entry is used to refer to the state maintained in a routing device to represent the distribution tree.
A route entry can include such fields as:
source address
group address
incoming interface from which packets are accepted
list of outgoing interfaces to which packets are sent
timers
flag bits
The wildcard route entry's incoming interface points toward the RP.
The outgoing interfaces point to the neighboring downstream routing devices that have sent join and prune messages toward the RP as well as the directly connected hosts that have requested membership to group G.
This state creates a shared, RP-centered, distribution tree that reaches all group members.
IGMP is also used as the transport for several related multicast protocols (for example, Distance Vector Multicast Routing Protocol [DVMRP] and Protocol Independent Multicast version 1 [PIMv1]).
Starting in Junos OS Release 15.2, PIMv1 is not supported.
IGMP is an integral part of IP and must be enabled on all routing devices and hosts that need to receive IP multicast traffic.
For each attached network, a multicast routing device can be either a querier or a nonquerier. The querier routing device periodically sends general query messages to solicit group membership information. Hosts on the network that are members of a multicast group send report messages. When a host leaves a group, it sends a leave group message.
IGMP version 3 (IGMPv3) supports inclusion and exclusion lists. Inclusion lists enable you to specify which sources can send to a multicast group. This type of multicast group is called a source-specific multicast (SSM) group, and its multicast address is 232/8.
IGMPv3 provides support for source filtering. For example, a routing device can specify particular routing devices from which it accepts or rejects traffic. With IGMPv3, a multicast routing device can learn which sources are of interest to neighboring routing devices.
Exclusion mode works the opposite of an inclusion list. It allows any source but the ones listed to send to the SSM group.
IGMPv3 interoperates with versions 1 and 2 of the protocol. However, to remain compatible with older IGMP hosts and routing devices, IGMPv3 routing devices must also implement versions 1 and 2 of the protocol. IGMPv3 supports the following membership-report record types: mode is allowed, allow new sources, and block old sources.
See Also
Configuring IGMP
Before you begin:
Determine whether the router is directly attached to any multicast sources. Receivers must be able to locate these sources.
Determine whether the router is directly attached to any multicast group receivers. If receivers are present, IGMP is needed.
Determine whether to configure multicast to use sparse, dense, or sparse-dense mode. Each mode has different configuration considerations.
Determine the address of the RP if sparse or sparse-dense mode is used.
Determine whether to locate the RP with the static configuration, BSR, or auto-RP method.
Determine whether to configure multicast to use its own RPF routing table when configuring PIM in sparse, dense, or sparse-dense mode.
Configure the SAP and SDP protocols to listen for multicast session announcements. See Configuring the Session Announcement Protocol.
To configure the Internet Group Management Protocol (IGMP),
include the igmp statement:
igmp { accounting; interface interface-name { disable; (accounting | no-accounting); group-policy [ policy-names ]; immediate-leave; oif-map map-name; promiscuous-mode; 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; } query-interval seconds; query-last-member-interval seconds; query-response-interval seconds; robust-count number; traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag <flag-modifier> <disable>; } }
You can include this statement at the following hierarchy levels:
[edit protocols][edit logical-systems logical-system-name protocols]
By default, IGMP is enabled on all interfaces on which you configure Protocol Independent Multicast (PIM), and on all broadcast interfaces on which you configure the Distance Vector Multicast Routing Protocol (DVMRP).
You can configure IGMP on an interface without configuring PIM. PIM is generally not needed on IGMP downstream interfaces. Therefore, only one “pseudo PIM interface” is created to represent all IGMP downstream (IGMP-only) interfaces on the router. This reduces the amount of router resources, such as memory, that are consumed. You must configure PIM on upstream IGMP interfaces to enable multicast routing, perform reverse-path forwarding for multicast data packets, populate the multicast forwarding table for upstream interfaces, and in the case of bidirectional PIM and PIM sparse mode, to distribute IGMP group memberships into the multicast routing domain.
Enabling IGMP
The Internet Group Management Protocol (IGMP) manages multicast groups by establishing, maintaining, and removing groups on a subnet. Multicast routing devices use IGMP to learn which groups have members on each of their attached physical networks. IGMP must be enabled for the router to receive IPv4 multicast packets. IGMP is only needed for IPv4 networks, because multicast is handled differently in IPv6 networks. IGMP is automatically enabled on all IPv4 interfaces on which you configure PIM and on all IPv4 broadcast interfaces when you configure DVMRP.
If IGMP is not running on an interface—either because PIM and DVMRP are not configured on the interface or because IGMP is explicitly disabled on the interface—you can explicitly enable IGMP.
To explicitly enable IGMP:
See Also
Modifying the IGMP Host-Query Message Interval
The objective of IGMP is to keep routers up to date with 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 IGMP querier router periodically sends general host-query messages on each attached network to solicit membership information. The messages are sent to the all-systems multicast group address, 224.0.0.1.
The query interval, the response interval, and the robustness variable are related in that they are all variables that are used to calculate the group membership timeout. The group membership timeout 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 group membership timeout is calculated as the (robustness variable x query-interval) + (query-response-interval). If no reports are received for a particular group before the group membership timeout 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 IGMP messages sent on the subnet.
To modify the query interval:
See Also
Modifying the IGMP 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. Configuring this interval allows you to adjust the burst peaks of IGMP messages on the subnet. Set a larger interval to make the traffic less bursty. Bursty traffic refers to an uneven pattern of data transmission: sometimes a very high data transmission rate, whereas at other times a very low data transmission rate.
The query response interval, the host-query interval, and the robustness variable are related in that they are all variables that are used to calculate the group membership timeout. The group membership timeout 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 group membership timeout is calculated as the (robustness variable x query-interval) + (query-response-interval). If no reports are received for a particular group before the group membership timeout 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
Specifying Immediate-Leave Host Removal for IGMP
The immediate leave setting is useful for minimizing the leave latency of IGMP 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 IGMP 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 IGMP group-specific queries to the interface. The interface is pruned from the multicast tree for the multicast group specified in the IGMP 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 IGMP version 2 and IGMP version 3.
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 on an interface:
See Also
Filtering Unwanted IGMP Reports at the IGMP 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 IGMP reports at the interface level. When this
statement is enabled on a router running IGMP version 2 (IGMPv2) or
version 3 (IGMPv3), after the router receives an IGMP 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 IGMP group addresses (for
IGMPv2) by using the policy's route-filter statement to
match the group address. You define the policy to match IGMP (source,
group) addresses (for IGMPv3) 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.
On MX Series platforms, IGMPv2 and IGMPv3 can or cannot be configured together on the same interface, depending on the Junos OS release at your installation. Configuring both together can cause unexpected behavior in multicast traffic forwarding.
To filter unwanted IGMP reports:
See Also
Accepting IGMP Messages from Remote Subnetworks
By default, IGMP interfaces accept IGMP messages only from the
same subnet. Including the promiscuous-mode statement enables
the routing device to accept IGMP messages from indirectly connected
subnets.
When you enable IGMP on an unnumbered Ethernet interface that uses a /32 loopback address as a donor address, you must configure IGMP promiscuous mode to accept the IGMP packets received on this interface.
When enabling promiscuous-mode, all routers on the ethernet segment must be configured with the promiscuous mode statement. Otherwise, only the interface configured with lowest IPv4 address acts as the querier for IGMP for this Ethernet segment.
To enable IGMP promiscuous mode on an interface:
See Also
Modifying the IGMP Last-Member Query Interval
The last-member query interval is the maximum amount of time between group-specific query messages, including those sent in response to leave-group messages. You can configure this interval to change the amount of time it takes a routing device 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 message from a host, the routing device sends multiple group-specific queries to the group being left. The querier sends a specific number of these queries at a specific interval. The number of queries sent is called the last-member query count. The interval at which the queries are sent is called the last-member query interval. Because both settings are configurable, you can 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-member query count x (times) the last-member 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-member 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
Modifying the IGMP Robustness Variable
Fine-tune the IGMP robustness variable to allow for expected packet loss on a subnet. The robust count automatically changes certain IGMP message intervals for IGMPv2 and IGMPv3. Increasing the robust count allows for more packet loss but increases the leave latency of the subnetwork.
When the query router receives an IGMP leave message on a shared network running IGMPv2, the query router must send an IGMP group query message a specified number of times. The number of IGMP group query messages sent is determined by the robust count.
The value of the robustness variable is also used in calculating the following IGMP 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—The robust count is used to calculate the 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 number of queries is equal to the value of the robustness variable.
In IGMPv3, a change of interface state causes the system to immediately transmit a state-change report from that interface. In case the state-change report is missed by one or more multicast routers, it is retransmitted. The number of times it is retransmitted is the robust count minus one. In IGMPv3, the robust count is also a factor in determining the group membership interval, the older version querier interval, and the other querier present interval.
By default, the robustness variable is set to 2. You might want to increase this value if you expect a subnet to lose packets.
The number can be from 2 through 10.
To change the value of the robustness variable:
See Also
Limiting the Maximum IGMP Message Rate
This section describes how to change the limit for the maximum number of IGMP packets transmitted in 1 second by the router.
Increasing the maximum number of IGMP packets transmitted per second might be useful on a router with a large number of interfaces participating in IGMP.
To change the limit for the maximum number of IGMP 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.
See Also
Changing the IGMP Version
By default, the routing device runs IGMPv2. Routing devices running different versions of IGMP determine the lowest common version of IGMP that is supported by hosts on their subnet and operate in that version.
To enable source-specific multicast (SSM) functionality, you must configure version 3 on the host and the host’s directly connected routing device. If a source address is specified in a multicast group that is statically configured, the version must be set to IGMPv3.
If a static multicast group is configured with the source address defined, and the IGMP version is configured to be version 2, the source is ignored and only the group is added. In this case, the join is treated as an IGMPv2 group join.
If you configure the IGMP version setting at
the individual interface hierarchy level, it overrides the interface
all statement. That is, the new interface does not inherit the
version number that you specified with the interface all statement. By default, that new interface is enabled with version
2. You must explicitly specify a version number when adding a new interface. For example, if you specified version 3 with interface all, you would need to
configure the version 3 statement for the new interface.
Additionally, if you configure an interface for a multicast group
at the [edit interface interface-name static
group multicast-group-address] hierarchy
level, you must specify a version number as well as the other group parameters. Otherwise, the interface
is enabled with the default version 2.
If you have already configured the routing device to use IGMP version 1 (IGMPv1) and then configure it to use IGMPv2, the routing device continues to use IGMPv1 for up to 6 minutes and then uses IGMPv2.
To change to IGMPv3 for SSM functionality:
On MX Series platforms, IGMPv2 and IGMPv3 can or cannot be configured together on the same interface, depending on the Junos OS release at your installation. Configuring both together can cause unexpected behavior in multicast traffic forwarding.
See Also
Enabling IGMP Static Group Membership
You can create IGMP static group membership to test multicast forwarding without a receiver host. When you enable IGMP static group membership, data is forwarded to an interface without that interface receiving membership reports from downstream hosts. The router on which you enable static IGMP group membership must be the designated router (DR) for the subnet. Otherwise, traffic does not flow downstream.
When enabling IGMP static group membership, you cannot configure
multiple groups using the group-count, group-increment, source-count, and source-increment statements
if the all option is specified as the IGMP interface.
Class-of-service (CoS) adjustment is not supported with IGMP static group membership.
In this example, you create static group 233.252.0.1.
When you configure static IGMP group entries on point-to-point links that connect routing devices to a rendezvous point (RP), the static IGMP group entries do not generate join messages toward the RP.
When you create IGMP 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.
On the DR, configure the number of static groups to be created by including the
group-countstatement and specifying the number of groups to be created.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 group-count 3
After you commit the configuration, use the
show configuration protocol igmpcommand to verify the IGMP protocol configuration.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { static { group 233.252.0.1 { group-count 3; } } }After you have committed the configuration and after the source is sending traffic, use the
show igmp groupcommand to verify that static groups 233.252.0.1, 233.252.0.2, and 233.252.0.3 have been created.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.2 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.3 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
When you create IGMP static group membership to test multicast forwarding on an interface on which you want to receive multicast traffic, you can also configure the group address to be automatically incremented for each group created. This is useful when you want to test forwarding to multiple receivers without having to configure each receiver separately and when you do not want the group addresses to be sequential.
In this example, you create three groups and increase the group address by an increment of two for each group.
On the DR, configure the group address increment by including the
group-incrementstatement and specifying the number by which the address should be incremented for each group. The increment is specified in dotted decimal notation similar to an IPv4 address.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 group-count 3 group-increment 0.0.0.2
After you commit the configuration, use the
show configuration protocol igmpcommand to verify the IGMP protocol configuration.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { group-increment 0.0.0.2; group-count 3; } } }After you have committed the configuration and after the source is sending traffic, use the
show igmp groupcommand to verify that static groups 233.252.0.1, 233.252.0.3, and 233.252.0.5 have been created.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.3 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.5 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
When you create IGMP static group membership to test multicast forwarding on an interface on which you want to receive multicast traffic, and your network is operating in source-specific multicast (SSM) mode, you can also specify that the multicast source address be accepted. This is useful when you want to test forwarding to multicast receivers from a specific multicast source.
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 IGMP version on the interface must be set to IGMPv3. IGMPv2 is the default value.
In this example, you create group 233.252.0.1 and accept IP address 10.0.0.2 as the only source.
On the DR, configure the source address by including the
sourcestatement and specifying the IPv4 address of the source host.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2
After you commit the configuration, use the
show configuration protocol igmpcommand to verify the IGMP protocol configuration.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2; } } }After you have committed the configuration and the source is sending traffic, use the
show igmp groupcommand to verify that static group 233.252.0.1 has been created and that source 10.0.0.2 has been accepted.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
When you create IGMP 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 multicast sources be automatically accepted. This is useful when you want to test forwarding to multicast receivers from more than one specified multicast source.
In this example, you create group 233.252.0.1 and accept addresses 10.0.0.2, 10.0.0.3, and 10.0.0.4 as the sources.
On the DR, configure the number of multicast source addresses to be accepted by including the
source-countstatement and specifying the number of sources to be accepted.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2 source-count 3
After you commit the configuration, use the
show configuration protocol igmpcommand to verify the IGMP protocol configuration.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2 { source-count 3; } } } }After you have committed the configuration and the source is sending traffic, use the
show igmp groupcommand to verify that static group 233.252.0.1 has been created and that sources 10.0.0.2, 10.0.0.3, and 10.0.0.4 have been accepted.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.3 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.4 Last reported by: Local Timeout: 0 Type: Static
When you configure static groups on an interface on which you want to receive multicast traffic, and specify that a number of multicast sources be automatically accepted, you can also specify the number by which the address should be incremented for each source accepted. This is useful when you want to test forwarding to multiple receivers without having to configure each receiver separately and you do not want the source addresses to be sequential.
In this example, you create group 233.252.0.1 and accept addresses 10.0.0.2, 10.0.0.4, and 10.0.0.6 as the sources.
Configure the multicast source address increment by including the
source-incrementstatement and specifying the number by which the address should be incremented for each source. The increment is specified in dotted decimal notation similar to an IPv4 address.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2 source-count 3 source-increment 0.0.0.2
After you commit the configuration, use the
show configuration protocol igmpcommand to verify the IGMP protocol configuration.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2 { source-count 3; source-increment 0.0.0.2; } } } }After you have committed the configuration and after the source is sending traffic, use the
show igmp groupcommand to verify that static group 233.252.0.1 has been created and that sources 10.0.0.2, 10.0.0.4, and 10.0.0.6 have been accepted.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.4 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.6 Last reported by: Local Timeout: 0 Type: Static
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 source address configured. 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 source address configured.
If a source address is specified in a multicast group that is statically configured, the IGMP version on the interface must be set to IGMPv3. IGMPv2 is the default value.
In this example, you exclude address 10.0.0.2 as a source for group 233.252.0.1.
On the DR, configure a multicast static group to operate in exclude mode by including the
excludestatement and specifying which IPv4 source address to exclude.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 exclude source 10.0.0.2
After you commit the configuration, use the
show configuration protocol igmpcommand to verify the IGMP protocol configuration.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { exclude; source 10.0.0.2; } } }After you have committed the configuration and the source is sending traffic, use the
show igmp group detailcommand to verify that static group 233.252.0.1 has been created and that the static group is operating in exclude mode.user@host> show igmp group detail Interface: fe-0/1/2 Group: 233.252.0.1 Group mode: Exclude Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
See Also
Recording IGMP Join and Leave Events
To determine whether IGMP tuning is needed in a network, you can configure the routing device to record IGMP join and leave events. You can record events globally for the routing device or for individual interfaces.
Table 1 describes the recordable IGMP events.
ERRMSG Tag |
Definition |
|---|---|
RPD_IGMP_JOIN |
Records IGMP join events. |
RPD_IGMP_LEAVE |
Records IGMP leave events. |
RPD_IGMP_ACCOUNTING_ON |
Records when IGMP accounting is enabled on an IGMP interface. |
RPD_IGMP_ACCOUNTING_OFF |
Records when IGMP accounting is disabled on an IGMP interface. |
RPD_IGMP_MEMBERSHIP_TIMEOUT |
Records IGMP membership timeout events. |
To enable IGMP accounting:
See Also
Limiting the Number of IGMP Multicast Group Joins on Logical Interfaces
The group-limit statement enables you to limit the
number of IGMP multicast group joins for logical interfaces. When
this statement is enabled on a router running IGMP version 2
(IGMPv2) or version 3 (IGMPv3), 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 IGMP 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 IGMPv3 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 IGMP logical interfaces using dynamic profiles.
Starting in Junos OS Release 12.2, you can optionally configure a system log warning threshold for IGMP 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 IGMP 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 the 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 IGMP multicast group joins.
On ACX Series routers, the maximum number of multicast routes is 1024.
To limit multicast group joins on an IGMP logical interface:
To confirm your configuration, use the show protocols igmp command. To verify the operation of IGMP on the interface, including
the configured group limit and the optional warning threshold and
interval between log messages, use the show igmp interface command.
See Also
Tracing IGMP Protocol Traffic
Tracing operations record detailed messages about the operation of routing protocols, such as the various types of routing protocol packets sent and received, and routing policy actions. You can specify which trace operations are logged by including specific tracing flags. The following table describes the flags that you can include.
Flag |
Description |
|---|---|
all |
Trace all operations. |
client-notification |
Trace notifications. |
general |
Trace general flow. |
group |
Trace group operations. |
host-notification |
Trace host notifications. |
leave |
Trace leave group messages (IGMPv2 only). |
mtrace |
Trace mtrace packets. Use the |
normal |
Trace normal events. |
packets |
Trace all IGMP packets. |
policy |
Trace policy processing. |
query |
Trace IGMP membership query messages, including general and group-specific queries. |
report |
Trace membership report messages. |
route |
Trace routing information. |
state |
Trace state transitions. |
task |
Trace task processing. |
timer |
Trace timer processing. |
In the following example, tracing is enabled for all routing protocol packets. Then tracing is narrowed to focus only on IGMP packets of a particular type. To configure tracing operations for IGMP:
See Also
Disabling IGMP
To disable IGMP on an interface, include the disable statement:
disable;
You can include this statement at the following hierarchy levels:
[edit protocols igmp interface interface-name][edit logical-systems logical-system-name protocols igmp interface interface-name]Note:ACX Series routers do not support
[edit logical-systems logical-system-name protocols]hierarchy level.
See Also
IGMP and Nonstop Active Routing
Nonstop active routing (NSR) configurations include two Routing Engines that share information so that routing is not interrupted during Routing Engine failover. These NSR configurations include passive support with IGMP in connection with PIM. The primary Routing Engine uses IGMP to determine its PIM multicast state, and this IGMP-derived information is replicated on the backup Routing Engine. IGMP on the new primary Routing Engine (after failover) relearns the state information quickly through IGMP operation. In the interim, the new primary Routing Engine retains the IGMP-derived PIM state as received by the replication process from the old primary Routing Engine. This state information times out unless refreshed by IGMP on the new primary Routing Engine. No additional IGMP configuration is required.
See Also
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.