Example configuration for ASPA with rpki-client?
Hello, does somebody have an example configuration snippet for ASPA in BIRD with rpki-client? I've read https://bird.network.cz/?get_doc&v=20&f=bird-6.html but I'm still not sure how the configuration in BIRD for an AS with two transit providers (just upstreams, no downstreams) would look like... Regards, Robert
Hi Robert, I have ASPA implemented. I use the following function: function is_aspa_invalid(bool is_upstream) -> bool { if aspa_check(ASPAS, bgp_path, is_upstream) = ASPA_INVALID then { print "Reject: ASPA INVALID: ", net, " ", bgp_path, " protocol: ", proto; return true; } return false; } and I call this function in my filter for upstream as follows: if is_aspa_invalid(false) then { reject; } What I found, for ASPA the upstream question is, is your ASN the upstream of the peer. In case of a transit the answer is no. Regards, Jelle -----Original Message----- From: Bird-users <bird-users-bounces@network.cz> On Behalf Of Robert Scheck Sent: Friday, 4 April 2025 21:19 To: bird-users@network.cz Subject: Example configuration for ASPA with rpki-client? Hello, does somebody have an example configuration snippet for ASPA in BIRD with rpki-client? I've read https://bird.network.cz/?get_doc&v=20&f=bird-6.html but I'm still not sure how the configuration in BIRD for an AS with two transit providers (just upstreams, no downstreams) would look like... Regards, Robert
Hi Jelle and Robert, On Fri, Apr 04, 2025 at 08:11:47PM +0000, Jelle Luteijn via Bird-users wrote:
I have ASPA implemented. I use the following function: function is_aspa_invalid(bool is_upstream) -> bool { if aspa_check(ASPAS, bgp_path, is_upstream) = ASPA_INVALID then { print "Reject: ASPA INVALID: ", net, " ", bgp_path, " protocol: ", proto; return true; }
return false; }
and I call this function in my filter for upstream as follows: if is_aspa_invalid(false) then { reject; }
What I found, for ASPA the upstream question is, is your ASN the upstream of the peer. In case of a transit the answer is no.
with ASPA, you get several cases of what you are actually testing, and the check itself has two variants, upstream and downstream. The upstream check requires (kinda contradictorily), as you correctly state, that the AS Path is upstream *only*. In other words, for most of your clients, you do the upstream check. You also do the upstream check for your lateral peers e.g. in IXPs, unless you wanna use them as transit. Only if the neighbor is your transit (or transit-like), you do the downstream check.
does somebody have an example configuration snippet for ASPA in BIRD with rpki-client? I've read https://bird.network.cz/?get_doc&v=20&f=bird-6.html but I'm still not sure how the configuration in BIRD for an AS with two transit providers (just upstreams, no downstreams) would look like...
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; ``` Happy routing! Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
Hello Maria, 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? Regards, Robert
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.
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. 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. -- Douglas Fernando Fischer Engº de Controle e Automaçã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
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.
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
My advice to our consulting clients regarding a list of about 8–10 specific ASNs (which are the same everywhere in the world) is always the same: 1- If you can set up a bilateral session with them via an MLPA at no cost, do it... 1.1- And send the routes to them with the `no-export` community. 1.2- Lower the local preference for everything coming from that peer. 2- For Route Servers: 2.1- When advertising your routes, tag them with the "selective-do-not-announce-to" community for those ASNs. 2.2- Reject anything the Route Server tags with the "learned-from-asn" community corresponding to those ASNs. I know it’s massive overkill! I know it’s even a bit rude... But unfortunately, after losing so much sleep, this is how I finally stopped worrying about that type of network operator—the kind that thinks it’s great to declare themselves everyone's upstream provider. If everyone (or at least a good number of people) does this... their business model collapses. Em qui., 25 de jun. de 2026 às 10:55, Maria Matejka <maria.matejka@nic.cz> escreveu:
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.
-- Douglas Fernando Fischer Engº de Controle e Automação
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
On Thu, Jun 25, 2026 at 02:56:54PM +0200, Robert Scheck wrote:
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?
To clarify → you get routes from Vodafone which always begin 6830-3209-something, and 6830 has ASPA 0, the 3209 is at best an apex of an up-path. Therefore, if 3209 is actually using another transit or peering with ASPA, that route gets marked downstream invalid. If this part is no longer Liberty Global, they should stop using 6830, as that is not their ASN. But the real question comes in the other direction. How do your routes look like after passing 3209? Can you find them somewhere in looking glasses? Because if they send routes looking like 3209-6830-yourasn to their peers or providers, their peers will refuse them as an outright leak.
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! ;-(
Welcome to the party! -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
participants (6)
-
André Grüneberg -
Douglas Fischer -
Jelle Luteijn -
Jeroen Massar -
Maria Matejka -
Robert Scheck