Hello,
I'm curious to understand how "Automatic channel reloads based on RPKI changes"
works, as I've noticed that after I enabled RPKI reload, the daemon is
constantly reloading the ingress policies/filters. I have set it up in the
laboratory and observed that the ingress policies/filters are constantly
re-processed even if the following:
- We don't have RPKI RTR sessions flapping, being renegotiated, and/or changing
state.
- We don't have a refresh requested from/to the clients/neighbours BGP sessions.
- We don't have BGP updates coming or going from/to BGP clients/neighbours at
the moment that I see the ingress policy/filter being re-processed in bird2.
- We don't have RPKI ROA update/changes for the specific prefix during this
meantime.
>From Bird doc:
"BIRD offers crude automatic re-validating of affected routes after RPKI
update, see option rpki reload.
...
In contrast to to other filter operators, this status for the same route may
change as the content of ROA tables changes. When this option is active, BIRD
activates automatic reload of affected channels whenever ROA tables are updated
(after a short settle time)."
I sincerely expected that the automatic reload would be triggered after an
event (RPKI RTR session flapping/changing state) or if the specific ROA changes
(not any ROA changes).
For small deployments, the extra load wouldn't be an issue, but I have
deployments with 3k active clients/neighbours, and the extra load concerns me
to use this function in production.
The lab env is using as minimal configuration as possible, doing RPKI
validation (one RTR session with routinator), and 2 clients/neighbours. I just
added a "print" to ingress protocol filter to see each time that the daemon
process it:
Oct 26 07:21:19 bird_lab-01 bird: Reconfigured
Oct 26 07:21:43 bird_lab-01 bird: Started
Oct 26 07:21:48 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path
65002)
Oct 26 07:21:48 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path
65003)
Oct 26 07:26:43 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path
65002)
Oct 26 07:26:43 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path
65003)
Oct 26 07:47:21 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path
65002)
Oct 26 07:47:21 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path
65003)
Oct 26 08:07:52 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path
65002)
Oct 26 08:07:52 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path
65003)
Oct 26 08:20:39 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path
65002)
Oct 26 08:20:39 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path
65003)
Oct 26 08:43:35 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path
65002)
Oct 26 08:43:35 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path
65003)
Oct 26 09:04:07 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path
65002)
Oct 26 09:04:07 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path
65003)
Oct 26 09:26:56 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path
65002)
Oct 26 09:26:56 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path
65003)
Oct 26 09:47:28 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path
65002)
Oct 26 09:47:28 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path
65003)
Oct 26 10:08:00 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path
65002)
Oct 26 10:08:00 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path
65003)
Oct 26 10:28:36 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path
65002)
Oct 26 10:28:36 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path
65003)
Oct 26 10:51:29 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path
65002)
Oct 26 10:51:29 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path
65003)
...
bird> show proto
Name Proto Table State Since Info
device1 Device --- up 2021-10-26 07:21:43
kernel1 Kernel master4 up 2021-10-26 07:21:43
rpki1 RPKI --- up 2021-10-26 07:21:43 Established
TEST BGP --- up 2021-10-26 07:21:47 Established
TEST2 BGP --- up 2021-10-26 07:21:47 Established
Configuration snippet(not production configuration):
...
filter BGP_IN
{
RPKI_IPV4(65002);
print "INGRESS FILTER => ", net, " => ", bgp_path;
accept;
}
protocol bgp TEST from PEERS {
neighbor 192.168.242.49 as 65002;
ipv4 {
import keep filtered on;
import table yes;
import filter BGP_IN;
export all;
next hop keep;
};
}
...
When/if I disable the automatic RPKI reload(comment out import table yes), this
behaviour(constantly re-processing ingress filters) is gone.
If possible, could you please help me to understand if this is the expected
behaviour for the automatic RPKI reload?
Thanks in advance!
Best regards,
Tiago Felipe Gonçalves
PGP Fingerprint - A2:82:BD:48:EE:8D:C4:99:C2:4E:81:D4:C4:7B:1C:2E:C7:F3:04:C9
