Route table growth and hardware limits...talk to the filter

Sat Sep 8 22:50:25 UTC 2007

On Sat, 8 Sep 2007, Andrew - Supernews wrote:

> >>>>> "Forrest" == Forrest  <forrest at almighty.c64.org> writes:
> 
>  Forrest> Sure, this would fail if a network decided to only announce
>  Forrest> /24's for example without a larger aggregate, but how many
>  Forrest> networks are really doing that?
> 
> More than you probably imagine.
> 
> Consider the following table:
> 
>       asn | count | c24  | c23 
> ----------+-------+------+-----
>      9583 |  1100 | 1014 |  42
>      7018 |  1140 |  764 | 125
>     17488 |   560 |  557 |   0
>     19916 |   568 |  532 |   6
>       701 |   729 |  501 |  38
>      1221 |   474 |  380 |  14
>      1239 |   572 |  359 |  24
>       577 |   417 |  337 |  19
>       209 |   587 |  329 |  38
>     17557 |   291 |  270 |   1
>     10292 |   270 |  267 |   2
>      4802 |   345 |  259 |  25
>      6140 |   315 |  243 |  16
>      4323 |   483 |  242 |  12
>      7474 |   284 |  228 |   8
>      2386 |   295 |  218 |   9
>      3301 |   307 |  217 |  30
>       702 |   392 |  206 |  34
>      6746 |   279 |  200 |  41
> 
> In this, "count" is the number of prefixes originated by the AS that
> are not covered by any longer prefix (without regard to origin); "c24"
> is the number of those prefixes which are /24s; "c23" is the number
> which are /23s. I've cut this table off at 200 - the total number of
> uncovered /24 routes across all ASes is 51811.
> 
> Some of the above numbers would be worse if not for the presence of
> over-large route announcements from other providers (for example,
> Chinanet announce 125.96.0.0/14 even though 125.99.0.0/16 belongs
> to hathway.net in India (AS 17488); approximately 230 _more_ /24
> routes announced by Hathway are in this range).
> 
> 

You're right, that's way more than I would have imagined.  Ok, why not 
combine the idea of throwing away more specific routes that have the same 
AS path as the larger aggregate with a mechanism that will do something 
like the CIDR-REPORT and aggregate bunches of routes that all have the 
same AS path.  Or is the processing power/memory just not available to 
accomplish that?

It seems either option would be better for not breaking connectivity than 
to simply reject anything longer than a /21 in 64/7 for example.

Forrest