search

inex / IXP-Manager

Full stack web application powering peering at over 200 Internet Exchange Points (IXPs) globally.
https://www.ixpmanager.org/
GNU General Public License v2.0
374 stars 161 forks source link

Honor PeeringDB 'never via route server' #798

Open ninjaix opened 2 years ago

ninjaix commented 2 years ago

Members' downstreams have set "never via a route server" in PeeringDB would like to have that honored by our platform. Ideally this would flow thru in the IXP Manager Virtual Interface and then onto Bird with a tagged community so it could be seen in the Looking Glass similar to a failed/mismatched IRRDB lookup.

rlaager commented 1 year ago

@ninjaix can you elaborate on the intended use case for this? I'm asking you specifically because it sounds like you've got people who have actually asked you for this.

The PeeringDB help text says, "Indicates if this network will announce its routes via route servers or not". As written, that seems to indicate whether my AS would be a route server client. In that case, why do I need to set that to true, when I can just, not peer with the route server?

It seems that people implementing filtering expect this to mean, "If you see this ASN, drop the prefix." (That is how arouteserver handles it, for example.) That is, it's the same as the "transit-free ASNs" filtering, but dynamically configurable at PeeringDB (and it seems the IX is "supposed" to apply that filtering for all ASNs in PeeringDB, regardless of whether they peer at that IX). But why do people want that? That prevents their upstreams from peering their traffic at IXs via route servers.

barryo commented 1 year ago

An answer recently on the mailing list re my opinion on this:

Yes and no. We do support it:

https://docs.ixpmanager.org/features/routers/#filtering-known-transit-networks

We do not take it from PeeringDB.

Having looked, admittedly some time ago, at the number of networks with this set in PeeringDB, my inclination is that many networks do not know what this means and I felt it would be dangerous to pull this from PeeringDB in its current form. Especially as it would propagate to up to 200 IXPs.

rfc1036 commented 1 year ago

FWIW at MINAP we do honor "never via route server" automatically taken from PeeringDB, and the only dubious rejects are a few routes from HE. So I believe that it is reasonably safe to use.

barryo commented 1 year ago

Thanks @rfc1036 - good to know. We're planning a major refactor of the route server code in Q4 2023 to look to support OpenBGPD also so will revisit this as part of that.