Scenario 7-5: Configuring Cisco Group Management Protocol (CGMP)

Cisco Group Management Protocol (CGMP), as the name suggests, is a proprietary protocol that is used to constrain multicast traffic on the LAN for networks that use Cisco routers and switches. In the previous scenario, you learned about IGMP snooping, where Cisco Catalyst switches monitor IGMP conversations between multicast routers and receivers, allowing a switch to dynamically determine the ports that frames with a specific multicast group address should be forwarded out. With IGMP snooping, multicast routers and receivers have no idea that a switch is monitoring IGMP traffic, so IGMP snooping is transparent to the multicast routers and receivers. Multicast routers see IGMP Membership Reports from receivers, and receivers see IGMP Queries generated by multicast routersthe fact that a switch might be monitoring the IGMP traffic between multicast routers and receivers is unbeknownst to either.


IGMP snooping is not really transparent when it comes to the IGMP leave process. As indicated in Figure 7-19, if IGMP snooping is enabled on a Cisco Catalyst switch, a multicast router will not see IGMP Leave Group messages until the last receiver for a group leaves the LAN segment. This quality actually enhances the IGMP leave process, because multicast routers do not need to unnecessarily query the LAN for more receivers when a receiver leaves a group and there are still other receivers on the LAN for the group.

To implement IGMP snooping properly, switches must possess knowledge of the IGMP protocol and must be able to look at information located much deeper within IGMP frames than normal frames that the switch receives and forwards. Switches need to be able to forward frames at high speeds because the switches attach to high-speed LAN networks. Thus, switches that support IGMP snooping require more expensive hardware-based components such as IGMP-aware ASICs (as opposed to implementing IGMP snooping in software) to ensure that IGMP snooping does not have an effect on frame-forwarding performance.

CGMP provides an alternative approach to IGMP snooping and offloads much of the intelligence required to determine group membership at a Layer 2 level to the multicast routers attached to the LAN. For this reason, CGMP is supported on many earlier low-end Cisco switches, with IGMP snooping supported only on high-end or recent Cisco Catalyst switches that possess enhanced hardware that enables the intelligence required for IGMP snooping while maintaining the frame-forwarding performance of the switch.


Although CGMP requires less switch intelligence and, therefore, offers a multicast traffic control solution for low-end switches, today's low-end switches possess enough intelligence to implement IGMP snooping at a low cost. Because IGMP snooping is essentially transparent to the rest of the network and works with any multicast routers that supports IGMP, it is considered superior in benefits over CGMP, and CGMP is considered a legacy protocol that should be implemented only where IGMP snooping is not supported. Proof of this concept is shown on the next-generation Catalyst 2950 and Catalyst 3550 switches, which support only IGMP snooping and do not support CGMP. That said, there are still major deployments of switches that support only CGMP (e.g., the Catalyst 4000 running CatOS), so it is important you understand CGMP.

CGMP Operation

CGMP takes quite a different approach to multicast traffic control from IGMP snooping. With CGMP, the intelligence required to determine the multicast groups present on a LAN segment and the receivers attached to the LAN is performed by CGMP-enabled multicast routers attached to the LAN (known as CGMP servers). Multicast routers already possess the required intelligence to a certain extent because they must be able to determine whether a Layer 3 subnet has receivers attached so that they can build the outgoing interface list for routes in the multicast route table. With CGMP enabled, multicast routers take this process one step further by transmitting host-specific group membership information to CGMP-enabled LAN switches (known as CGMP clients) using CGMP messages. Using this mechanism creates a communications channel between multicast routers and switches on the LAN, which is separate to normal IGMP communications. It also reduces the computational requirements for switches because they do not need to perform the logic required to determine multicast group membership. Instead this computation is performed by the multicast router and then transmitted to each switch, with switches simply updating bridge table information based upon the information received.

For example, when a receiver attaches to the LAN and sends an IGMP Membership Report message to a local multicast router, the multicast router performs normal IGMP operations, but also sends a CGMP message to the switch that indicates a new receiver exists for a group. Because the multicast router receives the IGMP Membership Report message as an IP packet within an Ethernet frame, the multicast router knows the MAC address of the receiver, which is the source MAC address of the Ethernet frame. The multicast router then sends a CGMP Join message to all switches on the LAN, which includes the multicast group address and the MAC address of the new receiver. The CGMP-enabled switches that receive the message then look up the egress port associated with the MAC address of the receiver and add that port to the egress port list for the group address.

CGMP communications are one-way in that CGMP servers (multicast routers) communicate information to CGMP clients (switches), but because CGMP operates separately to IGMP and is used purely to provide CGMP clients with receiver membership for each group, CGMP clients are not required to communicate with CGMP servers. CGMP servers communicate with CGMP clients using CGMP messages, which are sent to a special multicast Ethernet address of 01-00-0C-DD-DD-DD. CGMP messages are made up of the following fields:

  • Version 1 or 2

  • Message Type Join or Leave

  • Count The number of multicast/unicast address pairs in the message

  • Group Destination Address (GDA) The MAC address of the multicast group address

  • Unicast Source Address (USA) The MAC address of the host that is joining or leaving the multicast group indicated by the GDA

Each CGMP message contains a pair of GDA and USA entries that define a specific host (USA) joining or leaving a specific multicast group (GDA). Table 7-4 shows the various combinations of GDA, USA, and Join/Leave fields and each combination's respective meaning.

Table 7-4. CGMP Message Types



Message Type


Group MAC

Host MAC


Add receiver to group

Group MAC

Host MAC


Remove receiver from group


Router MAC


Assign router port


Router MAC


Remove router port

Group MAC



Delete Group




Delete all Groups

As you can see from Table 7-4, CGMP messages can be used to indicate several different events that are part of normal multicast operation. Important multicast events on the LAN include the following, which normally occur in the order specified:

  • Assigning a router port

  • Adding receivers to a group

  • Removing receivers from a group

  • Maintaining group membership

Each of these events and how CGMP communicates these events to CGMP-enabled switches is now examined in detail.

Assigning a Router Port

When a multicast router starts up that has CGMP enabled, the router generates a CGMP Join message with the GDA set to all zeroes and the USA set to the MAC address of the router. This message is multicast out all CGMP-enabled interfaces, ensuring all switches on the LANs the multicast router is attached to receive the message. Referring back to Figure 7-6, assume that L3-Switch-B and L3-Switch-C have just started up, with L3-Switch-B having CGMP configured on interfaces Fa0/3 and Fa0/4, and L3-Switch-C having CGMP configured on interface Fa0/3. This means that on the subnet, two CGMP-enabled routers exist (L3-Switch-B and L3-Switch-C). On the subnet, even though two multicast routers are attached (L3-Switch-B and L3-Switch-D), only L3-Switch-B is a CGMP-enabled router and, therefore, must communicate information on behalf of L3-Switch-D as well. Also, assume that Switch-B and Switch-C are both CGMP clients. Figure 7-20 demonstrates the process of L3-Switch-B and L3-Switch-C announcing their presence to Switch-C, and L3-Switch-B announcing its presence to Switch-B.

Figure 7-20. Assigning a Router Port via CGMP

In Figure 7-20, the following events occur:

  1. When L3-Switch-B and L3-Switch-C start up, they send a CGMP Join message out all interfaces that are enabled for CGMP. The CGMP Join message contains a GDA set to all zeroes and a USA of the router's own MAC address (e.g., 0090.b7aa.9c80 for L3-Switch-B). This message is intended to inform any connected switches of the multicast router's existence.

  2. On the subnet, L3-Switch-B is the only CGMP-enabled router and, for proper IGMP operation, needs to ensure that Switch-B knows about L3-Switch-D, which is another multicast router attached to Switch-B. Therefore, L3-Switch-B is configured as a CGMP proxy¸ which means that it will also send CGMP Joins on behalf of other multicast routers on the LAN that do not have CGMP enabled. In Figure 7-20, L3-Switch-B also sends a CGMP Router Join for L3-Switch-D, which informs Switch-B of the presence of L3-Switch-D.


    To perform the CGMP proxy function, a multicast router must be the IGMP Querier (DR) for the LAN. In IGMPv1, the IGMP Querier is elected via the multicast routing protocol (e.g., PIM), while in IGMPv2, the IGMP Querier is elected based upon the lowest IP addressed router on the LAN. Because all multicast routers in Figure 7-6 are configured for IGMPv2, L3-Switch-B is the IGMP Querier for the subnet (because it has the lowest IP address on the subnet of and, therefore, can act as a CGMP proxy.

  3. Switch-B and Switch-C receive the CGMP Join messages on the and subnets, respectively. Each switch examines the GDA and USA, determines that the message indicates a CGMP router announcing itself, and ensures that the egress port associated with the router MAC address specified in the USA field (the egress port is determined by looking up the unicast entry for the router MAC address in the bridge table) is added to all future bridge table entries for multicast group addresses. For example, on Switch-C, the bridge table indicates that the MAC address of L3-Switch-B is reachable via port 2/2 and that L3-Switch-C is reachable via port 2/1. This means that any future multicast group entries in the bridge table include port 2/1 and port 2/2 in the egress port list.

The CGMP Router Join mechanism ensures that any new multicast group entries added to the bridge table (because receivers send Membership Reports to the new group addresses) contain the port or interface that attaches to each CGMP-enabled multicast router on the LAN. This process ensures that multicast routers always receive IGMP Membership Reports from receivers for groups in response to IGMP General Queries that are sent periodically as part of normal IGMP maintenance.

Adding Receivers to a Group

When receivers attach to the LAN and want to join a multicast group, they issue IGMP Membership Report messages, indicating the multicast group that they want to join. Once the multicast routers attached to the LAN receives these messages, they ensure the router interface that the Membership Report was received on is added to the multicast routing topology. If CGMP is enabled on the interface, the multicast router also sends a CGMP Join message out the interface to communicate the fact that a new receiver has joined a multicast group to all CGMP-enabled switches.

Figure 7-21 demonstrates this process on the subnet of Figure 7-6, assuming Router-B (a receiver) has just attached to the network.

Figure 7-21. Adding Receivers to a Group via CGMP

In Figure 7-21 the following events occur:

  1. Router-B (a receiver for the group) starts up and generates an IGMP Membership Report message to indicate that it wants to join the group. This message is sent to the group multicast address at both the IP and Ethernet layers. The destination MAC address of the Membership Report is 0100.5e01.0101, which is the Ethernet group address for the IP group address. Assuming that Router-B is the first receiver on the LAN for the group, Switch-B does not have any bridge table entries for the group address and thus floods the Membership Report out all interfaces except the ingress interface.

  2. L3-Switch-B receives the flooded Membership Report and ensures that interface Fa0/4 (attached to the LAN that Router-B is attached to) is in the outgoing interface for the (*, entry in the multicast routing table, as well as any (S,G) entries that include a group address of Assuming CGMP is enabled on the interface, L3-Switch-B generates a CGMP Join message and sends this message out the interface the Membership Report was received on. The GDA of the CGMP Join message is copied from the destination MAC address of the IGMP Membership Report frame (0100.5e01.0101), and the USA is copied from the source MAC address of the IGMP Membership Report frame (0001.41a0.8310). The multicast router sends an IGMP Group-Specific Query to check if any hosts on the segment belong to multicast groups. This query indicates to all CGMP-enabled switches on the LAN that a new receiver with a MAC address of 0001.41a0.8310 has joined the multicast group with a MAC address of 0100.5e01.0101.

  3. Switch-B receives the CGMP Join message and, assuming that this is the first receiver on the LAN for the group, creates a new entry in the bridge table for the group address indicated by the GDA of the message. All CGMP router interfaces (which are known to Switch-B based upon the process described in Figure 7-6) are added to the egress port list for the new bridge table entry. Switch-B also reads the USA of the message and searches the bridge table for the bridge table entry that matches the MAC address specified by the USA. Once this entry has been found, the egress port associated with the entry (i.e., the interface attached to Router-B) is added to the egress port list of the bridge table entry for the multicast group.

If subsequent receivers attach to the LAN for the multicast group, the same events as described in Figure 7-20 occur, except that Switch-B updates an existing bridge table entry for the multicast group, rather than creating a new bridge table entry.


It is important to understand that when multiple CGMP-enabled routers are attached to a LAN segment, only the IGMP Querier (DR) sends CGMP Join messages for receivers that have joined a group. Consequently, on the subnet of Figure 7-6, L3-Switch-C sends CGMP Join messages for attached receivers because L3-Switch-C is the IGMP Querier for this subnet (because IGMPv2 is being used and L3-Switch-C has the lowest IP address on this subnet). The same rule applies to CGMP Leave messages (discussed in the next section).

Removing Receivers from a Group

When receivers want to leave a group, they generate IGMP Leave Group messages. When a CGMP-enabled router receives these messages, it generates a CGMP Leave message and sends this to the LAN to which the receiver is attached to ensure that any CGMP-enabled switches can remove the appropriate port from the egress port list. This process is identical to the events illustrated in Figure 7-21. However, the IGMP Membership Report message is replaced with an IGMP Leave Group message that is addressed to the all multicast routers address (, and the CGMP Join message is replaced with a CGMP Leave message. If the receiver that is leaving is not the last receiver on the LAN (i.e., other receivers are still attached), the CGMP Leave message specifies the following GDA and USA values:

  • GDA Multicast group address (e.g., 0100.5e01.0101 for the topology used in Figure 7-21)

  • USA MAC address of the leaving receiver (e.g., 0001.41a0.8310 for the topology used in Figure 7-21)

Each CGMP-enabled switch that receives the CGMP Leave message reads the GDA and USA and removes the interface associated with the USA from the egress port list for the GDA.

If the receiver that is leaving is the last receiver on the LAN, the CGMP Leave message includes the multicast group address in the GDA, but includes a USA value of all zeroes (0000.0000.0000), which indicates to all CGMP-enabled switches that there are no more receivers on the LAN and that the bridge table entry for the group address should be deleted from the bridge table.

CGMP Local Leave Processing

Later versions of CGMP on Cisco Catalyst switches include a feature known as local leave processing. This feature is similar to how leave processing is handled with IGMP snooping. When CGMP local leave is enabled, the switch intercepts any IGMP Leave Group messages that are received and then sends an IGMP General Query message out the port that the Leave Group message was received on. If no receivers for the group respond to the General Query, the switch knows that no more receivers for the group are attached to the port, and the port is removed from the egress port list of the bridge table entry for the group address. At this point, if other receivers are still attached to other ports on the switch for the group, the original IGMP Leave Group message is discarded and not forwarded to any multicast routers. However, if there are no more receivers for the group, the switch forwards the IGMP Leave Group message to all multicast routers to ensure that they can prune the LAN interface from the outgoing interface list in the multicast route table entry for the group.


Just as with IGMP snooping, the benefits of local leave processing are realized only for IGMPv2 receivers, because IGMPv2 requires a receiver that wants to leave a group to send a Leave Group message to the (0100.5e00.0002) all multicast routers address, which provides a distinct indication to the switch that a Leave Group message has been generated and the switch CPU should inspect the message. IGMPv1 receivers do not generate a message that indicates they want to leave a group. Rather, they just ignore IGMP General Queries sent by routers to ensure receivers are still active on a segment.

In more recent Cisco Catalyst switches, the CGMP local leave feature has been extended to include a fast leave feature, which is identical in function to the IGMP snooping fast leave feature. When fast leave is enabled, Cisco Catalyst switches do not send an IGMP General Query message out the port the Leave Group message was received on, instead assuming that the receiver wanting to leave a group is the only device attached to the switch port. Only enable CGMP fast leave processing if all receivers are directly attached to the switch.

Maintaining Group Membership

As discussed in the IGMP snooping scenario (Scenario 7-4), maintaining group membership is an important consideration for constraining multicast traffic on the LAN. The multicast router that performs the IGMP Querier role for the LAN sends General Query messages periodically to ensure that at least one receiver for every group previously active on the LAN is still active. Receivers use the report suppression mechanism if they hear other IGMP Membership Reports sent by other receivers in response to the General Query messages, which causes an issue for switches that need to know about all receivers attached to the switch.

With IGMP snooping, switches ensure that IGMP Membership Reports sent from receivers are not heard by any other receivers on the LAN, which solicits a response from all receivers, ensuring that the switch knows exactly which receivers are still active on the LAN. With CGMP, because this feature lacks a detailed understanding of IGMP, each CGMP-enabled switch simply relies on the multicast routers attached to the LAN to indicate when receivers have left a group. Unfortunately, using this mechanism to maintain group membership on a CGMP-enabled switch is not ideal in the following situations:

  • When an IGMPv1 receiver leaves a group

  • When an IGMPv2 receiver leaves a group without sending a Leave Group message


The IGMPv2 specification, unfortunately, does not mandate that receivers must send an IGMP Leave Group message when a receiver wants to leave a group, instead recommending that an IGMP Leave Group should be sent. Consequently, some TCP/IP stacks might implement of IGMPv2 and not generate a Leave Group message when the receiver wants to leave a group.

In both of these situations, there is no way for the multicast router attached to a LAN to verify that the receiver has left a group. Hence, no CGMP Leave messages can be generated to indicate to a CGMP-enabled switch that an attached receiver has left a group. The switch continues to forward multicast traffic to receivers who have left the group in the situations just described. These ports cannot be cleared from the egress port list until the group as a whole is removed from the bridge table (i.e., no more receivers are on the LAN for a group).

CGMP and IGMP Snooping Interoperability

In some networks, due to hardware limitations, you might not be able to run IGMP snooping on all switches, which might create a special scenario where you might need to run CGMP on some switches and also run IGMP snooping in the same LAN.

Because CGMP operation relies on multicast routers generating CGMP Joins in response to IGMP Membership Reports sent from receivers, all IGMP Membership Reports must be seen by multicast routers to ensure the appropriate CGMP Joins are generated. IGMP snooping uses a proxy reporting mechanism, which means that not all IGMP Membership Report messages are sent to the multicast router if a group already exists. If CGMP-enabled switches exist in the network, proxy reporting must be disabled on the switches running IGMP snooping, which then ensures all Membership Reports are sent to the multicast router. Cisco Catalyst switches that are running IGMP snooping can detect CGMP messages and can detect that some switches in the network are running CGMP, because they see CGMP multicast messages sent by CGMP-enabled multicast routers. Each switch moves to a special IGMP-CGMP mode that automatically disables the proxy reporting, which ensures CGMP works correctly on the LAN.

CGMP Support on Cisco Catalyst Switches

It is important to understand that not all Cisco Catalyst switches support CGMP. Table 7-5 lists the various Cisco Catalyst platforms and indicates whether or not CGMP is supported and what minimum software is required. As you can see, CGMP is supported only on the older Cisco Catalyst switches, indicating that CGMP is considered a legacy protocol.

Table 7-5. CGMP Support on Cisco Catalyst Switches


CGMP Support

Minimum Software

Catalyst 1900/2820


Catalyst 2900XL/3500XL


All IOS Releases

Catalyst 2950/3550


Catalyst 4000 (Supervisor 1/2)


All CatOS Releases

Catalyst 4000 (Supervisor 3/4)


Catalyst 5000/5500


All CatOS Releases

Catalyst 6000/6500


Configuration Tasks

The configuration of CGMP consists of the following tasks, which are both required to ensure CGMP operation works correctly:

  • Configuring CGMP on a Cisco multicast router

  • Configuring CGMP on a Cisco switch

This scenario uses the topology of Figure 7-6, and referring to Table 7-5, you can see that none of the switches in Figure 7-6 actually support CGMP. For this scenario, assume that Switch-C is a Catalyst 4000 switch running CatOS and that Switch-B is a Catalyst 3500XL switch running Cisco IOS (both of these switches support CGMP). The configuration of CGMP on the and subnets are demonstrated.

Configuring CGMP on a Cisco Multicast Router

CGMP operation on a multicast router (referred to as a CGMP Server) is supported from Cisco IOS version 11.1(2) onwards in all IOS features sets and is supported on all current Cisco router platforms. CGMP Server operation is also supported on Cisco Catalyst Layer 3 Switches, such as the Catalyst 3550, Catalyst 4000/4500 with Supervisor 3/4, and native IOS Catalyst 6000/6500.

To enable CGMP on a multicast router, you simply need to enable it on each routed LAN interface that has CGMP-enabled switches attached, which on Cisco Catalyst Layer 3 switches means any physical routed interface or SVI that connects to a VLAN that has CGMP-enabled switches attached.


Each interface that you want to enable CGMP on must have PIM enabled.

To enable CGMP on a routed LAN interface that has PIM enabled, use the ip cgmp interface configuration command:

 Router(config-if)# ip cgmp [proxy | router-only] 

The optional proxy keyword indicates that the multicast router should generate CGMP Join messages not only for all receivers attached to the LAN and itself, but also for any other non-CGMP multicast routers on the LAN. This feature is known as CGMP proxy and can be configured only on the IGMP Querier (DR) for the LAN.

The router-only keyword indicates that the multicast router should generate CGMP Join messages only for itself and other non-CGMP multicast routers on the LAN, without generating CGMP Join messages for receivers on the LAN. This mode of operation is required if you want to use CGMP as the router learning mechanism for IGMP snooping, because the multicast router generates a CGMP Join messages only for itself.

Example 7-44 demonstrates configuring CGMP on L3-Switch-C in Figure 7-6 for the interface attached to the subnet.

Example 7-44. Enabling CGMP on L3-Switch-C
 L3-Switch-C# configure terminal L3-Switch-C(config)# interface range FastEthernet0/3 L3-Switch-C(config-if-range)# ip cgmp proxy 

Example 7-45 demonstrates configuring CGMP on L3-Switch-B in Figure 7-6 for the interfaces attached to the and subnets, assuming that on the subnet L3-Switch-D is not configured to support CGMP.

Example 7-45. Enabling CGMP on L3-Switch-B
 L3-Switch-B# configure terminal L3-Switch-B(config)# interface FastEthernet0/3 L3-Switch-B(config-if)# ip cgmp L3-Switch-B(config-if)# exit L3-Switch-B(config)# interface FastEthernet0/4 L3-Switch-B(config-if)# ip cgmp proxy 

Notice in Example 7-44 that the CGMP proxy feature has been enabled only on interface FastEthernet0/4 and not interface FastEthernet0/3. The CGMP proxy feature is not required on the subnet (attached to interface FastEthernet0/3 on L3-Switch-B), because L3-Switch-C is also configured for CGMP on this subnet.

On the subnet, however, L3-Switch-D is not configured for CGMP; hence, L3-Switch-B must be configured as a CGMP proxy. Because L3-Switch-B has the lowest IP address ( on the subnet, it becomes the IGMP Querier and the CGMP proxy feature works.

Configuring CGMP on a Cisco Switch

Once you have enabled CGMP on all multicast routers on a LAN, or enabled CGMP on at least one multicast router with the CGMP proxy feature configured, you must next enable CGMP on all switches in the LAN. Cisco Catalyst switches operate as CGMP clients, meaning that they are the Layer 2 devices that receive receiver information from multicast routers (CGMP servers).

To enable or disable CGMP on a CatOS switch, use the set cgmp command as follows:

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

By default, CGMP support is disabled. You can also configure CGMP leave and fast leave processing as follows:

 Console> (enable) set cgmp {leave [enable | disable]} |   {fastleave [enable | disable]} 

The leave keyword enables the CGMP leave processing feature, while the fastleave keyword enables the CGMP fast leave feature. Example 7-46 demonstrates enabling CGMP on Switch-C (a Catalyst 4000 switch for this scenario) in Figure 7-6 and also enabling the CGMP fast leave feature.

Example 7-46. Enabling CGMP on a CatOS Switch
 Switch-C > (enable) set cgmp enable CGMP support for IP multicast enabled. Switch-C > (enable) set cgmp fastleave enable CGMP fastleave processing enabled. 

Once you have enabled CGMP, you should verify that the switch can see the multicast routers attached to the LAN. Example 7-47 demonstrates the show multicast router cgmp command, which is used to display all multicast routers that have been learned via CGMP router joins.

Example 7-47. Displaying Multicast Routers Learned via CGMP on CatOS
 Switch-C> (enable) show multicast router cgmp Port       Vlan ---------- ----------------  2/1       1  2/2       1 Total Number of Entries = 2 '*' - Configured '+' - RGMP-capable 

Notice that both L3-Switch-B (connected to port 2/2) and L3-Switch-C (connected to port 2/1) have been learned, because CGMP is configured on both switches.

After verifying that the switch can see all multicast routers on the LAN, you should next verify that the correct receiver information is being reported for each group. Example 7-48 demonstrates using the show multicast group command on Switch-C.

Example 7-48. Verifying Multicast Group Information Learned via CGMP on CatOS
 Switch-C> (enable) show multicast group VLAN  Dest MAC/Route Des    [CoS]  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 

In Example 7-48, you can see that the switch has a multicast group entry for 01-00-5e-01-01-01, which is the Ethernet multicast address for the group. Notice that port 2/3 is not included in the destination port list because no receivers are attached to that port.


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

On Cisco IOS-based Catalyst switches that support CGMP, such as the Catalyst 2900XL/3500XL, CGMP support is enabled by default, with the CGMP fast leave feature disabled by default. If you want to enable CGMP fast leave, use the cgmp leave-processing global configuration command.

 Switch(config)# cgmp leave-processing 

Cisco IOS also allows you to tune a parameter called the CGMP router hold-time, which is the number of seconds the switch waits before removing a router entry after a CGMP Router Leave message has been received. Once a router entry is aged out, all groups associated with that router are also removed. By default this parameter is configured as 400 seconds; however, you can tune this parameter if you want to accelerate the removal of expired group information by using the cgmp holdtime global configuration command:

 Switch(config)# cgmp holdtime seconds 

Example 7-49 demonstrates configuring CGMP fast leave and modifying the CGMP router hold-time on Switch-B (a Catalyst 3500XL switch for this scenario).

Example 7-49. Enabling CGMP Fast Leave and Modifying CGMP Router Hold-Time on Cisco IOS
 Switch-B# configure terminal Switch-B(config)# cgmp leave-processing Switch-B(config)# cgmp holdtime 60 

In Example 7-49, remember that CGMP is enabled by default on Cisco IOS switches, so you don't need to explicitly enable CGMP. The CGMP router hold-time has been altered to 60 seconds to allow faster aging out of group information associated with CGMP routers that have send CGMP router leave messages.

Once you have configured CGMP on Cisco IOS switches, you should verify that CGMP is working correctly. On Cisco IOS, you can use the show cgmp command to view all CGMP router and group information, as demonstrated on Switch-B in Example 7-50.

Example 7-50. Verifying CGMP on Cisco IOS
 Switch-B# show cgmp CGMP is running. CGMP Fast Leave is running. CGMP Allow reserved address to join GDA. Default router timeout is 60 sec. vLAN     IGMP MAC Address   Interfaces ------  -----------------   -----------     1    0100.5e01.0028      Fa0/1, Fa0/2     1    0100.5e01.0101      Fa0/1, Fa0/2, Fa0/3 vLAN     IGMP Router        Expire   Interface ------  -----------------  --------  ----------     1    0090.b7aa.9c80     191 sec   Fa0/1     1    0009.b7aa.3d40     191 sec   Fa0/2 

In Example 7-49, you can see that Switch-C knows about both L3-Switch-C and L3-Switch-D, as indicated by the last two shaded lines of the output. The CGMP proxy configuration on L3-Switch-B has ensured that L3-Switch-D is also advertised as a multicast router via CGMP. You can also see that a multicast group entry exists for 0100.5e01.0101, with the appropriate interfaces listed (Fa0/1, Fa0/2, Fa0/3) for multicast forwarding.

CCNP Self-Study CCNP Practical Studies. Switching
CCNP(R) Practical Studies: Switching (CCNP Self-Study)
ISBN: 1587200600
EAN: 2147483647
Year: 2002
Pages: 135
Authors: Justin Menga

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: