> If there is a route object in the RADB for the /24 we will set policy
> according to the origin AS of the RO. If you can't get rid of a bogus
> RADB RO, ask us we can create exceptions for AS based policy on a per
> prefix basis. If there is no RO, we won't listen to the /24 so we
> won't hear the bogon, just the /16. This is temporarily moot since we
> have 2 routers in AS1673 that can't handle the policy filters.
> The bottom line is the IRR helps keep connectivity in the face of this
> sort of problem where you are claiming it hurts.
Is there any way of determining which routes ANS are filtering out
(other than noticing customer X can't reach you all of a sudden),
or trying to filter out as is the case currently.
How about a daily mailing which would encourage people to register
routes in the appropriate IRR as well as allow us to preempt our
slower learning BGP downstreams into warning them they are about to
have a problem when they start using a new block they haven't registered
a routing policy (yep, they *should* know this by now).
I've tried to code stuff like this but I'd prefer not to send mail to
people asking them to register something leaking from and aggregate or
when an aggregate would better solve the problem.
It seems that most people that know how to form an aggregate also know
enough to register the aggregate. We haven't done anything because of
lack of time and wanting to wait until we had automated something that
could give quality advice rather than spray mail to a few thousand
unregistered /24s asking them to register when we should be asking
their provider to aggregate them.
Or a web site. Even if it just does the equivalent of the Digex l/g.
Your NOC are normally v. helpful, but I'm sure it would save you
some man hours.
Good suggestions. Thanks,