CGMPIGMP: Advanced Traffic Management

CGMP/IGMP: Advanced Traffic Management

Multicast traffic originates at sources desiring to distribute the same information to multiple recipients. When a source creates multicast traffic, it uses special Layer 2 and Layer 3 addresses so that routers and bridges know how to disperse the frame. By default, routers do not forward multicast traffic unless they are multicast capable and have a multicast routing protocol such as DVMRP (distance vector multicast routing protocol) or PIM (protocol independent multicast) enabled. DVMRP and PIM are inter-router protocols. Therefore, hosts and switches do not participate in messages for these protocols.

A LAN switch is not a router (although a router can be incorporated, such as the RSM). What happens, then, to multicast traffic in a switched network? By default, a switch (bridge) floods multicast traffic within a broadcast domain. This consumes bandwidth on access links and trunk links. Depending upon the host's TCP/IP stack implementation and network interface card (NIC) attributes, the multicast frame can cause a CPU interrupt. Why does a switch flood multicast traffic? A switch floods multicast traffic because it has no entry in the bridge table for the destination address. Multicast addresses never appear as source addresses, therefore the bridge/switch cannot dynamically learn multicast addresses. You can manually configure an entry with the set cam static command.

IGMP is a multicast protocol that directly affects hosts. IGMP allows hosts to inform routers that they want to receive multicast traffic for a specific multicast group address.

Current Catalysts don't understand IGMP messages (unless you have the NetFlow Feature Card [NFFC]). IGMP messages appear to a Catalyst like any other multicast frames. Cisco developed the proprietary CGMP that enables routers to inform Catalysts about hosts and their interest in receiving multicast traffic. This modifies the Catalyst's default behavior of flooding the multicast frame to all hosts in the broadcast domain. Rather than flooding the frame to all hosts, the Catalyst limits the flooding scope to only those hosts in the broadcast domain that registered with the router through IGMP. If a host does not register with the router, it does not receive a copy of the multicast frame. This preserves access link bandwidth.

Multicast Addresses

Whenever an application needs to send data to more than one station, but wants to restrict the distribution to only stations interested in receiving the traffic, the application typically uses a multicast destination address. Multicast addresses target a subset of all stations in the network. The other two transmission choices for a transmitting device are unicast or broadcast frames. If the source uses a broadcast address, all stations in the broadcast domain must process the frame, even if they are not interested in the information. If the source transmits unicast frames, it must send multiple copies of the frame, one addressed to each intended receiver. This is a very inefficient use of network resources and does not scale well as the number of receivers increases.

By using multicast addresses, the source transmits only one copy of the frame onto the wire and routers distribute the multicast message to the other segments where interested receivers reside. Multicast addresses appear at Layer 2 and at Layer 3. A network administrator assigns the multicast Layer 3 address for an application. The Layer 2 multicast address is then calculated from the Layer 3 multicast address. This is shown in the section, "Layer 2 Multicast Addresses." When you configure a multicast application, the NIC adds the multicast address to its list of valid MAC addresses. Usually this list consists of the built-in MAC address plus any user configured addresses. Whenever the station receives a frame with a matching multicast destination address, the receiver sends the frame to the CPU.

The router examines multicast addresses at both Layer 2 and Layer 3, whereas a switch examines the Layer 2 address. If the switch has hardware such as a Catalyst 5000 Supervisor III module with an NFFC, the Catalyst can examine the Layer 3 addresses as well. (The advantage of this is seen in the section, "IGMP Snooping: Advanced Traffic Management," later in the chapter). Otherwise, the Catalyst simply examines the MAC address in the frame.

Layer 3 Multicast Addresses

IP multicast addresses at Layer 3 are characterized as class D addresses. The first four bits of IP class D addresses are 1110. This means that IP multicast addresses have a valid range from 224.0.0.0 to 239.255.255.255. Note that multicast addresses from 224.0.0.0 to 224.0.0.255 are reserved. The following three reserved addresses are specifically interesting to this discussion:

• 224.0.0.1 All multicast capable hosts on the segment

• 224.0.0.2 All multicast capable routers on the segment

• 224.0.0.4 All DVMRP routers on the segment

Usually, a network administrator assigns a multicast address to the application and must select an address not used by other applications or processes. The administrator should not use a multicast address in the reserved range.

Layer 2 Multicast Addresses

When you assign a Layer 3 multicast address, a Layer 2 address is automatically generated from the IP address. Figure 13-1 shows how a MAC multicast address is derived from an IP multicast address. To calculate the Layer 2 address, the host copies the last 23 bits of the IP address into the last 24 bits of the MAC address. The high order bit is set to 0.

The first 3 bytes (24 bits) of the multicast MAC address are 0x01-00-5E. This is a reserved OUI value indicating a multicast application.

Figure 13-1. Calculating a Multicast MAC Address

Consider an example. The IP address 224.1.10.10, assigned by an administrator, has a low 23-bit value of 1.10.10. In hexadecimal format, this is 0x01-0A-0A. The MAC address takes the last 23 of the 24 bits and places them into the MAC field. The complete MAC address in this case is 01-00-5E-01-0A-0A.

What happens if the IP multicast address is 225.1.10.10? A side effect of this scheme is address ambiguity. Although a different IP multicast group is identified at Layer 3, the Layer 2 address is the same as for 224.1.10.10. Layer 2 devices cannot distinguish the two multicast groups and receive frames from both multicast groups. The user application needs to filter the two streams and discard the unwanted multicast frames. Any bit value combination for the 5 bits in Figure 13-1 identified as ambiguous generates the same Layer 2 MAC multicast address. Five bits means that there are 2⁵ combinations, or 32 Layer 3 addresses that create the same Layer 2 address.

Tip

When assigning multicast addresses, be sure to remember the 32:1 ambiguity and try to avoid multicast overlaps. This helps to preserve bandwidth on access and trunk links. The end station discards the unwanted multicast at Layer 3, after it interrupts the CPU.

IGMP

IGMP defines a protocol for hosts to register with a router to receive multicast traffic for a specific multicast group. Two versions of IGMP exist: version 1, specified in RFC 1112, and version 2, specified in RFC 2236. Version 2 added significant features to version 1 making it more efficient and enabling hosts to explicitly leave a multicast group. These features are described in the section on IGMP version 2.

IGMP Version 1

Figure 13-2 shows the 8-octet IGMP version 1 frame format.

Figure 13-2. IGMP Version 1 Frame Format

The first field of the frame indicates what version of IGMP generated the frame. For version 1, this value must be 1. The next field specifies the message type. Version 1 defines two messages: a host membership query and a host membership report. The Checksum field carries the checksum computed by the source. The receiving device examines the checksum value to determine if the frame was corrupt during transmission. If the checksum value doesn't match, the receiver discards the frame. The source computes the checksum for the entire IGMP message. The final field indicates the multicast destination group address targeted by the message.

In Figure 13-3, several hosts and a router share a LAN segment. When a host on the segment wants to receive multicast traffic, it issues an unsolicited host membership report targeting the intended multicast group.

Figure 13-3. A Router and Hosts Using IGMP

Note the membership report shown in Figure 13-4.

Figure 13-4. IGMPv1 Multicast Host Membership Report

The destination MAC address targets the multicast group it intends to join. If this were the only information in the frame to identify the group, any of 32 groups might be desired due to the address ambiguity discussed earlier. However, the Layer 3 address is included in both the IP header and in the IGMP header. The Layer 3 multicast group desired by the host is 239.255.160.171. This translates to a MAC address of 01-00-5E-7F-A0-AB. All multicast-capable devices on the shared media receive the membership report. In this situation, however, only the router is interested in the frame. The frame tells the router, "I want to receive any messages for this multicast group." The router now knows that it needs to forward a copy of any frames with this multicast address to the segment where the host that issued the report lives.

A device issues an IGMP membership report under two conditions:

• Whenever the device first intends to receive a multicast stream When you enable the multicast application, the device configures the NIC, and the built-in IGMP processes send an unsolicited membership report to the router requesting copies of the multicast frames.

• In response to a membership query from the router This is a solicited membership report and helps the router to confirm that hosts on the segment still want to receive multicast traffic for a particular multicast group.

Routers periodically issue host membership queries. You can configure the router query period from 0 seconds to a maximum of 65,535 seconds with the router command ip igmp query-interval seconds. The default is 60 seconds.

The host membership query message in Figure 13-5 interrogates the segment to determine if hosts on the segment still desire to receive multicast frames.

Figure 13-5. An IGMPv1 Multicast Host Membership Query

Only one router on each segment issues the membership query message. If the segment uses IGMP version 1, the designated router for the multicast routing protocol issues the query. If the segment uses IGMP version 2, the multicast router with the lowest IP address on the segment issues the queries.

The host membership query message targets the all multicast hosts address, 224.0.0.1, in the Layer 3 address field. The Layer 2 address is 01-00-5E-00-00-01. The IGMP header uses a group address of 0.0.0.0. This translates to a query for all multicast hosts on all groups on the segment.

A host for each active multicast group must respond to this message. When multicast hosts receive the host membership query, and if the host wants to continue to receive multicast frames for a multicast group, the multicast host starts an internal random timer with an upper range of 10 seconds. The host waits for the timer to expire and then it sends a membership report for each multicast group that it wants to continue to receive.

If another station sends a membership report before the local timer expires, the host cancels the timer and suppresses the report. This behavior prevents a segment and a router from experiencing host membership report floods. Only one station from each multicast group needs to respond for each group on the segment.

If the router does not receive a membership report for a particular multicast group for three query intervals, the router assumes no hosts remain that are interested in that group multicast stream. The router stops forwarding the multicast packets for this group and informs upstream routers to stop sending frames.

This process defines an implicit leave from the multicast group. A host using IGMP version 1 cannot explicitly inform a router that it left the multicast group. A router learns this from repeated queries that receive no responses.

IGMP Version 2

Figure 13-6 shows the construction of a frame per the version 2 document, RFC 2236. Note that the version number disappeared, but the message type field expanded in length and new values allow a version 1 device to receive a version 2 frame for backwards compatibility. Another field added and not found in IGMP version 1 is the Maximum Response Time. This is explained later in this section.

Figure 13-6. IGMP Version 2 Frame Format

IGMP version 2 adds two messages not found in IGMP version 1 to streamline the join and leave process. RFC 2236 added a version 2 membership report and a leave group message. The complete list of messages now consists of the following:

0x11 Membership query

0x12 Version 1 membership report

0x16 Version 2 membership report

0x17 Leave group

The membership query and version 1 membership report carry over from IGMP version 1. However, the membership query can now target specific multicast groups. In version 1, the query message is a general query with the group address set to 0.0.0.0. All active groups respond to the general query. Version 2 allows a multicast query router to target a specific multicast group. When it sends this type of message, a multicast host, if it is running version 2, responds with a version 2 membership report. Other multicast groups ignore the group specific query if it is not directed to their group. The group specific membership query only works for version 2 systems.

If a version 2 host leaves a multicast group, it sends an unsolicited leave group message to inform the query router that it no longer desires to receive the multicast stream. The router maintains a table of all hosts in the multicast group on the segment. If other hosts still want to receive the multicast stream, the router continues to send the multicast frames onto the segment. If, however, the membership report arrives from the last host on the segment for the multicast group, the router terminates the multicast stream for that group.

Consider the multicast group shown in Figure 13-7. Two hosts belong to the multicast group 224.1.10.10, and one host belongs to the group 224.2.20.20.

Figure 13-7. An IGMP Version 2 Leave Demonstrated

The router currently forwards frames for both groups on the segment. The host currently subscribed to 224.2.20.20 decides that it no longer wants to receive the multicast stream for this group, so it transmits a leave message. The router receives this message and checks its multicast table to see if there are any other hosts on the segment that want the stream. In this example, there are no other hosts in the group. The router sends a group specific query message to the group 224.2.20.20 to make sure. If the router does not receive a membership report, it stops the 224.2.20.20 stream.

Continuing the example, assume that sometime later, Host 3 decides to leave the group 224.1.10.10 and issues a leave message. The router receives the leave message, sends a group specific query, and realizes that additional hosts on the segment still want to receive the multicast stream. Therefore, it continues to transmit all multicast frames for this group.

If at any time the router wants to confirm its need to send the stream, it can transmit a general or group specific query onto the segment. If it does not receive any responses to a couple of query messages, the router assumes no more hosts want the stream.

Another feature of IGMP version 2 affects the method for selecting the query router. In version 1, the query router is selected by the multicast routing protocol. The designated router for the protocol becomes the querier. In version 2, the IP address determines the query router. The multicast router with the lowest IP address becomes the query router. All routers initially assume that they are the query router and send a query message. If a router hears a query message from another multicast router with a lower IP address, the router becomes a non-querier router.

A final feature added to IGMP version 2 is the capability for the multicast router to specify the hosts' response timer range. Remember that when a host receives a membership query, the host starts a random timer. The timer value is in the range of 0 to maximum response time, with the maximum response time specified in the router's query message. Version 2 allows you to configure the upper range of the timer to a maximum of 25 seconds. The default in a Cisco router is 10 seconds.

Tip

If there are many groups on a segment, you might want to use a larger timer to spread out the responses. This helps to smooth out any membership report bursts on the segment. If you have fewer groups, you might want to lower the value so that a router can terminate a multicast flow stream sooner.

IGMP Version 1 and Version 2 Interoperability

The preceding two sections describe operations whenever the IGMP hosts and routers all run the same version. This represents a homogenous system. But what if you have a mixture of versions in your system?

The first possible combination of versions might involve hosts with a mix of versions as in Figure 13-8, but with a version 1 query router. All IGMP operations in this scenario are driven by the version that the query router uses. When there is such a combination, the hosts must use version 1 messages. The router does not understand version 2 membership reports, nor does it understand version 2 leave messages.

Figure 13-8. IGMPv1 and IGMPv2 Hosts with an IGMPv1 Router

A second case exists when the router supports IGMP version 2, but hosts use IGMP version 1. Although the router understands more message types than the hosts, it ultimately uses only version 1 messages. When the version 2 router receives the version 1 membership report, it remembers that they are present and only uses version 1 membership queries. Version 1 queries use the group address 0.0.0.0 and does not generate group specific queries. If it generated group specific queries, the version 1 hosts would not recognize the message and would not know how to respond.

What if there are both version 1 and version 2 hosts on the segment with the version 2 router as in Figure 13-9? As in the previous case, the router must remember that there are version 1 hosts and must, therefore, issue version 1 membership queries. Additionally, if any of the version 2 hosts send a leave message, the router must ignore the leave notification. It ignores the message because it must still issue general queries in case a version 1 member is still active on the segment.

Figure 13-9. IGMPv1 and IGMPv2 Hosts with an IGMPv2 Router

If two routers attach to the segment where one supports version 1 and the other version 2, the version 2 router must be administratively configured as a version 1 router. The version 1 router has no way to detect the presence of the version 2 router. Because the two versions use different methods of selecting the query router, they might not reliably agree on the query router.

IGMP in a Switched Environment

Switches, by default, flood multicast traffic. The network in Figure 13-10 has multicast hosts and routers attached to a LAN switch. All of the ports belong to one VLAN. Some of the hosts attached to the switch, such as PC-3, do not participate in multicast traffic. When multicast host PC-1 sends a membership report, the switch floods the multicast frame to all ports, even to the hosts that do not want multicast traffic.

Figure 13-10. Switches and Multicast Traffic

When the router sends a general membership query, it uses the MAC multicast address 01-00-5E-00-00-01. This multicast address forces the switch to send the frame to all ports. When a host responds to the query with a report, the report goes to all ports.

Clearly, though, it would be nice to restrict the distribution of multicast frames in the switched network to only those hosts that really want the traffic. In a Catalyst, you have three potential ways of limiting the multicast scope: static configurations, CGMP, and IGMP Snooping, each of which is covered later in the chapter.

Configuring IGMP on a Router

Basic IGMP router configuration requires you to enable a multicast routing protocol and then to configure optional IGMP features if desired. For example, you can select the IGMP version to use. The router enables IGMP version 2 by default. If you enable version 2, you can adjust various timers if the hosts on the segment support version 2. Example 13-1 shows a partial configuration. Other unrelated router command lines were deleted for brevity. However, it shows the significant IGMP and multicast routing commands.

Another command present in the example output enables CGMP, which is described in more detail in a later section.

Example 13-1 Partial Router Configuration for IGMP/CGMP

   !   ip multicast-routing   ip dvmrp route-limit 7000   !   !   interface Ethernet0    ip address 193.10.2.33 255.255.255.224    ip pim dense-mode    ip cgmp 

This router uses PIM for the multicast routing. Notice the global configuration statement ip multicast-routing. This is mandatory to enable the routing. If you do not enter this statement, neither CGMP nor PIM functions.

To check the operation of your multicast router, use the show ip igmp interface command as demonstrated in Example 13-2.

Example 13-2 show ip igmp interface Output

   Router3-gateway#show ip igmp interface e0   Ethernet0 is up, line protocol is up     Internet address is 193.10.2.33/27     IGMP is enabled on interface     Current IGMP version is 2     CGMP is enabled on interface     IGMP query interval is 60 seconds     IGMP querier timeout is 120 seconds     IGMP max query response time is 10 seconds     Inbound IGMP access group is not set     IGMP activity: 3 joins, 2 leaves     Multicast routing is enabled on interface     Multicast TTL threshold is 0     Multicast designated router (DR) is 193.10.2.33 (this system)     IGMP querying router is 193.10.2.33 (this system)     Multicast groups joined: 224.0.1.40   Router3-gateway# 

The output of Example 13-2 verifies that IGMP is enabled and the version number. It also displays the timer values and the identity of the query router. In this case, this router is the query router.

Static Multicast Configurations

One tool that you have to control the distribution of multicast frames modifies the bridge table. You can statically define which ports should receive what multicast traffic. For example, suppose that PC-1 and PC-2 in Figure 13-10 belong to multicast group 224.1.10.10. You can manually modify the bridge table specifying that the ports they attach to should receive any frames with a destination address of 01-00-5E-01-0A-0A. You can do this with the Catalyst command set cam {static | permanent} multicast_macmod/ports.. VLAN. (CAM means content addressable memory and refers to the hardware portion containing the bridge table.) You can enter the multicast address multicast_MAC to the bridge table as a static or permanent entry. A static entry modifies the table until you reset the Catalyst. Normal bridge aging processes are suspended for static entries. But the Catalyst does not remember the entry across power cycles or resets. On the other hand, you can make the change permanent. A permanent entry stores the address in NVRAM so that the Catalyst restores the configuration after a reset or power cycle.

Modifying the configuration of Figure 13-10 can be accomplished through the command entry shown in Example 13-3.

Example 13-3 Creating a Permanent CAM Entry

   Console> (enable) set cam permanent 01-00-5E-01-0A-0A 2/1-3 30   Permanent multicast entry added to CAM table.   Console> (enable) 

Note that the configuration includes the router port. If you exclude the router from the command, the router never receives a membership report from a host. When the host transmits the multicast frame with the address in the configuration, the switch looks at the destination address and checks the bridge table. The properly configured bridge table in this case has three ports eligible to receive the multicast frame. The Catalyst does not forward the frame to any ports without the multicast configuration.

This is a reliable method of modifying the CAM table. But, it is completely manual. If you need to add or delete a multicast group, or if you need to add or move a host, you need to change the configuration in the switch. Manually modifying the CAM table does not scale well if you have many hosts and many multicast groups.

The Catalyst has two dynamic tools for modifying the bridge tables in a multicast environment. These methods, CGMP and IGMP Snooping, eliminate the need for manual configuration and become very attractive in dynamic multicast environments. The following sections describe both dynamic processes.

CGMP

The Cisco proprietary CGMP protocol interacts with IGMP to dynamically modify bridge tables. Because CGMP is Cisco proprietary, you must use Cisco routers and Catalyst switches for it to be effective. When a host sends IGMP membership reports to a CGMP-capable router, the router sends configuration information, via CGMP, to the Catalyst. The Catalyst modifies its local bridge table based upon the information contained in the CGMP message. Figure 13-11 shows a multicast system with two Catalysts cascaded together and a router attached to one of them. PCs attach to the Catalysts and desire to receive a multicast stream.

Figure 13-11. CGMP Operation Example

In Figure 13-11, a Cisco router receives IGMP membership reports from PC-1 and PC-2. The router sends a CGMP configuration message to the Catalyst telling it about the source MAC address of the host and the multicast group from which it wants to receive traffic. For example, PC-1 asks to join 224.1.10.10. The router tells the Catalyst to send multicast traffic with the destination MAC address of 01-00-5E-01-0A-0A to the host with the source MAC address 00-60-08-93-DB-C1. The Catalyst searches its bridge table for the corresponding unicast address and adds the multicast group address to the port the host attaches to. Any frames that the Catalyst sees with the multicast address gets forwarded to the port without bothering other ports. It is possible that many hosts belong to the multicast group. Each host individually registers with the router, and the router updates the Catalyst.

Notice two things about the CGMP operations. First, CGMP does not require any modifications to the host. CGMP operates independently of the hosts and only involves the router and the switch. Secondly, CGMP messages flow from the router to the switch, never from the switch to the router.

CGMP Frame Format

CGMP defines a single frame format, but the content of it varies depending upon the operation that the router attempts to perform. When the router transmits the CGMP frame, the data link layer targets the destination MAC address of 0x01-00-0C-DD-DD-DD. The SNAP header uses a value of 0x2001. Figure 13-12 illustrates the CGMP frame format, excluding the DLC, LLC, and SNAP header.

Figure 13-12. CGMP Frame Format

Several fields comprise the CGMP frame of Figure 13-12 as detailed in the following list:

• Version Describes the version of CGMP sending this message.

• Message Type Two messages defined: join or leave.

• Reserved Not used, set to 0.

• Count Indicates number of multicast/unicast address pairs contained in this CGMP message.

• Group Multicast Address Indicates multicast address to be modified. Referred to as Group Destination Address (GDA).

• Source Unicast Address Indicates the source address of the device joining or leaving the multicast group. Referred to as the Unicast Source Address (USA).

The Version Number indicates the version of CGMP that the transmitting router is using. Currently, only one version exists. Therefore, this 4-bit field has a value of 1.

The Message Type might have one of two values. The message is either a join message with a type value of 0, or a leave message with a type value of 1.

The Reserved field is currently unused and sets all bits in the field to 0.

When the router sends a CGMP message to the switch, it includes address pairs of hosts and the multicast address the host wants to receive. The router can include more than one pair in the CGMP message. The Count field tells the switch how many address pairs are included in the CGMP message.

CGMP refers to the Multicast Group Address as a Group Destination Address (GDA). Many of the show statements display values labeled as the GDA. The first three octets of this field value should be 0x01-00-5E.

Finally, the Unicast Source Address (USA) appears in the list. It helps the Catalyst recognize the specific host desiring to receive the multicast stream. The GDA/USA forms an address pair. A router can include many address pairs in the CGMP frame when it sends configuration information to the switch.

You might see several combinations of GDAs and USAs in a CGMP message decode. Table 13-1 shows possible combinations and describes the meaning of each.

Table 13-1. CGMP Message Combinations

GDA

USA

Message Type

Description

Multicast

Device

Join

Add USA port to group

Multicast

Device

Leave

Delete USA port from group

0000.0000.0000

Router

Join

Learn CGMP router and port

0000.0000.0000

Router

Leave

Forget CGMP router and port

Multicast

0000.0000.0000

Leave

Delete multicast group from bridge table

0000.0000.0000

0000.0000.0000

Leave

Delete all multicast groups from bridge table

The first two messages of Table 13-1 represent typical messages because the router sends these when it instructs the Catalyst to add or delete a host or set of hosts from the multicast group specified in the GDA field. When the Catalyst receives this message, it correspondingly modifies the bridge table to correctly forward or filter group multicast traffic to the port.

The Catalyst needs to learn where a CGMP-capable router resides. You can manually configure the information in the switch. However, a CGMP discovery process enables a router to announce itself to a switch. A router can also tell the switch that it no longer participates in CGMP by sending a leave message with its MAC address and an all zeros GDA value.

Finally, the router can inform a switch to forget about a specific multicast group and to remove any entries for this group. Or, it can send a flush to delete all multicast entries for all multicast groups from the bridge table. Figure 13-13 shows a decoded CGMP join message for a specific host. What multicast group does this client want to join?

Figure 13-13. A CGMP Join Message Analyzer Decode

You cannot tell exactly which multicast group the client wants to join, because there are no Layer 3 addresses in the message. If you could capture the IGMP join message that spawned the CGMP join, you could know for certain the desired multicast group. From the CGMP decode, the only thing you can tell about the multicast group is the last 23 bits of the address. These bits translate to a decimal address representation of xxx.127.160.171. You cannot determine the first octet due to the address ambiguity issue.

The GDA 0100.5E00.0128 is for the multicast routing protocol. The router indicates to the switch that it wants to receive any multicast frames belonging to this group to ensure that it receives multicast route updates. Examine the network in Figure 13-14. Multiple hosts desire to receive a multicast stream from a single multicast group group.

Figure 13-14. A Detailed CGMP Exchange

PC-1 wants to join multicast group 224.1.10.10. It sends an IGMP membership report informing routers that it wants to see these frames. The router creates a CGMP join message with a GDA of 01-00-5E-01-0A-0A and a USA with PC-1's source address. The router sends the frame as a CGMP multicast (01-00-0C-DD-DD-DD). The Catalyst detects the CGMP join message, looks in its bridge table for the host, adds the GDA to the port bridge table, and starts to forward any frames for this GDA to PC-1. The CGMP join message from the router causes both Cat-A and Cat-B to modify their bridge tables. Cat-A modifies its bridge table so that the multicast frame forwards to Cat-B. This works if the port is an access or trunk link. In either case, the multicast frame stays within the VLAN boundaries. If PC-2 decides to join the multicast group too, the process repeats, but with PC-2's USA.

The multicast query router occasionally issues a general query that both hosts receive. They both start random timers to determine when to issue a solicited membership report. The report suppression mechanism works here, because the report frame has the GDA in the MAC layer destination field. The switch forwards this to all ports with members of the group. When the other host receives the membership report, it cancels its timer and does not send another membership report for that group.

After some period of time, PC-1 decides it wants to leave the group. In an IGMP version 1 environment, PC-1 does nothing proactively to announce its leave, so the router does not know explicitly. However, at some point in time, the query router issues a general query. PC-2 responds to the query and the router continues to forward multicast traffic for the group. The router still does not know that PC-1 left the group. Therefore, the switch continues to forward the multicast traffic to PC-1 even though it no longer wants to receive the frame. In fact, PC-1 continues to receive the group traffic until all hosts leave the group and the router detects that there are no more members in the group.

Tip

In an IGMP version 1 environment, members of a group continue to receive traffic until all members of the group leave. If at some point in time there were ten members, but only one currently remains active, all ten continue to receive the multicast stream. IGMP version 2 improves this situation. If all clients on your segments (broadcast domain) support IGMP version 2, it is wise to set them up to run the later version and gain bandwidth efficiencies that are not possible with IGMP version 1.

Eventually, PC-2 decides that it no longer wants to receive the multicast stream. When the query router issues a membership query, no hosts respond for this group. The multicast query router stops forwarding the multicast frames after it fails to see a solicited membership report for at least two queries. At this point, the router stops forwarding the multicast traffic and sends a CGMP group leave message to the switch. The group leave message has the GDA for the group and a USA of 0000.0000.0000. This forces the Catalyst to flush all entries in the bridge table for this group.

Tip

Note that the Catalyst does not prune all multicast addresses. For example, the switch forwards reserved multicast addresses such as 224.0.0.5 and 224.0.0.6. These are used by Open Shortest Path First (OSPF) routing. If the switch pruned traffic for these multicast groups, the protocols would break.

Tip

Enabling CGMP Fast Leave processing on a Catalyst switch forces the switch to capture all IGMP leave messages sent to the IP multicast address 224.0.0.2 (all routers multicast). This is the same address used for the Cisco protocol Hot Standby Router Protocol (HSRP) and translates to a multicast MAC address of 01-00-5E-00-00-02. To capture the IGMP leave message, the Enhanced Address Recognition Logic (EARL) table has static entries for this MAC address causing the switch to absorb the leave message. This results in the switch also consuming HSRP frames. Normally the switch does not forward absorbed frames (such as CDP) to any other ports, and would break HSRP. However, the switch behavior is modified in the supervisor code so that the switch Supervisor module recognizes non-IGMP frames and floods them out all router ports and the Spanning Tree Root Port, preserving HSRP functionality.

Configuring CGMP

Enabling CGMP requires configurations on both the router and the Catalyst. By default, CGMP is disabled on both. Note that if you are using IGMP Snooping (described in the next section) on a Catalyst, you cannot use CGMP. CGMP and IGMP are mutually exclusive.

Catalyst configurations for CGMP include three set commands. The set cgmp enable command enables CGMP. This command was introduced in switch supervisor code version 2.2. Ensure that you have at least this revision before trying to use CGMP. The set multicast router mod_num/port_num command is an optional command that statically configures a multicast router. Normally, the router announces itself, enabling the switch to dynamically learn the presence of the multicast router. You can, however, elect to statically configure this so that your Catalyst does not need to wait to learn this information. Finally, you can use the set cgmp leave enable command in an IGMP version 2 environment to enable the Catalyst to look for IGMP version 2 leave messages. If the Catalyst sees a leave message from a host, it waits to see if any join messages appear on the interface. If not, the Catalyst prunes the port from the multicast group without sending the leave message to the router. Without this feature, the Catalyst waits to see a CGMP leave message from the router.

You must also turn on CGMP in the router. Use the ip cgmp interface configuration command to enable CGMP. You need to enter this command on all router ports participating in CGMP. The router output in Example 13-4 shows a router announcing itself with CGMP to any switches listening on the interface.

Example 13-4 Router debug for CGMP Hello Message

   Router3-gateway#debug ip cgmp   CGMP debugging is on   Router3-gateway#   02:03:09: CGMP: Sending self Join on Ethernet0   02:03:09:       GDA 0000.0000.0000, USA 0010.7b3a.d4bb   02:03:19: CGMP: Sending self Join on Ethernet0   02:03:19:       GDA 0100.5e00.0128, USA 0010.7b3a.d4bb   Router3-gateway# 

Notice that the GDA value targets the all groups address, whereas the USA value reflects the router's built-in MAC address on the Ethernet interface.

The router output comes from the router with the configuration shown in Example 13-2. The router also announces itself as a member of GDA 0100.5e00.0128. Where did this group come from?

The GDA 0100.5E00.0128 is for the multicast routing protocol. The router indicates to the switch that it wants to receive any multicast frames belonging to this group to ensure that it receives multicast route updates.