Re: Defines for mixed IPv6/IPv4
> On 25 Jan 2024, at 09:23, Maria Matejka wrote:
>
>
>
> On 25 January 2024 08:34:36 CET, Jeroen Massar wrote:
>>
>>
>>> On 24 Jan 2024, at 11:08, Maria Matejka wrote:
>>>
>>>
>>>
>>> On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users
>>> wrote:
> On 23 Jan 2024, at 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:
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": ,
"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 <
Re: Defines for mixed IPv6/IPv4
On 25 January 2024 08:34:36 CET, Jeroen Massar wrote:
>
>
>> On 24 Jan 2024, at 11:08, Maria Matejka wrote:
>>
>>
>>
>> On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users
>> wrote:
>>>
>>>
On 23 Jan 2024, at 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:
>>>
>>> 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.
Re: Defines for mixed IPv6/IPv4
> On 24 Jan 2024, at 11:08, Maria Matejka wrote:
>
>
>
> On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users
> wrote:
>>
>>
>>> On 23 Jan 2024, at 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:
>>
>> 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
Re: Defines for mixed IPv6/IPv4
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 wrote: > > > > On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users > wrote: > > > > > >> On 23 Jan 2024, at 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: > > > >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. >
Re: Defines for mixed IPv6/IPv4
On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users wrote: > > >> On 23 Jan 2024, at 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: > >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.
Re: Defines for mixed IPv6/IPv4
> On 23 Jan 2024, at 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: 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
Re: Defines for mixed IPv6/IPv4
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
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
Re: Defines for mixed IPv6/IPv4
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
