Honor PeeringDB 'never via route server'

[ninjaix]

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]

@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]

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

• Supports PeeringDB "never via route server", which IXP Manager seemingly does not:
  Honor PeeringDB 'never via route server' #798

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]

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]

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.