Multicasting and Switches

After the RP discovers multicast end stations off a given segment and begins receiving multicast traffic from the server, it forwards this traffic to the segment. In today's networks, that usually means that the first networking device that receives this traffic is a switch. Switches flood the traffic throughout the VLAN, treating it like a local broadcast. This could have a serious effect on the performance of a VLAN, especially if the multicast information is a video stream.

Controlling Multicast Traffic

With the use of a multicast routing protocol running on your RPs, you've solved your Layer 3 problems in the intelligent forwarding of your multicast traffic. Now you'll have to deal with the issues of your switches and how they can intelligently forward the multicast stream coming from their connected RPs. There are four basic ways of controlling the flood of multicast traffic:

• You can create VLANs for each multicast application.

• You can manually configure static multicast entries in the port address table of the switch.

• Switches can snoop IGMP queries and reports to learn end-station locations.

• Switches can gather IGMP end station information from an IGMP RP.

As you learned in Chapter 3, "VLANs, Trunks, and VTP," creating VLANs and assigning ports to them is an easy task. However, the problem with grouping users together based on their participation in a multicast group is that if end stations are constantly joining and leaving the group, maintaining the VLAN membership becomes a headache, if not an impossible task. Therefore, this is only used in environments where the multicast end stations remain constant members of a group.

The second solution is just as nonscalable as using VLANs: You can manually enter the multicast address and the end station's port numbers in the switch's address table, thereby limiting the number of ports that will actually forward the multicast data stream. The problem with this approach is that if the membership of the multicast group is constantly changing, manually updating the address table becomes an impossible task.

IGMP Snooping

The third solution to controlling multicast traffic is to have the switch dynamically keep track of joining and leaving members of a multicast group. The switch does this by snooping the IGMP queries that RPs generate and the reports that multicast end stations reply with. The problem with this approach is that the switch must examine every multicast frame, which is very process intensive and introduces a lot of latency in the switching of everyone's frames, including the multicast traffic. Therefore, IGMP snooping should not be used on lower-end switches, but only on higher-end switches that can perform snooping in hardware using ASICs.

Cisco Group Management Protocol

The fourth solution to controlling multicast traffic is the preferred one: a dynamic process that updates the switch's address table as with snooping but without the performance penalty of snooping. Cisco has a proprietary protocol called CGMP that performs this function.

CGMP allows Cisco's switches to learn from Cisco's IGMP-enabled RPs about the list of end stations participating in the different multicast groups. The switches take this address information and appropriately update their CAM tables. This solution has very little overhead only a minimal amount of management traffic is relayed between the RP and the switch. After the switch has updated its CAM table with the multicast addresses, it can intelligently forward the multicast traffic to only participating end stations. Unlike snooping, CGMP has no effect on the Layer 2 switching speeds. This is the recommended approach.

CGMP is based on a client/server model. In this model, the RP is considered the server and the attached switches in the switch fabric are considered the clients. The IGMP RPs know about all the end stations participating in a multicast group. They learn this information from the end station responses to their queries or from the information that the end station initially generates when it wants to participate in a multicast application. With CGMP, the RP periodically shares this information with its attached switches. Anytime the RP detects the joining or leaving of an end station from a multicast group, the RP shares it with the switches.

The CGMP multicast frame that the RP shares with the switches contains the multicast group address of the application and the real MAC address of the end station. Switches take this information and examine their CAM table for a matching MAC address and an associated port. If a switch finds the end-station's address in its port address table, it adds an additional entry for the Layer 2 multicast address and the same port number that the client resides off of. If the switch does not find the end-station's address, it basically ignores the CGMP message. With CGMP enabled, however, the switch will not flood multicast traffic it depends on the RP to tell the switch which end stations are participating in multicast groups.