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:
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
- CGMP (Cisco Group Management Protocol)
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.
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:
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:
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:
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:
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.
When a host leaves a multicast group, it will send an IGMP membership report (leave) to the router:
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.
The explanation above about the CGMP leave is the “text book explanation” but when I tested this, I never noticed my router CGMP leave messages when one host left the group 
This might be related to the router platform and/or IOS version. Nevertheless, let’s test it.
This might be related to the router platform and/or IOS version. Nevertheless, let’s test it.
I will configure H2 to join our multicast group:
H2(config)#interface FastEthernet 0/0
H2(config-if)#ip igmp join-group 239.1.1.1
When the host joins, our router will send another CGMP join message:
R1#
CGMP: Received IGMP Report on FastEthernet0/0
from 192.168.1.2 for 239.1.1.1
CGMP: Sending Join on FastEthernet0/0
GDA 0100.5e01.0101, USA 1234.1234.bbbb
The message above shows us that the router sends another CGMP join towards the switch. This will allow the switch to start forwarding multicast traffic towards H2.
Now let’s remove one of our hosts, this should trigger a CGMP leave message:
H1(config)#interface FastEthernet 0/0
H1(config-if)#no ip igmp join-group 239.1.1.1
When I do this, nothing happens on the router. It should generate a CGMP leave with the MAC address of H1 as the USA and the MAC address of 239.1.1.1 as the GDA but it doesn’t happen. I’ve tested this on a 3725 router running IOS 12.4T and a 2811 running IOS 15.
When the second host leaves the multicast group, there won’t be any receivers left. The host will send a membership report (leave) and the router will send an IGMP membership query for 239.1.1.1 to see if there are still any listeners. Nobody will respond so the router will then send a CGMP leave message where the GDA is the MAC address of the multicast group and the USA will be empty.
When the switch receives this message, it will know that there are no listeners left for this group so it will remove the GDA from the CAM table.
Let’s see this in action. The only thing we have to do is to make H2 stop listening to 239.1.1.1:
H2(config)#interface FastEthernet 0/0
H2(config-if)#no ip igmp join-group 239.1.1.1
As soon as you do this, R1 will generate the CGMP leave message:
R1#
CGMP: Sending Leave on FastEthernet0/0
GDA 0100.5e01.0101, USA 0000.0000.0000
Here’s what this packet looks like:
Above you can see the CGMP leave message. the USA is empty and the GDA is set to the MAC address of multicast group 239.1.1.1.
The messages you have seen above are everything we need to inform the switch so it can forward multicast traffic on the correct interfaces.
For the sake of completeness, let me show you two more CGMP messages.
The first one is a “clear” message. This instructs the switch to remove all multicast group entries from its CAM table. We can send it by using the following command:
R1#clear ip cgmpR1#
CGMP: Sending cleanup Leave on FastEthernet0/0
Here’s what it looks like:
Above you can see the leave message with an empty GDA and USA. The switch will recognize this as a “clear” message and will remove all multicast MAC addresses from the CAM table.
The last CGMP message is a “self” leave. When you disable CGMP, the router will inform the switch so it knows it is gone. We can test this by disabling CGMP on our router:
R1(config)#interface FastEthernet 0/0
R1(config-if)#no ip cgmp
Once you do this, the following debug shows up:
R1#
CGMP: Sending self Leave on FastEthernet0/0
GDA 0000.0000.0000, USA 1234.1234.ffff
Here’s what it looks like:
Above you can see that the GDA is empty. When the switch receives this message, it knows that the router is not using CGMP anymore.
Here’s an overview of all CGMP messages:
| Type | GDA | USA | Function |
| Join | Group MAC | Host MAC | Add USA interface to group |
| Leave | Group MAC | Host MAC | Remove USA interface from group |
| Join | Zero | Router MAC | Switch learns which interface is connected to CGMP router |
| Leave | Zero | Router MAC | Switch learns that router has stopped using CGMP |
| Leave | Group MAC | Zero | Remove multicast group from CAM table |
| Leave | Zero | Zero | Remove all multicast groups from CAM table |
hostname R1
!
ip multicast-routing
!
interface FastEthernet0/0
mac-address 1234.1234.ffff
ip address 192.168.1.254 255.255.255.0
ip pim dense-mode
ip cgmp
!
endhostname H1
!
interface FastEthernet0/0
mac-address 1234.1234.aaaa
ip address 192.168.1.1 255.255.255.0
ip igmp join-group 239.1.1.1
!
endhostname H2
!
interface FastEthernet0/0
mac-address 1234.1234.bbbb
ip address 192.168.1.2 255.255.255.0
ip igmp join-group 239.1.1.1
!
endConclusion
In this lesson you have learned what CGMP (Cisco Group Management Protocol) is and how it operates. Let’s summarize what we have seen:
- Multicast on L2 is an issue since a switch doesn’t learn the destination MAC addresses of group addresses. To help the switch figure out where to forward multicast traffic, we can use CGMP.
- CGMP is an old protocol, developed by Cisco as an alternative to IGMP snooping.
- The idea behind CGMP is that the router can help the switch since it has all required information through IGMP.
- The router will inform the switch through CGMP messages so the switch knows where to forward multicast traffic to.
- CGMP messages are only produced by routers, the switch only listens.
- In the CGMP message, you will find the GDA (Group Destination Address) and the USA (Unicast Source Address).
- There are a total of six CGMP messages.
I hope you enjoyed this lesson, if you have any questions feel free to leave a comment!
No comments:
Post a Comment