Subject: dvmrp table size

From: [email-masked]
Date: Wed, 3 Jun 1998 14:11:29 +0200 (MET DST)

Hello *,

we get since a few days routehog notifications on our cisco.

Normally we have up to 6000 dvmrp routes. At the moment we get
constantly the warning that 9000+ routes/per minute are coming from
our tunnel to the US.
The actual dvmrp table size has grown to around 7500 entries.

%DVMRP-1-ROUTEHOG: Receiving 9993 routes from 204.70.74.61 (Tunnel8) in the last 00:01:05
%DVMRP-1-ROUTELIMIT: Exceeded route-limit of 7000 routes, check your
access-lists

Who or what causes this ? Any ideas ?

regards, Peter H.

##   Network Operation Center, DFN-Verein Geschaeftsstelle Stuttgart   ##
## http://www.noc.dfn.de/ finger [email-masked] [email-masked] ##
##             >>>>>>  mailto:  [email-masked]  <<<<<<               ##
##      Phone: 0711-63314-112, FAX 0711-63314-134 (business hours)     ##

---

From: Naohiro Shichijo <[email-masked]>
Date: Wed, 03 Jun 1998 21:38:25 +0900

I have no idea about the reason of this phenomena.
In my site, rapid increase of routes (around 1k) happened on last Thursday.
Today's average route# is 7.5k.
(http://jus.race.u-tokyo.ac.jp/mroutes/)

From: [email-masked]
Subject: dvmrp table size
Date: Wed, 3 Jun 1998 14:11:29 +0200 (MET DST)

---

From: "John M. Zwiebel" <[email-masked]>
Date: Wed, 03 Jun 1998 09:01:28 -0700

^ 
 ^ Hello *,
 ^ 
 ^ we get since a few days routehog notifications on our cisco.
 ^ 
 ^ Normally we have up to 6000 dvmrp routes. At the moment we get
 ^ constantly the warning that 9000+ routes/per minute are coming from
 ^ our tunnel to the US.
 ^ The actual dvmrp table size has grown to around 7500 entries.
 ^ 
 ^ %DVMRP-1-ROUTEHOG: Receiving 9993 routes from 204.70.74.61 (Tunnel8) in the 
    last 00:01:05
 ^ %DVMRP-1-ROUTELIMIT: Exceeded route-limit of 7000 routes, check your
 ^ access-lists
 ^ 
 ^ 
 ^ Who or what causes this ? Any ideas ?
 ^ 

If you want to change this, use these commands.

    [no] ip dvmrp routehog-notification <route-count>
        This configures the number of routes allowed within an approximate
        one minute interval before a syslog message is isssued warning
        that there maybe a route surge going on in the MBONE. This is
        typically used to detect quickly when someone has misconfigured their
        routers to inject a large number of routes into the MBONE. The default
        value is 10,000. You can find a running count in the "show ip igmp
        interface" display. When the count is exceeded, you'll see an
        "*** ALERT ***" string appended to the line. [10.2]

    [no] ip dvmrp route-limit <route-count>
        This command limits the number of DVMRP routes advertised over
        an interface enabled to run DVMRP. That is a DVMRP tunnel, an
        interface where a DVMRP neighbor has been discovered, or an interface
        configured to run "ip dvmrp unicast-routing". The default value is
        7000. This command will be automatically generated to the configuration
        file when at least one interface is enabled for multicast routing.
        This command is necessary so misconfigured "ip dvmrp metric" commands
        don't cause massive route injection into the MBONE. The "no" version
        of the command configures no limit. [11.0]

 ^ 
 ^ regards, Peter H.
 ^ 
 ^  
 ^ ##   Network Operation Center, DFN-Verein Geschaeftsstelle Stuttgart   ##
 ^ ## http://www.noc.dfn.de/ finger [email-masked] [email-masked] ##
 ^ ##             >>>>>>  mailto:  [email-masked]  <<<<<<               ##
 ^ ##      Phone: 0711-63314-112, FAX 0711-63314-134 (business hours)     ##

------------------------------------------------------------------------------
	John Zwiebel                       Phone: 408-526-5303
	Cisco Systems Inc.                 
	Multimedia Group

---

From: Hugh LaMaster <[email-masked]>
Date: Wed, 3 Jun 1998 14:07:30 -0700 (PDT)

> (http://jus.race.u-tokyo.ac.jp/mroutes/)

The most likely explanation of a sudden 1k spike is that someone is
running PIM on an exchange router and has accidentally configured the
deadly "ip dvmrp metric"  command to include a much larger set of unicast
routes than intended.  Anybody out there change their PIM configuration on
such a router last Thursday?  If so, did you use an access list? 

> > constantly the warning that 9000+ routes/per minute are coming from

Another source of instability can be caused by a Cisco over-running
the input rate on neighbors.  The cure is:

ip dvmrp output-report-delay 100 1

AFAIK, this is always safe.

> > %DVMRP-1-ROUTELIMIT: Exceeded route-limit of 7000 routes, check your

A lot of people may have the implicit route-limit of 7000.
When the number of actual routes exceeds this, you generate
your own instability.  The way to fix this is to increase
the route limit on your Cisco.  e.g.:
 
ip dvmrp route-limit 10000

Now then, what should N (10,000 above) actually be?
In looking at the DVMRP routing table, I see an 
awful lot of routes which could and should be 
aggregated.  There are a lot of /16 networks
which are announcing O(100) /24 routes.  If ten
such sites could fix this, it would pull the
number of routes down enough to fit within the
default.  Granted, for complicated topologies,
it may not be a trivial fix, but I bet there must
be at least 10 such sites with simple topologies.

How about a few of these?  Anybody recognizing their
own network number care to go first?

9.2.0.0/16	(?)
36.0.0.0/8	**
128.103.0.0/16	**
128.118.0.0/16	**
128.162.0.0/16	**
128.178.0.0/16	**
130.62.0.0/16	(?)
134.60.0.0/16	**
134.68.0.0/16	**
134.93.0.0/16	**
137.224.0.0/16	**
137.248.0.0/16	**
140.173.0.0/16	**

:

(**) == most of the above appear to be running PIM
on a large network and are not auto-summarizing
for some reason or have it turned off, resulting
in a route per subnet being advertised.

(Many more, I just eyeballed the DVMRP routing table and 
looked for two pages of routes with the same prefix
starting at the lowest address.  High addresses are not
exempt.)

There may be some reason why one or two of them can't 
aggregate, but, I bet a lot of them can.  The Cisco
command needed is:

ip dvmrp summary-address

BTW, it seems that there are still a critical mass of
non-pruners out there.  It sure would be nice if they
could all be eliminated.  How many people run:

ip dvmrp reject-non-pruners

Corrections/Additions/Deletions gratefully accepted.

--
 Hugh LaMaster, M/S 233-21,    ASCII Email: [email-masked]
 NASA Ames Research Center     Or:          [email-masked]
 Moffett Field, CA 94035-1000  No Junkmail: USC 18 section 2701
 Phone: 650/604-1056           Disclaimer:  Unofficial, personal *opinion*.

---

From: Peter Heiligers <[email-masked]>
Date: Thu, 4 Jun 1998 09:43:12 +0200 (MET DST)

Hello John,

raising the limits of "routehog-notification" and "ip dvmrp route-limit"
was not the cure i had in mind.

When the number of advertized dvmrp routes suddenly rises, then there was
almost every time a failure somewhere.

Peter

---

From: [email-masked] (Jeremy Hall)
Date: Thu, 4 Jun 1998 05:56:57 -0400 (EDT)

A routelimit of 7000 is too low.

---

From: [email-masked]
Date: Thu, 4 Jun 1998 12:36:27 +0200 (MET DST)

As i said in the first mail on this subject, the "normal" dvmrp table
size we have since quite some time is up to 6000 entries. Everytime
the table size came close to or over 7000 routes there was a failure
somewhere. As it was this time.

So 1000+ normal size sounds reasonable to me.

What routelimit would you suggest ?  What about discovering failures ?

Peter

---

From: [email-masked] (Jeremy Hall)
Date: Thu, 4 Jun 1998 07:25:33 -0400 (EDT)

I'd say 10,000 is reasonable.

---

From: Karl Auerbach <[email-masked]>
Date: Thu, 4 Jun 1998 12:48:18 -0700 (PDT)

> almost every time a failure somewhere.

In other words you want something that looks not just at the absolute
number of route entries but at the rate of change in that number?

(I've found a need for similar things when watching link error rates --
significant changes in a rate or errors is more important than the rate
itself.)

In any case, how might we express such a test?  An increase/decrease of so
many percent in such and such a time?  Or would it be better to do an
increase/decrease of so many entries in such and such a time?

Or something else?

		--karl--

---

From: [email-masked]
Date: Fri, 5 Jun 1998 10:55:20 +0200 (MET DST)

> > almost every time a failure somewhere.
 
 Probably I got a little bit misunderstood. 

 I wanted to say that i didn't understood the advice to increase the
countervalues to get rid of the log messages.I want to know what
happens to the dvmrp routing table especially since the most sudden
rises in routing table size are caused by misconfiguration somewhere.
 And one doesn't get any information about rises if the thresholds are
 quite high.

 > significant changes in a rate or errors is more important than the rate

 It is probably very usefull to have a value which tells you something
 about the variation of link error rates but i doubt if its also
usefull to have one for the variation of the routing table size.

Peter

---

From: Stephen Casner <[email-masked]>
Date: Mon, 8 Jun 1998 18:30:20 -0700 (Pacific Daylight Time)

>  And one doesn't get any information about rises if the thresholds are

I think it is fine to leave the "routehog-notification" limit at a
lower value so that you do continue to get warning messages as
problems crop up.

However, having the "ip dvmrp route-limit" too low causes additional
instability in the routing updates.  I'd like to see everyone raise
that limit to 10000 or more.  The idea was to protect against large
routing tables from other sources being dumped into DVMRP, but now the
list of valid or mostly valid DVMRP routes has grown large enough to
bump into the limit.
							-- Steve

---

From: Hugh LaMaster <[email-masked]>
Date: Mon, 8 Jun 1998 21:08:48 -0700 (PDT)

> list of valid or mostly valid DVMRP routes has grown large enough to

I agree, mostly.  That is, it can't be a good thing to limit to 7000
routes when there are actually 8000.  However, before long, there will be
10000, then 15000, and so on, unless people start getting more aggressive
about aggregation. I see a lot of /16 networks which appear to be
needlessly advertising 100 /24 subnets individually.  I'm sure there are
valid reasons for some of these, but I bet most of them could easily be
aggregated into a single route.

---

From: [email-masked]
Date: Tue, 9 Jun 1998 13:59:45 +0200 (MET DST)

Hugh LaMaster writes:
 > routes when there are actually 8000.

 I don't want to be picky, but there are actually < 6000

  However, before long, there will be
 > 10000, then 15000,
 
 No hierachical multicast routing before that point ?

 Peter

---

From: Hyang-ah Kim <[email-masked]>
Date: Wed, 10 Jun 1998 03:20:27 +0900 (KST)

>  No hierachical multicast routing before that point ?

    Well, I'd like to talk about another story.
    Will the routing table size become smaller when we deploy 
    any hierarchical multicast routing structure (such as BGMP) 
    still using DVMRP as MIGP ? Or need modify DVMRP or use 
    other routing protocol as MIGP? 

Hyang-ah Kim
CS Dept. KAIST

---

From: John Meylor <[email-masked]>
Date: Tue, 09 Jun 1998 11:38:17 -0700

>  > However, before long, there will be

And hopefully more as multicast deployment continues. 
The key is to treat these routes as interdomain
routes, rather than as as globally shared IGP.

>  No hierachical multicast routing before that point ?

 Yes, you can address many hierarchical routing issues for 
multicast just as you can do for unicast, by utilizing PIM and 
BGP or Multicast BGP (MBGP) to provide routes for RPF checks.
(MBGP allows you to designate certain prefixes for the 
multicast RPF check when your unicast and multicast
paths-and/or-policies are different.)

  This approach takes advantage of all the BGP machinary
and policy guidelines which have been worked out for
unicast hierachical routing over the years.
 This allows: EGPs externally, IGPs internally.

- John

---

From: Stephen Casner <[email-masked]>
Date: Tue, 9 Jun 1998 11:48:51 -0700 (Pacific Daylight Time)

> aggregated into a single route. 

Absolutely.  Conscientious MBone participants should aggregate their
networks to the maximum extent possible.  For example, when using a
Cisco router, with the "ip dvmrp summary-address" command.  Note that
it makes sense to do this in some cases even when not all the
components of the aggregate are already included in the table.  That
is, even if not all the subnets within the /16 have multicast
connectivity, it still makes sense to advertise the aggregate, and the
aforementioned command will accomplish this.  Even if some subnet
within the aggregate has a different route, that will work because the
longest match is preferred.

>  I don't want to be picky, but there are actually < 6000

True, there are < 6000 "good" routes.  But the "ip dvmrp route-limit"
needs to be high enough to allow for small routing mishaps without
causing some of the good routes to get truncated.  I think having the
route limit turned on by default is probably a good thing to keep
someone who is setting up a router for the first time from
accidentally dumping in 40000 routes.  But the problem comes in
choosing a value for the default, since the lifetime of any particular
code release may be quite long.
							-- Steve

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 09 Jun 1998 16:00:32 -0400

In message <[email-masked]> you wri
>longest match is preferred.

We spent a lot of time discussing how do properly handle pruning and
grafting of aggregates. The outcome is in the latest DVMRP draft.
Before everyone starts wildly configuring aggregates, I would advise
that some testing be done to ensure it is working properly with
the software you are using.

Personally, I would rather have more routes in my routing table,
if the other choice is blackholes and non-pruning.

Lastly, I should mention that the current use of DVMRP on the mbone
is completely outside the scope of the protocol and rather than
expending too much energy on solutions that are known to be flawed,
we should be pitching in to help increase the pace of designing/deploying
solutions that we think might scale better.

FWIW,
Tom

---

From: Hugh LaMaster <[email-masked]>
Date: Wed, 10 Jun 1998 08:24:28 -0700 (PDT)

On Tue, 9 Jun 1998, Tom Pusateri wrote:

> In message <[email-masked]> 

> >> routes when there are actually 8000.  However, before long, there will be

My intention is not to encourage people to spend a lot of time
on this.  However, what I see are quite a few university networks
running PIM, and advertising 100's of /24's instead of one /16.
I think that can be fixed very easily, and will reduce instability
caused by "too many routes".

> the software you are using.

True.  AFAIK, in the simple-topology, isolated PIM domain with
one route in, case, on Cisco routers running PIM, this works.
And, that is where many of the routes are typically coming from.

> if the other choice is blackholes and non-pruning.

Clearly.  I recall a discussion of this about a year ago, but,
have since forgotten how blackholes arise.  Perhaps someone 
could remind me (us) so that this cab be avoided.

> solutions that we think might scale better.

Agreed.  Unfortunately, routing instability caused by "too many"
DVMRP routes is also causing the expenditure of energy, so, it
would be helpful if those who are in a position to safely and
easily aggregate, do.

That will buy a little time until the solutions which scale better
become widespread.