Routing Multicast Traffic with DVMRP
Problem
You want to route multicast traffic by using the DVMRP protocol.
Solution
Cisco routers support DVMRP only as a gateway to PIM. So the configuration is remarkably similar to the PIM configuration. The key difference is in the ip dvmrp unicast-routing command, which tells the router to use the DVMRP multicast routing table instead of the usual PIM choice of the unicast routing table:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip multicast-routing
Router1(config)#interface FastEthernet0/0
Router1(config-if)#ip pim sparse-dense-mode
Router1(config-if)#ip dvmrp unicast-routing
Router1(config-if)#ip dvmrp summary-address 192.168.0.0 255.255.0.0
Router1(config-if)#end
Router1#
Discussion
Before saying anything else, we will stress once again that DVMRP is not our first choice for a multicast routing protocol. PIM-DM is simpler to implement and more efficient with router resources if you want a dense-mode protocol. And PIM-SM scales much better in larger networks or when there are many groups. In fact, Cisco routers do not provide a full implementation of DVMRP. They can take part in DVMRP neighbor discovery and route exchange, but internally the multicast processing is done using PIM. However, you can configure PIM to use the DVMRP routing table, which is what this recipe actually does.
DVMRP is defined in RFC 1075, and was the first widely implemented multicast routing protocol, forming the core of the Internet's original Multicast Backbone (MBONE). So the main reasons for implementing it today are to give compatibility with an existing DVMRP network. It is unlikely that anybody would want to implement a new production DVMRP network today, just as few people would want to implement any other routing protocol that hasn't been significantly updated since 1988 (the original publication date for RFC 1075).
The DVMRP protocol differs from PIM-DM in a fundamental way. Where PIM-DM uses the router's existing unicast routing table to determine the shortest path back to the source, DVMRP distributes and maintains its own internal routing table. This was needed because early multicast networks tended to use a lot of tunnels to allow multicast traffic to cross large network regions that supported only unicast routing. So the multicast network topology could be quite different from the unicast topology, necessitating a separate routing table.
DVMRP distributes routing information between adjacent routers by means of multicast packets sent on the globally defined well-known multicast address, 224.0.0.4. This process begins by exchanging neighbor information. Every router needs to know about all of its neighbors so that it can always determine the best path back to the source, which is the only way it can eliminate loops. This neighbor information is updated every 60 seconds by default. If a neighbor misses four consecutive updates, the router considers it dead and removes it from the routing tables.
These periodic updates also contain all of the multicast routing information for the network. If a route is not seen in two consecutive updates, then it is considered invalid if no longer used. It is removed from the tables if it remains invalid for two additional minutes. So when there are network problems, it is possible to have interruptions of up to two minutes.
Cisco does not offer a full DVMRP implementation. Instead, it gives the ability to make a gateway between DVMRP and PIM. This allows a Cisco router to perform many of the standard DVMRP functions, but it makes it impossible to use Cisco routers to build a pure DVMRP network. In particular, Cisco routers do not send any DVMRP Probe messages to establish new neighbor relationships.
However, when you enable PIM routing on an interface, the router also starts to listen for DVMRP announcements addressed to group 224.0.0.4. The Cisco router responds to these announcements by exchanging its routing tables with the DVMRP neighbors. However, by default, it does not use the DVMRP routing table it receives unless the interface has the command ip dvmrp unicast-routing enabled. This is particularly important in cases when the multicast topology is different than the unicast network topology, as in the DVMRP tunnel example in Recipe 23.12, for example.
Since DVMRP functionality on Cisco routers generally represents a gateway between pockets of PIM and DVMRP functionality, we have included another useful command in the recipe example. The command ip dvmrp summary-address tells the router to advertise only a summary route into the DVMRP network:
Router1(config-if)#ip dvmrp summary-address 192.168.0.0 255.255.0.0
This helps to simplify the multicast routing tables to save memory and improve overall efficiency.
In some cases, you might have a router connected to a segment with several DVMRP devices like Unix servers running mrouted. There are two ways that you can restrict what your router accepts from DVMRP devices, both are variants of the interface configuration command, ip dvmrp accept-filter:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip multicast-routing
Router1(config)#access-list 11 permit 192.168.1.17 0.0.0.0
Router1(config)#access-list 11 permit 192.168.1.18 0.0.0.0
Router1(config)#access-list 11 deny any
Router1(config)#interface FastEthernet0/0
Router1(config-if)#ip pim sparse-dense-mode
Router1(config-if)#ip dvmrp unicast-routing
Router1(config-if)#ip dvmrp accept-filter 0 neighbor-list 11
Router1(config-if)#end
Router1#
This version of the ip dvmrp accept-filter command restricts the allowed DVMRP neighbors. If this router receives DVMRP updates from any devices not in the specified access-list, it will simply ignore them. Note that we have used an access-list number of 0 in this command, indicating that all sources should be accepted.
The other version of this command specifies what ranges of multicast source address ranges this router will accept:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip multicast-routing
Router1(config)#access-list 12 permit 192.168.10.0 0.0.0.255
Router1(config)#access-list 12 deny any
Router1(config)#interface FastEthernet0/0
Router1(config-if)#ip pim sparse-dense-mode
Router1(config-if)#ip dvmrp unicast-routing
Router1(config-if)#ip dvmrp accept-filter 12 95
Router1(config-if)#end
Router1#
In this case, the router is only willing to listen to information about sources on the 192.168.10.0/24 network. And we have gone slightly further by specifying an administrative distance of 95 for these routes. When it hears about these multicast routes, this router will automatically give them a distance of 95. This will ensure that, if these same routes are learned by another method that has a better administrative distance, the router will not use them. For example, in Chapter 5 we saw that EIGRP has a default administrative distance value of 90 while OSPF has a value of 110. So this command will tell the router to use the DVMRP routes for constructing source-rooted multicast trees if the unicast route it has for the source is from OSPF. But if it has an EIGRP unicast route, it will use that route instead.
Note that the router will never use the DVMRP route for forwarding unicast traffic. It only uses this information for constructing loop-free trees back to the multicast source, which in turn tells the router which ports it can forward multicast traffic through.