CIDR FAQ

Curtis Villamizar curtis at ans.net
Fri Aug 18 01:35:38 UTC 1995


In message <"xlink100.x.910:17.07.95.23.48.56"@xlink.net>, Arnold Nipper writes
:
> Hank Nussbacher wrote:
> > 
> > On Thu, 17 Aug 1995 00:30:19 +0200 (MET DST) you said:
> > >Simon Poole wrote:
> > >>
> > >> Yakov, if you have data that CIDR is -not- working for new allocations
> > >> please present it here.
> > >>
> > >> Simon
> > >
> > >CIDR doesn't work as it should. We had to inject all of the more specifics
> > >of 194.45/16 cause Sprintlink isn't able to handle CIDR routes correctly.
> > 
> > Can someone explain this a bit more?  This sounds like a showstopper
> > for CIDR.
> > 
> 
> Xlink (AS517) was announcing 194.45.0.0/16 via Ebone. There are some
> networks within this block announced by PSI. Routing table at PSI looks
> like
> 
[ deleted for brevity ]
> 
> But Sprintlink was routing
> 
[ deleted for brevity ]
> 
> TT to Sprintlink didn't help. After 4 days still no response. I've fixed
> this silly routing by announcing all more specifics. 
> 
> Arnold

The way this is supposed to work is the originator announces the
aggregate and registers in in the IRR.  When confident that the
aggregate is reaching where it needs to go, the originator stops
announcing the components.

If you are the originator of these routes, where is PSI getting the
routes from?  If you are not the originator and are doing a proxy
aggregation, you have to be sure that anyone else that the originator
is advertising the routes to is either also doing proxy aggregation,
or is the intended primary for these routes (or more preferred than
you are).  In a coordinated multiprovider proxy aggregation, if you
can't all withdraw the componenents simultaneously, the least
preferred provider needs to withdraw the components first, then the
next least preferred, etc, until all providers doing proxy have
withdrawn the cpomponents.

The only sure way to know if you are going to break things are: 1)
check with a reliable IRR (the IRR exists, but there is some question
about whether it can be called "reliable"), or 2) try it and see what
breaks, or 3) do your best with the less than perfect IRR and the try
2).

The problem was not with Sprint if PSI was annoncing the components,
unless you were expecting Sprint to proxy aggregate for PSI (which
perhaps they hadn't yet agreed to do).  A TT would not be the way to
request proxy aggregation from another provider.

Curtis




More information about the NANOG mailing list