Without any mechanisms for switches to determine what hosts are part of what multicast group, all multicast messages would have to be flooded over all ports. To combat this, IGMP snooping was developed. Using IGMP snooping, a switch listens for IGMP Host Reports. Any time it receives an IGMP host report, it adds that port to the associated multicast group. Similarly, when detecing an IGMP leave message, the switch will remove that specific port from the specified multicast group. When the switch receives host queries from the router, it responds with one join request per multicast group.

In order for this to work, a switch has to examine every IGMP frame that comes into the switch. This can cause some serious performance issues in a low-end switch.

By default, IGMP snooping is enabled globally on the switch. It can be enabled or disabled globally, and (if enabled globally) may then be enabled or disabled on a per-vlan basis. The following command is used with igmp snooping:


This command will enable/disable igmp snooping on a global level. The vlan portion will enable/disable igmp snooping on a per-vlan basis. The immediate-leave keyword can be used to force a port to immediately be removed from a multicast group upon receipt of a leave message. This should be used in the case where only a single computer is attached to a port, but is not enabled by default.

By default, the switch listens to PIM/DVMRP packets. To listen to CGMP self-join packets instead, use the following command:


This forces the router to listen to ONLY CGMP self-join packets and no other types of CGMP packets. In order to set the router to use PIM/DVMRP instead, use the following command line:


To view the layer 2 multicast entries in the switch or for a specific vlan, use the following command:


By using the user keyword, you will only display user-configured multicast entries.

CGMP is a Cisco proprietary protocol that allows switches to learn about multicast hosts from a router. Any time that the router receives an IGMP message concerning a host joining or leaving a multicast group, the router generates a CGMP message and informs the switch. Thereby, the switch is able to control the propagation of multicast messages out of its ports without having to examine every IGMP frame. These CGMP messages are multicast to the multicast MAC address of 01:00:0c:dd:dd:dd and informs all switches of the type of IGMP packet (join or leave), the MAC address of the sending client, and the multicast address of the group specified in the IGMP message. This is sufficient information for the switch to then build a multicast forwarding database.

CGMP requires a CGMP capable router to exist on the same segment as the switch. Additionally, any interface running CGMP must also be running PIM. On newer switch models (including 2950 and 3550 series switches) CGMP is no longer used and has been replaced with IGMP Snooping.

To enable CGMP, use the following command line:

Multicast routing introduces a new level of complexity beyond standard Unicast routing. In unicast routing, the destination IP address is the address of the host, and a router simply needs to send the packets out the correct interface to reach that host. With multicast, the IP address is not a host's ip, but rather a 'transmission identifier'. There is no information within the packet that specificies what IP addresses the multicast packet should be relayed to.

To deal with this issue, multicast routing protocols have been developed. These routing protocols allow routers to relay information about member multicast groups, thereby building a multicast routing table that can be used to forward various multicast packets. By running a multicast routing protocol, routers build a virtual tree to model the distribution of multicast packets. There are two different tree models that can be used.

Source Distribution Tree is the first variety and is the simplest. The 'root' of the tree is the source of the multicast traffic, while branches define the various recipients. This method uses the shortest path between the source and the destination, and is thus called Shortest Path Tree (SPT) as well.

A notation of (S,G) is used to elucidate specific multicast streams. The S is for source, while the G is the multicast group address. For instance, an SG of (192.168.1.1,224.0.1.1) indicates the source address being 192.168.1.1, with the multicast address of 224.0.1.1 (which is Network Time Protocol).

Shared Distribution Tree is the other variety. These trees use a single root for every multicast stream, designated as a Rendezvous Point (RP), or Core (hence making RP Tree (RPT) and Core-Based Tree (CBT) alternate names for this tree variety). Every multicast stream is sent to this Core router and then distributed from there, so it's typically in some central, high-bandwidth portion of the network. The notation used for this type of tree is (*,G). The G, of course, stands for the group address. Since the root is always the same server, no source address is needed. An example notation would be (*,224.0.1.1).

Multicast streams have several features to help manage them. One thing that can be used is TTL. By setting TTL limits on multicast packets, a router can be used to selectively prune multicast packet streams by their TTL values. For instance, a multicast packet stream may start with a TTL of 32. After 6 hops, this has been reduced to 26, at which point it encounters a router with a TTL limit configured. In this case, the TTL limit is 15, so the TTL is reduced by 1 and forwarded on. Ten hops later, the TTL is down to 15 and the packet encounters a router with a TTL limit of 20. At this point, the multicast stream is discarded. By creating intelligent TTL limits, specific (distant) multicast streams can be eliminated from various network segments.

To configure multicast TTL, use the following command line:


Any multicast packet that arrives with a ttl below the specified value is automatically dropped. The default value is 0, which allows all packets to pass.

Another method to control multicast is Reverse Path Forwarding (RPF). Any time a router receives a multicast packet, it checks the source of the ip. It then looks at its routing table and figures out which interface it would send packets to reach that address. If the interface that the packet entered and the interface the router would send packets to get to the source are the same, the packet is passed. If, however, the packet came in on a different interface, the packet is dropped. Basically, the reasoning is that packets from a server should be coming in the same interface that packets destined to that server leave from. If the two are different, there must be a network loop. This check allows multicast to remain loop-free.

Routing protocols may also be classified as either Dense Mode or Sparse Mode. Dense Mode assumes that there will be alot of multicast clients throughout the network and an abundance of bandwidth.. Broadcasting a radio channel to every room, for instance, would be Dense Mode. Some examples of Dense Mode routing protocols are Distance Vector Multicast Routing Protocol (DVMRP), Protocol Independent Multicast Dense Mode (PIMDM), and Multicast Open Shortest Path First (MOSPF). Dense Mode protocols always use the shortest-path tree, using the (S,G) notation and assumes that there will be receivers in every point on the network. It then pushes multicast traffic to all these points until specifically told to not broadcast there.

Alternately, Sparse Mode assumes that multicast clients are widely dispersed and that network flooding would be an unnecessary waste of bandwidth. Sparse Mode begins with an empty distribution tree and only adds branches upon request. Some examples of Sparse Mode protocols incude Core-Based Trees (CBT) and Protocol Independent Multicast Sparse Mode (PIM SM).

Multicast routing introduces a new level of complexity beyond standard Unicast routing. In unicast routing, the destination IP address is the address of the host, and a router simply needs to send the packets out the correct interface to reach that host. With multicast, the IP address is not a host's ip, but rather a 'transmission identifier'. There is no information within the packet that specificies what IP addresses the multicast packet should be relayed to.

To deal with this issue, multicast routing protocols have been developed. These routing protocols allow routers to relay information about member multicast groups, thereby building a multicast routing table that can be used to forward various multicast packets. By running a multicast routing protocol, routers build a virtual tree to model the distribution of multicast packets. There are two different tree models that can be used.

Source Distribution Tree is the first variety and is the simplest. The 'root' of the tree is the source of the multicast traffic, while branches define the various recipients. This method uses the shortest path between the source and the destination, and is thus called Shortest Path Tree (SPT) as well.

A notation of (S,G) is used to elucidate specific multicast streams. The S is for source, while the G is the multicast group address. For instance, an SG of (192.168.1.1,224.0.1.1) indicates the source address being 192.168.1.1, with the multicast address of 224.0.1.1 (which is Network Time Protocol).

Shared Distribution Tree is the other variety. These trees use a single root for every multicast stream, designated as a Rendezvous Point (RP), or Core (hence making RP Tree (RPT) and Core-Based Tree (CBT) alternate names for this tree variety). Every multicast stream is sent to this Core router and then distributed from there, so it's typically in some central, high-bandwidth portion of the network. The notation used for this type of tree is (*,G). The G, of course, stands for the group address. Since the root is always the same server, no source address is needed. An example notation would be (*,224.0.1.1).

Multicast streams have several features to help manage them. One thing that can be used is TTL. By setting TTL limits on multicast packets, a router can be used to selectively prune multicast packet streams by their TTL values. For instance, a multicast packet stream may start with a TTL of 32. After 6 hops, this has been reduced to 26, at which point it encounters a router with a TTL limit configured. In this case, the TTL limit is 15, so the TTL is reduced by 1 and forwarded on. Ten hops later, the TTL is down to 15 and the packet encounters a router with a TTL limit of 20. At this point, the multicast stream is discarded. By creating intelligent TTL limits, specific (distant) multicast streams can be eliminated from various network segments.

To configure multicast TTL, use the following command line:


Any multicast packet that arrives with a ttl below the specified value is automatically dropped. The default value is 0, which allows all packets to pass.

Another method to control multicast is Reverse Path Forwarding (RPF). Any time a router receives a multicast packet, it checks the source of the ip. It then looks at its routing table and figures out which interface it would send packets to reach that address. If the interface that the packet entered and the interface the router would send packets to get to the source are the same, the packet is passed. If, however, the packet came in on a different interface, the packet is dropped. Basically, the reasoning is that packets from a server should be coming in the same interface that packets destined to that server leave from. If the two are different, there must be a network loop. This check allows multicast to remain loop-free.

Routing protocols may also be classified as either Dense Mode or Sparse Mode. Dense Mode assumes that there will be alot of multicast clients throughout the network and an abundance of bandwidth.. Broadcasting a radio channel to every room, for instance, would be Dense Mode. Some examples of Dense Mode routing protocols are Distance Vector Multicast Routing Protocol (DVMRP), Protocol Independent Multicast Dense Mode (PIMDM), and Multicast Open Shortest Path First (MOSPF). Dense Mode protocols always use the shortest-path tree, using the (S,G) notation and assumes that there will be receivers in every point on the network. It then pushes multicast traffic to all these points until specifically told to not broadcast there.

Alternately, Sparse Mode assumes that multicast clients are widely dispersed and that network flooding would be an unnecessary waste of bandwidth. Sparse Mode begins with an empty distribution tree and only adds branches upon request. Some examples of Sparse Mode protocols incude Core-Based Trees (CBT) and Protocol Independent Multicast Sparse Mode (PIM SM).