BIRD - RoA with aggregated prefixes - issue
Javor Kliachev
jkliachev at neterra.net
Tue Jul 14 07:40:38 CEST 2020
Hello,
Thank you very much for the quick responses.
We don't use BGP aggregated routes but our customers are using.
Best~
Javor Kliachev
Senior Engineer IP Services
office: +359 2 974 33 11
mobile: +359 885 98 84 95
[ http://www.neterra.net/ | www.neterra.net ] [ https://bg.linkedin.com/pub/javor-kliachev/11/b46/843 |
]
----- Original Message -----
From: "Chriztoffer Hansen" <ch at ntrv.dk>
To: "bird-users" <bird-users at network.cz>
Cc: "nmt-ip" <nmt-ip at neterra.net>, "Javor Kliachev" <jkliachev at neterra.net>
Sent: Monday, 13 July, 2020 20:38:22
Subject: Re: BIRD - RoA with aggregated prefixes - issue
Javor,
On Mon, 13 Jul 2020 at 08:32, Javor Kliachev <jkliachev at neterra.net> wrote:
> We're using BIRD 1.6.4 as Route Server.
>
> Recently we have implemented ROA prefix validation but we have hit the issue with prefixes that are aggregated only.
>
> What do I mean: When the prefix is aggregate and has something like 1234 { 10, 20 } in AS_PATH in the last ASN, bgp_path.last value returns zero ( 0 ). As a result of this, we just discarding such prefixes.
Do not use BGP aggregate routes?
RPKI validation is not feasible for BGP aggregate routes. E.g. the ROA
for AS 10 is valid and invalid for AS 20. What do you do in this case
if AS-path is 1234 { 10, 20 }? Say OK and accept it or reject the
unknown, due to the impossibility of validation the BGP route fairly
in accordance with the earlier mentioned expected RFC behaviour.
I general, the amounts of BGP aggregate routes in the DFZ is low
(measured -at most- in the hundreds if not in the tens).
--
Chriztoffer
More information about the Bird-users
mailing list