Home > Bi-directional Forwarding Detection BFD Tutorial

Bi-directional Forwarding Detection BFD Tutorial

Bi-directional Forwarding Detection (BFD) is a extremely lightweight detection protocol that provides very fast forwarding-path failure detection for all media types, encapsulations, topologies, and the routing protocols (like BGP, EIGRP, IS-IS and OSPF). By using along with these routing protocols, BFD can greatly reduce network convergence time.

In the picture below, we see we have two routers R1 and R2 connected together through a layer 2 switch. These two routers are OSPF neighbors with each other. What if the physical interface between R2 and the layer 2 switch goes down?

BFD_run_switch_between.jpg

The answer is:
+ R2 will tear down the OSPF neighbor immediately based on the layer 1 down event.
+ The physical interface on R1 remains up so it has no awareness of the link local event between the switch and R2. R1 will keep the OSPF neighbor up until the detection of four missing OSPF hellos. By default, OSPF uses a 10-second hello timer and 40-second hold timer on broadcast (Ethernet) links. Therefore R1 may need 40 seconds to detect the broken OSPF neighbor relationship in the worst case.

Of course we can fine tune the hello and hold timer to the minimum values (1 second for hello and 2 or 3 seconds for hold timer is recommended). But BFD can provide failure detection in less than one second (technically, 10s of miliseconds failure detection). This is very useful for real-time applications like Voice over IP (VoIP)

When OSPF discovers a neighbor:
1. OSPF discovers a neighbor
2. OSPF sends a request to the local BFD process to initiate a BFD neighbor session with the OSPF neighbor router
3. The BFD neighbor session with the OSPF neighbor router is established. BFD establishes a session between two endpoints over a particular link.

What happens when a failure occurs in the network:
1. A failure occurs on a link between two BFD neighbors
2. The BFD neighbor session with the OSPF neighbor router is torn down
3. BFD notifies the local OSPF process that the BFD neighbor is no longer reachable
4. The local OSPF process tears down the OSPF neighbor relationship
5. If an alternative path is available the routers will immediately start converging on it.

BFD_fail.jpg

BFD is enabled by default on all vEdge routers and we cannot disable it. For SDWAN, BFD is used to detect path liveliness (up/down) and measure quality (loss/latency/jitter/IPSec tunnel MTU).

A BFD session may operate in one of two modes: asynchronous mode and demand mode.

In asynchronous mode, both endpoints periodically send Hello packets to each other. If a number of those packets are not received, the session is considered down.

The demand mode is different, once the BFD session is established, the participating systems can request that BFD packets not be sent, then request an exchange of packets only when needed to verify connectivity.

BFD Configuration

In this simple lab we will enable BFD along with OSPF. Only two routers are required in this lab:

BFD_config.jpg

The routers in this lab run IOSv15.4.

First let’s complete OSPF configuration on R1 & R2:

R1:
int e0/0
ip address 10.10.10.1 255.255.255.0
no shut

router ospf 1
network 10.10.10.0 0.0.0.255 area 0

R2:
int e0/0
ip address 10.10.10.2 255.255.255.0
no shut

router ospf 1
network 10.10.10.0 0.0.0.255 area 0

After OSPF neighbor relationship has been established between R1 & R2, we can try turning off one interface to see how much time for OSPF to notify this:

R1(config)#int e0/0
R1(config-if)#shutdown
*Jul 21 04:38:35.537: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.2 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
R1(config-if)#
*Jul 21 04:38:37.538: %LINK-5-CHANGED: Interface Ethernet0/0, changed state to administratively down
*Jul 21 04:38:38.544: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to down

On R2 we see:

*Jul 21 04:39:07.763: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired

It took about 30 seconds for OSPF to detect link down and shut down OSPF neighbor relationship. Recall that on Ethernet interfaces the OSPF dead timer is 40 seconds so it may take 40 seconds to tear down OSPF neighbor relationship in the worst case.

Do a “no shut” on interface FastEthernet0/0 of R1 and enable BFD on interfaces of R1 and R2:

R1(config)#int e0/0
R1(config)#no shut
R1(config-if)#bfd interval 50 min_rx 50 multiplier 3
R2(config)#int e0/0
R2(config-if)#bfd interval 50 min_rx 50 multiplier 3

BFD timers are configured with the “bfd interval send-timer mix_rx receive-timer multiplier number” interface configuration command.

+ The send-timer specifies the frequency of BFD packets originated by the router (in milliseconds)
+ The receive-timer is the minimum interval between packets accepted from BFD peers (in milliseconds). This is how often we expect to receive a BFD packet from our neighbor. BFD adjacency will not form if the send-timer on one peer is lower than the receive-timer on another peer.
+ The multiplier number is the number of BFD packets that can be lost before the BFD peer is declared “down”

Therefore in the configuration above, we want to send BFD packets every 50 milliseconds and if four BFD packets are lost in a row then it will be considered “down”.

All the BFD was done so we can instruct OSPF to use BFD on its interfaces:

R1(config)#router ospf 1
R1(config-router)#bfd all-interfaces
R2(config)#router ospf 1
R2(config-router)#bfd all-interfaces

Note: In OSPF mode, we have two ways to configure BFD:
+ Use the command “bfd all-interfaces” to enable BFD on all OSPF interfaces. Then we can disable OSPF interfaces that do not need BFD with the “ospf bfd disable” command in interface configuration mode.
+ Enable BFD for a subset of OSPF interfaces by using the ip ospf bfd command in interface configuration mode

Now let’s try turning off interface on R1 again:

R1(config)#interface e0/0
R1(config-if)#shutdown

We can see OSPF changes state from FULL to DOWN immediately (less than 1 second):

On R1:

*Jul 21 04:50:32.653: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.2 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
R1(config-if)#
*Jul 21 04:50:34.653: %LINK-5-CHANGED: Interface Ethernet0/0, changed state to administratively down
*Jul 21 04:50:35.665: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to down

On R2:

*Jul 21 04:50:32.821: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: BFD node down

In order to verify BFD configuration, we can use the “show bfd neighbors” or “show bfd neighbors detail” command:

R1#show bfd neighbors

IPv4 Sessions
NeighAddr                LD/RD         RH/RS     State     Int
10.10.10.2                1/1          Up        Up        Et0/0
R1#show bfd neighbors details 

IPv4 Sessions
NeighAddr                LD/RD         RH/RS     State     Int
10.10.10.2                1/1          Up        Up        Et0/0
Session state is UP and using echo function with 50 ms interval.
Session Host: Software
OurAddr: 10.10.10.1     
Handle: 1
Local Diag: 0, Demand mode: 0, Poll bit: 0
MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3
Received MinRxInt: 1000000, Received Multiplier: 3
Holddown (hits): 0(0), Hello (hits): 1000(6)
Rx Count: 7, Rx Interval (ms) min/max/avg: 1/985/732 last: 230 ms ago
Tx Count: 8, Tx Interval (ms) min/max/avg: 1/985/650 last: 69 ms ago
Elapsed time watermarks: 0 0 (last: 0)
Registered protocols: OSPF 
Uptime: 00:00:04
Last packet: Version: 1                  - Diagnostic: 0
             State bit: Up               - Demand bit: 0
             Poll bit: 0                 - Final bit: 0
             C bit: 0                                   
             Multiplier: 3               - Length: 24
             My Discr.: 1                - Your Discr.: 1
             Min tx interval: 1000000    - Min rx interval: 1000000
             Min Echo interval: 50000   
Comments
  1. HB
    September 16th, 2020

    It says

    Therefore in the configuration above, we want to send BFD packets every 50 milliseconds and if four BFD packets are lost in a row then it will be considered “down”.

    I thought it will be Three BFD packet loss not Four ?? Multiplier= 3

  2. jimbo
    January 18th, 2022

    The multiplier number is the number of BFD packets that can be lost before the BFD peer is declared “down”
    three BFD packet loss is acceptable, when you loose the forth one, then the neighbor is down…

  3. SR
    July 25th, 2024

    For sub-seconds failurewe use 300ms inerval and and multiplier of 3 so that it is 900ms before the link is considered down. So, it should be three consecutive bfd packet loss not four before the link is down.

  4. Anonymous
    September 28th, 2024

    @certprepare

    check please

    + The multiplier number is the number of BFD packets that can be lost before the BFD peer is declared “down”

    Therefore in the configuration above, we want to send BFD packets every 50 milliseconds and if four BFD packets are lost in a row then it will be considered “down”.

    ///////////////

    3 o 4 BFD packets are lost in a row then it will be considered “down” ?

  1. No trackbacks yet.