BFD sessions updated 0 ---- Loopback device behavior

[triple-it]

Description

Hi,

As some networking engineer do, they create a loopback interface where the BGP communication happens on: e.g. dummy2
However BFD happens on an other IPSEC interface: vti2

In this case and this scenario, bfd (and bgp) does not know how to find the relative session to update?

DROP --> Notice bfd session_update going to the wrong interface vti2 instead of dummy2?

$ iptables -I INPUT -s 10.64.2.2/32 -d 10.64.2.1/32 -i vti+ -p udp -m multiport --dports 3784 -j DROP

2025/01/17 10:34:24 BFD: [SEY1D-NT8EQ] state-change: [mhop:no peer:10.64.2.2 local:10.64.2.1 vrf:default] up -> down reason:control-expired
2025/01/17 10:34:24 BFD: [SEY1D-NT8EQ] state-change: [mhop:no peer:10.64.2.2 local:10.64.2.1 vrf:default] up -> down reason:control-expired
2025/01/17 10:34:24 BGP: [Q4BCV-6FHZ5] zclient_bfd_session_update: 10.64.2.1/32 -> 10.64.2.2/32 (interface vti2) VRF default(0) (CPI bit no): Down
2025/01/17 10:34:24 BGP: [QFMSE-NPSNN] zclient_bfd_session_update:   sessions updated: 0

ACCEPT --> Notice bfd session_update going to the wrong interface vti2 instead of dummy2?

$ iptables -D INPUT -s 10.64.2.2/32 -d 10.64.2.1/32 -i vti+ -p udp -m multiport --dports 3784 -j DROP 

2025/01/17 10:34:55 BFD: [J1C6V-VMRW5] state-change: [mhop:no peer:10.64.2.2 local:10.64.2.1 vrf:default] down -> up
2025/01/17 10:34:55 BFD: [J1C6V-VMRW5] state-change: [mhop:no peer:10.64.2.2 local:10.64.2.1 vrf:default] down -> up
2025/01/17 10:34:55 BGP: [Q4BCV-6FHZ5] zclient_bfd_session_update: 10.64.2.1/32 -> 10.64.2.2/32 (interface vti2) VRF default(0) (CPI bit no): Up
2025/01/17 10:34:55 BGP: [QFMSE-NPSNN] zclient_bfd_session_update:   sessions updated: 0

I am unable to come up with a configuration that implements a dummy2 loopback device and bfd running, that seems to find the session properly.
Is there some preferred way (best practice) how I should configure the BGP peer? With or without update-source, with or without explicit BFD peer configuration.

Version

10.2.1 && 10.3-dev ....

How to reproduce

neighbor 10.64.2.2 remote-as 65001
neighbor 10.64.2.2 description tun2
neighbor 10.64.2.2 bfd
neighbor 10.64.2.2 bfd profile BFDBGP
neighbor 10.64.2.2 bfd check-control-plane-failure
neighbor 10.64.2.2 update-source 10.64.2.1

bfd
profile BFDBGP
transmit-interval 200
receive-interval 200
echo-mode
echo transmit-interval 200
echo receive-interval 200
exit
!
peer 10.64.2.2 local-address 10.64.2.1
transmit-interval 200
receive-interval 200
echo-mode
echo transmit-interval 200
echo receive-interval 200
exit

Dummy loopback device

4: dummy2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether a2:8c:ae:f6:6c:3a brd ff:ff:ff:ff:ff:ff
inet 10.64.2.1/32 scope global dummy2
valid_lft forever preferred_lft forever

Expected behavior

When this happens...

BFD Peers:
peer 10.64.2.2 local-address 10.64.2.1 vrf default
ID: 3993457047
Remote ID: 0
Active mode
Status: down
Downtime: 2 second(s)
Diagnostics: control detection time expired
Remote diagnostics: ok
Peer Type: configured
RTT min/avg/max: 0/0/0 usec
Local timers:
Detect-multiplier: 3
Receive interval: 200ms
Transmission interval: 200ms
Echo receive interval: 200ms
Echo transmission interval: 200ms
Remote timers:
Detect-multiplier: 3
Receive interval: 200ms
Transmission interval: 200ms
Echo receive interval: disabled

I expect BGP to go also down..

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
10.64.2.2       4      59576        12        15       13    0    0 00:01:20            1        1 tun2

With this config..

neighbor 10.64.2.2 remote-as 59576
neighbor 10.64.2.2 description tun2
neighbor 10.64.2.2 bfd
neighbor 10.64.2.2 bfd profile BFDBGP
neighbor 10.64.2.2 bfd check-control-plane-failure
neighbor 10.64.2.2 update-source 10.64.2.1

bfd
profile BFDBGP
transmit-interval 200
receive-interval 200
echo-mode
echo transmit-interval 200
echo receive-interval 200
exit
!
peer 10.64.2.2 local-address 10.64.2.1
transmit-interval 200
receive-interval 200
echo-mode
echo transmit-interval 200
echo receive-interval 200
exit

Actual behavior

I see in the debug

2025/01/16 18:06:33 BFD: [SEY1D-NT8EQ] state-change: [mhop:no peer:10.64.2.2 local:10.64.2.1 vrf:default] up -> down reason:control-expired
2025/01/16 18:06:33 BGP: [Q4BCV-6FHZ5] zclient_bfd_session_update: 10.64.2.1/32 -> 10.64.2.2/32 (interface vti2) VRF default(0) (CPI bit no): Down
2025/01/16 18:06:33 BGP: [QFMSE-NPSNN] zclient_bfd_session_update: sessions updated: 0

The session stays up..

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
10.64.2.2 4 59576 13 16 13 0 0 00:02:21 1 1 tun2

Additional context

What should be the preferred configuration, to have BFD && BGP on a loopback device come to work?

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.