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?
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 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:
The routers in this lab run IOSv15.4.
First let’s complete OSPF configuration on R1 & R2:
R1: router ospf 1 |
R2: router ospf 1 |
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 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 |
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 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
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
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…
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.
@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” ?