Re: roa_check not re-evaluating after roa table update

13 Jun 2017

      Hi Ondrej,

That works! thanks!

I now just create a random number each time the config is generated:

# random number which forces the RPKI roa_table to be re-evaluated
define force_roa_table_update = {{ range(1, 1000000) | random }};
...
function RPKI_PrefixFiltering() {
    if force_roa_table_update > 0 then {
        case roa_check( roa_table, net, bgp_path.last) {
            ROA_VALID:
                ...
            ROA_INVALID:
                ...
            ROA_UNKNOWN:
                ...
        }
    }
}

This makes the routes be re-evaluated.

Thanks for the help,

Stefan

On 13.06.2017 13:40, Ondrej Zajicek wrote:
...
On Fri, Jun 09, 2017 at 01:17:08PM +0200, Stefan Plug wrote:
...
Hi guys,
Bird 1.6.3
Just testing about with the RPKI roa_check and it seems that my routes are not being re-evaluated after a "configure" when my roa table is updated.
I do this check during the import phase so the routes are already in the table once I update the roa table.
simple check example:
  roa table roa_table {
    		roa 200.0.0.0/24 max 24 as 1340;
  }
    	if (roa_check( roa_table, net, bgp_path.last)) = ROA_INVALID then {
            if hardFilterRPKI > 0 then {
                return false;
            }
            else {
                return true;
            }
  }
Now I update the config to:
  roa table roa_table {
    		roa 200.0.0.0/24 max 24 as 1340;
    		roa 200.0.0.0/24 max 24 as 1339;
  }
When I now reconfigure BIRD this makes no changes at all. If I restart BIRD and thus the routes get re-sent then they do both get through the check as
expected. when adding/deleting roa entries using the command line I see the same behaviour.
Do note when I change the "hardFilterRPKI" which decides to actually filter or not, then the routes DO get re-evaluated like they should.
Hi
Currently, BIRD re-evaluates routes when a filter or protocol changes
(that is why it is re-evaluates when hardFilterRPKI is changed). But it
does not re-evaluate it when just the content of ROA table is changed.
You could re-evaluate appropariate protocols by hand using 'reload' command.
Or you could workaround that by having something like:
define roa_generation = 123;
And then reference this constant from appropriate filters, even by some
dummy reference, like: if (roa_generation = 0) reject;
And increase roa_generation value each time you change roa_table.
That will trigger re-evaluation.