BFD

What Is BFD?

Bidirectional Forwarding Detection (BFD) is a rapid fault detection mechanism that operates according to RFC 5880. Once a BFD session is established between two systems, BFD packets are regularly transmitted along the path connecting the systems. If one system fails to receive BFD packets within a predetermined interval, it indicates a fault on the path. By utilizing BFD to detect link faults, upper-layer protocols can swiftly respond and implement necessary actions to rectify the issue.

Why is BFD Needed?

To ensure network reliability and minimize the impact of device faults on services, it is crucial for a network device to swiftly identify communication faults with adjacent devices. This enables timely rectification measures for uninterrupted service continuity.

In practical scenarios, hardware detection mechanisms such as SDH alarms are employed to detect link faults. However, not all media supports such hardware detection mechanisms. In such cases, the Hello mechanism of upper-layer protocols is utilized for fault detection, which typically takes seconds. This extended detection period can result in significant packet loss, especially when transmitting traffic at gigabit rates. Additionally, on Layer 3 networks, the Hello mechanism may not effectively identify faults for all routes, such as static routes. This makes it challenging to pinpoint faults between interconnected systems accurately.

Bidirectional Forwarding Detection (BFD) addresses these challenges by providing rapid fault detection that is independent of media and routing protocols. BFD offers several advantages:

• It enables lightweight fault detection, taking only milliseconds, thus enhancing overall reliability.

• BFD swiftly detects various types of faults, including interface, data link, and forwarding engine faults.

• It ensures uniform and real-time fault detection for all media and protocol layers, eliminating the reliance on hardware-specific mechanisms.

Typical Application Scenarios of BFD

BFD is commonly utilized in conjunction with interface status or routing protocols, such as static routing, OSPF, IS-IS, and BGP. Presented below are two typical application scenarios of BFD.

Association Between BFD Session Status and Interface Status

In the context of BFD for process interface status (PIS), the BFD session status is linked to the interface status. This association enhances the sensitivity of interfaces towards link faults and reduces the impact of faults on indirectly connected links. When a link fault is detected, the corresponding BFD session promptly sends a Down message to the associated interface. Consequently, the interface enters the BFD Down state and exclusively processes BFD packets.

Consider the scenario depicted in the diagram, where SwitchA and SwitchB are directly connected at Layer 3, with transit devices deployed between them. In the event of a fault on the link between the transit devices, SwitchA and SwitchB would experience delayed fault detection. This delay can impede route convergence and prolong service interruption. To mitigate this, a BFD session is configured on SwitchA and SwitchB, associating the BFD session status with the interface status. Upon detecting a link fault, the BFD session promptly sends a Down message to the corresponding interface, causing it to enter the BFD Down state.

BFD for OSPF

Link failures or topology changes can necessitate route recalculations, demanding minimized convergence times for routing protocols to optimize network performance. One effective solution is to swiftly detect link faults and promptly notify routing protocols of such faults.

BFD for OSPF establishes an association between a BFD session and OSPF. The BFD session rapidly detects link faults and informs OSPF of the fault, enabling OSPF to promptly respond to the network topology change. The diagram below illustrates the OSPF convergence time.

In the diagram, SwitchA establishes OSPF neighbor relationships with SwitchC and SwitchD. Interface 1 serves as the outbound interface in the route from SwitchA to SwitchB, with packets from SwitchA routed through SwitchC to reach SwitchB. When the OSPF neighbor reaches the Full state, the system configures BFD to create a corresponding BFD session.

In the event of a fault on the link between SwitchA and SwitchC, the BFD session detects the fault and notifies SwitchA. Subsequently, SwitchA processes the neighbor Down event, triggering route recalculation. Interface 2 then becomes the new outbound interface in the route, rerouting packets from SwitchA through SwitchD to reach SwitchB.

Operational Mechanism of BFD

BFD operates by establishing a session between two systems that periodically exchange BFD packets along the path connecting them. If a system fails to receive BFD packets from its peer within a specified timeframe, the BFD session transitions to the Down state, indicating a fault in the path between the systems.

The functioning of BFD can be understood from three perspectives: the fault detection mechanism, the session establishment process, and the session establishment modes.

BFD Fault Detection Mechanism

When two network devices establish a BFD session to monitor the path between them, BFD does not handle neighbor discovery directly. Instead, it relies on upper-layer applications to provide neighbor information. Once a BFD session is established, the devices periodically exchange BFD packets. If a device fails to receive a response within the configured time limit, it considers the forwarding path as faulty. BFD then notifies the upper-layer protocol about the detected fault.

The process can be summarized as follows:

1. A link failure occurs.

2. BFD quickly detects the fault and changes the session status to Down.

3. BFD notifies the local OSPF process about the unreachable neighbor.

4. The local OSPF process terminates the OSPF neighbor relationship.

BFD Session Setup

A BFD session can have different states: Down, Init, Up, and AdminDown. The State field in BFD packets indicates the session status. The session status changes based on the local session status and the session status received from the peer.

Here is a brief explanation of the session states:

• Down: The BFD session is in the Down state or a request has just been sent.

• Init: The local end can communicate with the remote end, and the local end expects the BFD session to transition to the Up state.

• Up: The BFD session is successfully established.

• AdminDown: The BFD session is administratively taken down.

To ensure both systems detect session status changes, the BFD state machine implements a three-way handshake for session setup or deletion.

BFD Session Establishment Modes

BFD sessions can be established in either static or dynamic mode, with differences in the configuration of local and remote discriminators. Local and remote discriminators in BFD packets are used to distinguish between different BFD sessions.

1. Static Establishment: BFD session parameters, including local and remote discriminators, are manually configured via the command-line interface (CLI). The request for BFD session establishment is manually initiated.

2. Dynamic Establishment: In dynamic mode, the system handles the local and remote discriminators as follows:

• Dynamically Allocated Local Discriminator: When an application triggers the establishment of a dynamic BFD session, the system sets the local discriminator for the session. The local system then sends a BFD packet to the remote system with a remote discriminator value of 0 to negotiate the BFD session.

• Self-Learned Remote Discriminator: When one end of a BFD session receives a BFD packet with a remote discriminator of 0, it checks the packet. If the packet matches the local BFD session, the receiving end learns the value of the local discriminator from the received BFD packet, thereby obtaining the remote discriminator.

One-Arm BFD Echo

In addition to its integration with various protocols, BFD offers a unique feature called one-arm BFD echo. This feature is employed to verify the connectivity of a forwarding link by utilizing packet looping. One-arm BFD echo is particularly useful in scenarios where one of the two directly connected devices doesn't support BFD.

To enable one-arm BFD echo, you need to configure it on the BFD-capable device. This device initiates an Echo Request packet to the remote device that lacks BFD support. Subsequently, the remote device returns the Echo Request packet along the same path. This process enables the BFD-capable device to assess the connectivity of the forwarding link. It's important to note that one-arm BFD echo is applicable only to single-hop BFD sessions.