[1169] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: CIDR Aggregation Tool

daemon@ATHENA.MIT.EDU (Avi Freedman)
Mon Nov 27 11:58:29 1995

From: Avi Freedman <freedman@netaxs.com>
To: jon@branch.com (Jon Zeeff)
Date: Mon, 27 Nov 1995 11:44:12 -0500 (EST)
Cc: big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu
In-Reply-To: <m0tK6FH-000Nj6C@aero.branch.com> from "Jon Zeeff" at Nov 27, 95 11:17:30 am

> Perhaps this is just a small error that has to be accepted in your
> measurements, but we are dual homed and require both the aggregate and 
> the specific.
> 
> > 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).

The 205.88.10.128 was a random example.  I hope that's not you :)

There are no "value" judgements made by the tool - it's just suggesting
aggregates.  And if we see an aggregate and a specific, both set to 
the same next-hop, it's quite likely that it's the same AS announcing 
both routes, and that they (your transit provider(s)) could do the 
aggregation themselves - but the tool *is* deficient in that right now 
it doesn't consider AS-paths.

As an example, picking an IP for branch.com (198.111.253.37):

Our route table has:
*> 198.111.252.0    192.41.177.145        <--- agis
*> 198.111.252.0/22 192.41.177.181        <--- mci
*> 198.111.253.0    192.41.177.145        <--- agis
*> 198.111.255.0    192.41.177.145        <--- agis

So if 198.111.252/23 is suggested as an aggregate for the 192.41.177.145
(AGIS) target, that's because it looks like AGIS could in fact announce 
198.111.22.0/23 instead of 198.111.252/0 and 198.111.253.0.

Avi



home help back first fref pref prev next nref lref last post