Cisco Group Management Protocol (CGMP)

Multicast is an efficient way of sending traffic. We can have one or multiple sources and a group of receivers. Multicast-enabled routers keep track of all receivers and use a multicast routing protocol like PIM to ensure traffic is only forwarded on the correct interfaces.

There is a problem with L2 though, take a look at this picture:

multicast traffic flooded

Above we see a server which is streaming traffic to multicast destination 239.1.1.1, the destination MAC address is 0100.5e01.0101. The switch in the middle will check its MAC address table to figure out where to forward traffic for this McAC address. The problem here is that this MAC address has never been used as a source, so the switch will never learn this MAC address. The switch won’t know where to forward these frames to so it will just flood it everywhere.

To deal with multicast traffic on layer two, we have two solutions:

IGMP snooping is the most popular choice nowadays and we covered it in another lesson. In this lesson, we’ll take a closer look at CGMP.

Back in the 90s, Cisco was looking for a good solution to deal with L2 multicast traffic. IGMP snooping was CPU-intensive and/or required special expensive ASICs since the switch has to inspect IGMP traffic.

The idea behind CGMP is simple: a multicast router knows about the state of each multicast group. It receives IGMP membership reports from receivers so it knows which devices want to receive multicast traffic and for which groups. Since the router knows everything, why not share this information with the switch?

L2 switches don’t care about IP addresses so the router will have to inform the switch about the MAC addresses of the receivers and multicast groups. The router shares these MAC addresses with the switch which allows the switch to update its CAM table entries. Multicast traffic will then only be forwarded on the correct interfaces and life is good.

CGMP is a simple protocol, the routers are the only devices that are producing CGMP messages. The switches only listen to these messages and act upon it. CGMP uses a well-known destination MAC address (0100.0cdd.dddd) for all its messages. When switches receive frames with this destination address, they flood it on all their interfaces which so all switches in the network will receive CGMP messages.

Within a CGMP message, the two most important items are:

  • Group Destination Address (GDA)
  • Unicast Source Address (USA)

The group destination address is the multicast group MAC address, the unicast source address is the MAC address of the host (receiver). We will take a closer look at these two addresses.

Nowadays, CGMP is hardly ever used. This is probably because IGMP snooping is supported in the ASIC of any modern switch and unlike CGMP, it’s a standard. CGMP is Cisco proprietary and it’s difficult to find a catalyst IOS switch that supports it.

CGMP Process Explained

Let’s take a closer look at how CGMP operates. When CGMP is enabled on a router, it will start sending CGMP messages where the GDA (Group Destination Address) is zero and the USA (Unicast Source Address) is set to its own MAC address. This first message is sent so the switch knows that there is a multicast router on the interface where it received the CGMP message on. This message is repeated every 60 seconds.

multicast cgmp announce

Let’s take a look at this first CGMP packet in action. To demonstrate this, I will use a router that supports CGMP. Here’s the topology I will use:

Multicast CGMP Topology

We have one router (R1) and two hosts (H1 and H2). For each device, I added the IP address and MAC address. The multicast group address I will use is 239.1.1.1, this group uses MAC address 0100.5e01.0101.

Unfortunately, I don’t have any old switches that support CGMP so I can’t show you the output of the switch. However, since the router is the only device that produces CGMP messages you won’t miss much.

Before we configure the router, let’s enable a debug:

R1#debug ip cgmp 
CGMP debugging is on

This will allow us to see the CGMP messages. Let’s configure multicast routing and CGMP now:

R1(config)#ip multicast-routing 

R1(config)#interface FastEthernet 0/0
R1(config-if)#ip pim dense-mode 
R1(config-if)#ip cgmp

You’ll need to enable PIM or the router won’t process any IGMP traffic. CGMP is disabled by default so we’ll have to enable it. As soon as you do this, you see the following debug:

R1#
CGMP: Sending self Join on FastEthernet0/0
      GDA 0000.0000.0000, USA 1234.1234.ffff

Above you see that the router is announcing itself. The GDA is empty and the USA is the source MAC address of our router. Here’s what the packet looks like:

multicast cgmp join zero router capture

Multicast CGMP Join Zero Router Packet Capture

Above we see that the destination MAC address is the CGMP address, 01:00:0c:dd:dd:dd. It also shows the GDA and USA.

When a host wants to join a multicast group, it sends an IGMP membership report (join) . Normally the router only has to look at the L3 addresses in the IGMP join but when CGMP is enabled, it also takes a look at the L2 addresses. The router will then send a CGMP message where the USA is the MAC address of the host and the GDA is the MAC address of the multicast group that it wants to join:

Multicast CGMP IGMP Join

Let’s see this in action. I will configure H1 to join multicast group 239.1.1.1:

H1(config)#interface FastEthernet 0/0
H1(config-if)#ip igmp join-group 239.1.1.1

As soon as you do this, R1 will show us this debug message:

R1#
CGMP: Received IGMP Report on FastEthernet0/0
      from 192.168.1.1 for 239.1.1.1
CGMP: Sending Join on FastEthernet0/0
      GDA 0100.5e01.0101, USA 1234.1234.aaaa

Here’s what this packet looks like:

multicast cgmp join group host capture

Multicast CGMP Join Group Host Capture

The MAC address of multicast group 239.1.1.1 is 01:00:5e:01:01:01 which is stored as the GDA. The USA is the MAC address of H1.

When the switch receives this packet, it will check its CAM table and searches for the interface that is associated with the USA. It will then add the GDA to this interface so that multicast traffic for this group is now forwarded on this interface.

Multicast CGMP Forward Traffic

When a host leaves a multicast group, it will send an IGMP membership report (leave) to the router:

IGMP membership report

This leave packet is sourced from the MAC address of the host but sent to the “all multicast routers” address (224.0.0.2) and not to the multicast group address.

The router will have to inform the switch through CGMP that a host has stopped listening to a certain multicast group. It does so with a CGMP leave message. The router can copy the source MAC address of the host from the IGMP membership report to the USA in the CGMP leave but it doesn’t know the MAC address of the multicast group. It will look for the multicast group address in the membership report and calculates the matching MAC address, which is entered as the GDA.

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 799 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

593 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Dear Abdelaziz,

    Thanks, just replaced this image!

    Rene

  2. Hello,

    I see there is no simulation about the Leave Message which has GDA with Group address and USA with zero and used for removal of multicast group from CAM table. Could you please specify how to simulate or test this message.

Ask a question or join the discussion by visiting our Community Forum