not for AFRINIC, see http://rpki-browser.realmv6.org/ (select AFRINIC,
filter for Resource AS0)
Cheers
matthias
You could do the same trick. But with data fetched from PeeringDB via
the public API. Works well.
-Christoffer
I think that is essentially what the service does, but in a BGP feed
and maintained for you, kind of like the bogons service.
John
Small note:
I strongly recommend to only block IXP peering lan prefixes for IXPs you are actually connected to yourself.
This way the communication lines are short in case there should be an exception. Don’t block prefixes unrelated to your operation.
Kind regards,
Job
There is also a feature request [0] to tag those prefixes whether they
should be blocked or not. Once implemented it should be easy to build a
filter.
Arnold
[0] https://github.com/peeringdb/peeringdb/issues/352
slide 8 of http://archive.psg.com/970210.nanog.pdf
In Randy's presentation
from the credit where due department: this was not my bright idea. the
presentation was from a get together of some large isp operators a few
weeks prior.
randy
Job Snijders
Sent: Thursday, December 20, 2018 5:55 PM
We don't see a need for NTT to attempt to make such peering lan networks
reachable for third parties. Such reachability may negatively impact
operations, especially when more-specifics of Peering LAN prefixes are
distributed through the default-free zone.As a consequence, for IXPs this policy suggests that it is a necessity to host
their own infrastructure (IXP website, mail server, etc) outside the peering
lan prefix.
Reading this thread makes me wonder if the reasoning mentioned thus far should in fact be extrapolated to any Providers' infrastructure prefixes (essentially the plumbing prefixes).
Wondering what is the community's stance on this.
adam