On a router with a large FRR configuration, a commit that changes an export policy does not return until bgpd has finished re-evaluating that policy over the whole table. In the test that was almost two extra minutes per commit, and the time grows with table size and the number of update groups.
Root cause.
- After frr-reload.py --reload has applied the change and saved the configuration, FRRender.apply() runs vtysh -n --writeconfig, which asks every daemon for its configuration again and writes the same file.
- That second save is left over from T3217 (2021), when vyos reloaded one daemon at a time with --daemon. frr-reload.py does not save in that mode, but it does save without --daemon, which is how vyos has called it since T6747.
- On a large FRR configuration the extra round trip reaches bgpd after the route-map update timer (5 s) has started the policy walk, so it waits until the walk ends.
Measurements (20,000 FRR config lines, 100 export update groups, 500,000 routes; walk ≈ 116 s):
| before | after | |
|---|---|---|
| policy commit | 497.9 / 501.0 s | 381.1 / 381.6 s |
| commit without a policy walk | 384.9 / 383.4 s | 382.3 / 381.7 s |
After the fix the policy commit takes as long as a commit without a walk; the walk itself still runs, but after the 1.5.1 and rolling-2026-09-30, commit has returned. With a small FRR configuration the commit did not wait in either case.
Fix direction. Remove the second save (and the import it leaves unused).