With protocols ospf parameters opaque-lsa configured, every commit that makes VyOS reload FRR sends every OSPF neighbor of the router back to ExStart and flushes and re-originates the router's own LSAs. This includes commits that have nothing to do with OSPF (measured with a route-map description change). On a router with several neighbors, all of them are reset each time.

With parameters rfc1583-compatibility alone, every such commit runs one extra OSPF SPF. Without either option the same commits do not touch OSPF.

Root cause.

• The template renders FRR's alias commands ospf opaque-lsa and ospf rfc1583compatibility (ospfd.frr.j2). FRR accepts them but stores the setting under the canonical commands and prints capability opaque and compatible rfc1583, so the rendered lines are missing from the running config on every reload.
• frr-reload compares text: it runs no capability opaque / no compatible rfc1583 first, then adds the alias line (measured in the frr-reload log).
• capability opaque and its no form each call ospf_renegotiate_optional_capabilities (ospf_opaque.c:869, :898; ospf_neighbor.c:365-405), which flushes the self-originated LSAs and schedules NSM_SeqNumberMismatch on every neighbor. compatible rfc1583 and its no form schedule an SPF (ospf_vty.c:2225, :2241 at FRR 10.6.1). The handlers act only when the state changes, so the delete-and-add pair costs two state changes per reload; for rfc1583 the SPF throttle merges the two schedules into one run, which is the one extra SPF measured per reload.