Chapter 7. Multicast Routing and Switching

The growing level of multimedia content available on corporate networks and the Internet has increased many organizations bandwidth requirements. Streaming video and audio applications are becoming more commonplace, with many of these audio/video streams originating from a single source and being sent to many receivers. For example, a video server may transmit a single video feed to thousands of receivers, which raises concerns about bandwidth usage and CPU overheads. The video server could send a video feed to each individual receiver, but doing so means the server has to generate thousands of video streams. So many streams would most likely saturate the link connected to the server and render the server useless due to the high CPU load incurred. Multicasting allows a one-to-many transmission that consists of a single data stream that is propagated to any host that wants to receive the data stream, without unnecessarily sending that data stream to hosts that do not want to receive the data stream. That means multicast traffic must be controlled in some fashion at both a Layer 2 level and Layer 3 level.

This chapter focuses on controlling multicast traffic in both Layer 2 and Layer 3 networks. After some initial introductory material, this chapter presents the following configuration scenarios, which provide you with the practical knowledge required to implement multicast traffic control on Layer 2 and Layer 3 networks:

  • Scenario 7-1: Configuring PIM Dense Mode Multicast Routing
  • Scenario 7-2: Configuring PIM Sparse Mode and PIM Sparse-Dense Mode Multicast Routing
  • Scenario 7-3: Multicast Traffic Control on the LAN
  • Scenario 7-4: Configuring IGMP Snooping
  • Scenario 7-5: Configuring Cisco Group Management Protocol (CGMP)

Introduction

Most networking professionals are very familiar with the concept of unicast traffic and broadcast traffic. A unicast packet is sent from a single source to a single destination and is also known as one-to-one communications. A broadcast packet is sent from a single source to all hosts on a VLAN and is also known as one-to-all communication. Multicast traffic is designed to enable a host to send network data to a group of hosts (i.e., one-to-many communications) without requiring the data to be broadcast throughout the network or replicated as multiple unicast communications to each receiving host. This process ensures only a single copy of a one-to-many transmission is sent and that the transmission is forwarded only over the paths necessary to reach the group of hosts that need to receive it. This control allows for a reduction in bandwidth usage, increasing network efficiency and performance.

Multicast is important for any application that needs to send large amounts of the same information to multiple devices. Common uses for multicast traffic include:

  • Multimedia applications that consume high bandwidth, such as streaming video and TV servers
  • Voice-conferencing applications
  • Software distribution applications
  • Routing protocols such as Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), and Routing Information Protocol (RIP) version 2
  • Any application that requires a central host to efficiently send the same message to multiple peers

The following topics are now introduced to ensure that you are familiar with fundamental multicast concepts:

  • Multicast addressing
  • Internet Group Management Protocol (IGMP)
  • Multicast routing
  • Multicast on the LAN
  • Multicast performance considerations on Cisco Catalyst switches

Multicast Addressing

For both IP (Layer 3) and Ethernet (Layer 2) communications, special addressing is required to identify multicast packets and frames. A multicast address identifies a specific group of receivers that want to receive the information transmitted to the multicast address.

IP Multicast Addressing

For IP multicast addressing, the Class D address range is used (224.0.0.0-239.255.255.255) in the destination IP address field to identify a multicast packet. The source IP address of a multicast packet is always a unicast address (Class A, B, or C). Within the Class D address range, some smaller address ranges are reserved for special use. The first is the 224.0.0.x range, which is reserved for the use of various communications protocols. Table 7-1 describes some common reserved multicast addresses.

Table 7-1. Reserved Multicast Addresses

Address

Description

224.0.0.1

All multicast receivers on a subnet

224.0.0.2

All multicast routers on a subnet

224.0.0.5

All OSPF routers on a subnet

224.0.0.6

All OSPF designated routers on a subnet

224.0.0.9

All RIPv2 routers on a subnet

224.0.0.10

All EIGRP routers on a subnet

224.0.0.13

All Protocol Independent Multicast (PIM) routers on a subnet

224.0.0.18

All Virtual Redundancy Router Protocol

(VRRP) routers on a subnet (VRRP is a standards-based implementation of HSRP)

224.0.0.102

All Hot Standby Router Protocol (HSRP) routers on a subnet

The 224.0.0.x multicast range has a local scope. The scope of a multicast packet is basically the number of router hops the multicast is allowed to travel and is implemented using the IP TTL (time-to-live) field. A local scope means that the multicast is never forwarded by routers and is isolated to a single VLAN. If you are familiar with routing protocols, this is the reason why OSPF and EIGRP multicast communications are never forwarded off the subnet they originated in.

The other important reserved address range is 239.0.0.0 through 239.255.255.255, which is reserved for private use. This reservation is a similar concept to the RFC 1918 private IP address ranges (10.x.x.x, 172.16.x.x-172.31.x.x, and 192.168.x.x) and is designed to be used for multicast traffic that is restricted to a closed area of a private network.

Ethernet Multicast Addressing

Ethernet multicast addresses are derived directly from IP multicast addresses, as shown in Figure 7-1.

07fig01.gif

Figure 7-1 Layer 2 Multicast Addressing

Figure 7-1 shows that an Organizational Unique Identifier (OUI) of 01-00-5E is always used to allow a receiving host to identify the frame as an IP multicast (other OUIs are used to identify multicasts for other Layer 2 protocols). The first bit in the second octet (bit 24) is always 0, and the remaining low-order 23 bits are mapped directly from the first 23 low-order bits of the matching IP multicast address. With Class D IP addressing, the first four bits are always 1110, with the remaining 28 bits identifying each IP multicast group. When the conversion to Ethernet multicast addressing is performed, 5 bits from the IP multicast address (bits 24-28) are lost, which means that there are 32 (25) IP multicast addresses that map to the same Ethernet multicast address.

Internet Group Management Protocol

Multicast packets are transmitted to a particular multicast address, which represents a group of receivers interested in the packets. Internet Group Management Protocol (IGMP) facilitates the concepts of joining a group, maintaining group membership and leaving a group. IGMP exists in three versions (version 1, 2, and 3), of which version 2 is the most common. In this chapter, assume version 2 unless otherwise stated. IGMP uses several different messages that provide the following various functions:

  • Allows a receiver to join a multicast group— Facilitated by IGMP Membership Report messages
  • Allows a router to query a LAN segment for receivers that want to join a multicast group— Facilitated by IGMP General Query messages
  • Allows a receiver to notify a router that it wants to leave a multicast group— Facilitated by IGMP Leave Group messages and verified by IGMP Group-Specific Query messages.

IP Multicast Routing

IGMP deals with allowing receivers to register that they want to receive a particular multicast transmission, but does not deal with routing multicast traffic across the network from the source to each receiver. This task is left to a multicast routing protocol, several of which exist for IP networks:

  • Distance Vector Multicast Routing Protocol (DVMRP)
  • Protocol Independent Multicast (PIM)
  • Multicast OSPF (MOSPF)
  • Multicast BGP (MBGP)

Of the routing protocols listed above, PIM represents the most commonly used routing protocol used on Cisco routers.

The primary goal of IP multicast routing is to define exactly which IP subnets contain receiving hosts for a particular multicast transmission and to forward the multicast transmission only out interfaces connected to subnets that contain receivers, or out interfaces that lead to receivers connected to other multicast routers. Each multicast router determines via a multicast routing protocol which interfaces multicast traffic should be forwarded over, which builds a path or tree topology over which multicast traffic is forwarded. This tree is commonly referred to as a multicast distribution tree.

Two basic types of multicast distribution trees are used with multicast routing:

  • Source trees
  • Shared trees

Source Trees

A source tree, as the name implies, is rooted at the source of a multicast group, with a tree built from the source out to each receiver that belongs to the group. The paths that are used to deliver traffic to each receiver are the shortest possible paths between the source and receiver; hence, a source tree is also commonly known as a shortest path tree (SPT). With an SPT, the multicast tree is defined around two important parameters:

  • The source of a multicast group (S)
  • The multicast group (G)

An SPT can be identified using (S,G) nomenclature. For example, if a source with an IP address of 10.1.1.10 is sending multicast traffic to a group with an IP address of 239.1.1.1, then the SPT that is built to distribute this particular traffic can be defined as (10.1.1.10,239.1.1.1). For each unique (S,G) entity in the network, a separate SPT exists for each (S,G) entity. Understand that an STP only supports unidirectional traffic; it flows only from the source to receivers, and not vice versa. Figure 7-2 shows an SPT.

07fig02.gif

Figure 7-2 Shortest Path Trees

In Figure 7-2, the source is 10.1.1.10 and the multicast group is 239.1.1.1; hence, the SPT in Figure 7-2 can be represented as (10.1.1.10,239.1.1.1).

Shared Trees

A shared tree is a multicast distribution tree that can be shared by multiple sources for the same group. For example, if two separate sources are generating traffic for the same group, the traffic generated by each of these flows down the same shared tree. Because multiple sources share the same tree for a specific group, the (S,G) notation for a shared tree is (*,G), with the asterisk indicating any source. For example, if multiple sources are sending to a group address of 239.1.1.1, the shared tree is represented as (*,239.1.1.1).

Shared trees are not rooted at the source of a multicast group, because multiple sources can exist that use the shared tree. Instead, a shared tree is rooted at some common point in the network, which can be arbitrarily defined by an administrator. This common point is referred to as a shared root. The shared tree is built from the shared root to ensure that all receivers on the network can receive multicast traffic for the group. With a unidirectional shared tree, multicast traffic flows from the shared root across the shared tree to each receiver.

For multicast traffic to be placed upon the shared tree, each source that uses the shared tree for multicast delivery must somehow be able to deliver multicast traffic to the shared root. The multicast router locally attached to the source is responsible for ensuring that multicast traffic is forwarded to the shared root either by using a SPT, where the shared root joins an SPT rooted at the source, or by encapsulating the multicast traffic in a unicast packet and forwarding this directly to the shared root. Figure 7-3 demonstrates shared trees.

07fig03.gif

Figure 7-3 Shared Trees

In Figure 7-3, Router-A is configured as the shared root for the network, and a shared tree is built for (*,239.1.1.1) that ensures each receiver receives transmissions from any source associated with the 239.1.1.1 group. Notice that an SPT (10.1.1.10,239.1.1.1) enables the source to deliver multicast traffic to the shared root, which then forwards the traffic down the shared tree. Instead of using an SPT to ensure traffic from the source is sent to the shared root, Router-B could be configured to forward all multicast traffic encapsulated in unicast packets to the shared root.

Multicast Forwarding

A multicast distribution tree is a logical entity that is defined by the collective forwarding states of each multicast router that makes up the multicast distribution tree. Multicast routers maintain this state information in a multicast routing table, which is similar in concept to a unicast routing table, but just engineered for multicast forwarding as opposed to unicast forwarding. Each SPT (S,G) and shared tree (*,G) is defined as an entry in the multicast routing table, and each of these entries contains a forwarding state.

To build forwarding state for a particular multicast route entry, each router defines the following:

  • Incoming interface
  • Outgoing interface

The incoming interface defines the closest interface on the router to the source (S), which represents the interface on which multicast traffic should (and must) be received from the source. Depending on the multicast routing protocol in use, a multicast router might use the multicast routing protocol's own mechanism to determine the closest interface to the source (e.g., DVMRP) or might rely on the unicast routing table (e.g., PIM).

The incoming interface is determined using what is known as a reverse path forwarding (RPF) check. For example, with the PIM multicast routing protocol, when a multicast packet arrives on an interface, the source IP address is examined against the unicast IP routing table. The outgoing interface associated with the source IP address is determined, and if this is the same interface that the multicast packet was received on, the multicast router knows that the packet has arrived via the shortest path to the source. At this point, the multicast packet is said to have passed the RPF check.

Any multicast packet that passes the RPF check is accepted for subsequent multicast routing; any multicast packet that does not pass the RPF check (i.e., is received on an interface that is not the closest interface to the source) is dropped. The RPF check is primarily designed to prevent multicast routing loops from forming in the network, as demonstrated in Figure 7-4.

07fig04.gif

Figure 7-4 Preventing Multicast Routing Loops

In Figure 7-4, multicast traffic is being sent from a source attached to Router-A. When a packet arrives from the source on Ethernet0/0, an RPF check takes place. The source IP address of the multicast packet (10.1.1.10) is examined against the unicast routing table, with the outgoing interface associated with the source IP address found to be the same interface (Ethernet0/0) that the packet arrived on. This means that the RPF check succeeds, and the multicast traffic is accepted and forwarded appropriately. Notice that the packet then is forwarded to Router-B and then to Router-C. Router-C then forwards the multicast packet back to Router-A. At this point, Router-A performs an RPF check on the same IP address of the original packet (10.1.1.10). This time, it is determined that the packet has arrived on a different interface than that listed in the unicast routing table; hence, the RPF check fails and the multicast packet is dropped. Note that if Router-A accepted this packet for forwarding, a multicast routing loop would form. The RPF check ensures multicast routing loops don't form.

Once a multicast packet passes an RPF check (i.e., it is received on the interface that is defined as the incoming interface for the (S,G) STP or (*,G) shared tree), it must be forwarded appropriately. The outgoing interface list defines which interfaces a multicast packet should be forwarded out to ensure that the network forwards multicast packets to all receivers. This list is built using both IGMP (which indicates any local receivers attached to local interfaces) and the multicast routing protocol configured for the network (which indicates any receivers attached to remote multicast routers). Once the list is built, any multicast packets received that match a specific (S,G) or (*,G) route entry and pass an RPF check are forwarded out the outgoing interface list.

Figure 7-5 demonstrates how a multicast router forwards multicast traffic. In Figure 7-5, take a close look at the multicast distribution tree and Router-B. You can see that multicast traffic generated by the source is received on interface Fa0/1 on Router-B. This interface is defined as the incoming interface because multicast packets are received on this interface. Notice that Router-B must forward multicast packets received out interface Fa0/2 and interface Fa0/3 to ensure that the two receivers located further downstream receive multicast traffic. Because there are no receivers or downstream multicast routers attached to interface Fa0/5, Router-B does not need to forward multicast traffic out this interface. The outgoing interface list, therefore, consists of interface Fa0/2 and interface Fa0/3.

07fig05.gif

Figure 7-5 Multicast Forwarding

Multicast on the LAN

Multicast routing gets the traffic for a particular multicast group to only the Layer 2 segments that need to receive the group traffic. Once the multicast transmission is on the Layer 2 network, multicast routing has no control over which Layer 2 links or ports the transmission is sent to. This control is left to the Layer 2 device (such as a switch) that interconnects the segment.

Ideally, the Layer 2 device should forward the multicast transmission only out ports to which receivers are connected and also out any ports that are connected to downstream multicast routers. This configuration requires a Layer 2 device to be able to determine the ports on which multicast routers and receivers for each separate (S,G) or (*,G) multicast group are located. To facilitate intelligent forwarding of multicast traffic on the LAN, Cisco Catalyst switches support two mechanisms:

  • IGMP snooping— The switch listens in or "snoops" IGMP communications between receivers and multicast routers. This snooping enables the switch to determine which ports are connected to receivers for each multicast group and which ports are connected to multicast routers.
  • Cisco Group Management Protocol (CGMP)— The switch communicates with multicasts routers, with multicast routers relaying group membership information to switches.

Once a switch has learned the appropriate port information, the Layer 2 bridging table is updated for the each Ethernet multicast MAC address to include the ports associated with all multicast routers on the LAN and each receiver that belongs to each group represented by a specified multicast MAC address.

Multicast Routing Performance Considerations on Cisco Catalyst Layer 3 Switches

Cisco Catalyst Layer 3 switches are designed to route IP packets at high performances, so the mechanisms used by Cisco Catalyst Layer 3 switches to forward IP multicast traffic must be understood to determine how multicast routing impacts on Layer 3 switching. To ensure that multicast traffic does not have a negative effect on the network, Cisco Catalyst Layer 3 switches all perform hardware-based Layer 3 switching of multicast traffic, ensuring wire-speed performance for such traffic.

If you think about the differences between unicast traffic and multicast traffic, you should be able to quickly realize that it is much more difficult for a Layer 3 switch to route multicast traffic in hardware. For example, unicast routing requires only knowledge of the destination IP address of packets, whereas multicast routing requires knowledge of both the source and destination IP address (S,G). To further complicate things, Layer 3 switches that also provide Layer 2 functions for VLANs with receivers attached must also ensure that traffic is forwarded only out ports with receivers attached if IGMP snooping is enabled.

The various Cisco Catalyst Layer 3 switching platforms vary in their approach as to the specifics of how they implement Layer 3 switching of multicast traffic. The end result is that Cisco Catalyst Layer 3 switches not only forward unicast traffic in hardware, but also multicast traffic as well. This forwarding ensures that you can run multicast applications on top of Layer 3 switching infrastructure without any performance degradations.

+ Share This