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:
The following topics are now introduced to ensure that you are familiar with fundamental multicast concepts:
Multicast AddressingFor 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 AddressingFor 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.
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 AddressingEthernet multicast addresses are derived directly from IP multicast addresses, as shown in Figure 7-1. 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 ProtocolMulticast 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:
IP Multicast RoutingIGMP 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:
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. NOTE Cisco routers and Cisco Catalyst Layer 3 switches both support multicast routing, and either type of device may be represented as a multicast router in this chapter. Two basic types of multicast distribution trees are used with multicast routing:
NOTE Another less common type of multicast distribution tree used is called a Core-Based Tree (CBT). Discussion of this distribution tree is outside the scope of this book. Source TreesA 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:
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. 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 TreesA 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. 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. NOTE One important advantage of a shared tree over an SPT is that a shared tree can be either unidirectional or bidirectional. A bidirectional tree enables traffic to be sent either up or down a shared tree. In Figure 7-3, a bidirectional tree means that multicast traffic generated from the source and received at Router-B can be immediately forwarded to Router-X as well as forwarded to Router-A, instead of having to forward the traffic only to Router-A, which then simply forwards the traffic down the shared tree to Router-B if the tree is unidirectional. Multicast ForwardingA 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:
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. Figure 7-4. Preventing Multicast Routing Loops
NOTE For SPT (S,G) entries, the incoming interface is defined as the closest interface to the source (S). For shared tree (*,G) entries, no incoming interface can be defined based upon a source (as a shared tree can be shared by multiple sources). Instead, the incoming interface is defined as the closest interface to the shared root. 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. Figure 7-5. Multicast Forwarding
Multicast on the LANMulticast 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:
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. NOTE To control multicast bandwidth usage, you can use a feature called multicast/broadcast control, where multicast and broadcast traffic on a port that exceeds a configurable threshold over a defined time interval is dropped. This feature is considered a legacy and can have serious side effects. For example, a large multicast stream may reach the allowable multicast/broadcast threshold on a port. After this point, all multicasts and broadcasts are dropped (including crucial spanning tree BPDUs), which can cause network instability. For this reason, it is recommended that you don't use multicast/broadcast control in an attempt to reduce the bandwidth usage of multicast traffic. Multicast Routing Performance Considerations on Cisco Catalyst Layer 3 SwitchesCisco 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. |
EAN: 2147483647
Pages: 135