validating reachability via an ISP
andy.litzinger.lists at gmail.com
Thu Apr 5 17:30:58 UTC 2018
The root cause was they regional ISP was failing to advertise my prefix
due to a mistake in their export policy. While I'm glad we were able to
figure out the issue I'm generally more interested in figuring out a way
that I can programmatically monitor that my ISPs are providing me with good
reachability, even when their route isn't necessarily the best/installed
route to me.
I do have route objects defined in an IRR for this prefix. Perhaps you
wouldn't mind explaining to me how route-server or ISP operators generally
validate route-objects before accepting routes? Especially in the case
where I'm not peering with your route server but my ISP is. Do you query
the IRR DB to recurse from the ISP AS to my AS and validate route objects
On Thu, Apr 5, 2018 at 12:49 AM, Andy Davidson <andy at nosignal.org> wrote:
> On 29/03/2018, 00:22, Andy Litzinger <andy.litzinger.lists at gmail.com>
> >> The root cause is that the our prefix is not being adequately
> >> re-distributed globally by the regional ISP. This is unexpected and we
> >> working through this with them now.
> Hi, Andy —
> Are you failing to advertise it, or are they filtering it on ingress, or
> are they failing to send it to their other peers?
> One configuration mishap which is starting to come along more and more
> partial or poor reachability caused by route objects which are not
> correctly published in the IRRDB. It is going to be essential to make sure
> that you have properly recorded IRR route objects in, for instance, RADB.
> More BGP speakers properly filter their peers using information that is
> published there. Avoid future reachability problems by checking this today!
> A friendly route-server operator with strict filtering
> Andy Davidson Asteroid International BV
> https://www.asteroidhq.com @asteroidhq @andyd
> Local interconnection. Where you need it.
More information about the NANOG