os-frr: OSPF MD5 fails after FRR 10.6.1 with ExtremeXOS — upstream fix is FRR #22744

[em-esrf]

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

• [x ] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• [ x] I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• [ x] The title contains the plugin to which this issue belongs

Describe the bug
Hello,

On 25.10.2_12, OSPFv2 with MD5 next to ExtremeXOS 31.7.1.4 was stable. After the upgrade to OPNsense Business 26.4.1p1_3 (os-frr + frr10), MD5 adjacencies no longer come up.

We switched the interface to another mode so routing works again.

26.4 ships FRR 10.6.1, that daemon requires a strictly increasing MD5 cryptographic sequence number (FRRouting/frr#21096). ExtremeXOS may reuse the same sequence for more than one packet in the same second, which RFC 2328 allows, so valid packets are dropped. In our network MD5 OSPF actually went down.

This is already fixed upstream as an interoperability switch (strict stays the default):

• Same class of failure (Cisco NX-OS after FRR 10.6.0): FRRouting/frr#21387
• Merged fix (30 July 2026): FRRouting/frr#22744 — compatible rfc7474 / no compatible rfc7474

That pull request is not a ticket we opened. FRR 10.7.0 does not include the command yet (it landed after 10.7.0). Community 26.7.2 still has FRR 10.6.1 as well.

We believe this is mixed-vendor interoperability, and not a weaker MD5. The hash is still checked, only the sequence comparison matches RFC 2328.

To Reproduce

Steps to reproduce the behavior:

1. Run OPNsense Business 26.4.1p1_3 with os-frr, OSPFv2 MD5 (message-digest) toward ExtremeXOS 31.7.1.4 (matching key ID and key).
2. Confirm the same MD5 setup worked on 25.10.2_12.
3. After the 26.4 upgrade, the OSPF neighbor does not stay up / does not reach Full.
4. FRR logs a cryptographic sequence rejection, example: ospf_auth_check_md5_digest bad sequence N (expect > N).
5. Change authentication method, the adjacency comes up again.

Expected behavior

MD5 to ExtremeXOS works again, as it did on 25.10.

Any of these would work for us:

1. Patch on Business 26.4 — backport FRR #22744 onto the current frr10 package (10.6.1), plus a way in os-frr to persist no compatible rfc7474 (GUI option or documented manual snippet).
2. Community package update (26.7.x) with that backport or a later FRR that already contains #22744, then the same on Business 26.4 when you consider is ok.
3. Next FRR / OPNsense major — only if a 26.4 patch is not practical.

router ospf
 no compatible rfc7474

Screenshots

N/A. Happy to attach if it will be useful.

Relevant log files

Typical FRR warning (same class as FRR #21387):

ospf_auth_check_md5_digest bad sequence <N> (expect > <N>), Router-ID: <extreme-router-id>

We can provide the output of other commands if that would help.

Additional context

RFC 2328 Appendix D.4.3 (sender): sequence is non-decreasing; a clock-based sender may reuse one value in the same second.
https://datatracker.ietf.org/doc/html/rfc2328#page-232

RFC 2328 Appendix D.5.3 (receiver): discard only if received sequence is less than the last recorded value (equal is valid).
https://datatracker.ietf.org/doc/html/rfc2328#page-235

Mode	Command	Behavior
Hardened (default, current 26.4)	compatible rfc7474	Sequence must strictly increase
Interoperability (RFC 2328)	no compatible rfc7474	Equal sequence numbers are accepted

Thank you for looking at this.

Environment

OPNsense Business 26.4.1p1_3 (amd64), now 26.4.1p2
os-frr 1.53
frr10 10.6.1
Peer: ExtremeXOS 31.7.1.4, OSPFv2 MD5
Last known working: OPNsense Business 25.10.2_12
Hardware: DEC4280 (Deciso B V NetBoard-A30 x86 [64bit])

[Monviech]

@fichtner

Should we do something here? I think we could wait till upstream releases that patch in a new version.