Scenario 7-4: Configuring IGMP Snooping

In the previous scenario, you learned how to constrain multicast flooding on the LAN by directly configuring the bridge table on your switches. As highlighted in the scenario, although this method is very simple and easy to understand, it is totally static in that any modifications required to the configuration are not performed dynamically and must be manually configured.

Cisco Catalyst switches can provide intelligent multicast forwarding on Layer 2 (Ethernet) networks, by using features such as IGMP snooping, CGMP, and GMRP. These features dynamically learn which ports are connected to receivers or downstream multicast routers and automatically constrain multicast flooding to just these ports. When a receiver attaches, moves, shuts down, or disconnects from the network, this event is learned by the switch and the bridge table entries are automatically modified as appropriate. This scenario discusses IGMP snooping and shows you how to configure it on Cisco Catalyst switches. The topology of Figure 7-6 is used to demonstrate IGMP snooping for this scenario, and it is assumed that the multicast routing configurations of the previous scenarios have been implemented.

IGMP Snooping Operation

IGMP snooping allows a switch to dynamically determine which hosts connected to a particular VLAN in the switch need to receive a particular multicast transmission. The switch basically listens (snoops) to the various IGMP messages (such as Join, Query, Response, Leave), as well as other multicast protocol transmissions, and dynamically determines which egress ports are associated with each multicast transmission. The switch still uses a bridge table entry to control multicast forwarding, except the entry is dynamic and not statically configured. Based upon IGMP messages snooped, a switch performs the following actions:

• Adding a receiver to a group

• Removing a receiver from a group

• Maintaining group membership

Adding a Receiver to a Group

Before receivers attach to the LAN, multicast routers that are also attached to the LAN are normally already operational and have sent IGMP General Query messages in an attempt to locate any receivers attached to the LAN. IGMP snooping switches can use these messages to determine where multicast routers are located, which is important because switches must forward all multicast traffic to every multicast router on the LAN to ensure that IGMP group maintenance messages are always passed to the multicast routers and also to ensure that any multicast traffic that requires forwarding off the LAN by multicast routers is forwarded.

When a receiver attaches to the LAN, it immediately indicates its desire to join multicast groups by sending an IGMP Membership Report to each group address the receiver wants to join.

Figure 7-18 illustrates IGMP snooping operation on the 10.6.0.0/16 subnet of Figure 7-6.

Figure 7-18. IGMP Snooping

In Figure 7-18, assume that L3-Switch-B is the IGMP Querier for the LAN segment:

1. L3-Switch-B (a multicast router) sends an IGMP General Query (to the 224.0.0.1 all hosts address or 0100.5e00.0001) every 60 seconds as part of the normal IGMP maintenance process.

2. The switch receives the periodic IGMP General Query sent by L3-Switch-B. Notice that a permanent bridge table entry exists that forwards any IP multicast frames (0100.5eXX.XXXX) to port 0. Port 0 represents the switch CPU, which must receive all multicast frames to properly snoop IGMP Membership Reports and Leave Group messages. The General Query is forwarded to the CPU, and because multicast routers only ever send IGMP General Query messages, the switch knows that a multicast router is connected to interface Fa0/1, which is important because the interface attached to the multicast router should be included in all bridge table entries that reference a multicast address. This configuration ensures that the router receives any membership reports that are sent for multicast groups and also ensures that the switch can forward multicast frames generated by local sources only out interfaces attached to multicast routers. The IGMP General Query is then flooded out all interfaces on the switch to ensure it reaches all potential receivers on the LAN.

   NOTE

   In the real world on a live network, forwarding all multicast frames to the switch CPU can cause major performance issues. For example, if the switch CPU has to process every single frame sent of multiple video streams that each consume 1.5 Mbps and generate 20 frames per second, the CPU becomes quickly overwhelmed, causing the switch to crash or to not perform other more important functions, such as generating and processing spanning tree BPDUs. Cisco Catalyst switches do not forward all multicast frames to the switch CPU; only multicast frames that have an IP protocol type of 2 (IGMP) are forwarded to the switch CPU (after all, IGMP snooping requires only IGMP messages to be snooped).

   
   

3. Router-B attaches to the network and sends an IGMP Membership Report message, which is addressed to the group address (0100.5e01.0101) that Router-B wants to join.

4. The switch receives the IGMP Membership Report message from Router-B. Because the group address (0100.5e01.0101) is not currently in the bridge table, the multicast is flooded out all interfaces, except the interface the multicast was received upon. Switch-B also creates a new bridge table entry for the 0100.5e01.0101 address and adds the multicast router interface (Fa0/1) and the ingress interface of the frame (Fa0/4, attached to Router-B) to the egress port list. At this point, if multicast frames sent to 0100.5e01.0101 are received from the source (via L3-Switch-B), the bridge table entry means that the multicast is forwarded only out interface Fa0/4 (the multicast is not forwarded out interface Fa0/1, because this is the ingress interface for frames generated by the source).

   NOTE

   Notice that the process of populating the bridge table with multicast MAC addresses is based upon inspection of the destination MAC address, unlike unicast MAC addresses where the source MAC address of unicast frames is examined to generate bridge table entries.

   
   

5. The discussion so far has disregarded L3-Switch-D, which is a downstream multicast router for the 239.1.1.1 group. Because L3-Switch-B is the IGMP Querier for the segment, L3-Switch-D does not send any IGMP messages to the segment, which means Switch-B can't detect L3-Switch-D via IGMP messages. If L3-Switch-D has receivers attached further downstream, it is important that multicast frames are also forwarded to L3-Switch-D. To detect other multicast routers on the LAN, Cisco Catalyst switches also listen for other messages that indicate the presence of another multicast router. In Figure 7-18, L3-Switch-D generates PIM hellos every 30 seconds by default, as part of normal PIM operation. The switch hears these PIM Hello message generated by L3-Switch-D on interface Fa0/3 and thus ensures that interface Fa0/3 is added to the egress port list for all multicast addresses in the bridge table.

Figure 7-18 describes what happens when a single receiver joins a multicast group. If another receiver joins the multicast group, Switch-B receives the IGMP Membership Report sent by the receiver and simply appends the interface attached to the new receiver to the bridge table entry for the multicast group address, ensuring the new receiver also receives multicast frames. Because the group already exists and has active receivers on the LAN, the switch does not actually need to forward the IGMP Membership Report to the multicast router (L3-Switch-B). The Cisco Catalyst implementation of IGMP snooping forwards no more than one IGMP Membership Report for an existing group within a 10 second period, which reduces load on the multicast router if a large number of receivers attach to an existing group within a small period of time. This feature is known as proxy reporting and is also used for maintaining group membership, which is discussed later in this scenario.

Removing a Receiver from a Group

Now that you understand how IGMP snooping works when receivers join a group, you need to understand that IGMP snooping must also detect when receivers leave a group, because multicast frames no longer need to be forwarded out the interface attached to the receiver that has just left the group. Figure 7-19 illustrates what happens when Router-B (the receiver) wants to leave the multicast group 239.1.1.1.

Figure 7-19. Removing Receivers Using IGMP Snooping

In Figure 7-19, the following events occur:

1. Router-B wants to leave the multicast group and sends an IGMP Leave Group message to the 224.0.0.2 (0100.5e00.0002) all multicast routers multicast address. This message includes the group that the receiver wants to leave.

2. Switch-B receives the IGMP Leave Group message and passes the message to the switch CPU, based upon the bridge table entry that forwards all IGMP multicast messages to the CPU. Switch-B then sends an IGMP Group-Specific Query message out the interface attached to the receiver (Fa0/4) that sent the Leave Group message to ensure that other receivers are not attached to the interface (this could happen if another switch or hub is connected to the interface, with receiver and other receivers connected to the remote switch or hub).

3. Because Router-B is directly attached to interface Fa0/4 and wants to leave the group, the Group-Specific Query sent by Switch-B is not answered. Switch-B can safely assume that no more receivers are attached to the interface and subsequently remove the interface from the egress port list for the multicast group.

4. At this point, Switch-B examines the egress port list for the multicast group to determine whether any non-router interfaces are still present. If there are still non-router interfaces in the egress port list, it means that receivers are connected to the LAN and the switch discards the original IGMP Leave Group message sent in Step 1. (The multicast router attached to the LAN does not need to receive this message because it still has receivers attached that it would unnecessarily try to determine whether or not to forward the Leave Group message to.) In Figure 7-19, because Router-B is the only receiver (and therefore, last receiver) on the LAN, only router interfaces remain in the egress port list for the group address, indicating to Switch-B that no more receivers are connected to the LAN. Because of this indication, Switch-B forwards the original Leave Group message sent in Step 1 to the multicast routers, which ensures that the multicast routers can prune the locally attached interface from the LAN off the multicast routing tree if applicable.

Notice that IGMP snooping is more intrusive (although still transparent to receivers) for the leave process. The IGMP snooping switch actually acts almost like a proxy, accepting Leave Group messages from receivers and then querying the receivers' interface. Consequently, the IGMP leave process is more efficient because the Leave Group messages are forwarded to multicast routers only if no more receivers are attached to the LAN.

NOTE

Some Cisco Catalyst switches support IGMP fast-leave processing, which means that the switch immediately removes the interface attached to a receiver upon reception of the Leave Group message (i.e., the Group-Specific Query sent in Step 2 of Figure 7-19 is not sent). This feature speeds up leave processing, but should only be used when receivers are directly attached to the switch.

Maintaining Group Membership

Once a receiver has joined a multicast group, it must periodically indicate that it still wants to be a receiver for the group. The IGMP Querier (multicast router) for a LAN periodically sends IGMP General Query messages, every 60 seconds by default, and receivers attached to the LAN respond to the General Query with an IGMP Membership Report. If multiple receivers are attached to the LAN, once a Membership Report has been sent by one receiver for a multicast group, then all other receivers in the group suppress sending a Membership Report in response to the General Query, because one Membership Report message is sufficient to ensure the multicast router continues to forward multicast traffic onto the LAN.

The report suppression mechanism causes an issue for IGMP snooping switches because the switch needs to know which specific receivers are attached to the LAN, whereas a multicast router needs to know only that at least one receiver is attached to the LAN. The report suppression mechanism is designed for eliminating redundant membership report messages, but the result of the suppression is that IGMP snooping switches are not able to determine whether or not a receiver is still attached to a specific port, which in turn determines whether or not the port remains in the egress port list for a group address in the bridge table. You might argue that an IGMP snooping switch could simply maintain a receiver port in the egress port list for a group and remove the receiver port from the list when the receiver sends an IGMP Leave Group message. Although in theory this strategy might work, in reality, it is possible that a receiver might not get a chance to send a Leave Group message (due to the receiver being accidentally powered off or disconnected from the LAN). Also, only IGMPv2 receivers send Leave Group messages, so you still have a problem for IGMPv1 receivers.

To circumvent the issues just described that are introduced by the report suppression mechanism, Cisco Catalyst switches that implement IGMP snooping ensure that IGMP Membership Reports that are sent in response to IGMP General Queries are not heard by other receivers (i.e., each Membership Report is forwarded only to the switch CPU and not flooded to all ports that are specified in the egress port list for the group address). Consequently, every receiver on the LAN responds to the IGMP General Query because each receiver does not hear any other Membership Report messages. This process ensures the switch has an accurate picture of exactly which receivers are still attached to the LAN and can add, remove, or maintain the egress port list for group addresses in the bridge table appropriately.

Of course, the multicast router that sent the General Query message must receive at least one Membership Report response to ensure that the multicast router does not remove the interface attached to the LAN from outgoing interface list for the multicast group. Because a single response is sufficient to maintain the group state on multicast routers, Cisco Catalyst switches implement the proxy report feature, which ensures no more than one Membership Report is sent within a 10 second period in response to the General Query. This mechanism is the same one used when new receivers join an existing group.

IGMP Snooping Support on Cisco Catalyst Switches

Not all Cisco Catalyst switches support IGMP snooping. Table 7-3 lists the various Cisco Catalyst platforms and indicates whether or not IGMP snooping is supported and what minimum software is required.

Table 7-3. IGMP Snooping Support on Cisco Catalyst Switches

Platform	IGMP Snooping Supported	Minimum Software
Catalyst 1900/2820	No
Catalyst 2900XL/3500XL	No
Catalyst 2950/3550	Yes	All IOS Releases
Catalyst 4000 (Supervisor 1/2)	No
Catalyst 4000 (Supervisor 3/4)	Yes	All IOS Releases
Catalyst 5000/5500	Yes (Supervisor 2G/3G or Sup 3 with NFFC only)	CatOS 4.1
Catalyst 6000/6500	Yes	All CatOS Releases

Configuration Tasks

The configuration of IGMP snooping is very simple and consists of the following tasks:

• Enabling IGMP snooping

• Enabling IGMP fast-leave processing

• Enabling the IGMP Querier function

Enabling IGMP Snooping

By default, most recent CatOS and Cisco IOS software images that support IGMP snooping have the feature enabled by default. To enable IGMP snooping on CatOS, use the set igmp enable command:

 Console> (enable) set igmp {enable | disable} 

Example 7-36 demonstrates enabling IGMP snooping on Switch-C in Figure 7-6.

Example 7-36. Enabling IGMP Snooping on Switch-C

 Switch-C> (enable) set igmp enable IGMP Snooping is enabled. 

Once you have enabled IGMP snooping, the switch starts listening to IGMP messages and updates its bridge table entries for multicast addresses dynamically. The switch also automatically learns about the multicast routers attached to each VLAN. On CatOS, you can use the show multicast router command to verify that the switch has automatically learned about all of the multicast routers attached to the switch, as demonstrated in Example 7-37 on Switch-C.

Example 7-37. Verifying Multicast Router Information on Switch-C

 Switch-C> (enable) show multicast router IGMP enabled Port       Vlan ---------  ----------------  2/1       1  2/2       1 Total Number of Entries = 2 '*' - Configured 

In Example 7-37, you can see that Switch-C has detected both L3-Switch-B and L3-Switch-C, which are connected to ports 2/2 and 2/1 respectively.

TIP

You can statically configure multicast router ports using the set multicast router command.

CatOS also provides the show multicast group command, which allows you to view information related to active multicast groups detected by the switch and has the following syntax:

 Console> (enable) show multicast group [group-mac-address] [vlan-id] 

Example 7-38 demonstrates the use of this command on Switch-C.

Example 7-38. Verifying Multicast Group Information on Switch-C

 Switch-C> (enable) show multicast group IGMP enabled VLAN  Dest MAC/Route Des  Destination Ports or VCs / [Protocol Type] ----  ------------------  ---------------------------------------------------- 1     01-00-5e-00-01-28   2/1-2 1     01-00-5E-01-01-01*  2/1-2,2/4 Total Number of Entries = 1 

Notice in Example 7-38 that a single group address exists for the 239.1.1.1 group address (01-00-5E-01-01-01). The destination ports associated with this entry are indicated as ports 2/1, 2/2, and 2/4. Port 2/3 is correctly not included in the destination port list because no receivers are attached to this port.

TIP

The 01-00-5e-00-01-28 entry represents the 224.0.1.40 group, which is used for rendezvous point discovery and is automatically enabled on Catalyst 3550 Layer 3 switches.

To enable IGMP snooping on Cisco IOS, use the ip igmp snooping global configuration command:

 Switch(config)# ip igmp snooping vlan vlan-id mrouter learn {cgmp | pim-dvmrp} 

The mrouter learn keywords define how the switch learns about interfaces that are attached to multicast routers. If you choose the cgmp option, multicast router ports are determined by listening to CGMP packets sent from routers (CGMP is covered in the next section). If you choose the pim-dvmrp option, multicast router ports are determined by listening to IGMP, PIM, and DVMRP packets (this is the default learning method).

NOTE

Choosing the CGMP learning method just means that the switch determines where multicast routers are located on the LAN by listening to CGMP messages sent by multicast routers. It does not mean that the switch is configured to support full CGMP operation.

Example 7-39 demonstrates enabling IGMP snooping on Switch-B in Figure 7-6.

Example 7-39. Enabling IGMP Snooping on Switch-B

 Switch-B# configure terminal Switch-B(config)# ip igmp snooping vlan 1 mrouter learn pim-dvmrp 

Notice that the multicast router learning mode is set to pim-dvmrp, which is required because L3-Switch-B and L3-Switch-D are PIM neighbors. Once you have enabled IGMP snooping, you should use the show ip igmp snooping mrouter command to verify that the switch has automatically learned about all of the multicast routers attached to the switch, as is demonstrated in Example 7-40 on Switch-C.

Example 7-40. Verifying Multicast Router Information on Switch-B

 Switch-B# show ip igmp snooping mrouter Vlan    ports ----    -----    1    Fa0/1(dynamic)    1    Fa0/2(dynamic) 

In Example 7-40, you can see that Switch-B has detected both L3-Switch-C and L3-Switch-D, which are connected to interfaces Fa0/1 and Fa0/2 respectively. The "dynamic" text indicates that the switch has automatically learned the entries.

TIP

You can statically configure multicast router interfaces using the ip igmp snooping vlan vlan-id mrouter interface interface-id command.

Once you have verified the switch can see each multicast router, you can then verify that the appropriate interfaces are listed in the egress port list for the multicast group address in the bridge table. On Cisco IOS, this information can be verified by using the show mac-address-table multicast command, which allows you to view information related to active multicast groups detected by the switch. Example 7-41 demonstrates the use of this command on Switch-B.

Example 7-41. Verifying Multicast Group Information on Switch-B

 Switch-B# show mac-address-table multicast Vlan    Mac Address       Type       Ports ----    -----------       ----       -----    1    0100.5e01.0101    IGMP       Fa0/1 Fa0/2 Fa0/3 

Notice in Example 7-41 that a single group address exists for the 239.1.1.1 group address (01-00-5E-01-01-01). The destination ports associated with this entry are indicated as interfaces Fa0/1, Fa0/2, and Fa0/3. Interface Fa0/4 is correctly not included in the destination port list because no receivers are attached to this interface. The Type field indicates that the entry was learned dynamically via IGMP (compare with Example 7-35 which displayed a static entry).

TIP

You can use either the mac-address-table static mac-address vlan vlan-id interface interface-id global configuration command or the ip igmp snooping vlan vlan-id static mac-address interface interface-id command to statically associate a receiver with an interface.

Enabling IGMP Fast-Leave Processing

IGMP fast-leave processing modifies the default IGMP snooping process implemented on Cisco Catalyst switches when an IGMP Leave Group message is received from a receiver that wants to leave a multicast group. By default, Cisco Catalyst switches send an IGMP Group-Specific Query message out the interface upon which the Leave Group message was received to ensure that no other receivers are connected to the interface. If receivers are directly attached to the switch, there is no point in sending the membership query because the receiver wanting to leave is the only connected host.

NOTE

IGMP fast-Leave processing is also referred to as immediate leave processing on some Cisco Catalyst switches.

IGMP fast-leave processing caters to the situation where all receivers are directly attached to the switch and eliminates the IGMP Group-Specific Query message, allowing the switch to immediately remove an interface from the bridge table upon receiving the Leave Group message. This processing speeds up the overall leave process and also eliminates the CPU overhead of having to generate an IGMP Group-Specific Query message.

To enable fast-leave processing on CatOS, use the set igmp fastleave enable command, as shown in Example 7-42 on Switch-C.

Example 7-42. Enabling IGMP Fast Leave on Switch-C

 Switch-C> (enable) set igmp fastleave enable IGMP fastleave set to enable. 

To enable fast-leave processing on Cisco IOS, use the ip igmp snooping global configuration command, as follows:

 Switch(config)# ip igmp snooping vlan vlan-id immediate-leave 

Notice that you must specify each VLAN that you want enable immediate leave processing for.

NOTE

Only use IGMP fast-leave processing if all receivers (ideally all hosts) are directly attached to the switch. IGMP fast-leave processing also works only with IGMPv2 receivers because IGMPv1 receivers don't sent Leave Group messages whatsoever.

Enabling the IGMP Querier Function

The IGMP implementation on Cisco Catalyst 6000/6500 switches also caters to a special situation where no multicast routers are present on the LAN, yet you have a source and receivers for multicast groups and want to constrain this traffic to just the ports attached to the receivers. Because no multicast routers are present on the LAN, no device is querying hosts via IGMP for the multicast groups that they want to receive (this is normally the function of a multicast router). In this scenario, a Cisco Catalyst 6000/6500 switch can be configured to act as an IGMP Querier for the LAN, ensuring that the switch can constrain multicast traffic correctly, based upon the information gathered via the IGMP query process.

NOTE

If multiple IGMP Querier-enabled Catalyst 6000/6500 switches reside on the LAN, the IGMP Querier for the LAN is chosen as the switch with the lowest IP address. If the switch becomes the active IGMP Querier for the LAN, it sends IGMP General Queries every 125 seconds.

The IGMP Querier feature is supported only on the Catalyst 6000/6500 switch, starting from CatOS 7.1. To enable the IGMP Querier, use the set igmp querier command, as follows:

 Console> (enable) set igmp querier {enable | disable} vlan-id 

Assume in Figure 7-6 that Switch-C (Catalyst 6500) has been disconnected from the rest of the network, but still has a source and receivers attached. Example 7-43 demonstrates how to enable the IGMP Querier function on VLAN 1 for Switch-B to ensure that multicast traffic within VLAN 1 can be constrained correctly.

Example 7-43. Enabling the IGMP Querier Function on Switch-B

 Switch-B> (enable) set igmp querier enable 1