Hello Robert, On Wed, Jun 24, 2026 at 08:42:48PM +0200, Robert Scheck wrote:

On Tue, 08 Apr 2025, Maria Matejka wrote:

...

And with that, exactly as Jelle writes, you do the _downstream_ check for all your transits, i.e.

``` if aspa_check_downstream(ASPAS) = ASPA_INVALID then reject "ASPA INVALID ", net, " ", bgp_path, " ", proto; ```

just to get whether I understood you correctly: If I have transits (local role customer), such as Arelion, Deutsche Telekom or Vodafone, I need the aspa_check_downstream(), as written by you, in my import filter?

Yes. There is kinda a little catch though, and that is the rejection itself. While the current draft stipulates to drop downstream invalids, it may cause connectivity degradation in specific situations. There is nothing wrong witn dropping Upstream invalids; both customer and peer routes should be validated and invalids dropped. But then there are prefixes where all candidates for the best route have come from your transits. If your transits validate ASPA, they are going to drop ASPA-invalid routes, and probably won't send trash to you, and everything is still OK. But it they do not validate ASPA, they may easily select a leaked best route, and the only thing you get is trash. And while you could say whatever, it's still trash, drop it, the problem is that often such a leak works well, other customers of your transit therefore don't complain, and there is no easy way to get the leak rectified. For this reason, I would very much recommend only depreferencing downstream invalids (i.e. setting `preference = 67;`) or something like that. There is a rather long thread on this in the sidrops mailing-list, and I'm still quite surprised that this operational catch has been quite actively rejected by the authors of the draft. https://mailarchive.ietf.org/arch/msg/sidrops/FotQhXB7t-XsRMD2hGAj3VfdS4o/ Note: a situation like this, in a simplified form, happened with the RIPE network and CZ.NIC, which has been affected by Hurricane Electric leaking CZ.NIC routes. https://ripe92.ripe.net/programme/meeting-plan/sessions/109/ZT9NYU/ Note: The connectivity was hotfixed by temporarily adding HE as CZ.NIC provider in ASPA, and later returned to normal (checked right now). -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Hello Maria, On Thu, 25 Jun 2026, Maria Matejka wrote:

On Wed, Jun 24, 2026 at 08:42:48PM +0200, Robert Scheck wrote:

...

just to get whether I understood you correctly: If I have transits (local role customer), such as Arelion, Deutsche Telekom or Vodafone, I need the aspa_check_downstream(), as written by you, in my import filter?

Yes.

okay, thank you for the clarification. I configured it like this, but with a "print" instead of "reject" and had to notice that it prints all prefixes (at least syslog skips logging due to flooding after 10k+ lines in a few less seconds) on the Vodafone transit. Given your clarification I now noticed that this Vodafone transit is some alien/monster/... transit: While it's Vodafone, they still have configured AS6830 on their side. The local ISP was acquired long time ago by Liberty Global, they updated their configuration to AS6830. Some years ago that part was split out and sold to Vodafone, but they kept AS6830 there, even it's AS3209 (and they refused to change it). So my AS_PATH begins always with "AS6830 AS3209" instead of "AS3209". I might not have understood ASPA completely (and I know I'm not the only one), but my understanding so far is that "AS6830 AS3209" instead of just "AS3209" in AS_PATH leads to the wrong result. I thought it would be clever to remove AS6830 from the beginning of the AS_PATH but there doesn't seem to be a function for this in BIRD? Because my if bgp_path.first = 6830 then { bgp_path = delete(bgp_path, 6830); } removed AS6830 from any place in the AS_PATH. This leads to an ASPA result that could be more correct (compared with the other transit), but the ROA check now filters any ROAs with prefixes originating in AS6830, which is indeed wrong (and caused by my delete()). So...is there any solution for this mess - other than cancelling Vodafone transit or not performing ASPA checks?

Note: a situation like this, in a simplified form, happened with the RIPE network and CZ.NIC, which has been affected by Hurricane Electric leaking CZ.NIC routes.

https://ripe92.ripe.net/programme/meeting-plan/sessions/109/ZT9NYU/

I saw this (remotely) and I had the hope to not run into any ASPA fun, but they, here I am now! ;-( Regards, Robert

Dear all, Regarding the HE issue. When you open a peering request with HE, in the past(?) they offered "free IPv6 transit". One can easily write an email to their NOC that you want an ordinary peering session without transit and they will duly comply. This was originally meant as a service to the IPv6 community, but many people have forgotten about it. So the problem is IMO less HE's generosity, but people who do not realize what they "agreed" on. André On Thu, 25 Jun 2026 at 16:00, Maria Matejka via Bird-users < bird-users@network.cz> wrote:

On Thu, Jun 25, 2026 at 09:41:35AM -0300, Douglas Fischer wrote:

Em qui., 25 de jun. de 2026 às 09:01, Maria Matejka via Bird-users < bird-users@network.cz> escreveu:

Note: The connectivity was hotfixed by temporarily adding HE as CZ.NIC provider in ASPA, and later returned to normal (checked right now).

It makes me very sad to hear that the solution to this involved informing in ASPA HE as a provider

Well, that was a connectivity hotfix, not a permanent solution.

My greatest hope regarding ASPA is (or was) that any of the ASNs exhibiting this behavior—taking peering routes and advertising them to downstream customers as if they were part of their own customer cone—would be publicly vilified.

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.

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.

– Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

-- André Grüneberg, Managing Director andre.grueneberg@bcix.de +49 30 2332195 42 BCIX Management GmbH Albrechtstr. 110 12103 Berlin Germany Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B

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