Bird 2.0.8 - Automatic RPKI reload behaviour
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
On Wed, Oct 27, 2021 at 06:53:20AM +0200, Tiago Felipe Goncalves wrote:
Hello,
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.
If possible, could you please help me to understand if this is the expected behaviour for the automatic RPKI reload?
Hello We currently cannot track which routes were affected by change of RPKI, therefore we trigger reload of a channel that uses RPKI after any ROA change. The reload is internal only (e.g. from import table to regular table) so it is only computational load of evaluating filters, not real BGP reload/refeed. We plan to improve it in the future, but as people done this (triggering full reload after any RPKI change) using external scripts anyways, we think tha offering current crude form is useful. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi Ondrej, Thanks for the clarification, really appreciate. One last question, let's say that I have a big one, doing 3000 thousands ROA updates on a automated way, will this be converted to 3000 thousands internal reloads, or there's any threshold/group update? I mean, if there was an internal reload, for the XYZ minutes, a next update will not trigger the reload, or are we going to see the update 1:1? On 29-10-2021 15:25, Ondrej Zajicek wrote:
On Wed, Oct 27, 2021 at 06:53:20AM +0200, Tiago Felipe Goncalves wrote:
Hello,
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.
If possible, could you please help me to understand if this is the expected behaviour for the automatic RPKI reload?
Hello
We currently cannot track which routes were affected by change of RPKI, therefore we trigger reload of a channel that uses RPKI after any ROA change. The reload is internal only (e.g. from import table to regular table) so it is only computational load of evaluating filters, not real BGP reload/refeed.
We plan to improve it in the future, but as people done this (triggering full reload after any RPKI change) using external scripts anyways, we think tha offering current crude form is useful.
-- 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
participants (2)
-
Ondrej Zajicek -
Tiago Felipe Goncalves