FRR loads its configuration at start from /etc/frr/frr.conf (a bind mount of /run/frr/config/frr.conf). If bgpd dies while that file is being written, the file can be written without the BGP section. watchfrr then restarts bgpd from it, and the router runs with no BGP configuration while the CLI still shows it. Commits that do not change the FRR configuration do not restore it (see the frrender cache task); a commit that changes the FRR configuration does.

Reproduced in three ways:

• bgpd killed just before frrender's second save (vtysh -n --writeconfig, removed on rolling by T9377 after that image);
• bgpd killed while frr-reload's own final write was writing the file;
• a save while watchfrr is not connected (vtysh then writes directly and skips watchfrr's "not all daemons are up" check).

In every case the commit printed no error; after the restart FRR had no router bgp.
With the second save removed (T9377), the first path is closed, but the other two still lose.
With watchfrr connected, a bgpd killed during a commit's reload left the file intact: watchfrr refuses the write while a daemon is down. The unguarded paths are the problem.

Where should this be prevented? Potential options: do not save while a daemon is down (check before writing, or write only through watchfrr); do not save after a failed reload (frr-reload / frrender); make the save atomic (write to a temporary file, rename); and/or re-push the configuration after an FRR or bgpd restart (vyos-configd / a watchfrr hook).