CIDR Aggregation Tool

Avi Freedman freedman at
Mon Nov 27 19:16:48 UTC 1995

> Avi,
> While this is useful as a metric of the degree of aggregation, it is
> not sufficient to configure aggregation.  This is still useful as a
> means to look at where improvement may be needed.  Please don't get me
> wrong in pointing out that there are limits to the applicability, this
> *is* useful.

I should have been much more specific.

There was never any intent to suggest that this was a 

Nor was there any intent to imply that certain providers are bad or
remiss or misconfigured or underconfigured...

The hope was that it might be useful as something to look at
(a raw generator of aggregation-possibilities).  Also, I was interested
in seeing how many routes could be aggregated at one peering point
(not inside a provider's network, but at one edge).

For example, if the processing to compute the aggregations was low, and
only aggregated entries were inserted into a cache (but the actual BGP
announced more specific entries were kept in the routing table), perhaps 
that would help if route table and/or cache table size was/is still a

But it seems that the current generation of technology that is out there 
doesn't run into a SP-cache-size wall from either a switching-speed or 
memory angle.

> You will find that while improvement is possible, and may still even
> be fairly substantial, your figures represent an optimistic estimate.


[Suggestions re: IRR deleted for brevity.]

Agreed re: the IRR as well.  Next on the list is to examine the Merit
tools.  Sigh -  my nanog notes were lost when my 200LX was stolen, but I
know where to find the tools...

> Thanks for the information.

Thanks for the feedback.

> Curtis


More information about the NANOG mailing list