bfd session is not created in multihop bgp when update-source is interface name

[weisuofayubg]

Description

I define an ebgp multihop neighbor, and enable bfd. But bfd session is not created if bgp session is not up.

Version

FRRouting 8.4.4 (game) on Linux(6.8.0-47-generic).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--localstatedir=/var/run/frr' '--sbindir=/usr/lib/frr' '--sysconfdir=/etc/frr' '--with-vtysh-pager=/usr/bin/pager' '--libdir=/usr/lib/x86_64-linux-gnu/frr' '--with-moduledir=/usr/lib/x86_64-linux-gnu/frr/modules' '--disable-dependency-tracking' '--enable-rpki' '--disable-scripting' '--disable-pim6d' '--with-libpam' '--enable-doc' '--enable-doc-html' '--enable-snmp' '--enable-fpm' '--disable-protobuf' '--disable-zeromq' '--enable-ospfapi' '--enable-bgp-vnc' '--enable-multipath=256' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' 'build_alias=x86_64-linux-gnu' 'PYTHON=python3'

How to reproduce

define ebgp neighbor, enable multihop and bfd, set update-source with interface name instead of ip addr.

router bgp 2702
 no bgp ebgp-requires-policy
 no bgp hard-administrative-reset
 no bgp graceful-restart notification
 no bgp network import-check
 neighbor 192.168.195.222 remote-as 123
 neighbor 192.168.195.222 bfd
 neighbor 192.168.195.222 ebgp-multihop 64
 neighbor 192.168.195.222 update-source ztc3qw4fhf
exit

Expected behavior

I expect to see bfd session even it is Down.

Actual behavior

BFD session is empty

game(config-router)# do show bfd peers
BFD Peers:
game(config-router)#

Additional context

When I use ip address in update-source, it works.

game(config-router)# neighbor 192.168.195.222 update-source 192.168.195.1
game(config-router)# do show bfd peers
BFD Peers:
        peer 192.168.195.222 multihop local-address 192.168.195.1 vrf default
                ID: 1706643650
                Remote ID: 0
                Active mode
                Minimum TTL: 192
                Status: down
                Downtime: 2 second(s)
                Diagnostics: ok
                Remote diagnostics: ok
                Peer Type: dynamic
                RTT min/avg/max: 0/0/0 usec
                Local timers:
                        Detect-multiplier: 3
                        Receive interval: 300ms
                        Transmission interval: 300ms
                        Echo receive interval: 50ms
                        Echo transmission interval: disabled
                Remote timers:
                        Detect-multiplier: 3
                        Receive interval: 1000ms
                        Transmission interval: 1000ms
                        Echo receive interval: disabled

Why can't it resolve interface IP if I use interface name in update-source?

Checklist

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

[ton31337]

BFD session is started only once the BGP session is established. Or the main issue for you is that update-source does not work with interface name?

[weisuofayubg]

BFD session is started only once the BGP session is established. Or the main issue for you is that update-source does not work with interface name?

Yes BFD session is created if BGP session is established. But as you see, when I use ip addr in update-source, BFD session can be created even bgp is down.
So the behavior is not the same.

[ton31337]

Could you try with the newer versions? I can't replicate this with master branch.

[tufeigunchu]

I have similar issue with master branch:

3500X(config-router)# do show run
Building configuration...

Current configuration:
!
frr version 10.3-dev
frr defaults traditional
hostname 3500X
log file /tmp/bgp.log
service integrated-vtysh-config
!
debug bgp bfd
!
vrf vrf1
exit-vrf
!
router bgp 1234
 bgp router-id 1.1.1.2
 no bgp ebgp-requires-policy
 no bgp network import-check
 neighbor 192.168.1.222 remote-as 123
 neighbor 192.168.1.222 bfd
 neighbor 192.168.1.222 ebgp-multihop 32
 neighbor 192.168.1.222 update-source wlan0
exit
!
end
3500X(config-router)# do show bfd peers
BFD Peers:
3500X(config-router)# no neighbor 192.168.1.222 bfd
3500X(config-router)# neighbor 192.168.1.222 bfd
3500X(config-router)# do show bfd peers
BFD Peers:
        peer 192.168.1.222 multihop local-address 192.168.1.5 vrf default
                ID: 2413620174
                Remote ID: 0
                Active mode
                Minimum TTL: 224
                Status: down
                Downtime: 3 second(s)
                Diagnostics: ok
                Remote diagnostics: ok
                Peer Type: dynamic
                RTT min/avg/max: 0/0/0 usec
                Local timers:
                        Detect-multiplier: 3
                        Receive interval: 300ms
                        Transmission interval: 300ms
                        Echo receive interval: 50ms
                        Echo transmission interval: disabled
                Remote timers:
                        Detect-multiplier: 3
                        Receive interval: 1000ms
                        Transmission interval: 1000ms
                        Echo receive interval: disabled

3500X(config-router)#

If you save the configuraion to frr.conf and restart frr, the BFD peers are empty. But it works by resetting bgp bfd via vtysh.
Is it startup order issue?

[ton31337]

Could you enable all "debug bgp bfd" stuff and show the logs?

[tufeigunchu]

There is no detail info from the startup log

2024/11/11 16:03:35 MGMTD: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00
2024/11/11 16:03:35 MGMTD: [G6NKK-8C6DV] end_config: VTY:0x5555559d2450, pending SET-CFG: 0
2024/11/11 16:03:35 OSPF6: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00
2024/11/11 16:03:35 OSPF6: [G6NKK-8C6DV] end_config: VTY:0x5555558e0a20, pending SET-CFG: 0
2024/11/11 16:03:35 OSPF: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00
2024/11/11 16:03:35 OSPF: [G6NKK-8C6DV] end_config: VTY:0x5555559e1dd0, pending SET-CFG: 0
2024/11/11 16:03:35 LDP: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00
2024/11/11 16:03:35 LDP: [G6NKK-8C6DV] end_config: VTY:0x555555814f00, pending SET-CFG: 0
2024/11/11 16:03:35 BGP: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00
2024/11/11 16:03:35 BGP: [G6NKK-8C6DV] end_config: VTY:0x555556107e50, pending SET-CFG: 0
2024/11/11 16:03:35 STATIC: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00
2024/11/11 16:03:35 STATIC: [G6NKK-8C6DV] end_config: VTY:0x5555556a9680, pending SET-CFG: 0
2024/11/11 16:03:35 BFD: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00
2024/11/11 16:03:35 BFD: [G6NKK-8C6DV] end_config: VTY:0x555555704140, pending SET-CFG: 0
2024/11/11 16:03:35 BGP: [P6TNR-ZB6G6] zclient_bfd_session_replay: sending all sessions registered
2024/11/11 16:03:35 ZEBRA: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00
2024/11/11 16:03:35 ZEBRA: [G6NKK-8C6DV] end_config: VTY:0x555555c031c0, pending SET-CFG: 0
2024/11/11 16:03:36 ZEBRA: [V98V0-MTWPF] client 68 says hello and bids fair to announce only bgp routes vrf=0
2024/11/11 16:03:36 BGP: [TXY0T-CYY6F][EC 100663299] Can't get remote address and port: Transport endpoint is not connected

Using vtysh to del/add bfd again, got below log:

2024/11/11 16:05:43 BGP: [Q4BCV-6FHZ5] zclient_bfd_session_update: 192.168.1.5/32 -> 192.168.1.222/32 VRF default(0) (CPI bit no): Down
2024/11/11 16:05:43 BGP: [MKVHZ-7MS3V] bfd_session_status_update: neighbor 192.168.1.222 vrf default(0) bfd state Unknown -> Down
2024/11/11 16:05:43 BGP: [QFMSE-NPSNN] zclient_bfd_session_update:   sessions updated: 1

[tufeigunchu]

By the way, I found the commit 348ad00 that fix the bug report by @weisuofayubg , it is not in 10.0 and below yet. So only 10.1 has the fix

[ton31337]

@tufeigunchu could you create a separate issue for your case? It's a bit confusing since we talk about two issues in a single thread.

[tufeigunchu]

OK

[ton31337]

Related to #17408.