Content

| 7.2 |  | Examining Multicast in a Multilayer Switched Network |
| 7.2.1 |  | Multicast overview |

Most campus networks today support intranet applications that operate between one sender and one receiver. However, this paradigm is rapidly changing. In the emerging campus network, there is a demand for intranet and multimedia applications where one sender will transmit to a group of receivers simultaneously. These types of applications include transmitting a corporate message to employees, video and audio broadcasting, interactive video distance learning, transmitting data from a centralized data warehouse to multiple departments, communication of stock quotes to brokers, and collaborative computing. For example, an internal technical support facility might use multicast file transfer software to send software updates to multiple users in the campus simultaneously in one stream of data.

Many corporations and industries are now realizing the potential of multimedia applications. Video and voice conferencing applications generate much of the multicast traffic today. Many Web sites offer video streams that transmit multicast traffic. Companies are experiencing a marked increase in multicast traffic from internal users. Because of the proliferation of multicast applications, network administrators are charged with installing and configuring devices and implementing policy to manage traffic associated with these applications. Many network designs deal efficiently with unicast traffic, but neglect the impact of multicast traffic within the network. Unfortunately, this can severely impact a well-designed unicast network.

Again, it should be reiterated that it is critical in network design to take a proactive approach to controlling multicast traffic in the network. The default behavior of a switch floods multicast frames out of all ports except the originating port. This is usually not the desired effect. Cisco has implemented the proprietary Cisco Group Management Protocol (CGMP) and the non-proprietary IGMP snooping to help administer multicast traffic in the network. CGMP and IGMP snooping run on switches and routers and work hand-in-hand with Internet Group Membership Protocol (IGMP), running on routers, to control the flooding of multicast traffic in a network. To control multicast traffic, either CGMP or IGMP snooping would be used, but not both.

Multicast traffic originates at sources that need to distribute the same information to multiple recipients. When a source creates multicast traffic, it uses special Layer 2 and Layer 3 addresses so that routers and switches know how to route or switch the frame. By default, routers do not forward multicast traffic unless they are multicast capable and have a multicast routing protocol such as Distance Vector Multicast Routing Protocol (DVMRP) or Protocol Independent Multicast (PIM) enabled. DVMRP and PIM are inter-router protocols. Therefore, hosts and switches do not participate in messages for these protocols.

By default, a switch floods multicast traffic within a broadcast domain. This consumes bandwidth on both access links and trunk links. Depending upon the host TCP/IP stack implementation and network interface card (NIC) attributes, the multicast frame can cause a CPU interrupt. The reason a switch floods multicast traffic is that it has no entry in the bridge table for the destination address. Multicast addresses never appear as source addresses; therefore, the bridge/switch cannot dynamically learn multicast addresses; they must be manually configured.

IGMP is a multicast protocol that directly affects hosts. IGMP allows hosts to inform routers that they want to receive multicast traffic for a specific multicast group address.

Many older switches don’t understand IGMP messages. As a result, Cisco developed the proprietary CGMP, which enables routers to inform switches about hosts and their interest in receiving multicast traffic. This modifies the Catalyst Switch default behavior of flooding the multicast frame to all hosts in the broadcast domain. Rather than flooding the frame to all hosts, the Catalyst Switch limits the flooding scope to only those hosts in the broadcast domain that registered with the router through IGMP. If a host does not register with the router, it does not receive a copy of the multicast frame. This helps preserve access-link bandwidth.

Newer switches understand IGMP requests from hosts and implement Internet Group Management Protocol (IGMP) snooping. IGMP snooping constrains the flooding of multicast traffic by dynamically configuring the interfaces so that multicast traffic is forwarded only to those interfaces associated with IP multicast devices. The LAN switch snoops on the IGMP traffic between the host and the router and keeps track of multicast groups and member ports. When the switch receives an IGMP join report from a host for a particular multicast group, the switch adds the host port number to the associated multicast forwarding table entry. When it receives an IGMP Leave Group message from a host, it removes the host port from the table entry. After it relays the IGMP queries from the multicast router, it deletes entries periodically if it does not receive any IGMP membership reports from the multicast clients.