Layer 2 Group Management
As mentioned earlier, Layer 2 devices treat multicast messages as broadcasts when no group management mechanism is present. This not only causes an increase of traffic on a particular subnet, but these messages are sent to every device within that subnet (flooding). These devices may treat the processing of multicast messages differently, depending on the behavior of the operating system and associated hardware. Multicast messages may be processed in hardware, software, or the combination of both. Consequently, multicast messages, or too many multicast messages, may have an adverse effect on a device. It is better to handle multicast messages in the network and only send messages to the devices that are interested in receiving them.
Two protocols were created to help manage this behavior on LAN segments, Cisco Group Management Protocol (CGMP) and Router-port Group Management Protocol (RGMP). While both of these protocols still exist in networks today, they are generally not used in favor of IGMP snooping, which is discussed in the next section. For this reason, we only provide a brief introduction to these protocols.
Cisco Group Management Protocol
In order to address the Layer 2 challenges with multicast as a broadcast message, Cisco first developed a proprietary solution called CGMP. At the time of development, the capabilities of Layer 2 switches did not offer the Layer 3 inspection or snooping of messages as they do today. CGMP was used between the connected router and switch. The router would send IGMP information to the switch using CGMP, regarding which clients have registered. The receiving switch could then determine which interfaces to send the outgoing multicast messages.
CGMP behaves in the following manner: When a host is interested in receiving a stream from a particular Group Destination Address (GDA), it sends an IGMP report message. This messages is received by the router and the router in turn sends a CGMP Subnetwork Access Protocol (SNAP) frame to the destination MAC address of 0x0100.0CDD.DDD with the following information:
Version: 1 or 2
Message field: Join or Leave
Count: Number of address pairs
MAC address of the IGMP client
Group multicast address/Group destination address (GDA)
Unicast source address (USA): MAC address of the host sending the join message
The attached switch, configured to support CGMP, receives the frame from the router. The switch looks at the USA and performs a lookup in the content addressable memory (CAM) table to determine the interface of the requesting host. Now that the interface of the requesting host has been determined, the switch places a static entry for the GDA and links the host address in the CAM table if this is the first request for the GDA. If there was already an entry for the GDA, the switch just adds the USA to the GDA table.
The CGMP Leave Process
The leave process is dependent on the IGMP version of the host. IGMPv1 does not provide a mechanism to inform the network when it no longer wants to participate in receiving the stream. When an IGMPv1 host leaves, the only way the network realizes that the host is no longer participating in the multicast stream is through an IGMP query message. You can imagine that having a host join a stream, then join another stream, and so on, can cause a significant impact on the amount of traffic on the network. Consider someone watching IPTV and quickly changing channels. To address this problem, the router periodically sends IGMP query messages to determine if devices are still interested in receiving the stream. If a router does not receive a response after sending three IGMP query messages, it informs the switch via CGMP, which then removes the entries for the GDA.
IGMPv2 added the functionality of a leave message; this provides the ability for a host to gracefully leave a session that it is no longer interested in receiving. When a host sends an IGMP leave message, the router sends a query message and starts a query-response message timer. This process is done to determine if there are hosts on that specific network that are still interested in receiving the multicast stream. If the router does not receive a response, it will send a CGMP message to the switching informing it to remove the entries for the GDA.
Router-Port Group Management Protocol
Along the same lines as CGMP, another protocol, RGMP, was developed to address the multicast communication of routers over a switched network. When several routers are connected to the same Layer 2 switched network, multicast messages are forwarded to all protocol independent multicast (PIM) routers, even those that are not interested in receiving the multicast streams.
RGMP is configured on the switch in conjunction with IGMP snooping (IGMP snooping is discussed at length in the next section of this chapter). The routers that are connected to the switch are configured with PIM sparse-mode and RGMP. A router configured with RGMP sends a RGMP hello messaged to the attached switch. The switch creates an entry indicating the receiving interface is a RGMP router and will not forward multicast traffic to that interface unless it receives a join message from the router. A router interested in receiving a specific multicast stream sends a RGMP join message to the switch with the GDA. The switch in turn creates an entry for the GDA and links the router interface in the CAM table.
We have covered two of the four RGMP message types, “hello” and “join.” The other messages are “bye” and “leave.” The “bye” RGMP message tells the switch to place the interface in a normal forwarding state. Finally, the “leave” message is sent from the router when it no longer is interested in receiving a specific multicast stream.