Chapter 8 - PIM-DVMRP Networks

Chapter 8: PIM-DVMRP Networks

	Overview

	Consider these facts. Approximately 80 percent of the Internet routers are Cisco routers, and the Multicast Backbone (MBONE) runs on top of the Internet. The multicast protocol that is used on the MBONE is DVMRP and Cisco does not support a full implementation of DVMRP. So how do we get MBONE multicast traffic into a Cisco network? Very easily. Cisco routers interoperate with DVMRP routers for route exchange.

	At the outset of this chapter, it is important to clarify the distinction between a routing protocol and a routed protocol. OSPF, for example, is a routing protocol. Routing protocols are used to determine a path to the destination for a routed protocol. Routed protocols include IP, IPX, AppleTalk and DECNet. Routed protocols carry their data inside of specific packets. If we are using OSPF, then we are routing IP packets, which do not travel inside of OSPF packets; they travel inside of IP packets. The same argument can be made for IP multicast data, which travels inside of IP packets. The packet does not care how it gets routed to the destination as long as it gets there. It makes no difference if the network is running DVMRP, PIM-DM, or PIM-SM. Therefore, if a mechanism exists so that PIM and DVMRP can exchange routes, then MBONE packets can be delivered to non-DVMRP networks.

	No configuration commands can enable PIM-DVMRP interoperability; thus, no commands are needed because PIM-DVMRP interaction on a Cisco router is automatic. In the network of Figure 8-1, we have a Cisco router connected to an MBONE router running mrouted. When the DVMRP router sends a periodic neighbor probe message on the common interface between the two routers, the Cisco router realizes that a DVMRP router is out there and PIM-DVMRP interoperability will be automatically enabled.

	Figure 8-1: PIM router discovery of a DVMRP neighbor

	The interaction between the two domains depends on the type of connection between them. In a tunnel connection, the PIM router does not respond to the neighbor probe, but other information is exchanged. When the PIM router receives a DVMRP route report, the DVMRP routes are installed in a separate DVMRP routing table on the PIM router. The PIM router then poison-reverses the appropriate routes learned from the DVMRP router and sends a route report to the DVMRP neighbor. Selected routes from the unicast routing table are also advertised in the route report, while DVMRP probes and grafts are exchanged between the PIM and DVMRP routers over the DVMRP tunnel (see Figure 8-2).

	Figure 8-2: DVMRP-PIM exchanges through a DVMRP tunnel.

	For a non-tunnel connection, such as ethernet, the information exchange is modified slightly from the tunnel case (see Figure 8-3). Again, DVMRP probes are not sent by the PIM router. If the PIM routers in Figure 8-3 send a DVMRP neighbor probe onto the ethernet network, then the other PIM neighbor would receive them and think that the other PIM router is a DVMRP router.

	Figure 8-3: DVMRP-PIM exchanges over a regular interface.

	The route report only contains selected routes from the unicast routing table and does not contain poison-reversed DVRMP routes, as in the tunnel case. Received DVRMP route reports are actually ignored by the PIM routers. Although Prunes, Grafts, and Graft Acknowledgments are also exchanged, Prunes from the DVMRP neighbor are also ignored. The PIM routers sends IGMP joins for any group that has IGMP state on the PIM routers. This makes the DVMRP router think that hosts on the ethernet have joined the group, causing the DVMRP router to forward traffic for these groups onto the ethernet. Obviously, the PIM routers do not act like a true DVMRP router. An interface command that you can use to instruct the PIM routers to behave more like a DVMRP router on a multi-access network is

	ip dvmrp unicast-routing

	The interface command causes routes received in DVMRP Report messages to be cached in the DVMRP routing table; these routes will have preference over routes in the unicast routing table. Also, IGMP Joins for groups that have state on the PIM router will no longer be sent (see Figure 8-4). This command is not used to enable DVMRP between Cisco routers but to force the router to act more like a DVMRP router when there is a non-Cisco DVMRP neighbor. IGMP Group Joins no longer need to be sent to the DVMRP neighbor because the PIM router sends poison-reversed routes in the route report that inform the DVMRP neighbor which traffic needs to be forwarded to the PIM neighbor. The Cisco router now functions more like a true DVMRP router, except that DVMRP neighbor probes are not being sent and received Prunes are still ignored.

	Figure 8-4: PIM routers configured to exchange DVMRP route reports

Route Exchange

	Which unicast routes from the local routing table are reported to the DVMRP neighbor? By default, only the directly connected routes are reported. For example, in Figure 8-5, we have a PIM-DM-enabled router connected through a DVMRP tunnel to an MBONE DVMRP router. The configuration for the PIM router is given below.

	Figure 8-5: Connecting to the MBONE with a DVMRP tunnel

	interface Ethernet 0

ip address 10.1.1.1 255.255.255.0

ip pim dense mode

	interface Serial 0

ip address 10.1.2.1 255.255.255.0

ip pim dense mode

	interface Tunnel 0

ip unnumbered Ethernet 0

ip pim dense-mode

tunnel source Ethernet 0

tunnel destination 10.1.1.2

tunnel mode dvmrp

	The routing table for the PIM router contains the directly connected routes and any routes learned through a dynamic unicast IP routing protocol. Assume that for now the unicast routing table contains only the directly connected routes and that the DVMRP route advertises two routes:

	144.223.136.0/24

	Metric = 5

	156.26.31.0/24

	Metric = 7

	When the PIM router receives the routes, the metric is increased by one and the routes are placed in the local DVMRP routing table, which contains

	144.223.136.0/24

	Metric = 6

	156.26.31.0/24

	metric = 8

	These routes are then reported back to the DVMRP router and are oisoned-reversed. The routes from the local DVMRP table sent in the route report are

	144.223.136.0/24

	metric 38

	156.26.31.0/24

	metric 40

	The routes that are reported from the unicast routing table to the DVMRP router are

	10.1.1.0/24

	Metric = 1

	10.1.2.0/24

	Metric = 1

	Notice that a default metric of one hop is used for the routes reported from the unicast routing table. How do we advertise non-connected networks from the unicast routing table? The answer is with the following interface command on the tunnel interface:

	ip dvmrp metric metric [list access-list] {[protocol process-id] | dvmrp]

ip dvmrp metric metric route-map map-name

	metric

	Metric to be used for the routes in the DVMRP route report. The value can be between 0 and 32. A value of 0 prevents a route or routes from being advertised. A value of 32 indicates infinity or unreachable.

	list access list

	Optional. A standard IP access list can be used to control which routes are reported.

	protocol

	Optional. Unicast routing protocol name (rip, igrp, eigrp, ospf, bgp, isis, static, or dvmrp).

	process-id

	Optional. Unicast routing protocol process ID.

	dvrmp

	Optional. Allows routes in the DVMRP routing table to be filtered or have their metric adjusted.

	route-map

	Filter the unicast routes that are reported using a route map.

	map-name

	ip dvmrp metric <metric>

	The configuration for the DVMRP tunnel would be

	interface Tunnel 0

ip unnumbered Ethernet 0

ip pim dense-mode

ip dvmrp metric 1

tunnel source Ethernet 0

tunnel destination 10.1.1.2

tunnel mode dvmrp

	What we have done is make a very serious mistake. The dvmrp metric command applies to every route in the unicast routing table. This is not too serious, however, if the unicast routing table is small. If the table is large, on the order of thousands of routes, then all these routes will be injected in the DVMRP router and the MBONE. When something like this occurs, we usually need a rule to remind us not to do it:

	When using the command ip dvmrp metric, always use an access list.

	Another good rule when connecting PIM and DVMRP is to always use a tunnel, because a tunnel gives us the maximum DVMRP capability.

	If we have the routes 172.16.1.0/24 and 202.5.6.0/24 in our routing table, for example, and we only want to advertise the 172.16.1.0 network, then we could use the access list shown below:

	access-list 1 permit 172.16.1.0 0.0.0.255

access-list 1 deny any

	The modified tunnel configuration would now contain

	interface Tunnel 0

ip unnumbered Ethernet 0

ip pim dense-mode

ip dvmrp metric 1 list 1

tunnel source Ethernet 0

tunnel destination 10.1.1.2

tunnel mode dvmrp

	access-list 1 permit 172.16.1.0 0.0.0.255

access-list 1 deny any

	If the value of the metric is 0, then this means the indicated routes will not be advertised. Let s look at some examples to illustrate some of the permutations of this command.

	ip dvmrp metric 0

	Do not advertise any of the routes in the unicast routing table. The same effect can be achieved by not even using this command.

	ip dvmrp metric 0 list 1

	Denies routes in list 1 but advertises others with a metric of one.

	ip dvmrp metric 1 eigrp 100

	Advertises EIGRP routes in the routing table with a metric of one.

	ip dvmrp metric 0 dvmrp

	If your network has more than one PIM-DVMRP boundary router, then you may want to prevent DVRMP routes learned from one border from being advertised back into the MBONE by another boundary router. This form of the command will prevent that from happening.

Route Selection

	In the PIM-DVMRP network, there now exist many routes that have been learned from possibly many sources. Dynamic unicast routing protocols, unicast static routes, multicast static routes, and DVMRP can all be sources of routing information. When performing the RPF check for a particular multicast source, the route will be selected according to the following rules:

	1.		If the route is contained in both the unicast table and the DVMRP table, then use the route with the lowest administrative distance.

			The administrative distance is used to select a route when the route has been learned from routing sources with metrics that cannot be compared. A route learned from RIP, for example, has a hop count metric. The same route learned from OSPF has a metric that is related to the speed of the link. Therefore, the RIP and OSPF metrics are not comparable. The administrative distance is then used in determining the better route. The Administrative distance for RIP is 120 and for OSPF it is 110. The lowest administrative distance indicates a better route, so in this case the OSPF route would be selected over the RIP route. The default administrative distance for DVMRP routes is 0, meaning that DVMRP routes take precedence when determining the RPF interface for a particular multicast source. The administrative distance for DVMRP routes reported by a DVMRP neighbor can be adjusted using the interface command:

	ip dvmrp accept-filter access-list-number [distance] neighbor-list access-list-number

	access-list-number

	IP standard access list number (0 99). If 0, then all sources are accepted with the value of distance.

	distance

	Optional. The administrative distance of the reported route.

	neighbor-list

	Reports are only accepted from neighbors in the list.

	access-list-number

			For example, if the DVMRP neighbor is reporting the routes

	144.223.136.0/24

	Metric = 5

	156.26.31.0/24

	Metric = 7

	and we wish to set the administrative distance of the 156.26.31.0 network to 130 but leave the administrative distance for network 144.223.136.0 set to the default of 0, we could use the following configuration:

	interface Tunnel 0

ip unnumbered Ethernet 0

ip pim dense-mode

ip dvmrp accept-filter 1 130

tunnel source Ethernet 0

tunnel destination 10.1.1.2

tunnel mode dvmrp

access-list 1 permit 156.26.31.0 0.0.0.255

	2.		Use the DVMRP route if the administrative distances are equal.

	3.		If there is a static multicast route (mroute) and the administrative distance of the static mroute is less than or equal to the DVMRP route, use the static mroute.

	4.		If there are multiple routes in the selected table to the destination, use the longest match. For example, assume the two routes to the 156.26.0.0 network in the DVMRP table are

	156.26.0.0/16

156.26.31.0/24

			Each route contains the source address 156.26.31.1, but the route given by 156.26.31.0 in the DVMRP table would be preferred.

	Any time routes from different routing tables are compared, things can go wrong. Unicast and multicast traffic on the Internet and MBONE typically do not follow the same path due to the tunnels that connect DVMRP areas through non-DVMRP areas. In Figure 8-6, we have the following situation. Router B has a logical connection through a tunnel to the DVMRP router. Logically, when multicast traffic is sent by the source, the path the packets take is from the source to the DVMRP router, from the DVMRP router through the tunnel to router B, and then to the S1 interface of router A. Router A has a unicast route table but no DVMRP route table because router A has no DVMRP neighbors. When the packet arrives from router B, it does not pass the RPF test and therefore is discarded. Router A also has a unicast route to the source through the S0 interface, so the S0 interface is the RPF interface for the source.

	Figure 8-6: Logical path for multicast traffic

	The problem is illustrated differently in Figure 8-7. Here the actual physical path the multicast traffic takes from the source is displayed. The packet arrives at the DVMRP router and is encapsulated in an IP unicast packet. The packet is then sent to router A, which forwards the packet to router B. Router B removes the encapsulated multicast packet and checks the RPF interface. Because the packet is received on the tunnel interface, the RPF check passes and the packet is forwarded to router A, where we have already seen the RPF check fail, so the packet is discarded.

	Figure 8-7: Physical path for tunnel-encapsulated multicast traffic

	The solution to this problem is to avoid such situations. Whenever possible, the physical and logical paths should be the same. Stated differently, the unicast and multicast paths from the source to the receivers should be the same. This is not always possible, but it is a good goal to keep in mind.

	Another solution is to advertise the DVMRP table on router B to router A. This can be accomplished by using the interface command, ip dvmrp unicast-routing, on the serial interfaces connecting the two routers. Router B sends its DVRMP routing table to A, but router A does not poison-reverse the DVMRP routes and sends them back. In this case, split horizon is used on the link. If router A has the DVMRP table, then the RPF check succeeds because DVMRP routes take precedence over routes in the unicast routing table.

	Another situation arises when hooking a PIM-SM domain to a DVMRP domain and you have a sender in the PIM-SM domain and a receiver in the DVMRP domain. In Figure 8-8, the RP and the PIM-DVMRP border router are not the same router.

	Figure 8-8: When the border router and RP are different, multicast traffic cannot be forwarded to the DVMRP receiver.

	Recall from Chapter 7, Protocol Independent Multicast Sparse Mode, that PIM-SM can be thought of as having two distinct trees. One tree is from the source to the RP and the other tree is from the RP to the receivers. Senders and receivers register to the RP and, in this case, the receiver s Join does not get propagated to the RP. When the sender sends the first multicast packet, the directly attached router registers with the RP-creating state (S,G) in the RP. The receiver joins by sending an IGMP Join to the DVMRP router and the DVMRP router creates a (*,G) state. Because the RP does not know to forward packets to the receiver in the DVMRP domain, the packets never reach it. An easy solution for this problem is to make the RP the border router by either attaching it directly to the DVMRP router or by making it the current border router (see Figure 8-9).

	Figure 8-9: When connecting to the MBONE, make the RP the border router.

DVMRP Configuration Commands

	We have already seen some of the commands that can be used to configure the route exchange process between a DVMRP and a PIM router. This section will present the rest of the commands that can be used to fine-tune this process.

	ip dvmrp metric-offset [in | out] increment

	in

	Optional. The value of increment is added to routes in incoming DVMRP route reports. The default increment for in is 1.

	out

	Optional. The value of the increment is added to routes in outgoing DVMRP reports. The default increment for out is 0.

	increment

	Value added to the routes in a DVMRP route report.

	Use this interface command to adjust the metric of DVMRP routes being received on an interface (in) or reported to a neighbor (out). The default value when applied to incoming routes is 1 and the default value applied to outgoing routes is 0. But be careful, this command adds the same metric to all incoming or outgoing routes.

	ip dvmrp output-report-delay delay-time [burst]

	delay-time

	Number of milliseconds between DVMRP route reports.

	burst

	Optional. Number of packets in a set of route reports. The default value is 2.

	Use this interface command to send the route reports to a neighbor. DVMRP typically runs as mrouted on UNIX machines, and if the Cisco router has a large DVMRP routing table, then it is possible for the route reports to overload the DVMRP router, preventing some of the routes from being received. Any missed routes consequently expire and are placed in hold-down. Subsequent reports may fix this problem for the routes missed in previous route reports, but other routes may be dropped in subsequent reports, causing route flapping to occur. The delay-time parameter is the time to wait between sending route report packets to the neighbor and the Burst parameter indicates how many reports to send. For example, if we use

	ip dvmrp output-report-delay 300 3

	and nine reports must be sent, then the sequence listed on the following page will be executed.

	1.		Send three reports.

	2.		Wait 300 milliseconds.

	3.		Send three reports.

	4.		Wait 300 milliseconds.

	5.		Send three reports.

	The default value for delay-time is 100 milliseconds and the default value of burst is 2.

	ip dvmrp route-limit count

	count

	Number of DVMRP routes that can be advertised. The default value is 7000.

	This global command limits the number of routes that can be advertised on an interface that has DVMRP enabled. When the first interface is configured with ip dvmrp unicast-routing, when a DVMRP tunnel is configured, or when a PIM interface hears a DVMRP neighbor, this command is automatically configured with a default limit of 7000 routes. This prevents flooding routes into DVMRP when the ip dvmrp metric command is accidentally misused.

	ip dvmrp route-hog-notification count

	count

	Number of routes allowed before a syslog message is sent. Default is 10,000 routes.

	This global command places a limit on the number of routes that can be advertised over a DVMRP-enabled interface, including tunnels during a one-minute interval. If the number is exceeded, a syslog message is sent. This is another method for determining if a misconfigured router is injecting too many routes. The default value is 10,000.

	ip dvmrp reject-non-pruners

	This is an interface command that prevents peering with a DVMRP neighbor that does not support pruning and grafting.

	ip dvmrp default-information {originate | only}

	originate

	Routes more specific than the default route (0.0.0.0) can be advertised

	only

	Only the default route (0.0.0.0) is advertised

	Here we have an interface command used to advertise the default network 0.0.0.0. to the DVMRP neighbor on the interface. The originate option allows more specific routes to be advertised. The only keyword prevents other routes from being advertised. Do not use this command to inject a default route into the MBONE.

	ip dvmrp auto-summary

	This interface command is enabled by default. Auto-summarization is when subnets are advertised as a classful network number. To turn off this feature, use the no form of the command.

	ip dvmrp summary-address address mask [metric value]

	address

	The summary IP address that is advertised.

	mask

	The mask for the summary address.

	metric value

	Optional. The metric that is advertised for the summary address. The default metric is 1.

	This command is used on an interface to summarize addresses in a route report. The summarization applies only to routes in the unicast routing table, not the DVMRP routing table, and the default metric assigned to the summarized route is one of the unicast routing table routes. This command can be used multiple times on an interface.