FRR compatibility

FRR compatibility

The engine is a BFD data plane for FRR's bfdd. What works depends on the FRR version, so this page records what was measured rather than what the release notes imply.

Everything below was run on 2026-09-21 against stock quay.io/frrouting/frr images, using the frr-marked end-to-end suite (9 tests: data plane handshake, both sides to Up, --dp-hold across a bfdd crash, Poll/Final renegotiation, and multihop TTL).

sudo BFD_FRR_IMAGE=quay.io/frrouting/frr:10.7.1 \
    python3 -m pytest tests/e2e -m frr

Which releases work

FRR	Result
9.0.5	fails
9.1.3	fails
10.0.4	fails
10.1.1	fails
10.1.2	9/9
10.1.4	9/9
10.2.6	9/9
10.3.4	9/9
10.4.2	9/9
10.4.5	9/9
10.5.5	9/9
10.6.2	9/9
10.7.1	9/9
master	9/9

The floor is 10.1.2. Use that or newer.

On anything older the control channel connects and then drops in a loop, about once a second, and no session ever reaches Up. The cause is in bfdd: after a successful connect in client mode, it fell through into its reconnect path and closed the socket it had just opened. Mark Stapp's b71fd2f68f ("bfdd: retain remote dplane client socket") added the missing return, and 10.1.2 is the first release carrying it. The measured pass/fail split matches the presence of that commit at every tag tested, with no exceptions.

The data plane protocol has not changed

BFD_DP_VERSION is 1 in every release from 9.0.5 through current master, so the handshake itself is not a compatibility risk. The 10.1.2 floor is about the connect loop, not the wire format.

Transport: use TCP

bfdd reaches the engine either over TCP or over a unix socket. Only the TCP form works with a released FRR.

Transport	10.1.2	10.7.1	master
ipv4c:127.0.0.1:50700	works	works	works
unixc:/path/to.sock	EINVAL	EINVAL	works

bfdd passes an oversized addrlen to connect(2), which AF_UNIX rejects with EINVAL and AF_INET tolerates, which is exactly why TCP is unaffected. The one-line fix is upstream as #22621 but is on master only; the faulty assignment is present at every release tag from 9.0.5 to 10.7.1.

So, with any released FRR:

bfdd_options="  -A 127.0.0.1 --dplaneaddr ipv4c:127.0.0.1:50700"

If you do run master and want the unix socket, note that a distribution bfdd AppArmor profile may allow only @{run}/frr/bfdd.sock. A socket anywhere else is refused with Permission denied before FRR is involved at all; dmesg shows the apparmor="DENIED" operation="connect" line.

Fixes this engine depends on, and where they are

These bfdd changes came out of building and running this engine. All are merged to FRR master. None is in any release yet, including 10.7.1.

PR	Merged	What it fixes
#22621	2026-07-09	unixc: connect fails with EINVAL
#22645	2026-07-15	sessions silently lost when registration overflows the output buffer: a release offloads about 58
#22692	2026-08-14	output buffer not drained on shutdown
#22694	2026-08-17	input buffer space not reclaimed
#22805	2026-07-25	echo interval not negotiated for data plane sessions
#22920	2026-08-12	IPv6 echo sourced from the wrong address
#23023	2026-08-24	demand mode (RFC 5880 section 6.6)
#23281	2026-09-15	keyed SHA1 sequence number validation
#23282	2026-09-15	session runs unauthenticated when its keychain has no usable key
#23284	2026-09-14	State field ignored when Your Discriminator is zero
#23331	2026-09-25	authentication keys, with their lifetimes, carried to the data plane

FRR branches a release well before it is tagged, so a master merge does not reach the next tag. frr-10.7.0 was tagged on 2026-07-15, six days after #22621 merged, and still does not contain it. Expect these in 10.8.

What that means in practice: a released FRR gives you working BFD, and the list above is what you do not get. Echo interval negotiation, demand mode, the authentication fixes and offloading an authenticated session at all need master. Run master if you need those; otherwise 10.1.2 or newer is fine.

What has not been measured

The suite covers the data plane channel, session establishment, the crash hold, renegotiation and multihop. It does not drive echo, demand mode or authentication against a real bfdd, so those rows are recorded from upstream history rather than from an end-to-end run here. Authenticated offload with master has been run on the 1024-session testbed instead: 68 keyed SHA1 sessions, meticulous among them, up through the engine.