This page mostly contains rambling -- some facts but no hard and fast rules about how to make things work well.
IOS uses three RIBs: unicast, DVMRP, and MBGP. There is a 4th conceptual RIB, containing all "static mroute"s. When looking up a source, IOS looks in all 4 RIBs and then uses distance to select the route to use. The default distances can make it hard to use MBGP.
First, let's review the default distances:
| Protocol | Default Distance | RIB |
|---|---|---|
| Connected Interface | 0 | Unicast |
| Static MRoute | 0 | Static MRoute |
| DVMRP | 0 | DVMRP |
| Static | 1 | Unicast |
| EIGRP Summary Route | 5 | Unicast |
| MBGP External | 20 | MBGP |
| BGP External | 20 | Unicast |
| iEIGRP | 90 | Unicast |
| IGRP | 100 | Unicast |
| OSPF | 110 | Unicast |
| IS-IS | 115 | Unicast |
| RIP | 120 | Unicast |
| EGP | 140 | Unicast |
| MBGP Internal | 200 | MBGP |
| BGP Internal | 200 | Unicast |
The 4 lookups potentially result in 4 different routes. The first round of tie-breaking is performed using the distance, which defaults as above but can be modified in various ways. If there are multiple routes with the same distance, then table-based tie-breaking occurs: static mroutes are best, followed by the MBGP table, the DVMRP table, and finally the unicast table.
These distances work well enough if your unicast and multicast topologies are congruent. However, if they are not, you have to start playing with the distances to ensure that the distance for unicast-only routes is always higher than the distance of routes you want to use for multicast. In particular, this may mean that you want to reduce the distance of internal MBGP routes. You probably want distance(eMBGP) < distance(MIGP) < distance(iMBGP) < distance(eBGP). MIGP is whatever IGP you're using for multicast; the only one that Cisco supports is DVMRP, unless your unicast and multicast topologies are congruent internally. In that case, it's impossible to satisfy both this inequality and distance(eBGP) < distance(IGP) since IGP == MIGP. In that case, you basically have to hope that there are no routes for which you're depending on the [M]IGP that appear in the eBGP table.
If you are using static mroutes, in particular a default static mroute, it will cause trouble because it defaults to the absolute best (distance of 0 and in the static mroute RIB). The way to get around this is to install static mrouted with distance 255 in the static mroute RIB; this allows routes from the other RIB lookups to be used. For example, if Xerox were to use a static default mroute, we could install a static mroute for 13/8 with distance 255 to allow route lookups in the other RIBs. In this way, you can still perform dynamic routing for your local routes.
If you are using DVMRP, the default distance of 0 is sure to cause problems. By defualt, a DVMRP route wins over any other route except for a connected interface or a static mroute. Change the DVMRP distance with the global "ip dvmrp distance" command or with "ip dvmrp accept-filter" commands on each interface.
If you have static unicast routes, e.g. a static unicast for default pointing to Null0 since you're default-free, you can end up with strange multicast lookups. If a route is in the unicast table (generally has a high distance) and you have a route in the MBGP table (default distance of 20), you get the MBGP route. However, if there is a route in the MBGP table that is not in the unicast table (e.g. a network that's only globally advertised for multicast and not for unicast) you will match the static default route, which has a better distance than the MBGP route, and black-hole the traffic. Make sure that all of your static routes are positioned to match what you think they should match!
Bill Fenner - <fenner@research.att.com>
This material is based upon work supported by the National Science Foundation under Grant No. 9729498. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author and do not necessarily reflect the views of the National Science Foundation (NSF).