Defines for mixed IPv6/IPv4

[Jeroen Massar]

> On 25 Jan 2024, at 09:23, Maria Matejka <maria.matejka at nic.cz> wrote:
> 
> 
> 
> On 25 January 2024 08:34:36 CET, Jeroen Massar <jeroen at massar.ch> wrote:
>> 
>> 
>>> On 24 Jan 2024, at 11:08, Maria Matejka <maria.matejka at nic.cz> wrote:
>>> 
>>> 
>>> 
>>> On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users <bird-users at network.cz> wrote:
>>>> 
>>>> 
>>>>> On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users <bird-users at 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