> On 25 Jan 2024, at 09:23, Maria Matejka <maria.mate...@nic.cz> wrote:
>
>
>
> On 25 January 2024 08:34:36 CET, Jeroen Massar <jer...@massar.ch> wrote:
>>
>>
>>> On 24 Jan 2024, at 11:08, Maria Matejka <maria.mate...@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
