Subject: Re: DVMRP routing loop

From: Bill Fenner <[email-masked]>
Date: Tue, 7 Jan 1997 08:20:37 PST

>  There seems to be a routing loop going on somewhere in the MBone,
>since after withdrawing a specific route it keeps echoing back, every
>time with two to four worse metric and also another route is echoing
>back with varying metrics:

This is called "counting to infinity".  It is a side effect of
distance-vector protocols, and normally takes a few minutes to
complete.  However, Cisco's DVMRP implementation takes significantly
longer to count to infinity, so if there are any Ciscos in the loop
that is regenerating the route you will see it for a while.  I saw some
net 13 routes a day after I stopped advertising them.

  Bill

---

From: Petri Helenius <[email-masked]>
Date: Tue, 7 Jan 1997 20:31:12 +0200 (EET)

> net 13 routes a day after I stopped advertising them.
Do you know the reason for this or can you give an example scenario
how this can happen? We stopped announcing _all_ routes to MBone a
couple of hours ago.

The routes seem still be well alive and kicking:
(note the metric fluxuation...)

Any suggestions how to go isolating the problem are welcome.

fi-gw#sh ip dvmrp route 193.166.0.0
DVMRP Routing Table - 3891 entries
193.166.0.0/15 [0/15] uptime 00:04:00, expires 00:02:59
    via 193.166.2.225, Tunnel0, [version mrouted 3.8] [flags: GPM]
fi-gw#sh ip dvmrp route 193.166.0.0
DVMRP Routing Table - 3894 entries
193.166.0.0/15 [0/14] uptime 00:04:28, expires 00:02:36
    via 193.166.2.225, Tunnel0, [version mrouted 3.8] [flags: GPM]
fi-gw#sh ip dvmrp route 193.166.0.0
DVMRP Routing Table - 3890 entries
193.166.0.0/15 [0/14] uptime 00:04:44, expires 00:02:20
    via 193.166.2.225, Tunnel0, [version mrouted 3.8] [flags: GPM]
fi-gw#sh ip dvmrp route 193.166.0.0
DVMRP Routing Table - 3888 entries
193.166.0.0/15 [0/14] uptime 00:05:43, expires 00:01:21
    via 193.166.2.225, Tunnel0, [version mrouted 3.8] [flags: GPM]
fi-gw#sh ip dvmrp route 193.166.0.0
DVMRP Routing Table - 3823 entries
193.166.0.0/15 [0/14] uptime 00:06:43, expires 00:00:21
    via 193.166.2.225, Tunnel0, [version mrouted 3.8] [flags: GPM]
fi-gw#sh ip dvmrp route 193.166.0.0
DVMRP Routing Table - 3883 entries
193.166.0.0/15 [0/14] uptime 00:06:56, expires 00:00:08
    via 193.166.2.225, Tunnel0, [version mrouted 3.8] [flags: GPM]
fi-gw#sh ip dvmrp route 193.166.0.0
DVMRP Routing Table - 3881 entries
193.166.0.0/15 [0/14] uptime 00:07:12, expires now
    via 193.166.2.225, Tunnel0, [version mrouted 3.8] [flags: GPM]
fi-gw#sh ip dvmrp route 193.166.0.0
DVMRP Routing Table - 3878 entries
193.166.0.0/15 [0/20] uptime 00:00:02, expires 00:02:57
    via 193.166.2.225, Tunnel0, [version mrouted 3.8] [flags: GPM]
fi-gw#sh ip dvmrp route 193.166.0.0
DVMRP Routing Table - 3881 entries
193.166.0.0/15 [0/20] uptime 00:00:06, expires 00:02:53
    via 193.166.2.225, Tunnel0, [version mrouted 3.8] [flags: GPM]
fi-gw#sh ip dvmrp route 193.166.0.0
DVMRP Routing Table - 3890 entries
193.166.0.0/15 [0/18] uptime 00:00:26, expires 00:02:48
    via 193.166.2.225, Tunnel0, [version mrouted 3.8] [flags: GPM]
fi-gw#sh ip dvmrp route 193.166.0.0
DVMRP Routing Table - 3869 entries
193.166.0.0/15 [0/15] uptime 00:00:37, expires 00:02:57
    via 193.166.2.225, Tunnel0, [version mrouted 3.8] [flags: GPM]
fi-gw#sh ip dvmrp route 193.166.0.0
DVMRP Routing Table - 3872 entries
193.166.0.0/15 [0/15] uptime 00:01:13, expires 00:02:30
    via 193.166.2.225, Tunnel0, [version mrouted 3.8] [flags: GPM]
fi-gw#sh ip dvmrp route 193.166.0.0
DVMRP Routing Table - 3889 entries
193.166.0.0/15 [0/15] uptime 00:01:57, expires 00:02:47
    via 193.166.2.225, Tunnel0, [version mrouted 3.8] [flags: GPM]
fi-gw#sh ip dvmrp route 193.166.0.0
DVMRP Routing Table - 3894 entries
193.166.0.0/15 [0/14] uptime 00:06:56, expires 00:01:10
    via 193.166.2.225, Tunnel0, [version mrouted 3.8] [flags: GPM]

Pete

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 7 Jan 1997 10:53:39 -0800

>> net 13 routes a day after I stopped advertising them.

    We put in a bugfix to speed up counting to infinity. It has been 
    integrated in the following releases:

    11.0(12.4) 11.1(8.1) 11.2(2.2)

Dino

---

From: Bill Fenner <[email-masked]>
Date: Tue, 7 Jan 1997 12:06:06 PST

>how this can happen? We stopped announcing _all_ routes to MBone a

If you stop advertising a route, and there is a loop in the topology
(which there obviously is in the MBONE), the metric of the route can
count up through that loop and be re-injected where the loop touches
the rest of the network.  This normally happens quickly, as mrouted
will trigger routing updates and it should take seconds to resolve the
loop.  There is a Cisco bug which has been recently fixed which causes
it to ignore higher-metric updates from a neighbor, which causes this
process to take longer.  Also, the fact that Cisco doesn't trigger
routing updates causes it to take much much longer.

The reason you see the metric going back down is you end up with the
higher metrics from an all-mrouted loop (since they trigger updates),
and then a Cisco's route report interval triggers and since it didn't
accept the higher metric update, it will refresh the lower metric.

You could use "mtrace -P" to watch the path but I'd be surprised if
you learned anything interesting.

  Bill

---

From: Tony Li <[email-masked]>
Date: Tue, 7 Jan 1997 14:09:36 -0800 (PST)

complete. 

In fact, not all DV protocols have this count to infinity problem.
Alternatively, one can implement holddown, in which case one "holds the
route down" when the metric increases.  This allows the route to age
without continually circulating.  Continual triggered updates (a bandwidth
sink) are also not necessary with holddown.

Further, since the count to infinity is bounded by the dynamic range of the
metric, holddown allows you increase your range, thereby achieving either
more granularity in your metrics and/or larger networks.

Tony