Re: Peering Policies and Route Servers

[Rob Gutierrez]

> > >In other words, what is the value for an organization to utilize the Route
> > >Servers?  And if there is value, why is everyone not doing it?
> > 
> > One detractor, to the best of my knowledge, is that the route servers are
> > not exactly 'dynamic', meaning that they are updated a couple of times
> > during the course of the day to reflect any changes in routing policy.
> > Therefore, the possibility for blackhole'ing packets exists.
> 
> There is no possibility for blackholing packets.  Blackholing means
> advertising a route and then not delivering the packet.

I'm afraid that I did run into a situation where the route was advertised
and the packet was blackholed.

I started to peer with AS-2882 at the PB NAP, and I accepted routes
from it for another ISP (no finger pointing today -- sorry).  Well, the
ISP didn't have the VC map config'd in their router, and that route
became preferred after a glitch somewhere in their network.  Well, since
the med's were the same in the routes we were sending to them, they
preferred the PB NAP route after their glitch.  Needless to say, not
a happy situation.  Then, of course, there was yet another ISP we were
waiting for their router to be config'd, etc.

Well, I didn't have time to wait for my advisory to be updated, so,
brute force was utilized:

   (config-router)# no neighbor 198.32.128.130

This was more out of frustration in that I had my config's ready and I
agreed to accept and give routes via the R/S.  Needless to say, I'll
decline to accept/advertise to that peer until I can ping them.

Yes, I know this is more of a initial config issue, but the route servers
were "in the way" at this point.  Can You Say "neighbor x weight 1" next
time :)

	rob gutierrez / internex information services