Just creating this task to document an issue that's been observed between the L3 access switches in drmrs and the doh/durum VMs there (running Bird daemon for BGP and BFD).
BGP has established between the VMs and the top-of-rack switches, however the BFD sessions on IPv6 remain down. As they have never been "up", and transitioned to a down state, the BGP sessions are working so this is not an operational issue.
Checking the switch shows they have decided that these sessions should be multi-hop BFD:
cmooney@asw1-b13-drmrs> show bfd session address 2a02:ec80:600:102:10:136:1:23 extensive | match "Session type" Session type: Multi hop BFD
A PCAP reveals that this is the case, the switch is sending packets to destination UDP port 4784 (multihop bfd), whereas the VMs are sending to port 3784 (regular bfd).
This is not occuring with the BFD sessions to the same VMs over IPv4. The suspicion would be that the switches are defaulting to "multi-hop" as the link-local and global unicast IPs of the two peers are on different subnets. Which differs from the v4 case where both sides are using IPs on the same subnet.
Forcing the sessions to single-hop mode as shown below causes them to start working:
cmooney@asw1-b12-drmrs> show configuration protocols bgp group Anycast6 bfd-liveness-detection minimum-interval 300; session-mode single-hop;
cmooney@asw1-b12-drmrs> show bfd session | match ^2a02 2a02:ec80:600:1:185:15:58:11 Up irb.611 0.900 0.300 3 2a02:ec80:600:101:10:136:0:21 Up irb.621 0.900 0.300 3
We will need to consider this in light of T209989 however, in terms of what the generic/global config should be here.
As all our peerings are single-hop, in that the VMs running Bird and router/switch are always L2 adjacent, it makes sense that the sessions should be single hop. But there is probably some nuance to the TTL/Hop-Limit being set either side. In drmrs both sides seem to be setting that to 255 and thus we don't see similar problems to those in the task referenced above.