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).