CIDR Aggregation Tool
Enke Chen
enke at mci.net
Mon Nov 27 14:39:35 UTC 1995
Avi,
Did you not see the aggregation report by Tony Bates on cidrd
posted periodically for the last couple of years? It lists
aggregation gains for each origin AS, rather than the BGP
neighbor in your numbers. IMHO, numbers based on origin AS
is much more useful.
If you need to invent wheels, let us at least invent better
wheels :-)
-- Enke
Date: Mon, 27 Nov 1995 01:34:55 EST
To: cidrd at iepg.org
From: Tony Bates <Tony.Bates at mci.net>
Subject: In the spirit...
Here's the latest top-30. Looks like UUNET-CANADA dropped a fair bit
from last time.
--Tony.
ASnum NetsNow NetsCIDR NetGain % Gain Description
AS2493 1047 576 471 45.0% i*internet
AS174 1493 1053 440 29.5% Performance Systems International
AS544 740 524 216 29.2% The DataNet IP Service
AS3848 425 236 189 44.5% WORLDLINX
AS568 759 572 187 24.6% Milnet FIXes--144(W)/145(E)
AS4628 240 54 186 77.5% APNIC-AS-BLOCK
AS1324 465 287 178 38.3% ANS New York City - DNSS 35
AS97 506 338 168 33.2% JvNCnet
AS3602 285 175 110 38.6% Intergrated Network Services Inc.
AS4230 195 93 102 52.3% EMBRATEL-BR
AS1717 649 556 93 14.3% RENATER
[....]
> Date: Sun, 26 Nov 1995 23:00:49 -0500
> From: Avi Freedman <freedman at netaxs.com>
> To: big-internet at munnari.OZ.AU, cidrd at iepg.org, nanog at merit.edu
> CC: freedman at netaxs.com
> Well, after observing the debates about What To Do About The Routing Table
> Size, I decided to work on some informal tools to examine the current
> routing table space for possible aggregations.
>
> Right now, the raw data is the routing table from the Net Access MAE-East
> router.
>
> It only searches for aggregates /15 < x < /25 right now - ignoring some
> fairly obvious aggregation-suggestions in the /8 < x < /16 range.
>
> The results are up at http://routes.netaxs.com and the some of the caveats
> are listed on the web page, but are:
>
> 1) When the Net Access MAE-East router has multiple identical routes that
> point to the same next-hop (192.41.177.x), the system only uses the one
> first listed in the cisco 'sho ip bgp summ' output - even though that's
> not always the 'best' route.
>
> 2) When an AS advertises both an aggregate and a specific, the specific
> is 'dropped' by the aggregator. If the input is:
> {205.89.10.128/17, 205.89.10.130}, the output will be:
> {205.89.10.128/17} (205.89.10.130 will be dropped).
>
> 3) The source of data is the Net Access MAE-East router routing table,
> and we don't peer with all parties at MAE-East directly - thus, it's
> possible that the system catches aggregations that are impossible
> because they're announced to a 3rd party via different paths - but
> an informal look around doesn't appear to indicate that.
>
> 4) The system goes by next-hop rather than by AS-Path. There seems to
> be a good correlation, but ...
>
> Also, the final disclaimer: I've examined the results and they *look*
> reasonable. But I haven't written tester-tools to attempt to verify
> by another algorithm that the results are correct.
>
> Here's the table at the end of the web page:
>
> Before After
> Run Agg. Run
> 192.41.177.110 ibm 81 68
> 192.41.177.115 digex 98 98
> 192.41.177.120 eu.net 949 775
> 192.41.177.125 nsn.nasa 126 112
> 192.41.177.140 ans 2146 1425
> 192.41.177.145 agis 539 304
> 192.41.177.150 uscyber 2 2
> 192.41.177.160 interpath 2 2
> 192.41.177.170 net99 309 246
> 192.41.177.180 mci 2 2
> 192.41.177.181 mci 8963 6828
> 192.41.177.190 pipex 367 308
> 192.41.177.210 netcom 370 348
> 192.41.177.235 psi 1 1
> 192.41.177.240 icp 4499 3712
> 192.41.177.241 sprintlink 6429 4694
> 192.41.177.245 psi 1491 1098
> 192.41.177.249 alternet 3971 3148
> 192.41.177.251 es.net 96 88
> 192.41.177.252 es.net 122 101
> 192.41.177.6 suranet 470 445
> 192.41.177.70 internex 1 1
> 192.41.177.80 ios 10 8
> 192.41.177.85 cais 184 158
> 192.41.177.86 hlc 354 243
> 192.41.177.89 energis 2 2
> 192.41.177.95 delphi 3 3
>
> A final note: We're open to {Additional static sources of route tables at
> MAE-East; Additional static sources of route tables at {MAE-West, Pennsauken,
> or the PacBell NAP}; and dynamic (i.e. the vty password so we can run
> a sho ip bgp summ every so often) sources at any of the MAEs or NAPs.
>
> If we get good feedback, we may automate this to run overnight and keep
> a history.
>
> Avi Freedman
> freedman at netaxs.com
>
More information about the NANOG
mailing list