IGMP Snooping Overview

Benefits of IGMP Snooping

• Optimized bandwidth utilization—IGMP snooping’s main benefit is to reduce flooding of packets. The device selectively forwards IPv4 multicast data to a list of ports that want to receive the data instead of flooding it to all ports in a VLAN.

• Improved security—Prevents denial of service attacks from unknown sources.

How IGMP Snooping Works

Devices usually learn unicast MAC addresses by checking the source address field of the frames they receive and then send any traffic for that unicast address only to the appropriate interfaces. However, a multicast MAC address can never be the source address for a packet. As a result, when a device receives traffic for a multicast destination address, it floods the traffic on the relevant VLAN, sending a significant amount of traffic for which there might not necessarily be interested receivers.

IGMP snooping prevents this flooding. When you enable IGMP snooping, the device monitors IGMP packets between receivers and multicast routers and uses the content of the packets to build a multicast forwarding table—a database of multicast groups and the interfaces that are connected to members of the groups. When the device receives multicast packets, it uses the multicast forwarding table to selectively forward the traffic to only the interfaces that are connected to members of the appropriate multicast groups.

On EX Series and QFX Series switches that do not support the Enhanced Layer 2 Software (ELS) configuration style, IGMP snooping is enabled by default on all VLANs (or only on the default VLAN on some devices) and you can disable it selectively on one or more VLANs. On all other devices, you must explicitly configure IGMP snooping on a VLAN or in a bridge domain to enable it.

How IGMP Snooping Works with Routed VLAN Interfaces

The device can use a routed VLAN interface (RVI) to forward traffic between VLANs in its configuration. IGMP snooping works with Layer 2 interfaces and RVIs to forward multicast traffic in a switched network.

When the device receives a multicast packet, its Packet Forwarding Engines perform a multicast lookup on the packet to determine how to forward the packet to its local interfaces. From the results of the lookup, each Packet Forwarding Engine extracts a list of Layer 3 interfaces that have ports local to the Packet Forwarding Engine. If the list includes an RVI, the device provides a bridge multicast group ID for the RVI to the Packet Forwarding Engine.

For VLANs that include multicast receivers, the bridge multicast ID includes a sub-next-hop ID, which identifies the Layer 2 interfaces in the VLAN that are interested in receiving the multicast stream. The Packet Forwarding Engine then forwards multicast traffic to bridge multicast IDs that have multicast receivers for a given multicast group.

IGMP Message Types

Multicast routers use IGMP to learn which groups have interested listeners for each of their attached physical networks. In any given subnet, one multicast router acts as an IGMP querier. The IGMP querier sends out the following types of queries to hosts:

• General query—Asks whether any host is listening to any group.

• Group-specific query—(IGMPv2 and IGMPv3 only) Asks whether any host is listening to a specific multicast group. This query is sent in response to a host leaving the multicast group and allows the router to quickly determine if any remaining hosts are interested in the group.

• Group-and-source-specific query—(IGMPv3 only) Asks whether any host is listening to group multicast traffic from a specific multicast source. This query is sent in response to a host indicating that it is not longer interested in receiving group multicast traffic from the multicast source and allows the router to quickly determine any remaining hosts are interested in receiving group multicast traffic from that source.

Hosts that are multicast listeners send the following kinds of messages:

• Membership report—Indicates that the host wants to join a particular multicast group.

• Leave report—(IGMPv2 and IGMPv3 only) Indicates that the host wants to leave a particular multicast group.

How Hosts Join and Leave Multicast Groups

Hosts can join multicast groups in two ways:

• By sending an unsolicited IGMP join message to a multicast router that specifies the IP multicast group the host wants to join.

• By sending an IGMP join message in response to a general query from a multicast router.

A multicast router continues to forward multicast traffic to a VLAN provided that at least one host on that VLAN responds to the periodic general IGMP queries. For a host to remain a member of a multicast group, it must continue to respond to the periodic general IGMP queries.

Hosts can leave a multicast group in either of two ways:

• By not responding to periodic queries within a particular interval of time, which is considered a “silent leave.” This is the only leave method for IGMPv1 hosts.

• By sending a leave report. This method can be used by IGMPv2 and IGMPv3 hosts.

Support for IGMPv3 Multicast Sources

In IGMPv3, a host can send a membership report that includes a list of source addresses. When the host sends a membership report in INCLUDE mode, the host is interested in group multicast traffic only from those sources in the source address list. If host sends a membership report in EXCLUDE mode, the host is interested in group multicast traffic from any source except the sources in the source address list. A host can also send an EXCLUDE report in which the source-list parameter is empty, which is known as an EXCLUDE NULL report. An EXCLUDE NULL report indicates that the host wants to join the multicast group and receive packets from all sources.

Devices that support IGMPv3 process INCLUDE and EXCLUDE membership reports, and most devices forward source-specific multicast (SSM) traffic only from requested sources to subscribed receivers accordingly. However, you might see the device doesn’t strictly forward multicast traffic on a per-source basis in some configurations such as:

• EX Series and QFX Series switches that do not use the Enhanced Layer 2 Software (ELS) configuration style

• EX2300 and EX3400 switches running Junos OS Releases prior to 18.1R2

• EX4300 switches running Junos OS Releases prior to 18.2R1, 18.1R2, 17.4R2, 17.3R3, 17.2R3, and 14.1X53-D47

• SRX Series Services Gateways

In these cases, the device might consolidate all INCLUDE and EXCLUDE mode reports they receive on a VLAN for a specified group into a single route that includes all multicast sources for that group, with the next hop representing all interfaces that have interested receivers for the group. As a result, interested receivers on the VLAN can receive traffic from a source that they did not include in their INCLUDE report or from a source they excluded in their EXCLUDE report. For example, if Host 1 wants traffic for G from Source A and Host 2 wants traffic for group G from Source B, they both receive traffic for group G regardless of whether A or B sends the traffic.

IGMP Snooping and Forwarding Interfaces

To determine how to forward multicast traffic, the device with IGMP snooping enabled maintains information about the following interfaces in its multicast forwarding table:

• Multicast-router interfaces—These interfaces lead toward multicast routers or IGMP queriers.

• Group-member interfaces—These interfaces lead toward hosts that are members of multicast groups.

The device learns about these interfaces by monitoring IGMP traffic. If an interface receives IGMP queries or Protocol Independent Multicast (PIM) updates, the device adds the interface to its multicast forwarding table as a multicast-router interface. If an interface receives membership reports for a multicast group, the device adds the interface to its multicast forwarding table as a group-member interface.

Learned interface table entries age out after a time period. For example, if a learned multicast-router interface does not receive IGMP queries or PIM hellos within a certain interval, the device removes the entry for that interface from its multicast forwarding table.

You can statically configure an interface to be a multicast-router interface or a group-member interface. The device adds a static interface to its multicast forwarding table without having to learn about the interface, and the entry in the table is not subject to aging. A device can have a mix of statically configured and dynamically learned interfaces.

General Forwarding Rules

An interface in a VLAN with IGMP snooping enabled receives multicast traffic and forwards it according to the following rules.

IGMP traffic:

• Forward IGMP general queries received on a multicast-router interface to all other interfaces in the VLAN.

• Forward IGMP group-specific queries received on a multicast-router interface to only those interfaces in the VLAN that are members of the group.

• Forward IGMP reports received on a host interface to multicast-router interfaces in the same VLAN, but not to the other host interfaces in the VLAN.

Multicast traffic that is not IGMP traffic:

• Flood multicast packets with a destination address of 233.252.0.0/24 to all other interfaces on the VLAN.

• Forward unregistered multicast packets (packets for a group that has no current members) to all multicast-router interfaces in the VLAN.

• Forward registered multicast packets to those host interfaces in the VLAN that are members of the multicast group and to all multicast-router interfaces in the VLAN.

Using the Device as an IGMP Querier

With IGMP snooping on a pure Layer 2 local network (that is, Layer 3 is not enabled on the network), if the network doesn’t include a multicast router, multicast traffic might not be properly forwarded through the network. You might see this problem if the local network is configured such that multicast traffic must be forwarded between devices in order to reach a multicast receiver. In this case, an upstream device does not forward multicast traffic to a downstream device (and therefore to the multicast receivers attached to the downstream device) because the downstream device does not forward IGMP reports to the upstream device. You can solve this problem by configuring one of the devices to be an IGMP querier. The IGMP querier device sends periodic general query packets to all the devices in the network, which ensures that the snooping membership tables are updated and prevents multicast traffic loss.

If you configure multiple devices to be IGMP queriers, the device with the lowest (smallest) IGMP querier source address takes precedence and acts as the querier. The devices with higher IGMP querier source addresses stop sending IGMP queries unless they do not receive IGMP queries for 255 seconds. If the device with a higher IGMP querier source address does not receive any IGMP queries during that period, it starts sending queries again.

To configure a device to act as an IGMP querier, enter the following:

To configure a QFabric Node device switch to act as an IGMP querier, enter the following:

IGMP Snooping on Private VLANs (PVLANs)

A PVLAN consists of secondary isolated and community VLANs configured within a primary VLAN. Without IGMP snooping support on the secondary VLANs, multicast streams received on the primary VLAN are flooded to the secondary VLANs.

Starting in Junos OS Release 18.3R1, EX4300 switches and EX4300 Virtual Chassis support IGMP snooping with PVLANs. Starting in Junos OS Release 19.2R1, EX4300 multigigabit model switches support IGMP snooping with PVLANs. When you enable IGMP snooping on a primary VLAN, you also implicitly enabled it on all secondary VLANs. The device learns and stores multicast group information on the primary VLAN, and also learns the multicast group information on the secondary VLANs in the context of the primary VLAN. As a result, the device further constrains multicast streams only to interested receivers on secondary VLANs, rather than flooding the traffic in all secondary VLANs.

The CLI prevents you from explicitly configuring IGMP snooping on secondary isolated or community VLANs. You only need to configure IGMP snooping on the primary VLAN under which the secondary VLANs are defined. For example, for a primary VLAN vlan-pri with a secondary isolated VLAN vlan-iso and a secondary community VLAN vlan-comm:

IGMP reports and leave messages received on secondary VLAN ports are learned in the context of the primary VLAN. Promiscuous trunk ports or inter-switch links acting as multicast router interfaces for the PVLAN receive incoming multicast data streams from multicast sources and forward them only to the secondary VLAN ports with learned multicast group entries.

This feature does not support secondary VLAN ports as multicast router interfaces. The CLI does not strictly prevent you from statically configuring an interface on a community VLAN as a multicast router port, but IGMP snooping does not work properly on PVLANs with this configuration. When IGMP snooping is configured on a PVLAN, the switch also automatically disables dynamic multicast router port learning on any isolated or community VLAN interfaces. IGMP snooping with PVLANs also does not support configurations with an IGMP querier on isolated or community VLAN interfaces.

See Understanding Private VLANs and Creating a Private VLAN Spanning Multiple EX Series Switches with ELS Support (CLI Procedure) for details on configuring PVLANs.