TLDR: - Contact the peer/transit, de-peer when no response or proper resolution - Temp use _internal_ BGP communities or logging to check what ASPA checks do to routes before rejecting ASPA invalids.
On 25 Jun 2026, at 15:55, Maria Matejka via Bird-users <bird-users@network.cz> wrote: ... The real question is, how to stop big leakers from forcing everybody to approve them as their provider. And while we can point our fingers here and there, the operational reality is to keep the connectivity running.
There are many options: - Contact them to configure it correctly (and if no response you know that is a bad peer) - De-peer (& stop paying if non-free) - Drop all routes that you should not be getting from them, eg filter on ASN or AS macro. - De-preference the complete ASN. - Name and shame publically. But the first two and especially the second is important: you chose to peer with them, that is on your side and something you can configure to stop. That the ASPA result tells you to drop them as is invalid makes it clear enough that either the ASPA object is misconfigured (missing upstream) or your relation is different. For filtering proper routes, also look at https://bgpfilterguide.nlnog.net <https://bgpfilterguide.nlnog.net/> (which misses ASPA checks at the moment though; will need to add that to https://github.com/NLNOG/bgpfilterguide).
I expect that quite a lot of these problems will disappear when IXPs deploy ASPA upstream validation and simply drop all leaks. Until then, with the downstream validation, we play chicken.
No need to play chicken: Like any good deployment plan the first phase of a new configuration deployment is to mark routes by adding a (internal, non-exported) community and process them as before instead of giving a reject/accept reason for that choice. Or simply log them in a file (but might get noisy quick). Then verify what routes you might drop, and what important thing you might be missing. When one is happy, add the reject, as one knows what the impact will be at that point. (and at that point remove the internal community; or keep it so that one can do "show route where net ~ ${prefix} filtered all" allowing one to see that yes, it got filtered and due to the community the reason why it got kicked out, which can be a very useful debug tool btw. The same goes for enabling RPKI validation, adding a new peer (could mark and drop initially to know what new routes they add), and many other configuration changes or in this case ASPA. And of course https://containerlab.dev <https://containerlab.dev/> and similar can be amazing for these kind of change checks (grab MRT dump from live router, replay it in the lab, validate). One big note about the 'validation result in a community' big warning about BGP churn: As an end/non-transit-site that only announces it's own prefixes this is easy as I do not validate my own announced prefixes thus do not tag them with a community either; I do export these internal communities to looking glasses though, but churn is minimal. A transit site should not do such tagging, see the following presentation and the current draft for more details: https://www.ietf.org/proceedings/119/slides/slides-119-sidrops-avoid-signali... https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-avoid-rpki-state-in... Regards, Jeroen