Hello Ondřej, thank you for catching this bug. It probably applies to v2.18 as well. Replicated, gonna fix soon. Maria On Thu, Feb 05, 2026 at 06:33:51PM +0100, Ondřej Caletka wrote:
Hello again!
On 29/01/2026 11:49, Ondřej Caletka wrote:
I wonder whether there is a way how to see a ASPA table entry for particular customer AS number. Something like:
bird> show route table aspas all for 2121 syntax error, unexpected NUM, expecting IP4 or IP6 or VPN_RD or CF_SYM_KNOWN
Found it!
bird> show route all aspa 2121 Table aspas: 2121 [rpki_validator 2026-01-29] * (100) preference: 100 source: RPKI aspa_providers: 3333 Internal route handling values: 0L 16G 1S id 10
Regarding the validation itself, a random trivial example where aspa_check_downstream fails and I don't know why is this:
80.254.230.0/24 bgp_path: 3333 12859 42695
(My ASN is 2121 and there is an ASPA stating that 3333 is provider for 2121)
There is no ASPA for 3333 There is ASPA for 12859 not stating 42695 as provider There is ASPA for 42695 not stating 12859 as provider
So the up ramp should be 42695 and the down ramp should be 2121 3333 12859
I don't see any valleys here yet it is rejected.
Am I doing it wrong?
I believe there is a logic error not covered by the tests in the validation logic around here
https://gitlab.nic.cz/labs/bird/-/blob/master/nest/rt-table.c?ref_type=heads...
I did some pen-and-paper tracing of this algorithm:
First ASN: 3333 ap = 0, found = up = down = false; set max_down = 1, min_up = 0;
So far so good, no ASPA so the min_down ramp ends here, the max_down goes further. If there is no ASPA everywhere, min_up can end here too.
Second ASN: 12859 ap = 1, found = true, up = down = false; set min_up = max_up = 1; set force_upstream = true;
There is ASPA but neither on the left or on the right is a provider. We don't touch the down ramp (it pointed here from the previous step) and we clamp the up ramp for this position. However, we also force upstream validation from now on. I believe this is wrong because if this is the apex of the down ramp, the upstream validation should start from the next ASN.
Third ASN: 42695 ap = 2, found = true, up = down = false, force_upstream = true; Bacause ap>0 and the ASN on the left is not provider, this ends up with ASPA_INVALID, because in previous iteration, the algorithm was switched to the upstream one.
Should we not switched to upstream validation at this point this would end up with min_up = max_up = 2.
I believe that this is expected result for the algorithm: both minimum and maximum up ramps end on AS with index 2, minimum down ramp is 0 since the leftmost ASN does not have ASPA, but maximum down ramp is 1.
Thus having max_up = 2 and max_down = 1 says that the up and down ramps are meeting on adjacent peers. This should be allowed.
However the logic in the code requires max_up <= max_down for Unknown result. This means it requires up and down ramps to be touching or overlapping.
I don't think this is what the draft-ietf-sidrops-aspa-verification-24 is prescribing. It operates with ramp lengths in place of positions so for this particular case: max_up_ramp = 1, min_up_ramp =1, max_down_ramp = 2, min_down_ramp = 1, N = 3.
The draft says that:
the sum of max_up_ramp and max_down_ramp is less than N, the AS_PATH is Invalid.
Here 1 + 2 = 3 so this is not invalid.
Else, if the sum of min_up_ramp and min_down_ramp is less than N, enough information is not available to perform full AS_PATH verification, and the outcome is set to Unknown.
Here 1 + 1 < 3 so this should be unknown.
Am I still doing it wrong? :)
-- Best regards,
Ondřej Caletka
-- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.