• 1. Environment
• VyOS 1.5.1/circinus, FRR 10.5.2
• Bonded interface (bond0) with multiple 802.1Q VLAN sub-interfaces (bond0.2XX), each carrying its own IPv6 global address but no explicit per-interface MAC — i.e. all sub-interfaces inherit the parent bond's MAC (standard Linux default, not a VyOS misconfiguration)

Summary

On two directly-connected routers with this addressing pattern, IPv6 BFD sessions between them — whether triggered by OSPFv3's own interface-level bfd profile integration, or by a manually configured protocols bfd peer <link-local> with explicit source address/source interface — never transition past Down, indefinitely. IPv4 BFD on the same physical links, same routers, same OSPF/BGP config style, works correctly and reaches Up with both sides negotiating the configured profile's timers.

Steps to reproduce

set interfaces bonding bond0 vif 210 address '<ipv6-global>/64'
set interfaces bonding bond0 vif 213 address '<ipv6-global>/64'
set interfaces bonding bond0 vif 214 address '<ipv6-global>/64'
# (no explicit `mac` set on bond0 or any vif — all inherit bond0's MAC)

set protocols bfd profile CORE interval receive '300'
set protocols bfd profile CORE interval transmit '300'
set protocols bfd profile CORE interval multiplier '3'
set protocols ospfv3 interface bond0.210 bfd profile 'CORE'
set protocols ospfv3 interface bond0.213 bfd profile 'CORE'
set protocols ospfv3 interface bond0.214 bfd profile 'CORE'
commit

Repeat symmetrically on the peer router for the same link. OSPFv3 adjacency reaches Full normally (BFD is not required for adjacency, just for fast failure detection). But:

run show bfd peers

shows the corresponding fe80::.../interface bond0.21X peer(s) permanently Status: down, Diagnostics: neighbor signaled session down, with a Downtime that only grows.

Observed behavior

tcpdump -ni bond0.210 udp port 3784 on either router shows both directions actively exchanging valid BFD control packets every ~300ms (matching the configured transmit interval) — this is not a packet-loss or firewall issue, packets genuinely arrive on both ends. Both sides simply never progress their own state machine past Down in response.

ip addr show confirms the actual root cause: because all VLAN sub-interfaces on bond0 inherit the parent's MAC, the EUI-64-derived IPv6 link-local address is identical across every one of that router's own sub-interfaces (bond0, .200, .210, .211/.213, .212/.214, .302, .310, .311, .312 all show the same fe80::... address). The link-local address alone is therefore not sufficient to uniquely identify which interface a BFD control packet belongs to.

1. 1. Workarounds attempted, both unsuccessful
2. OSPFv3-integrated bfd profile (as above) — syntax accepted, adjacency fine, BFD session never comes up.
3. Manual static peer with explicit disambiguation: ` set protocols bfd peer <peer-link-local> source address <own-link-local> set protocols bfd peer <peer-link-local> source interface bond0.210 ` VyOS correctly requires both source address and source interface for IPv6 link-local peers (rejects a bare link-local peer otherwise: *"BFD IPv6 link-local peers require explicit local address and interface setting"*), and the resulting session does show up correctly in show bfd peers as Peer Type: configured with the right local-address/interface binding — but it still never leaves Down, with the same neighbor signaled session down diagnostic.
4. Removed the OSPFv3-integrated registration entirely (to rule out the dynamic and static registrations conflicting/stomping on each other for the same session) — the static-only session still stayed Down.

Root cause — matches known upstream FRR issue

This matches, exactly, the bug described in the still-open upstream PR FRRouting/frr#22921: multiple unnumbered peers deriving the same EUI-64 link-local address share an identical (source, destination) address pair, leaving the outgoing interface (ifindex) as the only distinguishing key in bfdd's session tracking — and under certain registration/update orderings, sessions with an unresolved or interface-less key collapse onto each other and "stomp," remaining Down indefinitely. The fix modifies _bfd_sess_valid() in lib/bfd.c to defer registration until the interface is unambiguously known. As of 2026-08-06 that PR is open, unmerged, targeting master — not present in FRR 10.5.2 (the version shipping in VyOS 1.5.1).

• 1. Ask
• Track FRRouting/frr#22921 for merge, and backport into VyOS's FRR package once it lands upstream — this is a real, reproducible functional gap for any unnumbered IPv6 deployment using OSPFv3/BGP BFD (i.e. anyone using VyOS's own IP-unnumbered pattern across VLAN sub-interfaces of the same physical bond/interface, not an exotic edge case).
• No VyOS-side config or documentation change is needed once the upstream fix ships — the existing ospfv3 interface bfd profile/bfd peer config already does the right thing, it's purely blocked on the FRR-side session-tracking bug.

Related context

Structurally the same root category as the fib daddr . iif type ambiguity bug from T9157 (same IP-unnumbered multi-device addressing pattern, different subsystem affected — FIB classification there, BFD session tracking here). Worth cross-referencing if a maintainer is looking at unnumbered-addressing robustness more broadly.