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@iepg.org From: Tony Bates <Tony.Bates@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@netaxs.com> To: big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu CC: freedman@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@netaxs.com