Table Of Contents
Configuring IP Multicast Routing
The Cisco Implementation of IP Multicast Routing
Basic IP Multicast Routing Configuration Task List
Advanced IP Multicast Routing Configuration Task List
Configuring a Rendezvous Point
Setting Up Auto-RP in a New Internetwork
Adding Auto-RP to an Existing Sparse-Mode Cloud
Announcing the RP and the Group Range It Serves
Assigning the RP Mapping Agent
Verifying the Group-to-RP Mapping
Preventing Join Messages to False RPs
Filtering Incoming RP Announcement Messages
Configuring a Router to Be a Member of a Group
Controlling Access to IP Multicast Groups
Modifying the IGMP Host-Query Message and Query Timeout Intervals
Routers That Run IGMP Version 1
Routers That Run IGMP Version 2
Changing the Maximum Query Response Time
Configuring the Router as a Statically Connected Member
Disabling Fast Switching of IP Multicast
Configuring sdr Listener Support
Limiting How Long an sdr Cache Entry Exists
Configuring Basic DVMRP Interoperability Features
Configuring DVMRP Interoperability
Advertising Network 0.0.0.0 to DVMRP Neighbors
Enabling the Functional Address for IP Multicast over
Token Ring LANsPIM Version 2 Configuration Tasks
Configuring PIM Version 2 Only
Configuring PIM Sparse-Dense Mode
Defining the PIM Domain Border
Defining the IP Multicast Boundary
Transitioning to PIM Version 2
Deciding When to Configure a BSR
Monitoring the RP Mapping Information
Configuring Advanced PIM Features
Understanding PIM Shared Tree and Source Tree (Shortest Path Tree)
Delaying the Use of PIM Shortest Path Tree
Understanding Reverse-Path Forwarding (RPF)
Assigning an RP to Multicast Groups
Modifying the PIM Router-Query Message Interval
Enabling PIM Nonbroadcast Multiaccess (NBMA) Mode
Configuring Advanced DVMRP Interoperability Features
Enabling DVMRP Unicast Routing
Limiting the Number of DVMRP Routes Advertised
Changing the DVMRP Route Threshold
Configuring a DVMRP Summary Address
Disabling DVMRP Autosummarization
Adding a Metric Offset to the DVMRP Route
Rejecting a DVMRP Nonpruning Neighbor
Configuring a Delay Between DVRMP Reports
Configuring an IP Multicast Static Route
Controlling the Transmission Rate to a Multicast Group
Configuring RTP Header Compression
Enabling RTP Header Compression on a Serial Interface
Enabling RTP Header Compression with Frame Relay Encapsulation
Changing the Number of Header Compression Connections
Enabling Express RTP Header Compression
Configuring IP Multicast over ATM Point-to-Multipoint
Virtual CircuitsEnabling IP Multicast over ATM Point-to-Multipoint VCs
Limiting the Number of Virtual Circuits
Configuring an IP Multicast Boundary
Configuring an Intermediate IP Multicast Helper
Configuring Stub IP Multicast Routing
Load Splitting IP Multicast Traffic Across Equal-Cost Paths
Configuring the Router at the Opposite End of the Tunnel
Configuring Both Routers to RPF
Load Splitting to a Stub Network
Load Splitting to the Middle of a Network
Monitoring and Maintaining IP Multicast Routing
Clearing Caches, Tables, and Databases
Displaying System and Network Statistics
IP Multicast Configuration Examples
DVMRP Interoperability Example
RTP Header Compression Examples
Express RTP Header Compression with PPP Encapsulation Example
Express RTP Header Compression with Frame Relay Encapsulation Example
IP Multicast over ATM Point-to-Multipoint VC Example
Functional Address for IP Multicast over Token Ring LAN Example
Border Router Configuration Example
Administratively Scoped Boundary Example
Load Splitting IP Multicast Traffic Across Equal-Cost Paths Example
Configuring IP Multicast Routing
This chapter describes how to configure IP multicast routing. For a complete description of the IP multicast routing commands in this chapter, refer to the "IP Multicast Routing Commands" chapter of the Cisco IOS IP and IP Routing Command Reference publication. To locate documentation of other commands in this chapter, use the command reference master index or search online.
Traditional IP communication allows a host to send packets to a single host (unicast transmission) or to all hosts (broadcast transmission). IP multicast provides a third scheme, allowing a host to send packets to a subset of all hosts (group transmission). These hosts are known as group members.
Packets delivered to group members are identified by a single multicast group address. Multicast packets are delivered to a group using best-effort reliability, just like IP unicast packets.
The multicast environment consists of senders and receivers. Any host, regardless of whether it is a member of a group, can send to a group. However, only the members of a group receive the message.
A multicast address is chosen for the receivers in a multicast group. Senders use that address as the destination address of a datagram to reach all members of the group.
Membership in a multicast group is dynamic; hosts can join and leave at any time. There is no restriction on the location or number of members in a multicast group. A host can be a member of more than one multicast group at a time.
How active a multicast group is and what members it has can vary from group to group and from time to time. A multicast group can be active for a long time, or it may be very short-lived. Membership in a group can change constantly. A group that has members may have no activity.
Routers executing a multicast routing protocol, such as Protocol-Independent Multicast (PIM), maintain forwarding tables to forward multicast datagrams. Routers use the Internet Group Management Protocol (IGMP) to learn whether members of a group are present on their directly attached subnets. Hosts join multicast groups by sending IGMP report messages.
Many multimedia applications involve multiple participants. IP multicast is naturally suitable for this communication paradigm.
The Cisco Implementation of IP Multicast Routing
The Cisco IOS software supports the following protocols to implement IP multicast routing:
•
Internet Group Management Protocol (IGMP) is used between hosts on a LAN and the router(s) on that LAN to track the multicast groups of which hosts are members.
•
•
•
Figure 50 shows where these protocols operate within the IP multicast environment. The protocols are further described after the figure.
Figure 50 IP Multicast Routing Protocols
IGMP
To start implementing IP multicast routing in your campus network, you must first define who receives the multicast. IGMP provides a means to automatically control and limit the flow of multicast traffic throughout your network with the use of special multicast queriers and hosts.
•
•
A set of queriers and hosts that receive multicast data streams from the same source is called a multicast group. Queries and hosts use IGMP messages to join and leave multicast groups.
IP multicast traffic uses group addresses, which are Class D IP addresses. The high-order four bits of a Class D address are 1110. Therefore, host group addresses can be in the range 224.0.0.0 to 239.255.255.255.
Multicast addresses in the range 224.0.0.0 to 224.0.0.255 are reserved for use by routing protocols and other network control traffic. The address 224.0.0.0 is guaranteed not to be assigned to any group.
IGMP packets are transmitted using IP multicast group addresses as follows:
•
•
•
•
–
IGMP Versions
IGMP messages are used primarily by multicast hosts to signal their interest in joining a specific multicast group and to begin receiving group traffic.
The original IGMP Version 1 Host Membership model defined in RFC 1112 is extended to significantly reduce leave latency and provide control over source multicast traffic by use of Internet Group Management Protocol, Version 2.
•
Provides for the basic Query-Response mechanism that allows the multicast router to determine which multicast groups are active and other processes that enable hosts to join and leave a multicast group. RFC 1112 defines Host Extensions for IP Multicasting.
•
Extends IGMP allowing such features as the IGMP leave process, group-specific queries, and an explicit maximum query response time. IGMP Version 2 also adds the capability for routers to elect the IGMP querier without dependence on the multicast protocol to perform this task. RFC 2236 defines Internet Group Management Protocol, Version 2.
PIM
The PIM protocol maintains the current IP multicast service mode of receiver-initiated membership. It is not dependent on a specific unicast routing protocol.
PIM is defined in RFC 2362, Protocol-Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. PIM is defined in the following Internet Engineering Task Force (IETF) Internet drafts:
•
•
•
•
•
PIM can operate in dense mode or sparse mode. It is possible for the router to handle both sparse groups and dense groups at the same time.
In dense mode, a router assumes that all other routers want to forward multicast packets for a group. If a router receives a multicast packet and has no directly connected members or PIM neighbors present, a Prune message is sent back to the source. Subsequent multicast packets are not flooded to this router on this pruned branch. PIM builds source-based multicast distribution trees.
In sparse mode, a router assumes that other routers do not want to forward multicast packets for a group, unless there is an explicit request for the traffic. When hosts join a multicast group, the directly connected routers send PIM Join messages toward the rendezvous point (RP). The RP keeps track of multicast groups. Hosts that send multicast packets are registered with the RP by that host's first-hop router. The RP then sends Join messages toward the source. At this point, packets are forwarded on a shared distribution tree. If the multicast traffic from a specific source is sufficient, the receiver's first-hop router may send Join messages toward the source to build a source-based distribution tree.
DVMRP
Cisco routers run PIM, and know enough about Distance Vector Multicast Routing Protocol (DVMRP) to successfully forward multicast packets to and receive packets from a DVMRP neighbor. It is also possible to propagate DVMRP routes into and through a PIM cloud. The Cisco IOS software propogates DVMRP routes and builds a separate database for these routes on each router, but PIM uses this routing information to make the packet-forwarding decision. The Cisco IOS software does not implement the complete DVMRP.
DVMRP builds a parent-child database using a constrained multicast model to build a forwarding tree rooted at the source of the multicast packets. Multicast packets are initially flooded down this source tree. If redundant paths are on the source tree, packets are not forwarded along those paths. Forwarding occurs until Prune messages are received on those parent-child links, which further constrain the broadcast of multicast packets.
DVMRP is implemented in the equipment of many vendors and is based on the public-domain mrouted program.
The Cisco IOS software supports dynamic discovery of DVMRP routers and can interoperate with them over traditional media (such as Ethernet and FDDI), or over DVMRP-specific tunnels.
CGMP
CGMP is a protocol used on routers connected to Cisco Catalyst switches to perform tasks similar to those performed by IGMP. CGMP is necessary for those Catalyst switches that cannot distinguish between IP multicast data packets and IGMP Report messages, which are both MAC-level addressed to the same group address.
Basic IP Multicast Routing Configuration Task List
The IP multicast routing tasks are divided into basic and advanced tasks, which are discussed in the following sections. The first two basic tasks are required to configure IP multicast routing; the remaining basic and advanced tasks are optional.
•
•
•
•
•
•
Advanced IP Multicast Routing Configuration Task List
Advanced, optional IP multicast routing tasks are described in the following sections:
•
•
•
•
•
•
•
•
•
•
•
See the "IP Multicast Configuration Examples" at the end of this chapter for examples of multicast routing configurations.
To see information on IP multicast multilayer switching, refer to the Release 12.1 Cisco IOS Switching Services Configuration Guide and Cisco IOS Switching Services Command Reference publication.
Enabling IP Multicast Routing
Enabling IP multicast routing allows the Cisco IOS software to forward multicast packets. To enable IP multicast routing on the router, use the following command in global configuration mode:
Enabling PIM on an Interface
Enabling PIM on an interface also enables IGMP operation on that interface. An interface can be configured to be in dense mode, sparse mode, or sparse-dense mode. The mode determines how the router populates its multicast routing table and how the router forwards multicast packets it receives from its directly connected LANs. You must enable PIM in one of these modes for an interface to perform IP multicast routing.
In populating the multicast routing table, dense-mode interfaces are always added to the table. Sparse-mode interfaces are added to the table only when periodic Join messages are received from downstream routers, or when there is a directly connected member on the interface. When forwarding from a LAN, sparse-mode operation occurs if there is an RP known for the group. If so, the packets are encapsulated and sent toward the RP. When no RP is known, the packet is flooded in a dense-mode fashion. If the multicast traffic from a specific source is sufficient, the receiver's first-hop router may send Join messages toward the source to build a source-based distribution tree.
There is no default mode setting. By default, multicast routing is disabled on an interface.
Enabling Dense Mode
To configure PIM on an interface to be in dense mode, use the following command in interface configuration mode:
See the "PIM Dense Mode Example" section at the end of this chapter for an example of how to configure a PIM interface in dense mode.
Enabling Sparse Mode
To configure PIM on an interface to be in sparse mode, use the following command in interface configuration mode:
See the "PIM Sparse Mode Example" section at the end of this chapter for an example of how to configure a PIM interface in sparse mode.
Enabling Sparse-Dense Mode
If you configure either the ip pim sparse-mode or ip pim dense-mode command, then sparseness or denseness is applied to the interface as a whole. However, some environments might require PIM to run in a single region in sparse mode for some groups and in dense mode for other groups.
An alternative to enabling only dense mode or only sparse mode is to enable sparse-dense mode. In this case, the interface is treated as dense mode if the group is in dense mode; the interface is treated in sparse mode if the group is in sparse mode. You must have an RP if the interface is in sparse-dense mode, and you want to treat the group as a sparse group.
If you configure sparse-dense mode, the idea of sparseness or denseness is applied to the group on the router, and the network manager should apply the same concept throughout the network.
Another benefit of sparse-dense mode is that Auto-RP information can be distributed in a dense-mode manner; yet, multicast groups for user groups can be used in a sparse-mode manner. Thus, there is no need to configure a default RP at the leaf routers.
When an interface is treated in dense mode, it is populated in a multicast routing table's outgoing interface list when either of the following is true:
•
•
When an interface is treated in sparse mode, it is populated in a multicast routing table's outgoing interface list when either of the following is true:
•
•
To enable PIM to operate in the same mode as the group, use the following command in interface configuration mode:
ip pim sparse-dense-mode
Enable PIM to operate in sparse or dense mode, depending on the group.
Configuring a Rendezvous Point
If you configure PIM to operate in sparse mode, you must also choose one or more routers to be rendezvous points (RPs). You need not configure the routers to be RPs; they learn this themselves. RPs are used by senders to a multicast group to announce their existence and by receivers of multicast packets to learn about new senders. The Cisco IOS software can be configured so that packets for a single multicast group can use one or more RPs.
The RP address is used by first-hop routers to send PIM register messages on behalf of a host sending a packet to the group. The RP address is also used by last-hop routers to send PIM Join and Prune messages to the RP to inform it about group membership. You must configure the RP address on all routers (including the RP router).
A PIM router can be an RP for more than one group. Only one RP address can be used at a time within a PIM domain. The conditions specified by the access list determine for which groups the router is an RP.
To configure the address of the RP, use the following command on a leaf router in global configuration mode:
ip pim rp-address ip-address [access-list-number] [override]
Configure the address of a PIM RP.
Configuring Auto-RP
Auto-RP is a feature that automates the distribution of group-to-RP mappings in a PIM network. This feature has the following benefits:
•
•
•
Multiple RPs can be used to serve different group ranges or serve as hot backups of each other. To make Auto-RP work, a router must be designated as an RP-mapping agent, which receives the RP-announcement messages from the RPs and arbitrates conflicts. The RP-mapping agent then sends the consistent group-to-RP mappings to all other routers. Thus, all routers automatically discover which RP to use for the groups they support.
Note
Note
Setting Up Auto-RP in a New Internetwork
If you are setting up Auto-RP in a new internetwork, you do not need a default RP because you configure all the interfaces for sparse-dense mode. Follow the process described in the section "Adding Auto-RP to an Existing Sparse-Mode Cloud," except that you should omit the first step of choosing a default RP.
Adding Auto-RP to an Existing Sparse-Mode Cloud
The following sections contain some suggestions for the initial deployment of Auto-RP into an existing sparse-mode cloud, to minimize disruption of the existing multicast infrastructure.
Choosing a Default RP
Sparse-mode environments need a default RP; sparse-dense-mode environments do not. If you have sparse-dense mode configured everywhere, you need not choose a default RP.
Adding Auto-RP to a sparse-mode cloud requires a default RP. In an existing PIM sparse-mode region, at least one RP is defined across the network that has good connectivity and availability. That is, the ip pim rp-address command is already configured on all routers in this network.
Use that RP for the global groups (for example, 224.x.x.x and other global groups). There is no need to reconfigure the group address range that RP serves. RPs discovered dynamically through Auto-RP take precedence over statically configured RPs. Assume it is desirable to use a second RP for the local groups.
Announcing the RP and the Group Range It Serves
Find another router to serve as the RP for the local groups. The RP-mapping agent can double as an RP itself. Assign the whole range of 239.x.x.x to that RP, or assign a subrange of that (for example, 239.2.x.x).
To designate that a router is the RP, use the following command in global configuration mode:
ip pim send-rp-announce type number scope ttl group-list access-list-number
Configure a router to be the RP.
To change the group ranges this RP optimally serves in the future, change the announcement setting on the RP. If the change is valid, all other routers automatically adopt the new group-to-RP mapping.
The following example advertises the IP address of Ethernet 0 as the RP for the administratively scoped groups:
ip pim send-rp-announce ethernet0 scope 16 group-list 1access-list 1 permit 239.0.0.0 0.255.255.255Assigning the RP Mapping Agent
The RP mapping agent is the router that sends the authoritative Discovery packets telling other routers which group-to-RP mapping to use. Such a role is necessary in the event of conflicts (such as overlapping group-to-RP ranges).
Find a router whose connectivity is not likely to be interrupted and assign it the role of RP-mapping agent. All routers within ttl number of hops from the source router receive the Auto-RP Discovery messages. To assign the role of RP mapping agent in that router, use the following command in global configuration mode:
Verifying the Group-to-RP Mapping
To learn if the group-to-RP mapping has arrived, use one of the following commands in EXEC mode on the designated routers:
Starting to Use IP Multicast
Use your IP multicast application software to start joining and sending to a group.
Preventing Join Messages to False RPs
Note the ip pim accept-rp commands previously configured throughout the network. If the ip pim accept-rp command is not configured on any router, this problem can be addressed later. In those routers already configured with the ip pim accept-rp command, you must specify the command again to accept the newly advertised RP.
To accept all RPs advertised with Auto-RP and reject all other RPs by default, use the ip pim accept-rp auto-rp command.
If all interfaces are in sparse mode, a default configured RP to support the two well-known groups 224.0.1.39 and 224.0.1.40. Auto RP relies on these two well-known groups to collect and distribute RP-mapping information. When this is the case and the ip pim accept-rp auto-rp command is configured, another ip pim accept-rp command accepting the default RP must be configured, as follows:
ip pim accept-rp default RP address 1access-list 1 permit 224.0.1.39access-list 1 permit 224.0.1.40Filtering Incoming RP Announcement Messages
To filter incoming RP announcement messages, use the following command in global configuration mode:
ip pim rp-announce-filter rp-list access-list-number group-list access-list-number
Filter incoming RP announcement messages.
Configuring IGMP Features
To configure IGMP features, perform the tasks in the following sections:
•
•
•
•
•
For information about configuring IGMP unidirectional link routing (UDLR), see the chapter "Configuring Unidirectional Link Routing" in this document.
Configuring a Router to Be a Member of a Group
Cisco routers can be configured to be members of a multicast group. This strategy is useful for determining multicast reachability in a network. If a device is configured to be a group member and supports the protocol that is being sent to the group, it can respond (to the ping command, for example). The device responds to ICMP echo request packets addressed to a group of which it is a member. Another example is the multicast traceroute tools provided in the Cisco IOS software.
To have the router join a multicast group and enable IGMP, use the following command in interface configuration mode:
Controlling Access to IP Multicast Groups
Multicast routers send IGMP host-query messages to determine which multicast groups have members of the router's attached local networks. The routers then forward to these group members all packets addressed to the multicast group. You can place a filter on each interface that restricts the multicast groups that hosts on the subnet serviced by the interface can join.
To filter multicast groups allowed on an interface, use the following command in interface configuration mode:
ip igmp access-group access-list-number
Control the multicast groups that hosts on the subnet serviced by an interface can join.
Changing the IGMP Version
By default, the router uses IGMP Version 2, which allows such features as the IGMP query timeout and the maximum query response time.
All routers on the subnet must support the same version. The router does not automatically detect Version 1 routers and switch to Version 1 as did earlier releases of the Cisco IOS software. However, a mix of IGMP Version 1 and Version 2 hosts on the subnet is acceptable. IGMP Version 2 routers will always work correctly in the presence of IGMP Version 1 hosts.
To control which version of IGMP the router uses, use the following command in interface configuration mode:
Modifying the IGMP Host-Query Message and Query Timeout Intervals
Multicast routers send IGMP host-query messages to discover which multicast groups are present on attached networks. These messages are sent to the all-systems group address of 224.0.0.1 with a time-to-live (TTL) of 1.
Multicast routers send host-query messages periodically to refresh their knowledge of memberships present on their networks. If, after some number of queries, the Cisco IOS software discovers that no local hosts are members of a multicast group, the software stops forwarding onto the local network multicast packets from remote origins for that group and sends a prune message upstream toward the source.
Routers That Run IGMP Version 1
If there are multiple routers on a LAN, a designated router (DR) must be elected to avoid duplicating multicast traffic for connected hosts. PIM routers follow an election process to select a DR. The PIM router with the highest IP address becomes the DR.
The DR is responsible for the following tasks:
•
•
By default, the DR sends host-query messages every 60 seconds in order to keep the IGMP overhead on hosts and networks very low.
To modify this interval, use the following command in interface configuration mode:
ip igmp query-interval seconds
Configure the frequency at which the designated router sends IGMP host-query messages.
Routers That Run IGMP Version 2
IGMP Version 2 improved the query messaging capabilities of IGMP Version 1.
The query and membership report messages in IGMP Version 2 are identical to the IGMP Version 1 messages with two exceptions.
1.
2.
Unlike IGMP Version 1, in which the DR and the IGMP querier are typically the same router, in IGMP Version 2, the two functions are decoupled. The DR and the IGMP querier are selected based on different criteria and may be different routers on the same subnet. The DR is the router with the highest IP address on the subnet, whereas the IGMP querier is the router with the lowest IP address.
IP addresses in general query messages are used to elect the IGMP querier and this is the election process:
•
•
•
By default, the timer is 2 times the query interval controlled by the ip igmp query-interval command.
To change the query timeout and to specify the period of time before a new election is performed, use the following command in interface configuration mode:
Changing the Maximum Query Response Time
By default, the maximum query response time advertised in IGMP queries is 10 seconds. If the router is using IGMP Version 2, you can change this value. The maximum query response time allows a router to quickly detect that there are no more directly connected group members on a LAN. Decreasing the value allows the router to prune groups faster.
To change the maximum query response time, use the following command in interface configuration mode:
ip igmp query-max-response-time seconds
Set the maximum query response time advertised in IGMP queries.
Configuring the Router as a Statically Connected Member
Sometimes either there is no group member on a network segment or a host cannot report its group membership using IGMP. However, you may want multicast traffic to go to that network segment. The following are two ways to pull multicast traffic down to a network segment:
•
•
To configure the router itself to be a statically connected member of a group (and allow fast switching), use the following command in interface configuration mode:
Configuring the TTL Threshold
The time-to-live (TTL) value controls whether packets are forwarded out of an interface. You specify the TTL value in hops. Only multicast packets with a TTL greater than the interface TTL threshold are forwarded on the interface. The default value is 0, which means that all multicast packets are forwarded on the interface. To change the default TTL threshold value, use the following command in interface configuration mode:
ip multicast ttl-threshold ttl
Configure the TTL threshold of packets being forwarded out an interface.
Disabling Fast Switching of IP Multicast
Fast switching of IP multicast packets is enabled by default on all interfaces (including GRE and DVMRP tunnels), with one exception: It is disabled and not supported over X.25 encapsulated interfaces. Keep the following in mind:
•
•
Disable fast switching if you want to log debug messages, because when fast switching is enabled, debug messages are not logged.
To disable fast switching of IP multicast, use the following command in interface configuration mode:
Configuring sdr Listener Support
The tasks in the following sections configure Session Directory Protocol (sdr) listener support:
•
•
Enabling sdr Listener Support
The multicast backbone (MBONE) allows efficient, many-to-many communication and is widely used for multimedia conferencing. To help announce multimedia conference sessions and provide the necessary conference setup information to potential participants, the Session Directory Protocol Version 2 (sdr) tool is available. A session directory client announcing a conference session periodically multicasts an announcement packet on a well-known multicast address and port.
To enable session directory listener support, use the following command in interface configuration mode:
Limiting How Long an sdr Cache Entry Exists
By default, entries are never deleted from the sdr cache. To limit how long an sdr cache entry stays active in the cache, use the following command in global configuration mode:
ip sdr cache-timeout minutes
Limit how long an sdr cache entry stays active in the cache.
Configuring Basic DVMRP Interoperability Features
The following sections describe some basic tasks that allow interoperability with DVMRP machines:
•
•
For more advanced DVMRP features, see the section "Configuring Advanced DVMRP Interoperability Features" later in this chapter.
Configuring DVMRP Interoperability
Cisco multicast routers using PIM can interoperate with non-Cisco multicast routers that use the DVMRP.
PIM routers dynamically discover DVMRP multicast routers on attached networks. Once a DVMRP neighbor has been discovered, the router periodically sends DVMRP Report messages advertising the unicast sources reachable in the PIM domain. By default, directly connected subnets and networks are advertised. The router forwards multicast packets that have been forwarded by DVMRP routers and, in turn, forwards multicast packets to DVMRP routers.
You can configure what sources are advertised and what metrics are used by configuring the ip dvmrp metric command. You can also direct all sources learned via a particular unicast routing process to be advertised into DVMRP.
The mrouted protocol is a public-domain implementation of DVMRP. It is necessary to use mrouted Version 3.8 (which implements a nonpruning version of DVMRP). When Cisco routers are directly connected to DVMRP routers or interoperate with DVMRP routers over an MBONE tunnel. DVMRP advertisements produced by the Cisco IOS software can cause older versions of mrouted to corrupt their routing tables and those of their neighbors. Any router connected to the MBONE should have an access list to limit the number of unicast routes that are advertised via DVMRP.
To configure the sources that are advertised and the metrics that are used when DVMRP Report messages are sent, use the following command in interface configuration mode:
ip dvmrp metric metric [list access-list-number] [[protocol process-id] | [dvmrp]]
Configure the metric associated with a set of destinations for DVMRP reports.
A more sophisticated way to achieve the same results as the preceding command is to use a route map instead of an access list. Thus, you have a finer granularity of control. To subject unicast routes to route-map conditions before they are injected into DVMRP, use the following command in interface configuration mode:
ip dvmrp metric metric route-map map-name
Subject unicast routes to route-map conditions before they are injected into DVMRP.
Responding to mrinfo Requests
The Cisco IOS software answers mrinfo requests sent by mrouted systems and Cisco routers. The software returns information about neighbors on DVMRP tunnels and all of the router's interfaces. This information includes the metric (which is always set to 1), the configured TTL threshold, the status of the interface, and various flags. The mrinfo command can also be used to query the router itself, as in the following example:
mm1-7kd# mrinfo171.69.214.27 (mm1-7kd.cisco.com) [version cisco 11.1] [flags: PMS]:171.69.214.27 -> 171.69.214.26 (mm1-r7kb.cisco.com) [1/0/pim/querier]171.69.214.27 -> 171.69.214.25 (mm1-45a.cisco.com) [1/0/pim/querier]171.69.214.33 -> 171.69.214.34 (mm1-45c.cisco.com) [1/0/pim]171.69.214.137 -> 0.0.0.0 [1/0/pim/querier/down/leaf]171.69.214.203 -> 0.0.0.0 [1/0/pim/querier/down/leaf]171.69.214.18 -> 171.69.214.20 (mm1-45e.cisco.com) [1/0/pim]171.69.214.18 -> 171.69.214.19 (mm1-45c.cisco.com) [1/0/pim]171.69.214.18 -> 171.69.214.17 (mm1-45a.cisco.com) [1/0/pim]See the "DVMRP Interoperability Example" section at the end of this chapter for an example of how to configure a PIM router to interoperate with a DVMRP router.
Configuring a DVMRP Tunnel
The Cisco IOS software supports DVMRP tunnels to the MBONE (the multicast backbone of the Internet). You can configure a DVMRP tunnel on a router if the other end is running DVMRP. The software then sends and receives multicast packets over the tunnel. This strategy allows a PIM domain to connect to the DVMRP router in the case where all routers on the path do not support multicast routing. You cannot configure a DVMRP tunnel between two routers.
When a Cisco router runs DVMRP over a tunnel, it advertises sources in DVMRP Report messages much as it does on real networks. In addition, the software caches DVMRP Report messages it receives and uses them in its Reverse Path Forwarding (RPF) calculation. This behavior allows the software to forward multicast packets received over the tunnel.
When you configure a DVMRP tunnel, you should assign a tunnel an address in the following two cases:
•
•
You can assign an IP address either by using the ip address interface configuration command, or by using the ip unnumbered interface configuration command to configure the tunnel to be unnumbered. Either of these two methods allows IP multicast packets to flow over the tunnel. The software will not advertise subnets over the tunnel if the tunnel has a different network number from the subnet. In this case, the software advertises only the network number over the tunnel.
To configure a DVMRP tunnel, use the following commands in interface configuration mode:
See the "DVMRP Tunnel Example" section at the end of this chapter for an example of how to configure a DVMRP tunnel.
Advertising Network 0.0.0.0 to DVMRP Neighbors
The mrouted protocol is a public-domain implementation of DVMRP. If your router is a neighbor to an mrouted Version 3.6 machine, you can configure the Cisco IOS software to advertise network 0.0.0.0 to the DVMRP neighbor. Do not advertise the DVMRP default into the MBONE. You must specify whether only route 0.0.0.0 is advertised or if other routes can also be specified.
To advertise network 0.0.0.0 to DVMRP neighbors on an interface, use the following command in interface configuration mode:
ip dvmrp default-information {originate | only}
Advertise network 0.0.0.0 to DVMRP neighbors.
Enabling the Functional Address for IP Multicast over
Token Ring LANsBy default, IP multicast datagrams on Token Ring LAN segments use the MAC-level broadcast address 0xFFFF.FFFF.FFFF. That default places an unnecessary burden on all devices that do not participate in IP multicast. The IP multicast over Token Ring LANs feature defines a way to map IP multicast addresses to a single Token Ring MAC address.
This feature defines the Token Ring functional address (0xc000.0004.0000) that should be used over Token Ring. A functional address is a severely restricted form of multicast addressing implemented on Token Ring interfaces. Only 31 functional addresses are available. A bit in the destination MAC address designates it as a functional address.
The implementation used by Cisco complies with RFC 1469, IP Multicast over Token-Ring Local Area Networks.
If you configure this feature, IP multicast transmissions over Token Ring interfaces are more efficient than they formerly were. This feature reduces the load on other machines that do not participate in IP multicast because they do not process these packets.
The following restrictions apply to the Token Ring functional address:
•
•
•
To enable the mapping of IP multicast addresses to the Token Ring functional address 0xc000.0004.0000, use the following command in interface configuration mode:
ip multicast use-functional
Enable the mapping of IP multicast addresses to the Token Ring functional address.
For an example of configuring the functional address, see the section "Functional Address for IP Multicast over Token Ring LAN Example" at the end of this chapter.
Configuring PIM Version 2
PIM Version 2 includes the following improvements over PIM Version 1:
•
•
•
•
•
•
•
PIM Version 1, together with the Auto-RP feature, can perform the same tasks as the PIM Version 2 BSR. However, Auto-RP is a standalone protocol, separate from PIM Version 1, and is Cisco proprietary. PIM Version 2 is a standards track protocol in the IETF. We recommend that you use PIM Version 2.
Either the BSR or Auto-RP should be chosen for a given range of multicast groups. If there are PIM Version 1 routers in the network, do not use the BSR.
Cisco's PIM Version 2 implementation allows interoperability and transition between Version 1 and Version 2, although there might be some minor problems. You can upgrade to PIM Version 2 incrementally. PIM Versions 1 and 2 can be configured on different routers within one network. Internally, all routers on a shared media network must run the same PIM version. Therefore, if a PIM Version 2 router detects a PIM Version 1 router, the Version 2 router downgrades itself to Version 1 until all Version 1 routers have been shut down or upgraded.
PIM uses the BSR to discover and announce RP-set information for each group prefix to all the routers in a PIM domain. This is the same function accomplished by Auto-RP, but the BSR is part of the PIM Version 2 specification. The BSR mechanism interoperates with Auto-RP on Cisco routers.
To avoid a single point of failure, you can configure several candidate BSRs in a PIM domain. A BSR is elected among the candidate BSRs automatically; they use bootstrap messages to discover which BSR has the highest priority. This router then announces to all PIM routers in the PIM domain that it is the BSR.
Routers that are configured as candidate RPs then unicast to the BSR the group range for which they are responsible. The BSR includes this information in its bootstrap messages and disseminates it to all PIM routers in the domain. Based on this information, all routers will be able to map multicast groups to specific RPs. As long as a router is receiving the bootstrap message, it has a current RP map.
PIM Version 2 is a standards track protocol in the IETF.
Prerequisites
When PIM Version 2 routers interoperate with PIM Version 1 routers, Auto-RP should have already been deployed. A PIM Version 2 BSR that is also an Auto-RP mapping agent will automatically advertise the RP elected by Auto-RP. That is, Auto-RP prevails in its single RP being imposed on every router in the group. All routers in the domain refrain from trying to use the PIM Version 2 hash function to select multiple RPs.
Because bootstrap messages are sent hop by hop, a PIM Version1 router will prevent these messages from reaching all routers in your network. Therefore, if your network has a PIM Version 1 router in it, and only Cisco routers, it is best to use Auto-RP rather than the bootstrap mechanism. If you have a network that includes routers from other vendors, configure the Auto-RP mapping agent and the BSR on a Cisco PIM Version 2 router. Also ensure that no PIM Version 1 router is located on the path between the BSR and a non-Cisco PIM Version 2 router.
PIM Version 2 Configuration Tasks
There are two approaches to using PIM Version 2. You can use Version 2 exclusively in your network, or migrate to Version 2 by employing a mixed PIM version environment.
•
•
•
The tasks to configure PIM Version 2 are described in the sections that follow:
•
•
•
Specifying the PIM Version
All systems using Cisco IOS Release 11.3(2)T or later start in PIM Version 2 mode by default. In case you need to reenable PIM Version 2 or specify PIM Version 1 for some reason, you can control the PIM version by using the following command in interface configuration mode:
Configuring PIM Version 2 Only
To configure PIM Version 2 exclusively, perform the tasks in this section. It is assumed that no PIM Version 1 system exists in the PIM domain.
The first task is recommended, configuring sparse-dense mode. If you configure Auto-RP, none of the other tasks is required to run PIM Version 2. To configure Auto-RP, see the section "Configuring Auto-RP" earlier in this chapter.
If you want to configure a BSR, complete the tasks in the sections that follow:
•
•
•
Configuring PIM Sparse-Dense Mode
To configure PIM sparse-dense mode, use the following commands on all PIM routers inside the PIM domain, beginning in global configuration mode:
Repeat Steps 2
