Vyos BFD down, but BGP session is UP?

Development
,
1

i have configured BFD with BGP as per BFD — VyOS 1.3.x (equuleus) documentation

the remote peer, at this point does not yet have BFD configured, and as expected BFD is operationally Down

vyos@VYOS-02:~$ show protocols bfd peer
BFD Peers:
peer 192.168.255.46 vrf default interface eth5
ID: 939062670
Remote ID: 0
Active mode
Status: down
Downtime: 31 minute(s), 2 second(s)
Diagnostics: ok
Remote diagnostics: ok
Peer Type: configured
Local timers:
Detect-multiplier: 3
Receive interval: 300ms
Transmission interval: 300ms
Echo transmission interval: 50ms
Remote timers:
Detect-multiplier: 3
Receive interval: 1000ms
Transmission interval: 1000ms
Echo transmission interval: 0ms

however, unexpectedly BGP is UP, note how the BGP session is aware BFD is down…
vyos@VYOS-02:~$ show ip bgp neighbors 192.168.255.46
BGP neighbor is 192.168.255.46, remote AS 65535, local AS 65538, external link
BGP version 4, remote router ID 192.168.30.6, local router ID 192.168.254.2
BGP state = Established, up for 00:27:14
Last read 00:00:01, Last write 00:00:04
Hold time is 30, keepalive interval is 10 seconds
Configured hold time is 30, keepalive interval is 10 seconds
Neighbor capabilities:
4 Byte AS: advertised and received
AddPath:
IPv4 Unicast: RX advertised IPv4 Unicast
Route refresh: advertised and received(old & new)
Address Family IPv4 Unicast: advertised and received
Hostname Capability: advertised (name: VYOS-02,domain name: n/a) not received
Graceful Restart Capability: advertised
Graceful restart information:
Local GR Mode: Helper*
Remote GR Mode: Disable
R bit: False
Timers:
Configured Restart Time(sec): 120
Received Restart Time(sec): 0
Message statistics:
Inq depth is 0
Outq depth is 0
Sent Rcvd
Opens: 13 13
Notifications: 12 12
Updates: 286 31
Keepalives: 195359 224495
Route Refresh: 0 0
Capability: 0 0
Total: 195670 224551
Minimum time between advertisement runs is 0 seconds
Update source is 192.168.255.45

For address family: IPv4 Unicast
Update group 4, subgroup 4
Packet Queue length 0
Inbound soft reconfiguration allowed
Community attribute sent to this neighbor(all)
Inbound path policy configured
Outbound path policy configured
Route map for incoming advertisements is *fromECVs
Route map for outgoing advertisements is *toECVs
8 accepted prefixes

Connections established 13; dropped 12
Last reset 00:27:40, Admin. shutdown
Local host: 192.168.255.45, Local port: 40363
Foreign host: 192.168.255.46, Foreign port: 179
Nexthop: 192.168.255.45
Nexthop global: fe80::20c:29ff:fe59:6b60
Nexthop local: fe80::20c:29ff:fe59:6b60
BGP connection: shared network
BGP Connect Retry Timer in Seconds: 120
Estimated round trip time: 47 ms
Read thread: on Write thread: on FD used: 32

BFD: Type: single hop
Detect Multiplier: 3, Min Rx interval: 300, Min Tx interval: 300
Status: Down, Last update: 0:00:29:16

vyos@VYOS-02:~$

VYOS version 1.3-beta-202107121144
vyos@VYOS-02:~$ show version

Version: VyOS 1.3-beta-202107121144
Release Train: equuleus

Built by: autobuild@vyos.net
Built on: Tue 13 Jul 2021 03:42 UTC
Build UUID: 1acfd1ce-c432-4fbf-9e9e-2933807e5e5f
Build Commit ID: 2ba1cbb93659bc

Architecture: x86_64
Boot via: installed image
System type: VMware guest

Hardware vendor: VMware, Inc.
Hardware model: VMware Virtual Platform
Hardware S/N: VMware-56 4d 2d f8 07 1c f8 c2-2a c2 5d 0f bb 59 6b 42
Hardware UUID: 564d2df8-071c-f8c2-2ac2-5d0fbb596b42

Copyright: VyOS maintainers and contributors
vyos@VYOS-02:~$

any ideas why BGP can be UP, when BFD is clearly down ???

2

i upgraded to 1.4-rolling-202212280917, and the situation is the same, BFD operationally down, but eBGP is UP

vyos@VYOS-02:~$ show bfd peers
BFD Peers:
        peer 192.168.255.46 local-address 192.168.255.45 vrf default
                ID: 113197427
                Remote ID: 0
                Active mode
                Status: down
                Downtime: 1 hour(s), 3 minute(s), 20 second(s)
                Diagnostics: neighbor signaled session down
                Remote diagnostics: ok
                Peer Type: configured
                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

vyos@VYOS-02:~$ show ip bgp neighbors 192.168.255.46
BGP neighbor is 192.168.255.46, remote AS 65535, local AS 65538, external link
  Local Role: undefined
  Remote Role: undefined
  BGP version 4, remote router ID 192.168.30.6, local router ID 192.168.254.2
  BGP state = Established, up for 01:03:42
  Last read 00:00:08, Last write 00:00:02
  Hold time is 30 seconds, keepalive interval is 10 seconds
  Configured hold time is 30 seconds, keepalive interval is 10 seconds
  Configured conditional advertisements interval is 60 seconds
  Neighbor capabilities:
    4 Byte AS: advertised and received
    Extended Message: advertised
    AddPath:
      IPv4 Unicast: RX advertised
    Long-lived Graceful Restart: advertised
    Route refresh: advertised and received(old & new)
    Enhanced Route Refresh: advertised
    Address Family IPv4 Unicast: advertised and received
    Hostname Capability: advertised (name: debian,domain name: n/a) not received
    Graceful Restart Capability: advertised
  Graceful restart information:
    Local GR Mode: Helper*
    Remote GR Mode: Disable
    R bit: False
    N bit: False
    Timers:
      Configured Restart Time(sec): 120
      Received Restart Time(sec): 0
  Message statistics:
    Inq depth is 0
    Outq depth is 0
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:               19          1
    Keepalives:           383        441
    Route Refresh:          0          0
    Capability:             0          0
    Total:                403        443
  Minimum time between advertisement runs is 0 seconds
  Update source is 192.168.255.45

 For address family: IPv4 Unicast
  Update group 4, subgroup 4
  Packet Queue length 0
  Inbound soft reconfiguration allowed
  Community attribute sent to this neighbor(all)
  Inbound path policy configured
  Outbound path policy configured
  Route map for incoming advertisements is *fromECVs
  Route map for outgoing advertisements is *toECVs
  8 accepted prefixes

  Connections established 1; dropped 0
  Last reset 01:03:44,  Waiting for peer OPEN
  External BGP neighbor may be up to 1 hops away.
Local host: 192.168.255.45, Local port: 33135
Foreign host: 192.168.255.46, Foreign port: 179
Nexthop: 192.168.255.45
Nexthop global: fe80::20c:29ff:fe59:6b60
Nexthop local: fe80::20c:29ff:fe59:6b60
BGP connection: shared network
BGP Connect Retry Timer in Seconds: 120
Estimated round trip time: 47 ms
Read thread: on  Write thread: on  FD used: 31

  BFD: Type: single hop
  Detect Multiplier: 3, Min Rx interval: 300, Min Tx interval: 300
  Status: Down, Last update: 0:01:03:44

vyos@VYOS-02:~$ show version
Version:          VyOS 1.4-rolling-202212280917
Release train:    current

Built by:         autobuild@vyos.net
Built on:         Wed 28 Dec 2022 09:17 UTC
Build UUID:       e5312f1b-3eaf-4537-b155-7653b874e80e
Build commit ID:  0351b37359517d

Architecture:     x86_64
Boot via:         installed image
System type:      VMware guest

Hardware vendor:  VMware, Inc.
Hardware model:   VMware Virtual Platform
Hardware S/N:     VMware-56 4d 2d f8 07 1c f8 c2-2a c2 5d 0f bb 59 6b 42
Hardware UUID:    564d2df8-071c-f8c2-2ac2-5d0fbb596b42

Copyright:        VyOS maintainers and contributors
vyos@VYOS-02:~$
3

Hello @hazza06
Can you show bgp and bfd configurations?

4

vyos bfd and bgp config as below…

 protocols {
     bfd {
         peer 192.168.255.46 {
             interval {
                 multiplier 3
                 receive 300
                 transmit 300
             }
             source {
                 interface eth5
             }
         }
         peer 192.168.255.249 {
             interval {
                 multiplier 3
                 receive 300
                 transmit 300
             }
             source {
                 interface eth1
             }
         }
     }

    bgp {
        address-family {
            ipv4-unicast {
                network 192.168.0.0/16 {
                }
                redistribute {
                    connected {
                    }
                    static {
                    }
                }
            }
        }
        neighbor 192.168.255.46 {
            address-family {
                ipv4-unicast {
                    route-map {
                        export toECVs
                        import fromECVs
                    }
                    soft-reconfiguration {
                        inbound
                    }
                }
            }
            bfd {
            }
            remote-as 65535
            timers {
                holdtime 30
                keepalive 10
            }
            update-source 192.168.255.45
        }
        parameters {
            log-neighbor-changes
            router-id 192.168.254.2
        }
        system-as 65538
    }
5

AFAIK this is by design. You can configure BFD with BGP even if the remote end doesn’t have BFD. The BGP session will come up without BFD active. It will respect the standard BGP timeouts. This applies to other routing protocols as well.

As soon as the remote device starts talking BFD and the BFD session comes up, it will be used to detect if the remote device is still alive and will tear the BGP session down if BFD goes down.

So, short: BFD will only be used once the BFD session is active else protocol standards apply.

6

Some quick googling only brings up this juniper thread: BGP sessions up while BFD down | Routing and I cannot find it in the RFC, but I’m pretty sure it’s by design.

7

that post makes no sense whatsoever, suggest you read the BFD RFC…

8

Well I did and like I told you I couldn’t find it. But in the meantime I found the correct RFC which is 5882, it states the following (I’ve highlighted the part for you):

4.1. Adjacency Establishment

If the session state on either the local or remote system (if known)
is AdminDown, BFD has been administratively disabled, and the
establishment of a control protocol adjacency MUST be allowed.

BFD sessions are typically bootstrapped by the control protocol,
using the mechanism (discovery, configuration) used by the control
protocol to find neighbors. Note that it is possible in some failure
scenarios for the network to be in a state such that the control
protocol is capable of coming up, but the BFD session cannot be
established, and, more particularly, data cannot be forwarded. To
avoid this situation, it would be beneficial not to allow the control
protocol to establish a neighbor adjacency. However, this would
preclude the operation of the control protocol in an environment in
which not all systems support BFD.

Therefore, the establishment of control protocol adjacencies SHOULD
be blocked if both systems are willing to establish a BFD session but
a BFD session cannot be established. One method for determining that
both systems are willing to establish a BFD session is if the control
protocol carries explicit signaling of this fact. If there is no
explicit signaling, the willingness to establish a BFD session may be
determined by means outside the scope of this specification.

If it is believed that the neighboring system does not support BFD,
the establishment of a control protocol adjacency SHOULD NOT be
blocked.

The setting of BFD’s various timing parameters and modes are not
subject to standardization. Note that all protocols sharing a
session will operate using the same parameters. The mechanism for
choosing the parameters among those desired by the various protocols

is outside the scope of this specification. It is generally useful
to choose the parameters resulting in the shortest Detection Time; a
particular client application can always apply hysteresis to the
notifications from BFD if it desires longer Detection Times.

Note that many control protocols assume full connectivity between all
systems on multiaccess media such as LANs. If BFD is running on only
a subset of systems on such a network, and adjacency establishment is
blocked by the absence of a BFD session, the assumptions of the
control protocol may be violated, with unpredictable results.

1 Like
9

You will need to allow the BFD UDP traffic. BFD is independent from BGP.

10

@hazza06

@roedie is right. BFD works only if BFD control plane is up. It must be configured on both sides. And it detects only situation from UP to DOWN. BGP session brings up independently. And it does not look at BFD at that time.

1 Like