Introduction and Overview
Bidirectional Forwarding Detection (BFD) is a light-weight standards-based protocol, defined by RFC 5880, that detects failure in the forwarding path on a layer 3 network between two adjacent routers. These failures may be on the connecting interfaces, data links, tunnels, and forwarding planes of devices not directly connected to the routers in a layer 2 network. BFD is capable of working on multiple media types. BFD uses UDP packets to exchange control information with peers on port 49152 as the source port and destination port of 3784.
BFD's primary goal is to detect loss of connectivity between two devices quickly and efficiently. BFD notifies client protocols of the link failure. BFD client protocols include OSPF, IS-IS RSVP, EIGRP, HSRP, BGP, static routes that have registered to receive BFD notifications. BFD provides faster and more consistent failure detection than the hello and keepalive timers of routing protocols. Failure detection in BFD can be in the millisecond range. Most routing protocol timers will detect a link failure at a minimum of one second after it has occurred. It is up to these client protocols to determine how to recover from the failure of the link between the two devices. The client protocols may try to find alternative paths for routes that were initially accessible through the failed device. The client protocols use the BFD-provided information independently. BFD runs to serve these client protocols. It is pointless to run BFD without client protocols.
Networks carrying realtime traffic such as video and voice need speedy network convergence. Link failure detection time usually delays convergence of networks. Traditional link failure detection relies on:
- Hello message timeouts of routing protocols.
- Transmission technology capability to detect failure.
BFD runs independent of routing protocol hello messages and notifies the client protocols of link failure by sending rapid failure detection notices to routing protocols and reducing convergence time through routing table recalculation. BFD can be used in place of routing protocol timers and can act as a single method of liveliness detection between nodes irrespective of media type.
On distributed platforms, BFD packets can be processed on interface modules of the line card hence it is not CPU intensive. In most cases, routing protocol hello packets are processed by the control plane (CPU).
BFD also provides failure detection on virtual circuits such as MPLS LSP, Ethernet virtual circuits tunnels.
By default, BFD topology is primarily point-to-point running on a link between two devices.
BFD can be implemented in multiple ways:
- Single-hop BFD: BFD for IPv4 and IPv6
- Generic Application of BFD
- BFD for MPLS (LSPs)
- Multihop BFD for peers that are several hops away from each other
Benefits of BFD
The closest alternative to using BFD for failure detection is the hello packet
of routing protocols EIGRP, OSPF, IS-IS and BGP keepalive messages.
If configured to their minimum supported values, these routing protocol timers
usually detect failures of peers or their links within one second of the failure.
With OSPF though, configuration of sub-second values is possible using the interface command
ip ospf dead-interval minimal hello-multiplier <multiplier>
where multiplier is the number of hello packets sent per second;
BFD does have some advantages over the aforementioned failure detection techniques:
- BFD is protocol independent and can therefore act as a generic failure detection mechanism for various routing protocols.
- Parts of BFD failure mechanisms can be configured to operate at the data-plane reducing or eliminating CPU involvement in failure detection. This can be contrasted with failure detection methods of routing protocols that largely operate at the control plane.
- BFD is able to detect failures in the sub-second range compared to most routing protocol failure detection which is usually at a minimum of one second.
Prerequisites for BFD
- Cisco Express Forwarding (CEF) needs to be enabled.
- The client routing protocol should be configured on the router before BFD is deployed.
Restrictions of BFD
- When BFD is enabled on an interface, an access control list (ACL) with the "log" opton is not supported on that interface.
- BFD is not supported in IPSec.
BFD Modes
BFD operates in one of two modes: asynchronous or demand mode. BFD also offers an echo function which works with both modes. Most vendors support asynchronous mode operating with or without echo function enabled.
Asynchronous Mode
BFD control packets are exchanged by neighboring systems at pre-agreed time intervals which is usually in milliseconds. If a specified number of sequential packets are not received from the BFD peer, BFD declares the session to be down and notifies any registered protocol of this failure. Asynchronous mode is supported by Cisco IOS.
Demand Mode
Once the BFD session is established, the participating systems can request that the BFD packets not be sent, then request an exchange of packets only when needed to verify connectivity. Though this mode is defined in the RFC 5880, few network equipment vendors support BFD demand mode.
How BFD Works
Once a BFD session is established with a neighbor, BFD exchanges control packets to verify connectivity and inform the requesting protocol(s) of link failure if a specified number of successive packets are not received. The requesting protocol is then responsible for responding to the link-failure. Routing protocols using BFD for failure detection continue to operate normally when BFD is enabled, including the exchange of their respective hello packets.
A BFD session is a three-way handshake and tear-down process:
- Routing protocol discovers neighbor and registers neighbor as a client with BFD.
- BFD control packets act as keepalive to maintain the neighbor session.
- Failure of the BFD session triggers a notification to the registered routing protocol client which in term tears down the routing protocol neighbor session. If an alternative path exists the routing protocol immediately converges.
BFD Packets
BFD utilises control packets to exchange control information as well as detect the liveliness of the BFD peer.
BFD Control Packet Format
| Field | Description |
| Diagnostic Code (Diag) and Session State: | State in which the BFD session is in and reason i.e. Up/Down/Init. |
| Discriminators: | demultiplexers |
| Detect Time Multiplier | Used to calculate detection times for peers. The detection time is the product of the Detect Time Multiplier and Min RX Interval that is used to question a peer's liveliness if a control packet is not received within this product in milliseconds. |
| Desired Min TX Interval (msecs): | Desired interval to transmit control packets. i.e. how fast the peer desires to send control packets. |
| Required Min RX Interval (msecs): | Minimum receive interval peer can handle. i.e. rate that the peer can receive packets. |
| Required Min Echo Interval | Interval within which echo packets are received to indicate liveliness of a peer (if the echo function is enabled). |
The following output shows a Wireshark packet capture of a BFD control packet. From this packet capture, it can be determined that the transmit interval is configured to 1000ms, the receive interval to 1000ms, minimum echo interval to 50ms and the multiplier to 3 (x3 the value of the transmit interval).
BFD Control message
001. .... = Protocol Version: 1
...0 0000 = Diagnostic Code: No Diagnostic (0x00)
01.. .... = Session State: Down (0x1)
Message Flags: 0x40
0... .. = Poll: Not set
.0.. .. = Final: Not set
..0. .. = Control Plane Independent: Not set
...0 .. = Authentication Present: Not set
.... 0. = Demand: Not set
.... .0 = Multipoint: Not set
Detect Time Multiplier: 3 (= 3000 ms Detection time)
Message Length: 24 bytes
My Discriminator: 0x00000002
Your Discriminator: 0x00000000
Desired Min TX Interval: 1000 ms (1000000 us)
Required Min RX Interval: 1000 ms (1000000 us)
Required Min Echo Interval: 50 ms (50000 us)
Timer Negotiation and Detection Times
When making decisions on detection timers, BFD sends packets as fast as their local peers allow but no faster.
A BFD device notes the Required Min RX Interval value received from a peer's BFD control packet
(how fast a peer can receive BFD packets) and compares it to its configured
Desired Min TX Interval (how fast it can send BFD control packets).
The operational transmit interval is then set to whichever of the two values is higher.
When calculating the detection timer values, the local detection is equal to the product of the
peer's Detect Time Multiplier and the peer's Tx value. The TX timer and the detection times can be different for each peer.
| Device | TX Interval | Min_Rx | Operational TX | Multiplier | Detection Time |
| R1 | 50ms | 50ms | 50ms | 3 | 3 ×50ms = 150ms |
| R2 | 50ms | 50ms | 50ms | 3 | 3 ×50ms = 150ms |
| R3 | 50ms | 150ms | 150ms | 5 | 10 ×150ms = 1500ms |
| R4 | 50ms | 150ms | 150ms | 10 | 5 × 150ms = 750ms |
| R5 | 50ms | 200ms | 150ms | 5 | 10 ×500ms = 5000ms or 5s |
| R6 | 500ms | 150ms | 500ms | 10 | 5 × 150ms = 750ms |
The first device to detect that the peer is unreachable will set a flag in the control packet notifying the peer that it is unreachable. The local BFD instance will notify the client routing protocols in each of the peers resulting in both tearing down the routing protocol neighborship.
Echo Function
When the echo function is activated, echo packets are looped back through the layer 3 forwarding path to the BFD peer without involving the CPU. Link failure is detected by an interruption in the stream of echoed packets. Echo function makes it possible for link failure detection using BFD to be handled at the data plane level and not involve the CPU.
The minimum reception rate for BFD control packets from the neighbor is also changed automatically when the echo function is operational, because liveness detection is supplied by the echo packets.
While BFD control messages are transmitted to UDP port 3784, BFD echo messages use UDP port 3785 for both source and destination ports of the BFD echo packet.
BFD started out based on a polling ("asynchronous") approach using control packets. One router polls the other and gets a quick response back. The challenge with this is delay in waking up the BFD process to send a reply, culminating in variable jitter in the response. If the peer is slow in responding BFD triggers a link failure notification, which is not ideal. It is possible to configure both peers to send BFD echo packets or one peer to send the BFD echo packet. The latter approach is referred to as BFD asymmetry.
The Echo function is an additional feature that can be enabled in any of the BFD operational modes i.e. asynchronous or demand modes. The BFD echo function enhances BFD in one very specific way; it allows the devices running BFD to test the actual forwarding path taken by data packets. This is a capability that the control packets are not able to carry out. In some IOS distributions, the Echo function is enabled by default.
Echo Packets
The Echo function uses echo packets using interesting values for the IP source and destination addresses. The destination IP address is set to the IP address of the sender. In other words, the destination IP address is the same as the source IP address of the sender. For Layer 2 addressing, the destination address is the MAC address of the BFD peer.
After the BFD peer receives an echo packet and determines that the destination IP address is different from any of its IP addresses, it consults the RIB/FIB to determine how to forward the packet and sends it to the sender. In this way it uses the data forwarding path of network traffic.
Echo Function in BFD Asynchronous Mode
Peers need to exchange BFD information such as intervals, State, Diag etc. Echo packets do not carry usable data and are technically processed by the sender. Control packets are still exchanged but the frequency is substantially decreased. In BFD asynchronous mode without the echo function, the control packets play the dual-role of exchanging BFD session information and detecting link failure. In BFD asynchronous mode with echo function, the echo function uses control packets to exchange BFD information as usual. However, the control packets are sent less frequently; more frequently sent are echo packets which take the primary role of detecting link failure.
Echo Function Activation
BFD peers use the control packet to signal activation of the echo function.
The control packet field Required Min Echo Interval is used to signal
echo function activation to a BFD peer. If the echo function is activated, the
Required Min Echo Interval field contains a value
in milliseconds. It is used to communicate to the BFD peer the minimum rate
of the sender receiving echo packets. Conceptually, it is similar to the
Required Min RX Interval of the Echo packet. The frequency of
Echo packet are therefore partially dictated by the neighbors. Echo packets can
not be sent more frequently than the Required Min RX Interval
values of the BFD peer.
If the echo function is not activated, the control packets from the peer will
contain zero values for the Required Min Echo Interval
field.
Restrictions to Using the Echo Function
- Disable ICMP redirects on any interface where the BFD echo function will
be used using the command
no ip icmp redirects. With ICMP redirect active on an interface, the interface will notice that the echo packets are looped back. It will then generate an ICMP redirect message for each echo packet. Disabling ICMP redirect messages helps in avoiding high CPU uilization. - Any uRPF checks will need to be disabled on the interface or an exception should be made for echo packets on the interface. Based on the way echo packets are transmitted and looped back, they fail uRPF checks; depending on how strict the uRPF checks have been configured. If BFD echo mode and uRPF are configured on the same interface, BFD sessions will flap.
BFD Slow Timer
BFD can use the slow timer to slow down the transmission rate of BFD control packets when the echo function is enabled. This reduces the number of BFD control packets that are sent between two BFD neighbors. With echo function enabled, control packets are not used for failure detection hence may not be desirable to be exchanged frequently. This, in turn, further lightens the CPU load.
To configure BFD slow timer use the global configuration mode command
bfd slow-timer <milliseconds>:
R6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z
R6(config)#bfd slow-timers 12000
R6(config)#
BFD Configuration
Configuration of BFD is a two step process:
Step 1: Enable BFD on interface through which the peer is reachable
using the interface configuration command:
bfd interval <tx-interval> min_rx < min_rex> multiplier <multiplier>.
The rate of exchanging hello control packets (similar to hello-timer) can be set in the range 50 - 9999 milliseconds.
min_rx: minimum interval supported for receiving BFD control packets from a neighbor.
multiplier: used to compute the hold-down time. If multiplier is 3 and hello interval 50 then holddown timer is 150 ms.
R6(config)#interface gigabitethernet0/0
R6(config-if)#bfd interval 100 min_rx 50 multiplier 3
Step 2: Configure the routing protocol to use BFD for failure detection. Interested clients include static routing, EIGRP, OSPF, BGP, FHRP(HSRP, VRRP, GLBP), MPLS LSP, etc registers with BFD and is notified as soon as BFD detects a neighbor loss.
BFD for BGP
BFD must be running on all participating BGP devices.
R6(config)#router bgp 65531
R6(config-router)#neighbor 1.1.1.1 remote-as 65532
R6(config-router)#neighbor 1.1.1.1 fall-over bfd ?
multi-hop Force BFD multi-hop to detect failure
single-hop Force BFD single-hop to detect failure
<cr>
BFD in BGP supports two session types: multi-hop and single-hop. This is because BGP supports BGP peers that can be directly connected or several hops away. This BFD session type will depend on the BGP session type of the neighbor being configured; if the neighbor is several hops away, configure the BFD multi-hop type.
BFD in EIGRP
In EIGRP named mode, BFD is configured under the af-interface mode:
R6(config)#router eigrp EIGRP_NAMED
R6(config-router)#address-family ipv4 autonomous-system 1
R6(config-router-af)#af-interface gigabitethernet0/0
R6(config-router-af-interface)#bfd
R6(config-router-af-interface)#
If BFD is configured under af-interface default, all interfaces with EIGRP peers will be registered to
receive BFD notifications. However, remember that BFD has to first be configured on the interface otherwise the
following error messaage will be generated:
R6(config)#router eigrp EIGRP_NAMED
R6(config-router)#address-family ipv4 autonomous-system 1
R6(config-router-af)#af-interface gigabitethernet0/0
R6(config-router-af-interface)#bfd
%EIGRP: BFD interval is not configured on interface GigabitEthernet0/0 required for BFD operation.
R6(config-router-af-interface)#
In EIGRP classic mode, EIGRP can be configured to receive BFD notifications on link failure on a single interface as below:
R6(config)#router eigrp 2
R6(config-router)#bfd interface gigabitethernet 0/0
In EIGRP classic mode, EIGRP can be configured to receive BFD notifications on all EIGRP-enabled interfaces as below:
R6(config)#router eigrp 2
R6(config-router)#bfd all-interfaces
NOTE: Configuration of EIGRP to receive notifications from all EIGRP enabled interfaces as demonstrated above does not issue a log message if BFD has not been enabled on the interface using the interface-mode BFD configuration commands.
BFD in OSPF
BFD is configured in OSPF for all interfaces with the router ospf mode command bfd all-interfaces.
The command does not provide the additional flexibility of EIGRP of installing
on select interfaces or all interfaces at once.
To enable BFD on an interface, issue the following interface
configuration command: ip ospf bfd
Under an interface, to disable BFD for a specific interface in interface mode issue the command:
ip ospf bfd disable.
BFD in Static Routing
BFD is able to detect failures in the forwarding path of static routes. To configure BFD in static routing:
R6(config)#interface g1/0
R2(config-if)#bfd interval 250 min_rx 150 multiplier 3
R2(config-if)#exit
R6(config)#ip route static bfd gigabitethernet1/0 10.0.26.1
Verification
BFD operation can be verified using the command show bfd neighbors (detail)
BFD Troubleshooting
Troubleshooting of BFD may be required when BFD is not functioning effectively:
- BFD session down: Verify BFD configuration on both routers.
- BFD session is flapping: check if uRPF has been configured on the interface.
The following commands are important in troubleshooting BFD:
| Command | Description |
show bfd neighbor detail |
Displays the BFD adjacency database. The details keyword shows all BFD protocol parameters and timers per neighbor. |
debug bfd event |
Displays debugging information about BFD control packets or events such as BFD state transitions. |
Recommendations on Deployment of BFD
- The use of BFD echo function is encouraged.
- BFD may not be necessary if devices are directly connected on point to point link without any other device such as a switch in-between. BFD is ideal if two routers are connected to each other with a switch interconnecting the two devices.
- Remember to configure the slower timer command, when you enable BFD echo function.
No comments:
Post a Comment