My home WAN edge is a VyOS router that runs OSPFv2 to a core switch and originates the IPv4 default with:

set protocols ospf default-information originate metric '10'

Every commit that makes VyOS reload FRR cuts IPv4 for everything behind the switch for about 5 seconds, including commits that have nothing to do with OSPF. In my case the trigger was a change to a BGP route-map's local-preference. IPv6 is not affected, though OSPFv3 on the same router has the same default-information originate. I matched two of these gaps to the second against frr-reload.log:

2026-10-08 16:01:54,205  INFO: Executed "router ospf  no default-information originate metric 10 exit"
2026-10-08 16:09:54,998  INFO: Executed "router ospf  no default-information originate metric 10 exit"

What happens

include/ospf/metric-type.xml.i has <defaultValue>2</defaultValue>, so the rendered vyos.frr.conf carries the metric type even though my config only sets metric '10':

/run/frr/config/vyos.frr.conf  default-information originate metric 10 metric-type 2
vtysh show running-config      default-information originate metric 10

ospfd prints metric-type only when it is 1 (config_write_ospf_redistribute and config_write_ospf_distribute in ospfd/ospf_vty.c, stable/10.6 lines 12775 and 12897; master is the same). frr-reload.py compares the two lines as text, finds them different, and runs no default-information originate metric 10 followed by the add. The no makes ospfd flush its Type-5 default (MaxAge). The new instance is originated within milliseconds, but my switch has a minimum LSA arrival of 1000 ms, so it discards the instance that arrives that soon and has no default until the 5 s retransmit interval delivers it again.

OSPFv3 does not show this for default-information, because ospf6d prints metric-type there whatever its value.

Scope

The same metric-type rendering is used on these template lines:

• ospfd.frr.j2 line 149, default-information originate (the one I hit)
• ospfd.frr.j2 lines 229 and 232, redistribute table-direct and redistribute <protocol>
• ospf6d.frr.j2 line 112, redistribute <protocol> (ospf6d prints metric-type for redistribute only when it is 1, ospf6d/ospf6_asbr.c)

I only use default-information originate on my router. I also reproduced this on a stock 2026.10.07-0712 nightly in a VM, with redistribute connected metric 20 added. An unrelated route-map commit deleted and re-added both lines, and the default LSA went from sequence 0x80000001 to 0x80000002. With the patched template, two unrelated commits left both lines and the LSA alone.

ospf6d.frr.j2 line 75 (OSPFv3 default-information originate) round-trips today and should keep rendering metric-type, since ospf6d prints it back.

This looks like the same mechanism as T8990 (BGP route-target vpn vs FRR's rt vpn) and T9441 (ospf opaque-lsa alias): the rendered line differs from the form FRR prints back, so frr-reload deletes and re-adds it on every reload.

Testing the template change on my router

I changed the three ospfd.frr.j2 lines on my router to emit metric-type only when it is '1', restarted vyos-configd (it keeps the Jinja environment loaded, so a template edit is not picked up until then), and made two commits that touch FRR without touching OSPF (add, then remove, a description on a route-map rule). With IPv4 pings running every 0.2 s from two hosts behind the switch:

• vyos.frr.conf now renders default-information originate metric 10, the same as FRR's running config.
• frr-reload.log for both commits has no router ospf lines.
• The Type-5 default kept LS sequence 80000004 and its age kept counting up, so it was not flushed or re-originated.
• Both ping runs lost nothing across the restart and both commits, and the switch's default route was installed 1 h 41 min before the test and never changed.

That is two commits on one router, not a long soak. I left metric-type unset in my config, so the patched template rendered the default type 2 without the keyword.

Workaround

set protocols ospf default-information originate metric-type '1'

FRR prints type 1 back, so frr-reload finds no difference. This only fits where E1 vs E2 does not change path selection. In my area there is a single default originator, so it would change nothing, but I tested the template change above instead.