Header
Home | Set as homepage | Add to favorites
  Search the Site     » Advanced Search
Sections
Syndication


Blogroll:

||||| ALL Cisco-Network ARTICLES |||||  
CCIE Journey,
The CCIE Journey,


Cisco Group Management Protocol 2

Oct 28,2010 by alperen

image

When the broadcast frame reaches the router, it will not be propagated to LIS 1 because routers do not forward broadcast traffic.  
  The network in Figure 4-4 can be implemented using one switch and two VLANs (see Figure 4-5). Each port on the switch is assigned to either VLAN 1 or VLAN 2 and the router has two logical interfaces configured on one physical interface.  
   
  Figure 4-5: Reducing broadcast domain size using VLANs  
  Broadcast traffic from host 25 on VLAN 1 is only forwarded to other hosts on VLAN 1; hosts on VLAN 2 do not receive the broadcast traffic, and inter-VLAN unicast IP traffic must go to the router. In Figure 4-6, host 25 on VLAN 1 is sending unicast IP traffic to host 2 on VLAN 2. The sequence of events to accomplish this are as follows:  
   
  Figure 4-6: Sending inter-VLAN traffic  
  1.   Host 25 on VLAN 1 wants to send traffic to host 2 on VLAN 2. The destination address is on a different IP subnet, so host 25 sends the packet to the default gateway, which is the router.  
  2.   The router examines the destination address and determines the traffic is for VLAN 2, so the packet is sent back to the switch.  
  3.   The switch examines the destination MAC address and forwards the packet to host 2 on VLAN 2.  
  The broadcast problem has been solved, but what about the multicast traffic? Have we improved the situation by replacing the shared hub with an ethernet switch? In Figure 4-7, one of the hosts on VLAN 1 is now a multicast sender and one host from VLAN 2 has joined the multicast group using IGMP. What will happen when the source sends a multicast packet?  
   
  Figure 4-7: Forwarding of multicast traffic on VLANs  
  Everyone will receive the multicast packet! Wait a minute, this is worse than the broadcast traffic. At least VLAN 2 did not receive the broadcast traffic from VLAN 1. The problem is that the switch (at least for now) treats multicast traffic like it was broadcast traffic, but the router does not. Therefore, the multicast traffic on VLAN 1 is forwarded to all hosts on VLAN 1 and the router. The router has state for the multicast group on VLAN 2 because there is a receiver on VLAN 2. The router forwards the multicast traffic to VLAN2, which treats the traffic as a broadcast and forwards it to every host on the VLAN. Looks like we need another protocol. And that protocol should cause multicast traffic to be forwarded as shown in Figure 4-8.  
   
  Figure 4-8: The ideal multicast traffic forwarding scenario  
  One method to overcome the multicast problem on switches is to manually configure the ports on the switch to receive multicast traffic. The content addressable memory (CAM) table on the switch contains a mapping of ethernet addresses to ports that the switch uses to forward traffic. A port can have multiple mappings because a hub can be tied to a switch port and multiple hosts with different ethernet addresses would depend on the port for traffic. Assume a host connected to switch port 1/4  wishes to receive traffic from the multicast group 224.65.10.154. The ethernet multicast address corresponding to this group is 01:00:5E:41:0A:9A (refer to Chapter 5) and we could put the mapping in the CAM table using the command  
  set cam permanent 01-00-5E-41-0A-9A 1/4  
  When multicast traffic arrives at the switch for group 224.65.10.154, the traffic would only be sent out through port 1/4 . What other multicast groups would have their traffic sent on only port 1/4 ? Remember that 32 different multicast groups map to the same multicast ethernet address (see Table 4-1). If traffic arrives from any one of those 32 groups, then it is sent only on port 1/4 .  
  Table 4-1: Class D multicast IP addresses that map to the multicast ethernet address 01:00:5E:41:0A:9A  
 
 
  224.65.10.154  
225.65.10.154  
 
226.65.10.154  
 
227.65.10.154  
 
  228.65.10.154  
229.65.10.154  
 
230.65.10.154  
 
231.65.10.154  
 
  232.65.10.154  
233.65.10.154  
 
234.65.10.154  
 
235.65.10.154  
 
  236.65.10.154  
237.65.10.154  
 
238.65.10.154  
 
239.65.10.154  
 
  224.193.10.154  
225.193.10.154  
 
226.193.10.154  
 
227.193.10.154  
 
  228.193.10.154  
229.193.10.154  
 
230.193.10.154  
 
231.193.10.154  
 
  232.193.10.154  
233.193.10.154  
 
234.193.10.154  
 
235.193.10.154  
 
  236.193.10.154  
237.193.10.154  
 
238.193.10.154  
 
239.193.10.154  
 
 
 
  Traffic for any multicast address not in the CAM table would be flooded to every port in the VLAN. This seems to be a solution to our problem. All we need to do every time a user wants to receive multicast traffic is to just add an entry to the CAM table (after we convert the IP multicast address to an ethernet multicast address). Whenever the user wants to leave the group, we just simply delete the entry from the CAM table using  
  no set cam permanent 01-00-5E-41-0A-9A 1/4  
  What could be easier? Hopefully you can see that this would be an administrative nightmare. Assuming you have hundreds or even thousands of users and only a fraction of them receive multicast traffic, this would turn into a full-time and rather boring job, but again this is not the ideal situation. Even though it achieves what we wanted, the solution is not dynamic and requires too much intervention.  
  To achieve the ideal multicast forwarding scenario, we need a protocol based on a layer two, or ethernet addresses, and one that is dynamic. And it should come as no surprise that this protocol is the CGMP. One of the main concerns when CGMP was designed was that no modifications should need to be made to existing multicast protocols on either hosts or routers. Therefore, CGMP must add additional functionality without altering the operation of IGMP or any of the layer three multicast routing protocols. The relationship between IGMP, CGMP, routers, and switches is shown in Figure 4-9.  
   
  Figure 4-9: Logical relationship between IGMP and CGMP  
  In Figure 4-9, it looks as if the host is sending the IGMP packets directly to the router and bypassing the switch. This is a logical diagram and, of course, the IGMP packet must pass through the switch. The diagram shows that IGMP is a protocol used between hosts and routers, and CGMP is the protocol used between routers and switches. The fundamental operation when using IGMP and CGMP is as follows:  
  1.   A host sends an IGMP Join to the router for a particular IP multicast group.  
  2.   The router, if CGMP is enabled, sends a message to the switch containing the unicast ethernet address of the host and the multicast ethernet address of the group the host is joining.  
  3.   The switch, if CGMP is enabled, installs the entry in the CAM table.  
  The format of a CGMP packet is given in Figure 4—10.  
   
  Figure 4-10: CGMP packet format  
  Ver—  
  CGMP version number = 1  
 
  Type—  
  0 = Join, 1 = Leave  
 
  Reserved—  
  Set to 0 and ignored  
 
  Count—  
  Number of GDA/USA pairs in the message  
 
  GDA—  
  Six-byte multicast group destination ethernet address  
 
  USA—  
  Six-byte unicast source address, which is the address of the host  
 
  CGMP must be enabled on the switch and the router using the commands listed below. On the router interface connected to the switch use  
  ip cgmp  
  and on the switch use  
  set cgmp enable  
  Example  
  Enable cgmp on router interface ethernet 0  
  interface ethernet 0  
  ip cgmp  
  How does the switch know to which port the router is connected? The router sends a CGMP Join message to the switch (if CGMP is enabled on the router interface) with the GDA set to zero and the USA set to the MAC address of the router port (see Figure 4-11).  
   
  Figure 4-11: CGMP Join message from a router to a switch  
  When all the receivers for a particular multicast group leave the group, the router deletes state for the group on the interface and sends a CGMP leave message for the group to the switch. The Group Leave message contains the multicast MAC address for the group and the USA field is zero. An example CGMP Group Leave message is shown in Figure 4-12 for multicast group 224.65.10.154.  
   
  Figure 4-12: Router CGMP Leave message from a router to a switch for a particular multicast group (224.65.10.154)  
  Upon receipt of the Group Leave message, the switch deletes all entries for the multicast group from the CAM table. What happens to multicast traffic for a group that has had all CAM entries deleted from the switch? The switch floods all packets from this group to every host in the VLAN. If all receivers for all groups no longer wish to receive multicast traffic, the router sends a CGMP Leave message with both the GDA and USA fields set to zero, as shown in Figure 4-13. All multicast groups are deleted from the CAM table and all multicast packets are flooded to all hosts in the VLAN. This may seem like a problem, but if the multicast traffic does not originate from a source connected to the switch but from a source that goes through the router, then this is not a problem.  
   
  Figure 4-13: Router CGMP Leave message from a router to a switch for all multicast groups  
  If no receivers are on the switch, then the multicast routing protocols prevent the traffic from reaching the switch. Well, sometimes. As we shall see, some of the multicast routing protocols periodically flood traffic on all router interfaces, even if no receivers are present. When this occurs, the switch floods the multicast traffic on all ports.  
  CGMP messages are layer two messages and are sent to the ethernet address 01:00:0C:DD:DD:DD.

170 times read

Related news

No matching news for this article
Did you enjoy this article?
(total 0 votes)

comment Comments (0 posted) 

More Top News
CCSP-Cisco Certified Security Professional
Most Popular
Most Commented
Featured Author