-
Network Protocols Configuration Guide, Part 1
-
IP Overview
-
Configuring IP Addressing
-
Configuring IP Services
-
Configuring RSVP
-
Configuring On-Demand Routing
-
Configuring RIP
-
Configuring IGRP
-
Configuring OSPF
-
Configuring IP Enhanced IGRP
-
Configuring Integrated IS-IS
-
Configuring BGP
-
Configuring IP Routing Protocol-Independent Features
-
Configuring IP Multicast Routing
-
Table Of Contents
Configuring IP Multicast Routing
Cisco's Implementation of IP Multicast Routing
Internet Group Management Protocol
Protocol-Independent Multicast Protocol
Distance Vector Multicast Routing Protocol
Cisco Group Management Protocol (CGMP)
Basic IP Multicast Routing Tasks
Advanced IP Multicast Routing Tasks
Configure a Rendezvous Point (RP)
Set Up Auto-RP in a New Internetwork
Add Auto-RP to an Existing Sparse-Mode Cloud
Announce the RP and the Group Range it Serves
Verify the Group-to-RP Mapping
Prevent Join Messages to False RPs
Filter Incoming RP Announcement Messages
Configure a Router to Be a Member of a Group
Control Access to IP Multicast Groups
Modify the IGMP Host-Query Message Interval
Change the Maximum Query Response Time
Configure the Router as a Statically Connected Member
Disable Fast Switching of IP Multicast
Configure sdr Listener Support
Limit How Long an sdr Cache Entry Exists
Configure Basic DVMRP Interoperability Features
Configure DVMRP Interoperability
Advertise Network 0.0.0.0 to DVMRP Neighbors
Enable the Functional Address for IP Multicast over Token Ring LANs
Configure Advanced PIM Features
Understand PIM Shared Tree and Source Tree (Shortest Path Tree)
Delay the Use of PIM Shortest Path Tree
Understand Reverse-Path Forwarding (RPF)
Assign an RP to Multicast Groups
Modify the PIM Router-Query Message Interval
Enable PIM Nonbroadcast, Multiaccess (NBMA) Mode
Configure Advanced DVMRP Interoperability Features
Limit the Number of DVMRP Routes Advertised
Change the DVMRP Route Threshold
Configure a DVMRP Summary Address
Disable DVMRP Auto-Summarization
Add a Metric Offset to the DVMRP Route
Reject a DVMRP Nonpruning Neighbor
Configure a Delay between DVRMP Reports
Configure an IP Multicast Static Route
Control the Transmission Rate to a Multicast Group
Configure RTP Header Compression
Enable RTP Header Compression on a Serial Interface
Enable RTP Header Compression with Frame Relay Encapsulation
Change the Number of Header Compression Connections
Configure IP Multicast over ATM Point-to-Multipoint Virtual Circuits
Enable IP Multicast over ATM Point-to-Multipoint VCs
Limit the Number of Virtual Circuits
Configure an IP Multicast Boundary
Configure an Intermediate IP Multicast Helper
Configure Stub IP Multicast Routing
Load Split IP Multicast Traffic across Equal-Cost Paths
Configure the Router at the Opposite End of the Tunnel
Load Splitting to a Stub Network
Load Splitting to the Middle of a Network
Monitor and Maintain IP Multicast Routing
Clear Caches, Tables, and Databases
Display System and Network Statistics
IP Multicast Configuration Examples
DVMRP Interoperability Example
RTP Header Compression Examples
IP Multicast over ATM Point-to-Multipoint VC Example
Functional Address for IP Multicast over Token Ring LAN 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 Network Protocols Command Reference, Part 1. 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.
Cisco's 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 of which multicast groups the hosts are members.
•
•
•
shows where these protocols operate within the IP multicast environment. The protocols are further described after the figure.
Figure 34 IP Multicast Routing Protocols
Internet Group Management Protocol
IP hosts use Internet Group Management Protocol (IGMP) to report their group membership to directly connected multicast routers. IGMP is an integral part of IP. IGMP is defined in RFC 1112, Host Extensions for IP Multicasting.
IGMP uses group addresses, which are Class D IP addresses. The high-order four bits of a Class D address are 1110. This means that host group addresses can be in the range 224.0.0.0 to 239.255.255.255. The address 224.0.0.0 is guaranteed not to be assigned to any group. The address 224.0.0.1 is assigned to all systems on a subnet. The address 224.0.0.2 is assigned to all routers on a subnet.
Protocol-Independent Multicast Protocol
The Protocol-Independent Multicast (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 the following IETF Internet drafts:
•
•
•
•
•
PIM can operate in dense mode, sparse mode, or sparse-dense mode.
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.
Distance Vector Multicast Routing Protocol
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. However, PIM only uses this information. Cisco routers do not implement DVMRP to forward multicast packets.
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.
Cisco Group Management Protocol (CGMP)
Cisco Group Management Protocol (CGMP) is a protocol used on routers connected to Cisco Catalyst switches to perform tasks similar to those performed by IGMP. CGMP is necessary because the Catalyst switch cannot tell the difference between IP multicast data packets and IGMP Report messages, which are both MAC-level addressed to the same group address.
Basic IP Multicast Routing Tasks
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 Tasks
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.
Enable IP Multicast Routing
Enabling IP multicast routing allows the Cisco IOS software to forward multicast packets. To enable IP multicast routing on the router, perform the following task in global configuration mode:
Enable 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 joins 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.
Enable Dense Mode
To configure PIM on an interface to be in dense mode, perform the following task 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.
Enable Sparse Mode
To configure PIM on an interface to be in sparse mode, perform the following task 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.
Enable Sparse-Dense Mode
If you configure either ip pim sparse-mode or ip pim dense-mode, 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, perform the following task in interface configuration mode:
Enable PIM to operate in sparse or dense mode, depending on the group.
ip pim sparse-dense-mode
Configure a Rendezvous Point (RP)
If you configure PIM to operate in sparse mode, you must also choose one or more routers to be RPs. You do not have to 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.
You must configure the IP address of RPs in leaf routers only. Leaf routers are those routers that are directly connected either to a multicast group member or to a sender of multicast messages.
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/prune messages to the RP to inform it about group membership. The RP does not need to know it is an RP. You must configure the RP address only on first-hop and last-hop routers (leaf routers).
A PIM router can be an RP for more than one group. A group can have more than one RP. The conditions specified by the access list determine for which groups the router is an RP.
To configure the address of the RP, perform the following task on a leaf router in global configuration mode:
Configure the address of a PIM rendezvous point (RP).
ip pim rp-address ip-address [access-list-number] [override]
Configure 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.
One way to start is to place (preserve) the default RP for all global groups at or near the border router of your routing domain, while placing another RP in a more centrally located router for all local groups using the administratively scoped addresses (239.x.x.x).
Note
Set Up Auto-RP in a New Internetwork
You do not need a default RP in this case. Follow the process described in the section "Add Auto-RP to an Existing Sparse-Mode Cloud," except that you should skip the first step of choosing a default RP.
Add 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 provide experience and allow minimal disruption of the existing multicast infrastructure.
Choose 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 do not need to 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.
Announce 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, perform the following task in global configuration mode:
Configure a router to be the RP.
ip pim send-rp-announce type number scope ttl group-list access-list-number
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.255Assign 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 perform the following task in global configuration mode:
Verify the Group-to-RP Mapping
To see if the group-to-RP mapping has arrived, perform one of the following tasks in EXEC mode on the designated routers:
Start Using IP Multicast
Use your IP multicast application software to start joining and sending to a group.
Prevent Join Messages to False RPs
Note the ip pim accept-rp commands previously configured throughout the network. If that command is not configured on any router, this problem can be addressed later. In those routers already configured with 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.40Filter Incoming RP Announcement Messages
To filter incoming RP announcement messages, perform the following task in global configuration mode:
Filter incoming RP announcement messages.
ip pim rp-announce-filter rp-list access-list-number group-list access-list-number
Configure IGMP Features
To configure IGMP features, perform the tasks in the following sections:
•
•
•
•
•
•
Configure a Router to Be a Member of a Group
Cisco routers can be configured to be members of a multicast group. This 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 transmitted to the group, it can respond (for example, the ping command). 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, perform the following task in interface configuration mode:
Control 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, perform the following task in interface configuration mode:
Control the multicast groups that hosts on the subnet serviced by an interface can join.
ip igmp access-group access-list-number
Modify the IGMP Host-Query Message Interval
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 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.
Multicast routers elect a PIM designated router for the LAN (subnet). This is the router with the highest IP address. The designated router is responsible for sending IGMP host-query messages to all hosts on the LAN. In sparse mode, the designated router also sends PIM register and PIM join messages toward the RP router.
By default, the designated router sends IGMP host-query messages once a minute in order to keep the IGMP overhead on hosts and networks very low. To modify this interval, perform the following task in interface configuration mode:
Configure the frequency at which the designated router sends IGMP host-query messages.
ip igmp query-interval seconds
Change 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 systems on the subnet must support the same version. The router does not automatically detect Version 1 systems and switch to Version 1, as did earlier releases of the Cisco IOS software.
Configure the router for Version 1 if your hosts do not support Version 2.
To control which version of IGMP the router uses, perform the following task in interface configuration mode:
Change the IGMP Query Timeout
You can specify the period of time before the router takes over as the querier for the interface, after the previous querier has stopped doing so. By default, the router waits 2 times the query interval controlled by the ip igmp query-interval command. After that time, if the router has received no queries, it becomes the querier. This feature requires IGMP Version 2.
To change the query timeout, perform the following task in interface configuration mode:
Change 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, perform the following task in interface configuration mode:
Set the maximum query response time advertised in IGMP queries.
ip igmp query-max-response-time seconds
Configure 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), perform the following task in interface configuration mode:
Configure the router as a statically connected member of a group.
ip igmp static-group group-address
Configure 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, perform the following task in interface configuration mode:
Configure the TTL threshold of packets being forwarded out an interface.
ip multicast ttl-threshold ttl
Disable 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, perform the following task in interface configuration mode:
Configure sdr Listener Support
The tasks in the following sections configure Session Directory Protocol (sdr) listener support:
•
Enable 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, perform the following task in interface configuration mode:
Limit How Long an sdr Cache Entry Exists
By default, entries are never deleted from the sdr cache. You can limit how long an sdr cache entry stays active in the cache. To do so, perform the following task in global configuration mode:
Limit how long an sdr cache entry stays active in the cache.
ip sdr cache-timeout minutes
Configure 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 "Configure Advanced DVMRP Interoperability Features" later in this chapter.
Configure DVMRP Interoperability
Cisco multicast routers using PIM can interoperate with non-Cisco multicast routers that use the Distance Vector Multicast Routing Protocol (DVMRP).
PIM routers dynamically discover DVMRP multicast routers on attached networks. Once a DVMRP neighbor has been discovered, the router periodically transmits 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 transmitting DVMRP Report messages, perform the following task in interface configuration mode:
Configure the metric associated with a set of destinations for DVMRP reports.
ip dvmrp metric metric [list access-list-number] [[protocol process-id] | [dvmrp]]
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 being injected into DVMRP, perform the following task in interface configuration mode:
Subject unicast routes to route-map conditions before being injected into DVMRP
ip dvmrp metric metric route-map map-name
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.
Configure 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 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 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, perform the following tasks 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.
Advertise 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, perform the following task in interface configuration mode:
Advertise network 0.0.0.0 to DVMRP neighbors.
ip dvmrp default-information {originate | only}
Enable the Functional Address for IP Multicast over Token Ring LANs
By default, IP multicast datagrams on Token Ring LAN segments used the MAC-level broadcast address 0xFFFF.FFFF.FFFF. That 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 Systems 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, perform the following task in interface configuration mode:
Enable the mapping of IP multicast addresses to the Token Ring functional address.
ip multicast use-functional
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.
Configure Advanced PIM Features
Perform the optional tasks in the following sections to configure PIM features:
•
•
•
•
•
•
Understand PIM Shared Tree and Source Tree (Shortest Path Tree)
By default, members of a group receive data from senders to the group across a single data distribution tree rooted at the rendezvous point (RP). This type of distribution tree is called shared tree, as shown in . Data from senders is delivered to the RP for distribution to group members joined to the shared tree.
Figure 35 Shared Tree and Source Tree (Shortest Path Tree)
If the data rate warrants, leaf routers on the shared tree may initiate a switch to the data distribution tree rooted at the source. This type of distribution tree is called a shortest path tree or source tree. By default, the Cisco IOS software switches to a source tree upon receiving the first data packet from a source.
The following steps describe the move from shared tree to source tree in more detail:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Join and Prune messages are sent for sources and RPs. They are sent hop-by-hop and are processed by each PIM router along the path to the source or RP. Register and Register-Stop messages are not sent hop-by-hop. They are sent by the designated router that is directly connected to a source and are received by the RP for the group.
Multiple sources sending to groups used the shared tree.
The network manager can configure the router to stay on the shared tree, as described in the section "Delay the Use of PIM Shortest Path Tree."
Delay the Use of PIM Shortest Path Tree
The switch from shared to source tree happens upon the arrival of the first data packet at the last hop router (Router C in ). This occurs because the ip pim spt-threshold command controls that timing, and its default setting is 0 kbps.
The shortest path tree requires more memory than the shared tree, but reduces delay. You might want to postpone its use. Instead of allowing the leaf router to move to the shortest path tree immediately, you can specify that the traffic must first reach a threshold.
You can configure when a PIM leaf router should join the shortest path tree for a specified group. If a source sends at a rate greater than or equal to the specified kbps rate, the router triggers a PIM Join message toward the source to construct a source tree (shortest path tree). If infinity is specified, all sources for the specified group use the shared tree, never switching to the source tree.
The group list is a standard access list that controls what groups the shortest path tree threshold applies to. If a value of 0 is specified or the group list is not used, the threshold applies to all groups.
To configure a traffic rate threshold that must be reached before multicast routing is switched from the source tree to the shortest path tree, perform the following task in interface configuration mode:
Specify the threshold that must be reached before moving to shortest path tree (spt).
ip pim spt-threshold {kbps | infinity} [group-list access-list-number]
Understand Reverse-Path Forwarding (RPF)
Reverse-Path Forwarding (RPF) is an algorithm used for forwarding multicast datagrams. It functions as follows:
•
•
•
PIM uses both source trees and RP-rooted shared trees to forward datagrams; the RPF check is performed differently for each, as follows:
•
•
Sparse-mode PIM uses the RPF lookup function to determine where it needs to send Joins and Prunes. (S,G) Joins (which are source-tree states) are sent toward the source. (*,G) Joins (which are shared-tree states) are sent toward the RP.
DVMRP and dense-mode PIM use only source trees and use RPF as described previously.
Assign an RP to Multicast Groups
If you have configured PIM sparse mode, you must configure a PIM rendezvous point (RP) for a multicast group. An RP can either be configured statically in each box, or learned through a dynamic mechanism. This section explains how to statically configure an RP. If the RP for a group is learned through a dynamic mechanism (such as Auto-RP), you need not perform this task for that RP. You should use Auto-RP, which is described in the section "Configure Auto-RP" earlier in this chapter.
PIM Designated Routers forward data from directly connected multicast sources to the RP for distribution down the shared tree.
Data is forwarded to the RP in one of two ways. It is encapsulated in Register packets and unicast directly to the RP, or, if the RP has itself joined the source tree, it is multicast forwarded per the RPF forwarding algorithm described in the preceding section, "Understand Reverse-Path Forwarding (RPF)." Last-hop routers directly connected to receivers may, at their discretion, join themselves to the source tree and prune themselves from the shared tree.
A single RP can be configured for multiple groups defined by an access list. If there is no RP configured for a group, the router treats the group as dense using the dense-mode PIM techniques.
If a conflict exists between the RP configured with this command and one learned by Auto-RP, the Auto-RP information is used, unless the override keyword is configured.
To assign an RP to one or more multicast groups, perform the following task in global configuration mode:
Assign an RP to multicast groups.
ip pim rp-address ip-address [group-access-list-number] [override]
Increase Control over RPs
You can take a defensive measure to prevent a misconfigured leaf router from interrupting PIM service to the remainder of a network. To do so, configure the local router to accept Join messages only if they contain the RP address specified, when the group is in the group range specified by the access list. To configure this feature, perform the following task in global configuration mode:
Control which RPs the local router will accept Join messages to.
ip pim accept-rp {address | auto-rp} [access-list-number]
Modify the PIM Router-Query Message Interval
Route-query messages are used to elect a PIM designated router. The designated router is responsible for sending IGMP host-query messages. By default, multicast routers send PIM router-query messages every 30 seconds. To modify this interval, perform the following task in interface configuration mode:
Configure the frequency at which multicast routers send PIM router-query messages.
ip pim query-interval seconds
Enable PIM Nonbroadcast, Multiaccess (NBMA) Mode
PIM nonbroadcast, multiaccess (NBMA) mode allows the Cisco IOS software to replicate packets for each neighbor on the NBMA network. Traditionally, the software replicates multicast and broadcast packets to all "broadcast" configured neighbors. This might be inefficient when not all neighbors want packets for certain multicast groups. NBMA mode enables you to reduce bandwidth on links leading into the NBMA network, as well as CPU cycles in switches and attached neighbors.
Configure this feature on ATM, Frame Relay, SMDS, PRI ISDN, or X.25 networks only, especially when these media do not have native multicast available. Do not use this feature on multicast-capable LANs (such as Ethernet or FDDI).
You should use sparse-mode PIM with this feature. Therefore, when each join is received from NBMA neighbors, PIM stores each neighbor IP address/interface in the outgoing interface list for the group. When a packet is destined for the group, the software replicates the packet and unicasts (data-link unicasts) it to each neighbor that has joined the group.
To enable PIM nonbroadcast, multicaccess mode on your serial link, perform the following task in interface configuration mode:
Consider the following two factors before enabling PIM NBMA mode:
•
•
Configure Advanced DVMRP Interoperability Features
Cisco routers run PIM and know enough about DVMRP to successfully forward multicast packets to receivers and receive multicast packets from senders. It is also possible to propagate DVMRP routes into and through a PIM cloud. PIM uses this information; however, Cisco routers do not implement DVMRP to forward multicast packets.
The basic DVMRP features are described in the section "Configure Basic DVMRP Interoperability Features" earlier in this chapter. To configure more advanced DVMRP interoperability features on a Cisco router, perform the optional tasks in the following sections:
•
•
•
•
•
•
•
Enable DVMRP Unicast Routing
Since policy for multicast routing and unicast routing require separate topologies, PIM must follow the multicast topology to build loopless distribution trees. Using DVMRP unicast routing, Cisco routers and mrouted-based machines exchange DVMRP unicast routes, to which PIM can then Reverse Path Forward.
Cisco routers do not perform DVMRP multicast routing among each other, but they can exchange DVMRP routes. The DVMRP routes provide a multicast topology that may differ from the unicast topology. This allows PIM to run over the multicast topology, thereby allowing sparse-mode PIM over the MBONE topology.
When DVMRP unicast routing is enabled, the router caches routes learned in DVMRP Report messages in a DVMRP routing table. PIM prefers DVMRP routes to unicast routes by default, but that preference can be configured.
DVMRP unicast routing can run on all interfaces, including GRE tunnels. On DVMRP tunnels, it runs by virtue of DVMRP multicast routing. This feature does not enable DVMRP multicast routing among Cisco routers. However, if there is a DVMRP-capable multicast router, the Cisco router will do PIM/DVMRP multicast routing interaction.
To enable DVMRP unicast routing, perform the following task in interface configuration mode:
Limit the Number of DVMRP Routes Advertised
By default, only 7000 DVMRP routes will be advertised over an interface enabled to run DVMRP (that is, a DVMRP tunnel, an interface where a DVMRP neighbor has been discovered, or an interface configured to run ip dvmrp unicast-routing).
To change this limit, perform the following task in global configuration mode:
Change the number of DVMRP routes advertised over an interface enabled to run DVMRP.
ip dvmrp route-limit count
Change the DVMRP Route Threshold
By default, 10,000 DVMRP routes may be received per interface within a 1-minute interval. When that rate is exceeded, a syslog message is issued, warning that there might be a route surge occurring. The warning is typically used to quickly detect when people have misconfigured their routers to inject a large number of routes into the MBONE.
To change the threshold number of routes that trigger the warning, perform the following task in global configuration mode:
Configure the number of routes that trigger a syslog message.
ip dvmrp routehog-notification route-count
Use the show ip igmp interface command to display a running count of routes. When the count is exceeded, "*** ALERT ***" is appended to the line.
Configure a DVMRP Summary Address
You can customize the summarization of DVMRP routes if the default classful auto-summarization does not suit your needs. To summarize such routes, specify a summary address by performing the following task in interface configuration mode:
Note
Disable DVMRP Auto-Summarization
By default, the Cisco IOS software performs some level of DVMRP summarization automatically. Disable this function if you want to advertise all routes, not just a summary. If you configure the ip dvmrp summary-address command and did not configure no ip dvmrp auto-summary, you get both custom and auto-summaries.
To disable DVMRP auto-summarization, perform the following task in interface configuration mode:
Add a Metric Offset to the DVMRP Route
By default, the router increments by 1 the metric of a DVMRP route advertised in incoming DVMRP reports. You can change the metric if you want to favor or not favor a certain route. The DVMRP metric is a hop-count. Therefore, a very slow serial line of one hop is preferred over a route that is two hops over FDDI or another fast medium.
For example, perhaps a route is learned by Router A and the the same route is learned by Router B with a higher metric. If you want to use the path through Router B because it is a faster path, you can apply a metric offset to the route learned by Router A to make it larger than the metric learned by Router B, allowing you to choose the path through Router B.
To change the default metric, perform the following task in interface configuration mode:
Change the metric added to DVMRP routes advertised in incoming reports.
ip dvmrp metric-offset [in | out] increment
Similar to the metric keyword in mrouted configuration files, the following is true.
•
•
Reject a DVMRP Nonpruning Neighbor
By default, Cisco routers accept all DVMRP neighbors as peers, regardless of their DVMRP capability or lack thereof. However, some non-Cisco machines run old versions of DVMRP that cannot prune, so they will continuously receive forwarded packets unnecessarily, wasting bandwidth. shows this scenario.
Figure 36 Leaf Nonpruning DVMRP Neighbor
You can prevent a router from peering (communicating) with a DVMRP neighbor if that neighbor does not support DVMRP pruning or grafting. To do so, configure Router C (which is a neighbor to the leaf, nonpruning DVMRP machine) with the ip dvmrp reject-non-pruners command on the interface to the nonpruning machine. illustrates this scenario. In this case, when the router receives a DVMRP Probe or Report message without the Prune-Capable flag set, the router logs a syslog message and discards the message.
Figure 37 Router Rejects Nonpruning DVMRP Neighbor
Note that the ip dvmrp reject-non-pruners command prevents peering with neighbors only. If there are any nonpruning routers multiple hops away (downstream toward potential receivers) that are not rejected, then a nonpruning DVMRP network might still exist.
To prevent peering with nonpruning DVMRP neighbors, perform the following task in interface configuration mode:
