WB1 8.28 DVMRP Interoperability

8.28 DVMRP Interoperability

• Configure R4 for this task. Enable multicast routing and configure PIM
dense mode on the VLAN 146 interface and Loopack 0 interfaces.
• Create a DVMRP tunnel sourced off the Loopback 0 interface with a (nonexistent)
destination 204.12.X.100 (where X is your rack number).
• Advertise the VLAN 146 subnets to the DVMRP backbone with an offset
value of 3. Configure the use of DVMRP routes for RPF check by PIM on
VLAN 146 interface.

-----------------------------------------------------------------------------------

DVMRP or “Distance-Vector Multicast Routing Protocol” is defined in RFC 1075.
This protocol was implemented in the UNIX mrouted daemon and was the first to
gain more or less widespread adoption. DVMRP is based on RIP routing
protocol, and uses IGMPv1 messages to carry its routing information. For many
years, DVMRP was used as the core routing protocol of the MBONE – an
experimental set of multicast-capable networks, used to facilitate multicast
testing. However, DVMRP never was a scalable protocol, and most enterprises
use PIM as the standards based multicast routing protocol nowadays.

Similar to RIP, DVMRP propagates distance-vector information, but routing
updates carry subnets describing multicast sources and metrics to reach them.
The metric used by DVMRP is the same hop count used by RIP. When a router
receives a DVMRP update, it extracts the subnets contained in the update along
with their metrics and stores them in a separate multicast routing table. This table
is used to perform RPF checks only, not to route packets based on their
destination addresses.

DVMRP implements TRPB – Truncated Reverse Path Broadcasting, which is
another name for Constrained RPF. With respect to multicast flooding DVMRP is
very much similar to PIM Dense Mode - traffic is flooded using RPF checks and
then routers with no subscribers send “prune” messages upstream toward the
source.

Cisco IOS routers do not implement complete DVMRP stacks and rely on PIM for
multicast routing and signaling. However, Cisco routers might be configured to
border with a DVMRP domain and receive DVMRP routing updates. IOS routers
are capable of storing DVMRP information and using it to perform RPF checks
on packets received from the DVMRP cloud. At the same time, the routers will
generate DVMRP updates to cover sources in the PIM cloud and let DVMRP
systems receive multicast feeds. IOS routers may generate DVMRP prune and
graft messages in response to the respective PIM messages.

Use the command ip dvmrp interoperability to configure the IOS router
for interoperation with DVMRP systems. This will allow the router to accept/send
DVMRP updates and populate the multicast route cache. In order to use this
information for a particular interface, enter the ip dvmrp unicast-routing
interface-level command. This will make the router prefer cached DVMRP
information over unicast routes for RPF checks. Like RIP, DVMRP performs
automatic summarization when crossing major subnet boundaries. You may
disable this behavior, using the command no ip dvmrp auto-summary.

By default, the local router will only advertise directly connected subnets in
DVMRP updates. If you want to advertise more information, use the interface-level
command ip dvmrp metric <hops> [list <access-list>] [protocol <process-id>]
to redistribute static subnets or IGP networks to
all DVMRP neighbors on the interface. If you omit the protocol specification, the
command will only advertise connected routes. If you want to filter out certain
updates, use the metric value of zero to remove the matching subnets from the
DVMRP updates.

Another thing you might want to configure is a DVMRP tunnel. DVMRP tunnels
are supported on IOS routers to connect to remote DVMRP clouds over non-multicast
networks. Notice that you cannot configure a DMVRP tunnel between
two IOS routers, and these configurations are always unidirectional. DMVRP
tunnels are commonly used to link your multicast network with the MBONE. Use
the following syntax to configure a DVMRP tunnel:

interface tunnel 0
 ip unnumbered Loopback0
 ip pim dense-mode
 tunnel source Loopback0
 tunnel destination <IP in MBONE>
 tunnel mode dvmrp

Notice that PIM is enabled on the interface, to allow multicast feeds to flow to the
MBONE, even though no real PIM adjacencies are ever established over the
tunnel.


-----------------------------------------------------------------------------------

R4:
ip dvmrp interoperability
!
access-list 40 permit 155.1.0.0 0.0.255.255
!
interface FastEthernet0/1
 ip dvmrp metric 3 list 40 eigrp 100
!
interface tunnel 0
 ip unnumbered Loopback0
 ip pim dense-mode
 tunnel source Loopback0
 tunnel destination 204.12.1.100
 tunnel mode dvmrp

-----------------------------------------------------------------------------------

There is no way to fully verify DVMRP interoperability unless you have a real
DVMRP router. However, you may verify that the router actually generates
DVMRP updates using debug commands.

Rack1R4#debug ip dvmrp detail
DVMRP(0): Building Report for FastEthernet0/1
DVMRP(0): Report 155.1.146.0/24, metric 32
DVMRP(0): Report 155.1.10.0/24, metric 1
DVMRP(0): Report 155.1.8.0/24, metric 1
DVMRP(0): Report 155.1.5.0/24, metric 1
DVMRP(0): Report 155.1.58.0/24, metric 1
DVMRP(0): Report 155.1.45.0/24, metric 1
DVMRP(0): Report 155.1.67.0/24, metric 32
DVMRP(0): Report 155.1.108.0/24, metric 1
DVMRP(0): Report 150.1.6.0/24, metric 32
DVMRP(0): Report 150.1.5.0/24, metric 1
DVMRP(0): Report 150.1.10.0/24, metric 1
DVMRP(0): Report 150.1.8.0/24, metric 1
DVMRP(0): Delay Report on FastEthernet0/1
DVMRP(0): 12 unicast, 0 MBGP, 0 DVMRP routes advertised
DVMRP(0): Send Report on FastEthernet0/1 to 224.0.0.4