The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Note |
Distance Vector Multicast Routing Protocol (DVMRP) CLI and functionality are not provided in Cisco IOS software images that provide MTR support. |
This module describes the DVMRP Interoperability feature. Cisco routers run Protocol Independent Multicast (PIM), and know enough about 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 propagates 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. 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 constrains 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.
To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release.
To configure basic interoperability with DVMRP machines, perform the tasks described in the following sections. The tasks in the first section are required; the tasks in the remaining sections are optional.
For more advanced DVMRP interoperability features, see the section “Advanced DVMRP Interoperability Configuration Task List” later in this chapter.
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 which sources are advertised and which metrics are used by configuring the ip dvmrp metric interface configuration 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 multicast backbone (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:
Command |
Purpose |
---|---|
Router(config-if)# ip dvmrp metric metric [list access-list] [protocol process-id] |
Configures 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:
Command |
Purpose |
---|---|
Router(config-if)# ip dvmrp metric metric [route-map map-name] |
Subjects unicast routes to route map conditions before they are injected into DVMRP. |
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 interfaces of the router. 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 EXEC command can also be used to query the router itself, as in the following example:
mm1-7kd# mrinfo
171.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 later in this chapter for an example of how to configure a PIM router to interoperate with a DVMRP router.
The Cisco IOS software supports DVMRP tunnels to the MBONE. 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 later in this chapter for an example of how to configure a DVMRP tunnel.
The mrouted protocol is a public domain implementation of DVMRP. If your router is a neighbor to an mrouted Version 3.6 device, 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:
Command |
Purpose |
---|---|
Router(config-if)# ip dvmrp default-information {originate | only} |
Advertises network 0.0.0.0 to DVMRP neighbors. |
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 interoperability features are described in the section “Basic DVMRP Interoperability Configuration Task List” earlier in this chapter. To configure more advanced DVMRP interoperability features on a Cisco router, perform the optional tasks described in the following sections:
Because policy for multicast routing and unicast routing requires separate topologies, PIM must follow the multicast topology to build loopless distribution trees. Using DVMRP unicast routing, Cisco routers and mrouted 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. These routes allow PIM to run over the multicast topology, thereby allowing PIM sparse mode 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 generic routing encapsulation (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, use the following command in interface configuration mode:
Command |
Purpose |
---|---|
Router(config-if)# ip dvmrp unicast-routing |
Enables DVMRP unicast routing. |
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 the ip dvmrp unicast-routing interface configuration command).
To change this limit, use the following command in global configuration mode:
Command |
Purpose |
---|---|
Router(config)# ip dvmrp route-limit count |
Changes the number of DVMRP routes advertised over an interface enabled to run DVMRP. |
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 a route surge might be occurring. The warning is typically used to quickly detect when routers have been misconfigured to inject a large number of routes into the MBONE.
To change the threshold number of routes that trigger the warning, use the following command in global configuration mode:
Command |
Purpose |
---|---|
Router(config)# ip dvmrp routehog-notification route-count |
Configures the number of routes that trigger a syslog message. |
Use the show ip igmp interface EXEC command to display a running count of routes. When the count is exceeded, “*** ALERT ***” is appended to the line.
You can customize the summarization of DVMRP routes if the default classful automatic summarization does not suit your needs. To summarize such routes, specify a summary address by using the following command in interface configuration mode:
Command |
Purpose |
---|---|
Router(config-if)# ip dvmrp summary-address summary-address mask [metric value] |
Specifies a DVMRP summary address. |
Note |
At least one, more-specific route must be present in the unicast routing table before a configured summary address will be advertised. |
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 interface configuration command and did not configure the no ip dvmrp auto-summary command, you get both custom and automatic summaries.
To disable DVMRP automatic summarization, use the following command in interface configuration mode:
Command |
Purpose |
---|---|
Router(config-if)# no ip dvmrp auto-summary |
Disables DVMRP automatic summarization. |
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 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, use the following command in interface configuration mode:
Command |
Purpose |
---|---|
Router(config-if)# ip dvmrp metric-offset [in | out] increment |
Changes the metric added to DVMRP routes advertised in incoming reports. |
Similar to the metric keyword in mrouted configuration files, the following is true when using the ip dvmrp metric-offset interface configuration command:
By default, Cisco routers accept all DVMRP neighbors as peers, regardless of their DVMRP capability or lack of. However, some non-Cisco machines run old versions of DVMRP that cannot prune, so they will continuously receive forwarded packets unnecessarily, wasting bandwidth. The figure shows this scenario.
Figure 1 | 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 interface configuration command on the interface to the nonpruning machine. The figure 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 2 | 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, use the following command in interface configuration mode:
Command |
Purpose |
---|---|
Router(config-if)# ip dvmrp reject-non-pruners |
Prevents peering with nonpruning DVMRP neighbors. |
You can configure an interpacket delay of a DVMRP report. The delay is the number of milliseconds that elapse between transmissions of sets of packets that constitute a report. The number of packets in the set is determined by the burst value, which defaults to 2 packets. The milliseconds value defaults to 100 milliseconds.
To change the default values of the delay, use the following command in interface configuration mode:
Command |
Purpose |
---|---|
Router(config-if)# ip dvmrp output-report-delay milliseconds [burst] |
Configures an interpacket delay between DVMRP reports. |
To clear routes from the DVMRP routing table, use the following command in EXEC mode:
Command |
Purpose |
---|---|
Router# clear ip dvmrp route { * | route} |
Deletes routes from the DVMRP routing table. |
To display entries in the DVMRP routing table, use the following command in EXEC mode:
Command |
Purpose |
---|---|
Router# show ip dvmrp route [name | ip-address | type number] |
Displays the entries in the DVMRP routing table. |
This section provides the following DVMRP configuration examples:
The following example configures DVMRP interoperability for configurations when the PIM router and the DVMRP router are on the same network segment. In this example, access list 1 advertises the networks (198.92.35.0, 198.92.36.0, 198.92.37.0, 131.108.0.0, and 150.136.0.0) to the DVMRP router, and access list 2 is used to prevent all other networks from being advertised (the ip dvmrp metric 0 interface configuration command).
interface ethernet 0 ip address 131.119.244.244 255.255.255.0 ip pim dense-mode ip dvmrp metric 1 list 1 ip dvmrp metric 0 list 2 access-list 1 permit 198.92.35.0 0.0.0.255 access-list 1 permit 198.92.36.0 0.0.0.255 access-list 1 permit 198.92.37.0 0.0.0.255 access-list 1 permit 131.108.0.0 0.0.255.255 access-list 1 permit 150.136.0.0 0.0.255.255 access-list 1 deny 0.0.0.0 255.255.255.255 access-list 2 permit 0.0.0.0 255.255.255.255
The following example configures a DVMRP tunnel:
! ip multicast-routing ! interface tunnel 0 ip unnumbered ethernet 0 ip pim dense-mode tunnel source ethernet 0 tunnel destination 192.70.92.133 tunnel mode dvmrp ! interface ethernet 0 description Universitat DMZ-ethernet ip address 192.76.243.2 255.255.255.0 ip pim dense-mode