Core Issue
istance Vector Multicast Routing Protocol (DVMRP) is modeled after Routing Information Protocol version 1 (RIPv1) with few differences and uses a flood and prune mechanism similar to Protocol Independent Multicast (PIM) dense mode. DVMRP builds its own unicast routing table to perform a Reverse Path Forwarding (RPF) check for forwarding traffic received from multicast sources, whereas PIM can use any unicast routing protocol for the same purpose.
DVMRP is widely used on Multicast Backbone (MBone), which is the IP multicast backbone on the Internet. Cisco devices do not support a full implementation of DVMRP, but have support for interoperating with a DVMRP device to interconnect PIM and DVMRP domains.
These are some of the key differences between the DVMRP implementation on a Cisco device and a regular DVMRP device:
- Cisco devices receive probe messages, but do not send them. Whereas regular DVMRP devices send and receive probe messages. However, this does not affect the PIM and DVMRP interoperability function.
- A DVMRP device maintains its state for each individual DVMRP neighbor and can prune traffic only if all the downstream neighbors send prune messages. Cisco devices do not maintain their state for each individual DVMRP neighbor. Therefore, a Cisco device connected to a DVMRP device on a multi-access segment ignores prune messages and continues sending multicast traffic, even if the DVMRP device tries to prune the traffic for a group. On a point-to-point link, Cisco devices accept prune messages and stop forwarding multicast traffic, since only one neighbor is connected over such a link.
Resolution
A Cisco device running PIM on an interface automatically enables DVMRP interoperability once it discovers any directly connected DVMRP neighbors, using the probe messages sent by the DVMRP devices. It then populates the DVMRP routing table with the information learned through the report messages received from the DVMRP neighbor. Though the prefixes available in the DVMRP domain are learned and populated in the DVMRP routing table, it is PIM that uses this information for an RPF check and makes forwarding decisions.
If a network to which a source belongs to is learned through DVMRP as well as another unicast routing protocol, PIM uses the DVMRP information for an RPF check, since it has a default administrative distance of 0. Networks available in the PIM domain can also be advertised using report messages to DVMRP devices. This is done for forwarding traffic from sources in the PIM domain to receivers in the DVMRP domain.
When a Cisco device running PIM is supposed to exchange information with a DVMRP device that is not directly connected, such as a device in MBone, a DVMRP tunnel has to be configured on the Cisco device. DVMRP tunnel configuration is also useful when a Cisco device is directly connected to a DVMRP device on a multi-access segment. Since the tunnel is treated as a point-to-point link, they accept prune messages and can be used to solve the problem of ignoring prune messages on multi-access networks.
Cisco devices can also be configured for DVMRP unicast routing, which advertises the routes learned from DVMRP neighbors to other PIM neighbors who can store them in their DVMRP routing table and use them for an RPF check on multicast traffic. This is helpful when there are different unicast and multicast topologies for a source in a network.
For more information on how to configure the basic DVMRP interoperability features, and other advanced features such as controlling the prefixes exchanged with a DVMRP neighbor, manipulating metrics and route summarization, refer to these documents:
RP (Routing Protocol) Related Technologies
Multicast
