ROA with static protocol in BIRD 2
Good evening, I wonder if there's a good, full example about ROA with static protocol in BIRD 2. The following snippet is only for BIRD 1.x, right? --- %< --- roa table roa { roa 1.0.0.0/24 max 24 as 13335; # […] } --- %< --- Based on various snippets and half examples on the Internet, I've made this currently: --- %< /etc/bird.conf %< --- # […] roa4 table roa_v4; roa6 table roa_v6; include "/var/lib/rpki-client/bird2"; function reject_invalid_roa() { if (force_roa_table_update > 0) then { if (net.type = NET_IP4) then { case roa_check(roa_v4, net, bgp_path.last) { ROA_INVALID: reject; # ROA_VALID: # ROA_UNKNOWN: } } if (net.type = NET_IP6) then { case roa_check(roa_v6, net, bgp_path.last) { ROA_INVALID: reject; # ROA_VALID: # ROA_UNKNOWN: } } } } # […] --- %< /etc/bird.conf %< --- Note that /var/lib/rpki-client/bird2 is generated on a regular base. --- %< /var/lib/rpki-client/bird2 %< --- define force_roa_table_update = 1582237716; protocol static { roa4 { table roa_v4; }; route 1.0.0.0/24 max 24 as 13335; # […] } protocol static { roa6 { table roa_v6; }; route 2001:200::/32 max 32 as 2500; # […] } --- %< /var/lib/rpki-client/bird2 %< --- This however raises the following questions for me: - Is this good style at all? - Should "roa4 table roa_v4; roa6 table roa_v6;" be moved to the include? - To cover IPv4 and IPv6, I need two different tables and two different static protocols, and there is no way using one table/channel, right? - Is "define force_roa_table_update = 1582237716;" still needed with BIRD 2.0.7 to ensure proper revalidation? - Some use "bgp_path.last_nonaggregated", some "bgp_path.last". What is more suitable here? - Is "birdc configure soft && birdc reload in all" the only/best way? Regards, Robert
Hello!
I wonder if there's a good, full example about ROA with static protocol in BIRD 2. The following snippet is only for BIRD 1.x, right?
--- %< --- roa table roa { roa 1.0.0.0/24 max 24 as 13335; # […] } --- %< ---
Yes.
Based on various snippets and half examples on the Internet, I've made this currently:
--- %< /etc/bird.conf %< --- # […]
roa4 table roa_v4; roa6 table roa_v6; include "/var/lib/rpki-client/bird2";
function reject_invalid_roa() { if (force_roa_table_update > 0) then { if (net.type = NET_IP4) then { case roa_check(roa_v4, net, bgp_path.last) { ROA_INVALID: reject; # ROA_VALID: # ROA_UNKNOWN: } }
if (net.type = NET_IP6) then { case roa_check(roa_v6, net, bgp_path.last) { ROA_INVALID: reject; # ROA_VALID: # ROA_UNKNOWN: } } } }
# […] --- %< /etc/bird.conf %< ---
Note that /var/lib/rpki-client/bird2 is generated on a regular base.
--- %< /var/lib/rpki-client/bird2 %< --- define force_roa_table_update = 1582237716;
protocol static { roa4 { table roa_v4; };
route 1.0.0.0/24 max 24 as 13335; # […] }
protocol static { roa6 { table roa_v6; };
route 2001:200::/32 max 32 as 2500; # […] } --- %< /var/lib/rpki-client/bird2 %< ---
Yes, this seems to be valid.
This however raises the following questions for me:
- Is this good style at all?
If you prefer this to dynamically loading data via the rpki protocol inside BIRD, yes.
- Should "roa4 table roa_v4; roa6 table roa_v6;" be moved to the include?
This is a matter of a local admin policy.
- To cover IPv4 and IPv6, I need two different tables and two different static protocols, and there is no way using one table/channel, right?
Yes.
- Is "define force_roa_table_update = 1582237716;" still needed with BIRD 2.0.7 to ensure proper revalidation?
Yes. The autorevalidation is in code collision with ongoing structural changes of route propagation inside BIRD which is needed to allow proper multithreaded execution and better utilization of hardware.
- Some use "bgp_path.last_nonaggregated", some "bgp_path.last". What is more suitable here?
The latter. Last nonaggregated should be used if and only if you are sure that there is an aggregate on the last position and you are also sure that it is OK to have an aggregate there and you really need to know the value before it. Don't use last_nonaggregated unless you really know what you're doing.
- Is "birdc configure soft && birdc reload in all" the only/best way?
Still yes, unfortunately; see my pre-previous answer. Maria
Hello Maria, as of writing, OpenBSD rpki-client produces an output file for BIRD 1.x like the following, where IPv4 and IPv6 end up in the same table. For me this ends with "This is an IPv4 router, therefore IPv6 addresses are not supported" error on BIRD 1.x all the time...am I overlooking something? --- %< --- roa table roa { roa 1.0.0.0/24 max 24 as 13335; # […] roa 2001:200::/32 max 32 as 2500; # […] } --- %< --- Is the above under any circumstances valid in any BIRD 1.x version? I did not use BIRD 1.x much, but I thought it is strictly either IPv4 or IPv6... Regards, Robert
On Thu, Feb 27, 2020 at 12:36:32AM +0100, Robert Scheck wrote:
Hello Maria,
as of writing, OpenBSD rpki-client produces an output file for BIRD 1.x like the following, where IPv4 and IPv6 end up in the same table. For me this ends with "This is an IPv4 router, therefore IPv6 addresses are not supported" error on BIRD 1.x all the time...am I overlooking something?
--- %< --- roa table roa { roa 1.0.0.0/24 max 24 as 13335; # […] roa 2001:200::/32 max 32 as 2500; # […] } --- %< ---
Is the above under any circumstances valid in any BIRD 1.x version? I did not use BIRD 1.x much, but I thought it is strictly either IPv4 or IPv6...
AFAIK it is not valid. You would need IPv4 roas in IPv4 bird config and IPv6 ROAs in IPv6 bird config. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi, Robert Scheck skrev:
Hello Maria,
as of writing, OpenBSD rpki-client produces an output file for BIRD 1.x like the following, where IPv4 and IPv6 end up in the same table. For me this ends with "This is an IPv4 router, therefore IPv6 addresses are not supported" error on BIRD 1.x all the time...am I overlooking something?
--- %< --- roa table roa { roa 1.0.0.0/24 max 24 as 13335; # […] roa 2001:200::/32 max 32 as 2500; # […] } --- %< ---
Is the above under any circumstances valid in any BIRD 1.x version? I did not use BIRD 1.x much, but I thought it is strictly either IPv4 or IPv6...
Correct, what you fx. can do is: --- %< --- roa table internet_roas { include "/path/to/file/filename.conf"; }; --- %< --- in the main config file for both the bird and bird6 daemon is this and have the roa table itself located as separate files on disk. the output of rpki-client can then be separated into two files by simply piping through grep on the output. - grep -v ':' > /path/to/file/bird1_roa_table_4.conf, and - grep ':' > /path/to/file/bird1_roa_table_6.conf E.g. bird1_roa_table_4.conf --- %< --- roa 1.1.1.0/24 max 24 as 13335; roa 1.1.2.0/24 max 24 as 13335; etc. --- %< --- E.g. bird1_roa_table_6.conf --- %< --- roa 2001:db8::/40 max 48 as 65536; roa 2001:db8::/32 max 39 as 65536; etc. --- %< --- -- Best regards, Chriztoffer
On Thu, 27 Feb 2020, Chriztoffer Hansen wrote:
Is the above under any circumstances valid in any BIRD 1.x version? I did not use BIRD 1.x much, but I thought it is strictly either IPv4 or IPv6...
Correct,
what you fx. can do is:
Okay, while I'm using something similar for BIRD 2.x, this it not what I'm looking for when a software (here: rpki-client) mentions it has BIRD (1.x) output format. I now filed an issue at upstream's tracker (aside of that I also proposed a patch for BIRD 2.x compatible format natively). Thank you, Chriztoffer, Ondrej and Maria, for the clarification! Regards, Robert
On Tue, 25 Feb 2020, Maria Matějka wrote:
- Is "define force_roa_table_update = 1582237716;" still needed with BIRD 2.0.7 to ensure proper revalidation? Yes. The autorevalidation is in code collision with ongoing structural changes of route propagation inside BIRD which is needed to allow proper multithreaded execution and better utilization of hardware.
I was told that BIRD 1.x doesn't need such a define, because one could use "birdc configure && birdc flush roa && birdc reload all" instead. But given I see some examples for BIRD 1.x out that align with my BIRD 2.x one, I wonder which is better or more recommented from upstream for BIRD 1.x... Regards, Robert
participants (4)
-
Chriztoffer Hansen -
Maria Matějka -
Ondrej Zajicek -
Robert Scheck