Subject: >10k MBONE routes?

From: [email-masked]
Date: Tue, 11 Feb 1997 16:15:32 +0100

Hi,

to protect my Cisco routers (which connects our PIM cloud(s) to
the MBONE) I've imposed a limit on the number of DVMRP routes we
accept.  Currently we have that limit set to 7000.  For the past
couple of days I've repeatedly (continously?) seen log messages
saying that the number of routes is too large (10-11.000 routes).

Is this as it should be?  The DVMRP routing table seems to
currently be at a little over 6.000 entries.

What is a reasonable limit to impose these days?  If the size at
6.000 routes is as it should be, 7.000 seems a bit low, while the
10-11k routes still seems to be configuration mistakes (?).

Is the MBONE again showing its fragility, or is the source of the
problem closer to (my) home?

- Håvard

---

From: Petri Helenius <[email-masked]>
Date: Tue, 11 Feb 1997 18:43:47 +0200 (EET)

> currently be at a little over 6.000 entries.

That shouldn't be the case, it has been hovering around 3500 for quite
a while. Maybe somebody should start plotting a trend of the count of
DVMRP routes so the 'correct' value would be more easily determined.
 > problem closer to (my) home?
I'm not sure whether they have been around for longer but I see an
extensive amount of subnets for A and B class networks. Like about a
hundred for each of them.

Pete

---

From: Dave Thaler <[email-masked]>
Date: Tue, 11 Feb 1997 15:19:01 -0500 (EST)

> DVMRP routes so the 'correct' value would be more easily determined.

"Start" plotting?  I've been doing this for over 8 months now, and the
URL has been posted a couple of times (jhawk even put it up on the screen
at the last mboned...)

For example:

http://sydney.eecs.umich.edu/cgi-bin/routes?30

will show you the trend over the last 30 days. Times when it goes to zero 
are when my site was cut off from the MBone.  You'll see that it jumped 
from around 4000 to around 6000 about a week ago.

The graphs are generated on the fly and there are 3 levels of granularity:
   7 days or less has 10-min intervals
     8 to 30 days has 12-hour intervals
     over 30 days has 24-hour intervals
Graphs for 3 days or less graph "reachable" (non-infinite metric) routes in 
addition to total routes.

-Dave

---

From: Bill Fenner <[email-masked]>
Date: Tue, 11 Feb 1997 18:47:23 PST

In message <[email-masked]> you write:
>You'll see that it jumped 

At which time, I sent a message to mbone-eu-op suggesting that it was
a router in France.  I suppose this means that no one paid attention.

  Bill

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 12 Feb 1997 09:20:45 +0100 (MET)

> a router in France.  I suppose this means that no one paid attention.

Bill: Can we cite you like this:

   "A router in france means mobody pays attention"

   ;-)))

---

From: Christian DONOT <[email-masked]>
Date: Wed, 12 Feb 1997 11:18:37 +0100 (MET)

Quoting > Bill Fenner wrote,
> a router in France.  I suppose this means that no one paid attention.

Hi Bill,

What's the means to find which router in France could be the source of
this problem.
If I look the internal routing tables in /usr/tmp/mrouted.dump I see
the neighbour router which annonce to my mrouted about 6000 entries.

About "I suppose this means that no one paid attention.", somebody in
France paid attention. Maybe your message will be passed unnoticed.

This mailing list is some times very talkative.

Christian

---

From: Bill Fenner <[email-masked]>
Date: Wed, 12 Feb 1997 07:48:09 PST

Christian,

  I sent the mail to the mbone-eu-op list, not the mbone list, since
mbone-eu-op has less traffic.

  I suspect one of two routers:
1) r-jusren.reseau.jussieu.fr might be injecting lots of routes on *one*
of its tunnels but not the others.  It then learns the routes from another
neighbor and stops advertising them since IOS doesn't advertise unicast
routes that it has in its DVMRP routing table.  This is what is causing
the routes to appear and disappear so much (and makes it really hard to
track down).
2) The unnamed, unreachable router 193.52.80.2 .  Since it doesn't support
mtrace and is not unicast-reachable, I can't tell if it's the culprit
and r-jusren is just a suspect because it's counting to infinity, or if
193.52.80.2 is just in a small topology loop and r-jusren is the real suspect.

  Bill

---

From: Christian DONOT <[email-masked]>
Date: Thu, 13 Feb 1997 09:44:10 +0100 (MET)

> the routes to appear and disappear so much (and makes it really hard to

Bill,

r-jusren.reseau.jussieu.fr and fmroute1-1.exp.edf.fr are both our
primary multicast routers in France. Both have a tunnel with
mae-bone.psi.net 1/64 or r-jusren and 3/64 for fmroute1-1.
Yesterday, mae-bone sent 4843 route to r-jusren or fmroute1-1
according r-jusren put down or not the tunnel with mae-bone.

Annex question : Did the threshold with mae-bone put to 128 ??

> 193.52.80.2 is just in a small topology loop and r-jusren is the real suspect.

As Stephane Richard said in its Email, the cisco 193.52.80.2 has a old
IOS version (10.X). There is one week ago, I said him that is'nt a
good for the MBone and said I'll cut certainely the tunnel with
oreste.inria.fr. I had'nt put this warning to execution. Today, the
193.52.80.2 is without MBone and will come back only with good IOS
version.

Christian

---

From: Jacky THIBAULT <[email-masked]>
Date: Thu, 13 Feb 1997 10:20:53 +0100 (NFT)

On Wed, 12 Feb 1997, Bill Fenner wrote:

[...]

> the routes to appear and disappear so much (and makes it really hard to

r-jusren knows only 2 unicast routes : jussieu-net (134.157.0.0) on one
interface and default (0.0.0.0) on the other...
So it can't never add (or suppress) ~2000 unicast routes to/from the
multicast routes.  Hopely, there is a "ip dvmrp route-limit 6000" command
on that Cisco (Version 11.2(3)...

These 6000 routes *seem* to come from mae-bone.psi.net.
For exemple at "Thu Feb 13 10:19:09 NFT 1997":

DVMRP Routing Table - 6434 entries
1.0.0.0/8 [0/7] uptime 00:01:05, expires 00:02:45
    via 192.41.177.247, Tunnel8, [version mrouted 3.8] [flags: GPM]
2.0.0.0/8 [0/7] uptime 00:01:05, expires 00:02:45
    via 192.41.177.247, Tunnel8, [version mrouted 3.8] [flags: GPM]
4.0.0.34/32 [0/6] uptime 00:01:04, expires 00:02:43
    via 192.41.177.247, Tunnel8, [version mrouted 3.8] [flags: GPM]
4.0.20.16/28 [0/6] uptime 00:01:02, expires 00:02:42
    via 192.41.177.247, Tunnel8, [version mrouted 3.8] [flags: GPM]
[...]

Sincerely
	jt

---

From: Bill Fenner <[email-masked]>
Date: Thu, 13 Feb 1997 08:30:18 PST

In message <[email-masked]> you w
>    via 192.41.177.247, Tunnel8, [version mrouted 3.8] [flags: GPM]

Those are actually "normal" routes.  (Even though 1/8 and 2/8 are
martians.)  Even so, the routes that are being injected stabilize in
the US for a while, for a reason that I don't understand, but after
they count to infinity they flap to France for about a minute (see my
previous email about how the router injects the routes and then learns
them so stops injecting them and they count to infinity).

The best way to track this is to use "mtrace -P 195.221.235" (195.221.235
was one of the routes that showed up last week).  Despite Christian's
earlier message about taking the tunnel down from oreste.inria.fr, my
current path is still:

-11  fmroute1-1.exp.edf.fr (192.70.92.133)  DVMRP  thresh^ 48  
-12  * oreste.inria.fr (192.93.1.34)  DVMRP  thresh^ 32  
-13  * * ? (193.52.80.2) doesn't support mtrace

  Bill

---

From: Petri Helenius <[email-masked]>
Date: Thu, 13 Feb 1997 19:28:22 +0200 (EET)

> -13  * * ? (193.52.80.2) doesn't support mtrace
Guess 'taking tunnel down' means different things at different sides
of the globe since it's up and running:
  192.93.1.34 -> 193.52.80.2 (193.52.80.2) [1/32/tunnel/leaf]

The address is also safely behind a firewall to be unreachable for
mrinfo or so.

Pete

---

From: Christian DONOT <[email-masked]>
Date: Fri, 14 Feb 1997 09:29:34 +0100 (MET)

Quoting > Petri Helenius wrote,
> The address is also safely behind a firewall to be unreachable for

Since on early message, Stephane Richard said "I can cut the tunneling
tomorrow morning if you think that is better to wait the new version of 
IOS (maybe 11.3 ?)" and I had verified, it was DOWN, so I had'nt put it
down on oreste.inria.fr. 
Now, it's down on oreste end tunnel and it'll be UP only when the
cisco on IP@ 193.52.80.2 will be on a good IOS version and with a good
configuration.

Christian

---

From: Petri Helenius <[email-masked]>
Date: Fri, 14 Feb 1997 14:19:48 +0200 (EET)

> cisco on IP@ 193.52.80.2 will be on a good IOS version and with a good
I checked the number of routes and we're down to the regular sub-4000
range now.

Thank you for bringing down the tunnel.

Pete

---

From: Bill Fenner <[email-masked]>
Date: Fri, 14 Feb 1997 07:53:07 PST

>cisco on IP@ 193.52.80.2 will be on a good IOS version and with a good

Thanks, Christian!  I'd like to point out that in this particular case,
the configuration was the thing that was relevant; any version of IOS
can be configured to inject its whole routing table.  But, in any case,
it's definitely best to wait until it's upgraded so that it handles
mtrace and pruning.

  Bill