On a router with IS-IS, every commit that makes VyOS reload FRR makes isisd regenerate its own LSPs for every level of every instance: the own LSP sequence number goes up by 2 per level per commit (default VRF and VRF instances alike), and the IS-IS SPF runs +2 per address family and level, on the router and on its neighbors. No adjacency reset and no route change was seen.

Reproduced on rolling: one commit that changes only a route-map description (which reloads FRR) with IS-IS configured.

Root cause.

• frr-reload runs vtysh -f <file> for each pass that has lines to add; VyOS always has some (log facility daemon, ip forwarding, ipv6 forwarding and the default-valued lines FRR does not print back), and it runs two passes per commit.
• vtysh -f sends XFRR_start_configuration and XFRR_end_configuration around the file (vtysh_config.c:612, :620). isisd's end callback isis_config_end -> isis_config_finish -> config_end_lsp_generate (FRR 10.6.1: isis_main.c:231-240, :206; isisd.c:3314; the same path in FRR 10.5.2: isis_main.c:198-224) calls lsp_generate for every level of every area, whatever the file contained.
• Measured: a vtysh -f file with only a comment regenerates the LSPs (+1 per level per instance); vtysh -c commands, configure terminal, file-lock and vtysh -m -f do not; a reload with every default-valued line removed from the file (empty add list, no vtysh -f) does not.

Fix directions. FRR: regenerate in the config-end callback only when the configuration changed (or only for the first read after start). VyOS / frr-reload: an add list that is empty when everything is already in the running config in an equivalent form, which needs every default-valued line the templates render to be dropped or recognised (for example T9448, T9450) plus the three base lines above.