With protocols bgp parameters default local-pref 100 configured, every commit that changes FRR configuration (BGP, other routing protocols, policy, static routes) makes the router re-process all routes it has received from every BGP peer, even when the commit has nothing to do with local preference. With soft-reconfiguration inbound the router runs all stored routes through the import policy again; without it, the router asks every peer to send its whole table again. On a router with large tables this takes minutes of CPU per commit, and the commit waits for it. This is the behaviour of rolling and 1.5.x (circinus), which render and reload the whole FRR configuration on such commits; it was measured with BGP commits and follows from the code for the other FRR changes.

On 1.4.x (sagitta) it happens only on commits that change BGP configuration: only the BGP script renders the line, and the other scripts that reload bgpd (policy, RPKI) start from bgpd's running configuration, which does not contain it.

Root cause.

• VyOS renders bgp default local-preference 100 into the FRR configuration.
• FRR does not print that line in show running-config, because 100 is its default.
• frr-reload compares the rendered file with the running configuration, sees the line as missing, and sends it again on every reload (once in its first pass and twice in its second).
• FRR's handler for bgp default local-preference always re-processes the routes of every peer (it runs clear bgp * soft in), even when the value does not change.

Measurements. VyOS 1.5.1 VM, FRR 10.5.2, about 1.76M paths: 2 route-server sessions with 380,000 routes each, 2 transit sessions with 300,000 each, 80 IXP sessions with 5,000 each, soft-reconfiguration inbound on. One application of the line cost 98 s of bgpd CPU: a pass over the stored routes of every peer plus the route announcements that follow it. A commit that only re-added the line took 125.5 s.