I'm going to start out just describing some cases in which routing instability can occur because of distances, and perhaps this will end up being a coherent document (but perhaps not).
When using the "ip dvmrp metric" command to export unicast routes into DVMRP, you must be careful that if the route is learned back via another DVMRP neighbor that the distance of the learned DVMRP route is not better than the unicast route that created it. Since IOS doesn't put redistributed routes into the DVMRP table, when it learns the route back (e.g. via a redundant path) it has no idea that it advertised it in the first place. Therefore, it will put it in the DVMRP table with a certain distance. DVMRP's default distance is 0, so by default, the DVMRP route will beat the unicast route.
After learning the DVMRP route with a better distance, the router will stop advertising the original unicast route (after all, it's not as good as the DVMRP route that we learned). It will instead advertise the DVMRP route that it learned, which was in turn a copy of the route that it originated. This triggers the route to count to infinity.
When the route finishes counting to infinity and times out of the DVMRP table, the cycle will start over, starting with the advertisement of the unicast route.
A slight wrinkle on the previous example doesn't actually include a distance misconfiguration, so either this web page should be renamed or this example should move elsewhere.
IOS does the same auto-summarization in DVMRP that it does with RIP, i.e. for updates on interfaces that aren't in a classful network, it will summarize to the classful address on that interface. This means that, for example, an update for 192.0.2.0/30 on the interface 192.168.1.1 will be auto-summarized to 192.0.2/24 unless the "no ip dvmrp auto-summary" command is configured on that interface.
However, the distance is compared before the auto-summarization occurs. If there's a route in the DVMRP table for 192.0.2/24, it won't be compared with the interface route 192.0.2.0/30 since they're clearly different routes. A routing update will contain both an advertisement for 192.0.2/24 with the metric from the DVMRP table and an advertisement for 192.0.2/24 (summarized version of 192.0.2/30) with a metric of 1 (possibly modified by an "ip dvmrp metric" command). This will cause the route to flap metrics since a higher-metric update is believed from the original parent of the route. The route will simply swap metrics back and forth between 1 and the diameter of the loop.
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).