When a commit's FRR apply fails or is cut off (for example bgpd is killed by watchfrr while frr-reload runs), vyos still treats the new FRR configuration as applied. A retry of the same change prints "No configuration changes to commit", and unrelated commits (interfaces, system settings) do not run frr-reload at all. The CLI shows the new configuration while FRR keeps running the old one, until a later commit changes the FRR configuration again.
Cause: FRRender.generate() stores cached_config_dict (and cached_dhcp_gateways) before apply() runs, and the next commit skips the reload when the new dict equals the cache. The cache is not compared with what FRR runs.
Steps to reproduce:
- Stop FRR.
- Commit set protocols bgp parameters router-id 192.0.2.5: the commit fails at the FRR step.
- Start FRR again and retry the same commit: it reports success, but frr-reload does not run. FRR keeps router-id 192.0.2.1 while the CLI shows 192.0.2.5.
- An unrelated commit (login banner) does not change that.
- Only a commit that changes the FRR configuration (here a route-map description) brings FRR in line with the CLI.
With below fix, the retry in step 3 runs frr-reload and FRR gets the router-id the CLI shows.
Possible fix direction. In python/vyos/frrender.py, the cache could be updated only after the configuration has reached FRR:
- generate() would keep the newly rendered configuration aside instead of updating the cache;
- apply() would update the cache only after frr-reload and the save succeed;
- after a failed render, reload or save the cache would stay empty, so the next commit runs frr-reload again.
It would change behaviour: after a failed FRR apply, the next commit would reload FRR once, even if it does not change the FRR configuration (measured with the local change). If FRR were still down at that point, that commit would fail at the reload instead of reporting success (from the code; not measured).