os-frr: OSPF MD5 fails after FRR 10.6.1 with ExtremeXOS — upstream fix is FRR #22744
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 1.2k
- Forks
- 863
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 10
Description
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:
- 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).
- Confirm the same MD5 setup worked on 25.10.2_12.
- After the 26.4 upgrade, the OSPF neighbor does not stay up / does not reach Full.
- FRR logs a cryptographic sequence rejection, example:
ospf_auth_check_md5_digest bad sequence N (expect > N). - 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:
- Patch on Business 26.4 — backport FRR #22744 onto the current
frr10package (10.6.1), plus a way in os-frr to persistno compatible rfc7474(GUI option or documented manual snippet). - 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.
- 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])
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by examining the os-frr and frr10 package entry points for FRR 10.6.1 and the router ospf configuration path. Compare the requested behavior with upstream FRR #22744 and the no compatible rfc7474 command. Done means the interoperability option is backported or available in the supported package and can be persisted for OSPFv2 MD5 configurations.
Written by the indexing model from the issue text.
Assessment
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100