Defines for mixed IPv6/IPv4
Hello bird users, I am wondering how you handle matching both IPv6 and IPv4 prefixes efficiently. We have tons of blocks in our config like these: define net_genauso_v6 = [ 2a0a:5480::/29+ ]; define net_genauso_v4 = [ 185.203.113.0/24, 185.116.114.0/24 ]; And then later we have a function that combines them like this: function is_genauso() -> bool { if ((net ~ net_genauso_v6) || (net ~ net_genauso_v4)) then { return true; } return false; } And then much later, we have various filters utilising the function, the most simple one being: filter genauso { if(is_genauso()) then accept; reject; } Which is then used in both IPv4 & IPv6 channels: protocol bgp incoming_r2ge { ... ipv6 { import filter genauso; export none; }; ipv4 { import filter genauso; export none; extended next hop on; }; } Instead of writing a wrapper function for each peer/constellation, it would be great if we could do something like that: define net_genauso = [ 2a0a:5480::/29+, 185.203.113.0/24, 185.116.114.0/24 ]; ... filter genauso { if(net ~ net_genauso) then accept; reject; } ... However as of bird 2.14, this results in the following error: bridge:~nico# bird -f -c ./bird.conf bird: ./bird.conf:208:23 Mixed IPv4/IPv6 prefixes in prefix set. So my question is, how do you usually match on the two families? Do you also write a wrapper function like above? Or do you have a smarter way? BR, Nico -- Sustainable and modern Infrastructures by ungleich.ch
Hello Nico, I make separate defines per family (like you did) and then in my filters I just use: if (net.type = NET_IP4 && ! (net ~ ASxxx_IPV4)) then reject; if (net.type = NET_IP6 && ! (net ~ ASxxx_IPV6)) then reject; Best, Luiz On 23/01/2024 14:13, Nico Schottelius via Bird-users wrote:
Hello bird users,
I am wondering how you handle matching both IPv6 and IPv4 prefixes efficiently.
We have tons of blocks in our config like these:
define net_genauso_v6 = [ 2a0a:5480::/29+ ];
define net_genauso_v4 = [ 185.203.113.0/24, 185.116.114.0/24 ];
And then later we have a function that combines them like this:
function is_genauso() -> bool { if ((net ~ net_genauso_v6) || (net ~ net_genauso_v4)) then { return true; }
return false; }
And then much later, we have various filters utilising the function, the most simple one being:
filter genauso { if(is_genauso()) then accept; reject; }
Which is then used in both IPv4 & IPv6 channels:
protocol bgp incoming_r2ge { ...
ipv6 { import filter genauso; export none; };
ipv4 { import filter genauso; export none; extended next hop on; }; }
Instead of writing a wrapper function for each peer/constellation, it would be great if we could do something like that:
define net_genauso = [ 2a0a:5480::/29+, 185.203.113.0/24, 185.116.114.0/24 ];
... filter genauso { if(net ~ net_genauso) then accept; reject; } ...
However as of bird 2.14, this results in the following error:
bridge:~nico# bird -f -c ./bird.conf bird: ./bird.conf:208:23 Mixed IPv4/IPv6 prefixes in prefix set.
So my question is, how do you usually match on the two families? Do you also write a wrapper function like above? Or do you have a smarter way?
BR,
Nico
-- Sustainable and modern Infrastructures by ungleich.ch
That is almost the same methodology I used in other engines(RPL and XPL). But, after having some issues on performance of control plane, I needed to change a bit... Splitting the IFs of v4 and v6, and then inside that IF testing for the Prefix-list. Doing that recursion on IFs, reduced a bit the impact on CPU of route-filtering job. I'm curious if Bind has some method to optimize logic and sequence of those combined tests in some how. Em ter., 23 de jan. de 2024 às 10:44, Luiz Amaral <email@luiz.eng.br> escreveu:
Hello Nico,
I make separate defines per family (like you did) and then in my filters I just use: if (net.type = NET_IP4 && ! (net ~ ASxxx_IPV4)) then reject; if (net.type = NET_IP6 && ! (net ~ ASxxx_IPV6)) then reject;
Best, Luiz
On 23/01/2024 14:13, Nico Schottelius via Bird-users wrote:
Hello bird users,
I am wondering how you handle matching both IPv6 and IPv4 prefixes efficiently.
We have tons of blocks in our config like these:
define net_genauso_v6 = [ 2a0a:5480::/29+ ];
define net_genauso_v4 = [ 185.203.113.0/24, 185.116.114.0/24 ];
And then later we have a function that combines them like this:
function is_genauso() -> bool { if ((net ~ net_genauso_v6) || (net ~ net_genauso_v4)) then { return true; }
return false; }
And then much later, we have various filters utilising the function, the most simple one being:
filter genauso { if(is_genauso()) then accept; reject; }
Which is then used in both IPv4 & IPv6 channels:
protocol bgp incoming_r2ge { ...
ipv6 { import filter genauso; export none; };
ipv4 { import filter genauso; export none; extended next hop on; }; }
Instead of writing a wrapper function for each peer/constellation, it would be great if we could do something like that:
define net_genauso = [ 2a0a:5480::/29+, 185.203.113.0/24, 185.116.114.0/24 ];
... filter genauso { if(net ~ net_genauso) then accept; reject; } ...
However as of bird 2.14, this results in the following error:
bridge:~nico# bird -f -c ./bird.conf bird: ./bird.conf:208:23 Mixed IPv4/IPv6 prefixes in prefix set.
So my question is, how do you usually match on the two families? Do you also write a wrapper function like above? Or do you have a smarter way?
BR,
Nico
-- Sustainable and modern Infrastructures by ungleich.ch
-- Douglas Fernando Fischer Engº de Controle e Automação
On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users <bird-users@network.cz> wrote:
Hello bird users,
I am wondering how you handle matching both IPv6 and IPv4 prefixes efficiently.
We have tons of blocks in our config like these:
Generate the configs. Especially when doing IRR filtering, one simply lets bgpq4 generate the filters and then drop those definitions into a bird include file, and generate the peers parts too. For variations/options, generate those options too based on the input ASN/peer. Use your favourite configuration management tool or use something like: https://github.com/coloclue/kees That does all of it already (bgp4 and uses peeringdb for peers), YMMV for what tool to use (eg. I got my own little thingy for it). Greets, Jeroen
On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users <bird-users@network.cz> wrote:
On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users <bird-users@network.cz> wrote:
Hello bird users,
I am wondering how you handle matching both IPv6 and IPv4 prefixes efficiently.
We have tons of blocks in our config like these:
Generate the configs.
Not only that, please split IPv6 and IPv4 filters, at least if these are prone to frequent changes.
Especially when doing IRR filtering, one simply lets bgpq4 generate the filters and then drop those definitions into a bird include file, and generate the peers parts too.
When doing IRR filtering, please export it as JSON and load it through RTR mechanism. We support multiple ROA tables and this is exactly the use case for it. Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
Hi, I want to also show some example of configuration generation: https://gitlab.com/qratorlabs/example-automatic-filters There are also a couple of links to other similar projects. Jeroen, thanks for the reference to kees, I've added it to the list there too. Regards, Alexander On Wed, Jan 24, 2024 at 11:14 AM Maria Matejka via Bird-users <bird-users@network.cz> wrote:
On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users <bird-users@network.cz> wrote:
On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users <bird-users@network.cz> wrote:
Hello bird users,
I am wondering how you handle matching both IPv6 and IPv4 prefixes efficiently.
We have tons of blocks in our config like these:
Generate the configs.
Not only that, please split IPv6 and IPv4 filters, at least if these are prone to frequent changes.
Especially when doing IRR filtering, one simply lets bgpq4 generate the filters and then drop those definitions into a bird include file, and generate the peers parts too.
When doing IRR filtering, please export it as JSON and load it through RTR mechanism. We support multiple ROA tables and this is exactly the use case for it.
Maria
-- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
On 24 Jan 2024, at 11:08, Maria Matejka <maria.matejka@nic.cz> wrote:
On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users <bird-users@network.cz> wrote:
On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users <bird-users@network.cz> wrote:
Hello bird users,
I am wondering how you handle matching both IPv6 and IPv4 prefixes efficiently.
We have tons of blocks in our config like these:
Generate the configs.
Not only that, please split IPv6 and IPv4 filters, at least if these are prone to frequent changes.
Especially when doing IRR filtering, one simply lets bgpq4 generate the filters and then drop those definitions into a bird include file, and generate the peers parts too.
When doing IRR filtering, please export it as JSON and load it through RTR mechanism. We support multiple ROA tables and this is exactly the use case for it
Mmm... do you mean IRR data (what bgpq4 generates from RPSL) or RPKI data (what rpki-client generates from ROAs) ? As yes, RPKI data we generate into a JSON file and then pass that to a RTR which serves it up to bird; but IRR data becomes filter statements ("bgpq4 -b" ;) ) Greets, Jeroen
On 25 January 2024 08:34:36 CET, Jeroen Massar <jeroen@massar.ch> wrote:
On 24 Jan 2024, at 11:08, Maria Matejka <maria.matejka@nic.cz> wrote:
On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users <bird-users@network.cz> wrote:
On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users <bird-users@network.cz> wrote:
Hello bird users,
I am wondering how you handle matching both IPv6 and IPv4 prefixes efficiently.
We have tons of blocks in our config like these:
Generate the configs.
Not only that, please split IPv6 and IPv4 filters, at least if these are prone to frequent changes.
Especially when doing IRR filtering, one simply lets bgpq4 generate the filters and then drop those definitions into a bird include file, and generate the peers parts too.
When doing IRR filtering, please export it as JSON and load it through RTR mechanism. We support multiple ROA tables and this is exactly the use case for it
Mmm... do you mean IRR data (what bgpq4 generates from RPSL) or RPKI data (what rpki-client generates from ROAs) ?
As yes, RPKI data we generate into a JSON file and then pass that to a RTR which serves it up to bird; but IRR data becomes filter statements ("bgpq4 -b" ;) )
Of course I mean IRR data. You setup two caches, one for actual RPKI data, and another one for IRR data, feed it by SLURM, load both by two "protocol rpki" instances into two different "roa[64] table"s and call "roa_check()" twice. This way, you don't have to reload BIRD config every so often, and what is more, as soon as BIRD 3 comes out, when something changes in IRR, only the possibly affected routes are actually going to be reloaded. If you wanna know a bit more, there is a tutorial talk at the last RIPE where I speak (not only) about that. And it still was just the tip of the iceberg. If you wish to get more tips, tricks, optimization help and much more, contact me off-list for paid support options. Have a nice day! Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
On 25 Jan 2024, at 09:23, Maria Matejka <maria.matejka@nic.cz> wrote:
On 25 January 2024 08:34:36 CET, Jeroen Massar <jeroen@massar.ch> wrote:
On 24 Jan 2024, at 11:08, Maria Matejka <maria.matejka@nic.cz> wrote:
On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users <bird-users@network.cz> wrote:
On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users <bird-users@network.cz> wrote:
Hello bird users,
I am wondering how you handle matching both IPv6 and IPv4 prefixes efficiently.
We have tons of blocks in our config like these:
Generate the configs.
Not only that, please split IPv6 and IPv4 filters, at least if these are prone to frequent changes.
Especially when doing IRR filtering, one simply lets bgpq4 generate the filters and then drop those definitions into a bird include file, and generate the peers parts too.
When doing IRR filtering, please export it as JSON and load it through RTR mechanism. We support multiple ROA tables and this is exactly the use case for it
Mmm... do you mean IRR data (what bgpq4 generates from RPSL) or RPKI data (what rpki-client generates from ROAs) ?
As yes, RPKI data we generate into a JSON file and then pass that to a RTR which serves it up to bird; but IRR data becomes filter statements ("bgpq4 -b" ;) )
Of course I mean IRR data. You setup two caches, one for actual RPKI data, and another one for IRR data, feed it by SLURM, load both by two "protocol rpki" instances into two different "roa[64] table"s and call "roa_check()" twice.
Took a bit to wrap my mind around, but yes, I gotcha! The clue in the tutorial was that 'protocol rpki' should have been 'protocol rtr' ;) Thus the idea is to produce a "IRR" SLURM file with: ``` { "slurmVersion": 1, "validationOutputFilters": { "locallyAddedAssertions": { "prefixAssertions": [ { "asn": <peer>, "prefix": "<prefix>", "comment": "IRR-data" }, ``` and instead of RPKI where we check: ``` roa_check(rpki4, 192.0.2.0/24, originasn) # (where ', originasn' is default and thus normally omitted) ``` we check: ``` roa_check(irr4, 192.0.2.0/24, peerasn) ``` which means every peer is more or less the same as the peerasn is a parameter to whatever peer check function one calls and that then just calls the above roa_check(...peerasn), thus a lot less config and thus more readable and maintainable. (even if generated, as it gets repetitive). a quick stab at generating the slurm file: ``` #!/bin/bash set -e cat <<SLURMHEADER { "slurmVersion": 1, "validationOutputFilters": { "locallyAddedAssertions": { "prefixAssertions": [ SLURMHEADER # Test with three peers/test-ASNs for i in AS-IPNG:8298 AS-SPACENET:5539 AS-MASSAR:57777; do asset=$(echo $i | cut -f1 -d:) peeras=$(echo $i | cut -f2 -d:) bgpq4 -F "{ \"asn\": ${peeras}, \"prefix\": \"%n/%l\", \"comment\": \"IRR\" },\n" $asset done # Insert a AS112 prefix that should always be valid # If one does not peer with AS112 it has no effect # and which avoids having to deal with the trailing comma above ;) echo '{ "asn": 112, "prefix": "192.31.196.0/24", "comment": "IRR-static" }' cat <<SLURMTRAILER ] } } } SLURMTRAILER exit 0 ``` which produces: ``` { "slurmVersion": 1, "validationOutputFilters": { "locallyAddedAssertions": { "prefixAssertions": [ { "asn": 8298, "prefix": "44.31.3.0/24", "comment": "IRR" }, { "asn": 8298, "prefix": "44.31.27.0/24", "comment": "IRR" }, { "asn": 8298, "prefix": "44.154.130.0/24", "comment": "IRR" }, ... { "asn": 57777, "prefix": "192.31.196.0/24", "comment": "IRR" }, { "asn": 57777, "prefix": "192.175.48.0/24", "comment": "IRR" }, { "asn": 112, "prefix": "192.31.196.0/24", "comment": "IRR-static" } ] } } } ``` Though have to verify if one can do something with the min/max length for prefixes and that -A (aggregate) for bgpq4 can generate that so one has less prefixes there). And I have to verify how happy stayrtr and bird handle double prefixes and different ASNs and what scaling of that is. Will lab this out over the weekend/nights as this is for AS57777 and thus private and learning ;) Greets, Jeroen
participants (6)
-
Alexander Zubkov -
Douglas Fischer -
Jeroen Massar -
Luiz Amaral -
Maria Matejka -
Nico Schottelius