Traditional transparent bridges (and, therefore, most Layer 2 switches) do not have a mechanism to learn multicast MAC address. As a result, these Layer 2 bridging and switching devices treat multicast frames as if they were broadcast frames. Although this does allow multicast applications to function, it has the highly undesirable side effect of wasting lots of bandwidth (it can also waste CPU cycles on end stations).
One solution to this problem is the use of static CAM entries. However, given the growing popularity of multicast usage, this can rapidly become a huge management problem. For example, every time a user wants to join or leave a multicast group, it requires manual intervention by the network administrators. In a large network, this can easily amount to hundreds of entries and adjustments per day.
Clearly some sort of dynamic process is required. Three options are available for dynamically building multicast forwarding tables: CGMP, GMRP, and IGMP Snooping. This section briefly discusses these three options, especially as they pertain to the NFFC. For a more thorough discussion, please see Chapter 13.
Of these techniques, Cisco developed the Cisco Group Management Protocol (CGMP) first. This allows routers running the Internet Group Management Protocol (IGMP) to update the Catalyst Layer 2 CAM table. IGMP is a protocol that allows end stations to request that routers send them a copy of certain multicast streams. However, because it is a Layer 3 protocol, it is difficult for a Layer 2 switch to speak this protocol. Therefore, Cisco developed CGMP. Think of it as a mechanism that allows a Layer 3 router to tell a Layer 2 Catalyst about multicast group membership. As a result, the Layer 2 Catalyst forwards IP multicast traffic only to end-station ports that are actually interested.
Configuring CGMP on a Catalyst is simple. It runs by default on most Catalysts, requiring no configuration whatsoever. Other Catalysts, such as the 5000, require the set cgmp enable command. The show multicast group cgmp command can be used to display the multicast MAC address to port mappings created via the CGMP protocol. To configure CGMP on the router, the ip cgmp command must be configured on the interfaces where CGMP support is desired. In addition, some sort of multicast routing protocol must be configured (PIM dense-mode is the simplest option).
In the future, the GARP Multicast Registration Protocol (GMRP) might become a commonly used approach. GMRP uses the Generic Attributed Registration Protocol (GARP) specified in 802.1p to provide registration services for multicast MAC addresses. However, because work is still ongoing in the development of GMRP, this is not a suitable option today.
The third option, IGMP Snooping, is a standards-based alternative to the Cisco Group Management Protocol (CGMP). This relies on the pattern-matching capabilities of the NFFC to listen for IGMP packets as they flow between the router and the end stations. By inspecting these packets, the Catalyst can learn which ports have end stations interested in which multicast groups.
Some vendors have implemented IGMP Snooping using general-purpose CPUs. However, without some sort of hardware-based support, this approach suffers from extreme scaling problems. This situation arises because IGMP messages are intermixed with data in literally every multicast flow in the network. In short, vendors cannot simply point a single IGMP multicast MAC address at the CPU. Instead, the switch must sort through every packet of every multicast stream looking for and processing IGMP packets. Do not try this on a general-purpose CPU!
Was this article helpful?