North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

CIDR Aggregation Tool

  • From: Avi Freedman
  • Date: Sun Nov 26 23:34:13 1995

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
[email protected]