CIDR Aggregation Tool

Tue Nov 28 06:12:09 UTC 1995

In message <m0tK97D-000Nj7C at aero.branch.com>, Jon Zeeff writes:
> I wouldn't mind if aggregation was done automatically unless 
> the route was specifically registered somewhere as being a 
> "don't aggregate" route.  In other words, let people indicate
> if it wasn't a mistake.
> 
> > load splitting across providers (usually load split by AS path
> > filtering or more simply by AS path length).  There is no way to tell
> > a mistake from this being done intentionally.

A glance at the IRR is all it takes to find a dual homed site and
determined that even though primary connectivity is through the same
path as the aggregate an alternate path goes through another path.
The answer there is often to aggregate anyway and pass the dual homed
exceptions as explicit component routes.  Problems can arise if there
is no aut-num object for the AS in question, or the object is not
accurate, or the routes in question don't have their own AS and are
not registered correctly.  Of course, if you can't be bothered
registering in the IRR correctly, you have to accept the consequences.

In the context of ANS's scheme after determining that something could
be aggregated we would mark the aggregate with the community
ANSAGGREGATE and the components with the community ANSCOMPONENTS.  The
rest is (not yet deployed, and not quite completely coded) magic.  The
aggregate would be formed in the next config run.  There is also plan
to use ANSPROXYAGGR and ANSPROXYCOMP but marking other peoples route
objects (the components of a proxy aggregate) with a community is a
hard thing to do if not in the maintainer list for the object.

Curtis