![[previous]](../../../graphics/l_arrow.gif){kind=icon}
![[next]](../../../graphics/r_arrow.gif){kind=icon}
This chapter provides conceptual information, configuration options, and implementation guidelines for IP multicast routing on Switch 4007 Multilayer Switching Modules. This chapter covers these topics:
You can manage IP multicast routing parameters from the ip multicast menu in the Administration Console of Multilayer Switching Modules. See the Switch 4007 Command Reference Guide.
The management interfaces display "cb9000" and refer to the Management Module as the Enterprise Management Engine (EME) because the heritage of the Switch 4007 is the CoreBuilder® 9000 switch.
Switch 4007 Multilayer Switching Modules use two protocols to support IP multicast routing: the Internet Group Management Protocol (IGMP) and the Distance-Vector Multicast Routing Protocol (DVMRP). IGMP is also supported on Layer 2 Switching Modules, but that implementation is described in Chapter 11.
The easiest way to begin to understand multicasting is to compare it against two other address types and their communication models.
A unicast address is designed to transmit a packet from a source to a single destination. Unicast transmissions are for one-to-one communication. If multiple users need to receive the same communication, the source operating in unicast mode generates and sends each copy separately.
A broadcast address is used to send a datagram from a source to multiple destinations - an entire subnetwork, for example. Broadcast transmissions produce one-to-many communication, but some of the receivers may not want or need to receive the communication.
A multicast address is used for one-to-many and many-to-many communication in an environment where users and network devices either explicitly or implicitly communicate their desire to receive the communication.
In contrast to unicast, a source that uses IP multicast generates and sends only one copy of the information that is desired by multiple receivers. At point where the delivery path that reaches group members diverges, network devices replicate and forward the packets. This approach makes efficient use of both source processing power and network bandwidth.
When using the Internet Protocol (IP) as the basis for multicast communication, the requests for and delivery of the communication is fundamentally controlled by referencing certain IP addresses or their MAC-based equivalents. These addresses are called group addresses or groups and hosts that reference these addresses are called group members.
IP multicast group members can be scattered across multiple subnetworks; thus, successful transmission from a source to group members can occur within a campus LAN, a MAN, or over a WAN.
As an extension to the standard IP network-level protocol, IP multicast was first defined in 1985 in RFC 966. Certain other protocols are used to support IP multicast processes. These are explained later in this chapter.
New applications that are designed to increase productivity within and across organizations are driving the need for network infrastructures to support IP multicast. When the application content is time-sensitive or requires significant bandwidth (for example, a video stream), the IP multicast process provides an efficient delivery mechanism.
The business benefits of using IP multicast are that it:
To support IP multicast, the sending and receiving nodes, as well as the network infrastructure between them, must be multicast-enabled. Specifically, there must be cohesive support for IP multicast in the following components: TCP/IP protocol stack, operating systems, application software, NICs, and Layer 3 devices. Support for IP multicast in Layer 2 devices is not required by the standard, but is desirable, as explained later in this section.
IP multicast transmissions fundamentally depend on multicast-enabled Layer 3 devices (traditional routers or Layer 3 switches; hereafter both are called routers) to direct packets on an efficient path from sources to destinations.
As shown in Figure 50, routers that support IP multicast must accomplish two important tasks:
Figure 50 IP Multicast Communication Processes
To communicate with other routers, Switch 4007 Multilayer Switching Modules support the Distance-Vector Multicast Routing Protocol (DVMRP) version 3.6. DVMRP functions and configuration options are explained later in this chapter.
To communicate with group members on directly attached subnetworks, Switch 4007 Multilayer Switching Modules support the Internet Group Management Protocol (IGMP) version 1 and version 2. IGMP functions are covered later in this chapter.
IP multicast routers are key connection points for delivering IP multicast traffic between sources and multicast group members. In the event that some routers in your network only transmit unicast packets, you can configure a transitional technique called tunneling to extend the service area. Tunnels provide a virtual point-to-point link between two multicast routers, where the path between them includes one or more routers that do not support multicast routing (unicast routers).
Figure 51 DVMRP Tunnel Example
Figure 51 depicts a network configuration that requires an tunnel in order for the PC to receive the IP multicast application. The multicast routers support DVMRP, thus the tunnel is also configured with that protocol.
A multicast router is required at each end of the tunnel. At each tunnel entrance, the router encapsulates the IP multicast packets in standard IP unicast packets - that is, it puts them in a format that the unicast routers can understand. When these packets reach the end of the tunnel, the router strips the encapsulation away and returns the packet to its native IP multicast format.
Switch 4007 Multilayer Switching Modules use the Distance-Vector Multicast Routing Protocol (DVMRP) to form IP multicast tunnels. Specific aspects of tunnel configuration are described later in this chapter.
When a router discovers that at least one IP multicast group member resides on a directly attached subnetwork, it forwards group traffic on that interface until it determines that group members no longer require the traffic. If multiple ports are configured in an interface, a router sends copies of the group traffic to all ports, even if only one port of those ports leads to group members. This is because the multicast routing protocol does not track exactly where group members reside on that interface.
The ability to filter IP multicast traffic on ports within a routing interface that do not lead to group members is highly desirable (although it is not required in the IP multicast standard) because it allows you to further optimize the LAN environment. Through targeted filtering, a router can conserve even more network bandwidth and minimize unnecessary interruptions to endstation CPUs.
It is also important to have a similar IP multicast filtering capability in Layer 2 switches. See Chapter 11 to learn about this capability in Switch 4007 Layer 2 Switching Modules.
Your module supports the Internet Group Management Protocol (IGMP) version 1 and version 2. to track exactly which ports in an interface require IP multicast group traffic. IGMP covers two main functions: querying and snooping. These are explained later in this chapter.
The MBONE is the Internet's experimental multicast backbone network. It is an interconnected set of Internet routers, subnetworks, and tunnels that support the delivery of IP multicast traffic.
The MBONE was first configured in 1992 as a test zone to enable IP multicast applications to be deployed without waiting for multicast routers to replace unicast routers across the entire Internet. The MBONE is actually a virtual network located within portions of the physical Internet. Its construction reflects several multicast zones connected together via IP multicast tunnels. When it was created in 1992, the MBONE spanned four countries and 40 subnetworks; today it spans over 25 countries and thousands of subnetworks.
You can connect to the MBONE through most Internet service providers (ISPs). You can use it to test multicast applications and technology or to connect private multicast LANs. Some organizations broadcast public information over the MBONE; examples include IETF (Internet Engineering Task Force) meetings and NASA (National Aeronautics and Space Administration, United States) space shuttle launches.
This section describes several terms and concepts related to IP multicast routing.
Application sources generate the majority of IP multicast packets, but group members and routers that are communicating (DVMRP and IGMP messages) to establish the delivery path also generate IP multicast packets.
Traffic from application sources always travels in one direction - downstream from the source to group members. Using various protocols, network devices are responsible for determining where group members exist and coordinating a loop-free delivery path from the source to them.
Traffic that relates to the delivery path can travel both upstream and downstream - between routers and between routers and group members.
Users can join or leave an IP multicast group at any time. Users request and cancel membership through mechanisms built into their desktop application - perhaps visible to the user as Go and Quit buttons. There are no restrictions on the physical location or number of members in a group. A user may belong to one or more groups at any time.
Each IP multicast transmission can be linked to a unique pairing of a source address and multicast group address (destination address). In addition, network devices form a unique delivery path for each source-group pair. Multicast routers and switches track information about each source-group pair - mainly, the location of group members - and dynamically adjust the delivery path to ensure that IP multicast packets are delivered only where they need to go.
A multicast packet differs from a unicast packet by the presence of a multicast group address in the destination address field of the IP header. IP multicast uses a Class D destination address format, which has the high-order four bits set to 1-1-1-0 followed by a 28-bit multicast group identifier.
The Internet Assigned Numbers Authority (IANA) maintains a list of registered IP multicast groups. Expressed in standard dotted decimal notation, group addresses range from 224.0.0.0 - 239.255.255.255 and are classified by IANA as follows:
http://www.iana.org
IANA also controls a reserved portion of the IEEE-802 MAC-layer multicast address space. All addresses in this block use hexadecimal format and begin with 01-00-5E. A simple procedure maps Class D addresses to this block, so that IP multicasting can take advantage of the hardware-level multicasting supported by network interface cards (NICs).
The mapping process involves placing the low-order 23 bits of the Class D address (binary format) into the low-order 23 bits of the MAC address (hexadecimal format). For example, the Layer 3 address 224.10.8.5 maps to the Layer 2 MAC address 01-00-5E-0A-08-05.
To send a multicast packet, a source station inserts the Class D address in the IP packet, the network interface card maps that address to a IEEE-802 Ethernet multicast MAC address, and sends the frame. A host that wants to receive packets that are addressed to this group notifies its IP layer as such.
IGMP provides a way for routers and switches to learn where group members exist on a network, and thus provides a critical function in the IP multicast packet delivery process.
On each subnetwork or broadcast domain (VLAN), the communication between routers, switches, and group members begins with one IGMP-capable device being elected as the querier - that is, the device that asks all hosts to respond with a report of the IP multicast groups that they wish to join or to which they already belong. The querier is always the device with the lowest IP address in the subnetwork. It can be a router or a Layer 2 switch. The network traffic flows most efficiently if the querier is the closest device to the sources of IP multicast traffic.
The querier normally sends messages called IGMP Host Membership Query Messages, or queries, every 125 seconds. All the hosts hear the query because it is addressed to 224.0.0.1, the all systems on this subnetwork Class D address. A query is not forwarded beyond the subnetwork from which it originates.
Hosts use IGMP to build their own types of IP multicast messages, as described in this section.
Hosts respond to queries with IGMP Host Membership Report messages, or simply IGMP reports. These reports do not travel beyond their origin subnetworks, and hosts send them at random intervals to prevent the querier from being overwhelmed.
A host sends a separate report for each group that it wants to join or to which it currently belongs. Hosts do not send reports if they are not group members.
If a router does not receive at least one host report for a particular group after two queries, the router assumes that members no longer exist and it prunes the interface for that source-group spanning tree.
Rather than wait for a query, a host can also send an IGMP report on its own initiative to inform the querier that it wants to begin receiving a transmission for a specific group (perhaps by clicking a Go or Start button on the client interface). This is called a join message. The benefit is faster transmission linkages, especially if the host is the first group member on the subnetwork.
Leave-group messages are a type of host message defined in IGMP version 2. If a host wants to leave an IP multicast group, it issues a leave-group message addressed to 224.0.0.2, the all routers in this subnetwork Class D address. Upon receiving such a message, the querier determines whether that host is the last group member on the subnetwork by issuing a group-specific query.
Leave-group messages lower leave latency - that is, the time between when the last group member on a given subnetwork sends a report and when a router stops forwarding traffic for that group onto the subnetwork. This process conserves bandwidth. The alternative is for the router to wait for at least two queries to go unanswered before pruning that subnetwork from the delivery tree.
To further refine the IP multicast delivery process and maximize bandwidth efficiency, a Layer 3 module filters IP multicast packets on appropriate ports using a process called IGMP snooping. Both bridged interfaces and routed interfaces record which ports receive host IGMP reports and then set their filters accordingly so that IP multicast traffic for particular groups is not forwarded on ports or VLANs that do not require it.
DVMRP is a distance-vector routing protocol that allows routers to establish shortest-path, source-rooted, IP multicast delivery trees. While it is similar to the Routing Information Protocol (RIP), one important difference is that DVMRP focuses on the previous hop back to a multicast source, not the next hop to a destination. Multicast routers are concerned with moving packets away from the source on a loopless path so that multicast storms do not occur.
DVMRP version 3.x uses the Reverse Path Multicast (RPM) algorithm to construct a delivery tree that begins at the source and spans out to reach group members on a loopless path through the network. Hence, DVMRP seeks to form a source-rooted spanning tree for each source-group pair. The shape of each tree changes dynamically, depending on the location of hosts that join and leave the group. As shown in Figure 52, any routing interface that contains group members is called a leaf interface.
Figure 52 Sample IP Multicast Spanning Tree
The term spanning tree applies to any loopless graph that spans intelligent nodes. The DVMRP spanning tree structure provides only one active path to connect any two multicast routers in the network. This approach provides a logical, efficient path to reach group members and prevents multicast storms from decreasing network performance.
The Spanning Tree Algorithm that is specified in the IEEE 802.1D MAC Bridges base standard is a different implementation of the spanning tree concept; it is not used with IP multicast.
RPM uses three main techniques to dynamically adjust the shape of an IP multicast spanning tree: broadcasting, pruning, and grafting. These techniques balance the goal of an efficient delivery path with the goal of effective service for all potential group members. Figure 53 shows the broadcasting, pruning, and grafting processes.
Figure 53 RPM Techniques for Managing the Multicast Spanning Tree
The interface on which a router receives source-origin traffic for a given source-group pair is called the incoming or parent interface. Each interface over which the router forwards source-group traffic is called an outgoing or child interface. A child interface on one router can:
The first packet for any source-group pair is broadcast across the entire network, as far as packet time-to-live (TTL) and router TTL thresholds permit. If a packet arrives on an interface that the router determines to be the shortest path back to the source (by comparing interface metrics), then the router forwards the packet on all interfaces except the incoming interface. Downstream routers quickly send either:
Some IP multicast applications try to actively send traffic on the network, even if no group members are requesting their traffic. Your module can detect which ports lead to routers and send these infrequent broadcast packets only to those ports. Otherwise, the module filters all IP multicast group traffic for which it has received no IGMP Reports or graft messages.
A parent interface transmits a prune message to its upstream neighboring router if there are no group members on its child interfaces. A prune message directs the upstream router not to forward packets for a particular source-group pair in the future. Prune messages always affect the entire routing interface; they cannot be targeted to prune individual port segments that belong to an interface (IGMP snooping effectively achieves this, however).
Prune messages always begin at the leaf routers and are sent one hop back toward the source. Each successive router determines whether to prune its connections.
Inside the prune message is a prune lifetime, or prune timer, which is a period of time for which the prune message is valid. When the prune lifetime expires, the interface is added back into the multicast delivery tree - that is, until it generates another prune message.
Even though routers must use memory to store membership and prune information, this approach regains the bandwidth that would have been wasted on branches that do not lead to group members.
If a router that has previously sent a prune message discovers a new group member (from IGMP Reports) on one of its connections, it sends a graft message to the previous hop router. When an upstream router receives this message, it cancels the prune message it previously received. Hop by hop, graft messages cascade back toward the source until they reach the nearest live branch point on the IP multicast spanning tree.
All DVMRP interfaces and DVMRP tunnels have two characteristics: a metric that specifies the cost for the interface and a time-to-live (TTL) threshold.
In all cases where the multicast router drops multicast packets, the router does not provide an error notification to the source because IP multicast is a connection-less technology.
A Switch 4007 Multilayer Switching Module needs to have IP multicast routing features enabled only if network users that sit downstream of the module (from the perspective of the source location) require access to IP multicast application traffic.
To activate IP multicast routing and filtering capabilities in a Multilayer Switching Module, follow this general procedure:
1 . Configure VLANs and IP routing interfaces on the module. See Chapter 14 for more information about VLANs. See Chapter 16 for more information about IP routing.
2 . Ensure that IGMP snooping and querying functions are enabled on the module.
To figure IGMP functions on Switch 4007 Layer 2 Switching Modules, see Chapter 11 in this guide.
3 . Enable DVMRP on each interface that is to perform IP multicast routing.
4 . If your network requires a multicast tunnel and if a Multilayer Switching Module is to going to serve as one or more tunnel endpoints, configure the tunnels now. (Remember to configure the tunnels on the remote systems as well.)
5 . Configure a default route on an interface (if applicable to your network).
6 . View the various displays, routing table and cache to see how the module is processing IP multicast traffic.
7 . Use the traceroute option for troubleshooting or to determine the traffic paths.
As described in Chapter 9, you can use the bridge port multicastLimit option to set per-port multicast limits. This optional feature can prevent segments of your network from being adversely affected by multicast or broadcast storms. If network users have trouble receiving IP multicast application traffic, verify that bridge ports are not configured with a bridge port multicast limit that is too low.
Multicasting in 802.1Q VLAN tagging environments may have performance implications for a Multilayer Switching Module. Specifically, if you have multiple VLANs associated with a single port, the module is forced to replicate multicast packets to each VLAN that has multicast group members, even if the path to reach the members is the same physical link. To achieve wirespeed multicast performance, 3Com recommends that you configure only one VLAN per port. Contact your 3Com representative about network design options.
Routing protocols other than DVMRP exist to support IP multicast functions. Interoperability issues between these routing protocols mean that you should plan your routing infrastructure carefully. Contact your 3Com representative for more information.
You can enable or disable IGMP snooping and querying functions, set the interface time-to-live (TTL) threshold, and obtain summary and detail displays of IGMP-related information.
Your Multilayer Switching Module divides IGMP functions into two modes:
DVMRP is the protocol used to develop source-rooted spanning trees between routers in the network. You can enable or disable DVMRP on individual routing interfaces.
Table 79 lists conventional numeric values and network objectives.
A DVMRP tunnel allows IP multicast packets to traverse a portion of your network infrastructure that is not multicast-aware. In Multilayer Switching Modules, you can define tunnels, modify tunnel characteristics, display information about tunnels you have defined, and remove tunnels.
You can configure a default route for IP multicast traffic on any DVMRP routing interface in the module.
If an interface is configured as a default route, it advertises source 0.0.0.0 to neighboring DVMRP routers. In their DVMRP routing tables, these neighboring routers list 0.0.0.0 as a source and list the advertising router interface as the gateway to reach that source.
Thus, if a neighboring router receives an IP multicast packet for which it has no normal routing information in its routing table, instead of filtering the packet, the router forwards it to the router which advertises the default route.
To configure a default route on an interface, you
Specify a value from 1 through 32 to signify the cost of the route.
There are two options:
Your module records DVMRP route information in a table that you can access from the management interface. Your module learns source-based route information from neighboring DVMRP routers and also advertises routes that it learns to its neighbors. The routing table does not consider group membership or prune messages. It simply records path information it has learned on its own or from other routers, including:
The module may never actually process IP multicast traffic from the sources listed in the routing table. This depends on whether group members exist on directly-attached subnetworks or on subnetworks from downstream routers.
See the Command Reference Guide for definitions of the fields of information and symbols used in the DVMRP route display.
Your module records information about the IP multicast group traffic it has processed. You can see this information in the DVMRP cache.
To display the DVMRP cache, the module prompts you to enter:
This process limits the cache table to displaying information for one source-group pair at a time. To display cache information for all source-group pairs, enter 255.255.255.255 at both prompts.
See the Command Reference Guide for definitions of the fields of information and symbols used in cache display.
You can perform an IP multicast traceroute from a Layer 3 module. The ability to trace the path of a IP multicast group packet from a source to a particular destination is desirable for troubleshooting purposes.
Unlike unicast traceroute, IP multicast traceroute requires the ability for routers to understand a special IGMP packet type and the related processes.
Beginning a trace from an IP multicast source would be difficult because, at forks in the network paths, there is no way to determine which direction to take. You would have to flood the entire tree and wait for responses (or the lack thereof) to find the path. Thus, a more efficient approach is to start at the destination and travel backwards toward the source, using the knowledge held by IP multicast routing protocols that work by calculating previous hops back toward sources.
An IP multicast traceroute proceeds as follows:
1 . At the destination node (your module), you specify a source and group address.
2 . The module sends a traceroute Query packet to the last-hop multicast router (the upstream router for this source-group pair).
3 . The last-hop router turns the Query packet into a Request packet by adding a response data block containing its interface addresses and packet statistics. It then forwards the Request packet via unicast to the router that it believes is the previous hop for the given source-group pair.
4 . Each previous hop router adds its response data to the end of the Request packet, then forwards it via unicast to the next previous hop router.
5 . Finally, the first-hop router - that is, the router that believes that the source-group packets originate on one of its directly-attached subnetworks - adds its data, changes the Request packet to a Response packet, and sends the completed response back to the destination node that issued the traceroute query.
6 . You see a display that shows IP addresses of the interfaces that span from your module back to the source that you specify. The display also shows the number of hops back to those interfaces, the multicast routing protocols used, and the amount of time it takes to reach each hop from the receiver.
DVMRP was first defined in RFC 1075 and has been modified in various Internet drafts. IGMP was first defined in RFC 1112 and has been modified in various Internet drafts. To learn more about DVMRP and IGMP, IP multicast technology, or related events, consult the following Web resources: