IGMP snooping provides a way to constrain multicast traffic at Layer 2. By snooping the IGMP membership reports sent by hosts in the bridge domain, the IGMP snooping application can set up Layer 2 multicast forwarding tables to deliver traffic only to ports with at least one interested member, significantly reducing the volume of multicast traffic.

Configured at Layer 3, IGMP provides a means for hosts in an IPv4 multicast network to indicate which multicast traffic they are interested in and for routers to control and limit the flow of multicast traffic in the network at Layer 3.

IGMP snooping uses the information in IGMP membership report messages to build corresponding information in the forwarding tables to restrict IP multicast traffic at Layer 2. The forwarding table entries are in the form <Route, OIF List>, where:

• Route is a <*, G> route or <S, G> route.

• OIF List comprises all bridge ports that have sent IGMP membership reports for the specified route plus all multicast router (mrouter) ports in the bridge domain.

Implemented in a multicast network, IGMP snooping has the following attributes:

• In its basic form, it reduces bandwidth consumption by reducing multicast traffic that would otherwise flood an entire VPLS bridge domain.

• With the use of some optional configurations, it provides security between bridge domains by filtering the IGMP reports received from hosts on one bridge port and preventing leakage towards the hosts on other bridge ports.

• Using optional configurations, reduces the traffic impact on upstream IP multicast routers by suppressing IGMP membership reports (IGMPv2) or by acting as an IGMP proxy reporter (IGMPv3) to the upstream IP multicast router.

All high availability features apply to the IGMP snooping processes with no additional configuration beyond enabling IGMP snooping. The following high availability features are supported:

• Process restarts

• RP Failover

• Stateful Switch-Over (SSO)

• Non-Stop Forwarding (NSF)—Forwarding continues unaffected while the control plane is restored following a process restart or route processor (RP) failover.

• Line card online insertion and removal (OIR)

IGMP snooping operates at the bridge domain level. When IGMP snooping is enabled on a bridge domain, the snooping functionality applies to all ports under the bridge domain, including:

• Physical ports under the bridge domain.

• Ethernet flow points (EFPs)—An EFP can be a VLAN, VLAN range, list of VLANs, or an entire interface port.

• Pseudowires (PWs) in VPLS bridge domains.

• Ethernet bundles—Ethernet bundles include IEEE 802.3ad link bundles and Cisco EtherChannel bundles. From the perspective of the IGMP snooping application, an Ethernet bundle is just another EFP. The forwarding application in the Cisco ASR 9000 Series Routers randomly nominates a single port from the bundle to carry the multicast traffic.

IGMP snooping classifies each port (for example, EFPs, PWs, physical ports, or EFP bundles) as one of the following:

• Multicast router ports (mrouter ports)—These are ports to which a multicast-enabled router is connected. Mrouter ports are usually dynamically discovered, but may also be statically configured. Multicast traffic is always forwarded to all mrouter ports, except when an mrouter port is the ingress port.

• Host ports—Any port that is not an mrouter port is a host port.

IGMP snooping discovers mrouter ports dynamically. You can also explicitly configure a port as an mrouter port.

• Discovery—IGMP snooping identifies upstream mrouter ports in the bridge domain by snooping IGMP query messages and Protocol Independent Multicast Version 2 (PIMv2) hello messages. Snooping PIMv2 hello messages identifies IGMP nonqueriers in the bridge domain.

• Static configuration—You can statically configure a port as an mrouter port with the mrouter command in a profile attached to the port. Static configuration can help in situations when incompatibilities with non-Cisco equipment prevent dynamic discovery.

The router-guard command prevents a port from becoming a dynamically discovered mrouter port by filtering out multicast router messages, including IGMP queries and PIM messages. You can configure a port with the router-guard command and then configure it as a static mrouter. See the Router Guard and Static Mrouter for more information about configuring router-guard and mrouter commands on the same port.

The following tables describe traffic handling behaviors by IGMP snooping mrouter and host ports. Table 1 describes traffic handling for an IGMPv2 querier. Table 2 applies to an IGMPv3 querier.

By default, IGMP snooping supports IGMPv2 and IGMPv3. The version of the IGMP querier discovered in the bridge domain determines the operational version of the snooping processes. If you change the default, configuring IGMP snooping to support a minimum version of IGMPv3, IGMP snooping ignores any IGMPv2 queriers.

The following are the restrictions of the Bidirectional IGMP Snoop Synchronization feature on Satellite Dual-Homed Systems feature:

• Synchronization is not supported on ASR9K chassis running RSP cards of different endian types.

• IGMP synchronization over BVI requires that the BVI must have a lower IP address than the internal-querier, and the bridge domain is configured with an internal querier with the lowest possible query max response time, that is, "query-max-response-time 1."

• Ambiguous VLAN ports are not supported with IGMP snoop synchronization functionality.

• The IGMP snoop configuration has to be manually synchronized on both the hosts for the synchronization functionality to work as expected on the nV Satellite dual-homed systems.

To create a profile, use the igmp snooping profile command in global configuration mode.

To attach a profile to a bridge domain, use the igmp snooping profile command in l2vpn bridge group bridge domain configuration mode. To attach a profile to a port, use the igmp snooping profile command in the interface configuration mode under the bridge domain. To detach a profile, use the no form of the command in the appropriate configuration mode.

When you detach a profile from a bridge domain or a port, the profile still exists and is available for use at a later time. Detaching a profile has the following results:

• If you detach a profile from a bridge domain, IGMP snooping is deactivated in the bridge domain.

• If you detach a profile from a port, IGMP snooping configuration values for the port are instantiated from the bridge domain profile.

You cannot make changes to an active profile. An active profile is one that is currently attached.

• If the active profile is configured under the bridge, you must detach it from the bridge, and reattach it.

• If the active profile is configured under a specific bridge port, you must detach it from the bridge port, and reattach it.

Another way to do this is to create a new profile incorporating the desired changes and attach it to the bridges or ports, replacing the existing profile. This deactivates IGMP snooping and then reactivates it with parameters from the new profile.

Access control configuration is the configuration of access groups and weighted group limits.

The role of access groups in IGMP v2/v3 message filteringis to permit or deny host membership requests for multicast groups (*,G) and multicast source groups (S,G). This is required to provide blocked-and-allowed list access to IPTV channel packages.

Weighted group limits restrict the number of IGMP v2/v3 groups, in which the maximum number of concurrently allowed multicast channels can be configured on a per EFP- and per PW-basis.

IGMP Snooping Access Groups

Although Layer-3 IGMP routing also uses the igmp access-group command in support of access groups, the support is not the same in Layer-2 IGMP, because the Layer-3 IGMP routing access group feature does not support source groups.

Access groups are specified using an extended IP access list referenced in an IGMP snooping profile that you attach to a bridge domain or a port.

Note	A port-level access group overrides any bridge domain-level access group.

The access-group command instructs IGMP snooping to apply the specified access list filter to received membership reports. By default, no access list is applied.

Changes made to the access-list referenced in the profile (or a replacement of the access-list referenced in the igmp snooping profile) will immediately result in filtering the incoming igmp group reports and the existing group states accordingly, without the need for a detach-reattach of the igmp snooping profile in the bridge-domain, each time such a change is made.

IGMP Snooping Group Weighting

To limit the number of IGMP v2/v3 groups, in which the maximum number of concurrently allowed multicast channels must be configurable on a per EFP-basis and per PW-basis, configure group weighting.

IGMP snooping limits the membership on a bridge port to a configured maximum, but extends the feature to support IGMPv3 source groups and to allow different weights to be assigned to individual groups or source groups. This enables the IPTV provider, for example, to associate standard and high- definition IPTV streams, as appropriate, to specific subscribers.

This feature does not limit the actual multicast bandwidth that may be transmitted on a port. Rather, it limits the number of IGMP groups and source-groups, of which a port can be a member. It is the responsibility of the IPTV operator to configure subscriber membership requests to the appropriate multicast flows.

The group policy command, which is under igmp-snooping-profile configuration mode, instructs IGMP snooping to use the specified route policy to determine the weight contributed by a new <*,G> or <S,G> membership request. The default behavior is for there to be no group weight configured.

The group limit command specifies the group limit of the port. No new group or source group is accepted if its contributed weight would cause this limit to be exceeded. If a group limit is configured (without group policy configuration), a <S/*,G> group state will have a default weight of 1 attributed to it.

Note	By default, each group or source-group contributes a weight of 1 towards the group limit. Different weights can be assigned to groups or source groups using the group policy command.

The group limit policy configuration is based on these conditions:

• Group weight values for <*,G> and <S,G> membership are configured in a Route Policy, that is included in an igmp snooping profile attached to a BD or port.

• Port level weight policy overrides any bridge domain level policy, if group-limit is set and route-policy is configured.

• If there is no policy configured, each group weight is counted equally and is equal to 1.

• If policy has been configured, all matching groups get weight of 1 and un-matched groups have 0 weight.

The minimum-version command determines which IGMP versions are supported by IGMP snooping in the bridge domain:

• When minimum-version is 2, IGMP snooping intercepts IGMPv2 and IGMPv3 messages. This is the default value.

• When minimum-version is 3, IGMP snooping intercepts only IGMPv3 messages and drops all IGMPv2 messages.

IGMPv1 is not supported. The scope for this command is the bridge domain. The command is ignored in a profile attached to a port.

The system-ip-address command configures an IP address for IGMP snooping use. If not explicitly configured, the default address is 0.0.0.0. The default is adequate except in the following circumstances:

• If you are configuring an internal querier. The internal querier cannot use 0.0.0.0.

• If the bridge needs to communicate with an IGMP router that does not accept the 0.0.0.0 address.

The IGMP snooping system IP address is used in the following ways:

• The internal-querier sends queries from the system IP address. An address other than the default 0.0.0.0 must be configured.

• IGMPv3 sends proxy reports from the systemIP address. The default address 0.0.0.0 is preferred but may not be acceptable to some IGMP routers.

• In response to topology change notifications (TCNs) in the bridge domain, IGMP snooping sends global-leaves from the system IP address. The default address 0.0.0.0 is preferred but may not be acceptable to some IGMP routers.

The group membership interval (GMI) controls when IGMP snooping expires stale group membership states. The show igmp snooping group command shows groups with an expiry time of 0 until that stale state is cleaned up following the next query interval.

The GMI is calculated as:

GMI = (robustness-variable * query-interval) + maximum-response-time

where:

• maximum-response-time (MRT) is the amount of time during which receivers are required to report their membership state.

• robustness-variable is an integer used to influence the calculated GMI.

• query-interval is the amount of time between general queries.

Values for the components in the GMI are obtained as follows:

• MRT is advertised in the general query, for both IGMPv2 and IGMPv3.

• If the querier is running IGMPv2, IGMP snooping uses the IGMP-snooping-configured values for the robustness-variable and query-interval. These parameter values must match the configured values for the querier. In most cases, if you are interacting with other Cisco routers, you should not need to explicitly configure these values—the default values for IGMP snooping should match the default values of the querier. If they do not, use the querier robustness-variable and querier query-interval commands to configure matching values.

• IGMPv3 general queries convey values for robustness-variable and query-interval (QRV and QQI, respectively). IGMP snooping uses the values from the query, making the IGMP snooping GMI exactly match that of the querier.

The following IGMP snooping features reduce multicast traffic in a bridge domain. Both are enabled by default.

• IGMPv2 report suppression—If the bridge domain querier is running IGMPv2, IGMP snooping suppresses joins from a host if it has already forwarded the same join from another host during the current query interval. IGMP snooping forwards the last leave message to all mrouter ports.

  As insurance against lost reports when report suppression is enabled, IGMP snooping forwards IGMPv2 join reports the configured querier robustness-variable times for new groups. Configure the querier robustness-variable using the querier robustness-variable command.

• IGMPv3 proxy reporting—If the bridge domain querier is running IGMPv3, IGMP snooping acts as a proxy, generating reports from the proxy reporting address. Configure the proxy reporting address using the system-ip-address command. The default value is 0.0.0.0.

  As insurance against lost reports when proxy reporting is enabled, IGMP snooping generates and forwards state change reports robustness-variable times, where the robustness-variable is the QRV value in the querier’s general query. The reports are forwarded at random intervals within the timeframe configured with the unsolicited-report-timer command.

To disable report suppression and proxy reporting, use the report-suppression disable command.

The scope for the commands mentioned in this section is the bridge domain. The commands are ignored in a profile attached to a port.

In a Spanning Tree Protocol (STP) topology, a Topology Change Notification (TCN) indicates that an STP topology change has occurred. As a result of a topology change, mrouters and hosts reporting group membership may migrate to other STP ports under the bridge domain. Mrouter and membership states must be relearned after a TCN.

IGMP snooping reacts to TCNs in the following ways:

1. IGMP snooping temporarily extends the flood set for all known multicast routes to include all ports participating in STP that are in forwarding state. The short-term flooding ensures that multicast delivery continues to all mrouters and all member hosts in the bridge domain while mrouter and membership states are relearned.

   But, as a result of this TCN flooding, downstream STP links may sometimes become over-subscribed by these extra multicast flows. This feature can in such cases be disabled by use of the tcn flood disable command.

2. The STP root bridge issues a global leave ( for group 0.0.0.0) on all ports. This action triggers interoperable IGMP queriers to send general queries, expediting the relearning process.

   Note	Sending global leaves for query solicitation is a Cisco-specific implementation.

3. When the TCN refresh period ends, IGMP snooping withdraws the non-mrouter and non-member STP ports from the multicast route flood sets. You can control the amount of time that flooding occurs with the tcn flood query count command. This command sets the number of IGMP general queries for which the multicast traffic is flooded following a TCN, thereby influencing the refresh period.

IGMP snooping default behavior is that the STP root bridge always issues a global leave in response to a TCN, and that the non-root bridges do not issue global leaves.

With the tcn query solicit command, you can enable a bridge to always issue a global leave in response to TCNs, even when it is not the root bridge. In that case, the root bridge and the non-root bridge would issue the global leave and both would solicit general queries in response to a TCN. Use the no form of the command to turn off soliciting when the bridge is not the root.

Note

One use for the tcn query solicit command is when Reverse Layer 2 Gateway Protocol (RL2GP) is configured to set up a MSTP Access Gateway. In this scenario, IGMP snooping is unaware of the root or non-root status of the bridge and, therefore, when a TCN occurs, no query is solicited in the domain unless IGMP snooping is explicity configured to do so on at least one bridge.

The root bridge always issues a global leave in response to a TCN. This behavior can not be disabled.

The internal querier has its own set of configuration options that control its reactions to TCNs.

The scope for all tcn related configuration option(s) is per bridge domain. If the command appears in profiles attached to ports, it has no effect.

By default, IGMP snooping performs the following validations. If your network performs these validations elsewhere, you can disable the IGMP snooping validations.

• IGMP snooping checks the time-to-live (TTL) field in the IGMP header and drops packets where TTL is not equal to 1. The TTL field should always be set to 1 in the headers of IGMP reports and queries.

  You can disable this check using the ttl-check disable command, in which case IGMP snooping processes all packets without examining the TTL field in the IGMP header.

• IGMP snooping checks for the presence of the router alert option in the IP packet header of the IGMP message and drops packets that do not include this option.

  You can disable this check using the router-alert-check disable command, in which case IGMP snooping does not perform the validation before processing the message.

The startup query feature is configured using new igmp snooping profile parameters. You can configure the startup query processing in response to the following events:

• MC-LAG Port goes active

• Topology-change

• Port-up

• Process start

The above parameters are specific to MC-LAG feature. These are apart from the existing bridge domain level parameters such as count, MRT, and query interval. For more information about these CLI, refer the Multicast Command Reference for Cisco ASR 9000 Series Routers.

Note

For IGMP snooping to work on MC-LAG properly, the IGMP snooping configuration on both the POAs must be the same. In the case of downstream MC-LAG, when MC-LAG is configured and up and running, the MC-LAG port has to be added in IGMP Snooping enabled Bridge-domain. In the case of upstream MC-LAG, where POAs are attached to multicast router, the static mrouter port has to be configured on the multicast router that is towards both the POAs so that traffic is drawn to both the POAs.

Router guard is a security feature that prevents malicious users from making a host port into an mrouter port. (This undesirable behavior is known as spoofing.) When a port is protected with the router-guard command, it cannot be dynamically discovered as an mrouter. When router guard is on a port, IGMP snooping filters protocol packets sent to the port and discards any that are multicast router control packets.

The mrouter command configures a port as a static mrouter.

You can use the router-guard and the mrouter commands on the same port to configure a guarded port as a static mrouter, for example, when:

• A large number of downstream host ports are present and you want to block dynamic mrouter discovery and configure static mrouters. In this case, configure the router guard feature at the domain level. By default, it will be applied to all ports, including the typically large number of downstream host ports. Then, use another profile without router guard configured for the relatively few upstream ports on which you want to permit dynamic mrouter discovery or configure static mrouters.

• Incompatibilities with non-Cisco equipment prevents correct dynamic discovery, you can disable all attempts for dynamic discovery using the router guard feature, and statically configure the mrouter.

  If you are using the router guard feature, because there is an incompatible IGMP router on the port, you should also configure the mrouter command on the port to ensure that the router receives IGMP reports and multicast flows.

See the Group Leave Processing.

IGMP snooping learns Layer-2 multicast groups dynamically. You can also statically configure Layer-2 multicast groups.

You can use the static group command in profiles intended for bridge domains or ports. I f you configure this option in a profile attached to a bridge domain, it applies to all ports under the bridge.

A profile can contain multiple static groups. You can define different source addresses for the same group address. Using the source keyword, you can configure IGMPv3 source groups.

Static group membership supersedes any dynamic manipulation by IGMP snooping. Multicast group membership lists can contain both static and dynamic group definitions.

When you configure a static group or source groups on a port, IGMP snooping adds the port as an outgoing port to the corresponding <S/*,G> forwarding entry and sends an IGMPv2 join or IGMPv3 report to all mrouter ports. IGMP snooping continues to send the membership report in response to general queries for as long as the static group remains configured on the port.

In a network where IP multicast routing is configured, the IP multicast router acts as the IGMP querier. In situations when no external querier exists in the bridge domain (because the multicast traffic does not need to be routed), but local multicast sources exist, you must configure an internal querier to implement IGMP snooping. The internal querier solicits membership reports from hosts in the bridge domain so that IGMP snooping can build constrained multicast forwarding tables for the multicast traffic within the bridge domain.

An internal querier might also be useful when interoperability issues with non-Cisco equipment prevent IGMP snooping from working correctly with an external querier. In this case, you can:

1. Prevent the uncooperative external querier from being discovered by placing the router-guard command on that port.

2. Configure an internal querier to learn group membership interests from the ports in the bridge domain.

3. Configure static mrouter ports to receive multicast traffic.

The minimum configuration for an internal querier is:

• Add the internal-querier command to a profile attached to the bridge domain. The default configuration is shown in Table 1.

• Add the system-ip-address command to a profile attached to the bridge domain to configure an address other than the default 0.0.0.0.

You can disable the internal querier (using the no form of the internal-querier command) without removing any other internal querier commands. The additional internal querier commands are ignored in that case.

The scope for the internal-querier command is per bridge domain. If the command appears in profiles attached to ports, it has no effect.

When the internal querier is the elected querier in the domain, it solicits membership reports by sending IGMP general queries at the interval specified by the internal-querier query-interval command on every active port in the bridge domain. The internal querier sends IGMPv3 queries by default. You can configure it to send IGMPv2 messages instead using the internal-querier version command.

The local IGMP snooping process responds to the internal querier's general queries. In particular, the IGMPv3 proxy (if enabled) generates a current-state report and forwards it to all mrouters. For IGMPv2 or when the IGMPv3 proxy is disabled, IGMP snooping generates current-state reports for static group state only.

The queries are sent from the address you configure for IGMP snooping using the system-ip-address command. The queries include the maximum response time configured with the internal-querier max-response-time command.

The internal-querier robustness-variable and internal-querier query-interval commands configure values for both IGMPv2 and IGMPv3 processing.

A bridge domain can have only one active querier at a time. If the internal-querier receives queries from another querier in a bridge domain, it performs querier election. The lowest IP address wins. If the internal querier is the election loser, IGMP snooping starts a timer with the value set by the internal-querier timer expiry command. If this timer expires before another query is received from the election winner, the internal querier becomes the active querier.

Note	The default internal-querier timer expiry command value is derived from the values of other configuration options, as described in Table 1. You can configure a different value to override the default calculation.

IGMP snooping generates group leaves in response to topology change notifications. For more information about how IGMP snooping reacts to TCNs, see the Reaction to Topology Change Notifications.

If the internal querier receives a group leave while it is the elected querier in the domain, it reacts as follows:

• Generates an IGMP general query immediately.

• Waits the amount of time set by the internal-querier tcn query interval command and generates another IGMP general query.

• Continues to wait for the specified interval time and to send general queries until the query count reaches the value set with the internal querier tcn query count command.

Note	You can configure the internal querier to ignore global leaves by setting the internal querier TCN query count to 0.