8.3 Implementing High Availability in Networking
Bidirectional Forwarding Detection Support
The detection of failures is typically accomplished via hardware detection mechanisms. However, the signals from these mechanisms are not always conveyed directly to the upper protocol layers, such as routing protocols. When the hardware mechanisms do not exist (for example, Ethernet) or when the signaling does not reach the upper protocol layers, the protocols must rely on their much slower strategies to detect failures. The detection times in existing protocols are typically equal to or greater than one second, and sometimes much longer. For some applications, this is too long to be useful.
Drivers for Bidirectional Forwarding Detection:
Data link layer detection can miss some types of outages
Control Plane failure
Control Plane failure detection is slow
Order of tens of seconds
Data link layer failure detection is not consistent across media types
Very quick to quick for some media (SONET, Ethernet)
Slow on other WAN links
Provides failure detection consistency across routing protocols
Built in routing failure detection mechanisms are not fast enough for SP world
Packet over SONET (POS) tends to have the best failure detection time among the different media choices. It can typically detect and react to media or protocol failures in ~50 milliseconds. This has become the benchmark against which other protocols are measured.
Bidirectional Forwarding Detection
Bidirectional Forwarding Detection (BFD) provides low-overhead, short-duration detection of failures in the path between adjacent forwarding engines. BFD allows a single mechanism to be used for failure detection over any media and at any protocol layer, with a wide range of detection times and overhead. The fast detection of failures provides immediate reaction to failure in the event of a failed link or neighbor.
A secondary benefit of BFD, in addition to fast failure detection, is that it provides network administrators with a consistent method of detecting failures. Thus, one availability methodology could be used, irrespective of the Interior Gateway Protocol (IGP) or the topology of the target network. This eases network profiling and planning, because re-convergence time should be consistent and predictable. BFD function is defined in RFC 5880. It is UDP-based and is being put into all of the hardware (e.g. Cisco CRS, Cisco Nexus 9000, and Cisco NCS 6000). It actually resides in the port ASIC.
The Fundamental difference between the BFD Hellos and the Protocol Hellos (OSPF, RSVP and so on) is that BFD adjacencies do not go down on Control-Plane restarts (e.g. RSP failover) since the goal of BFD is to detect only the forwarding plane failures.
BFD has two operating modes that may be selected and an extra function that can be used with the two modes. The primary mode is known as Asynchronous mode. In this mode, the systems periodically send BFD Control packets to one another, and if a number of those packets in a row are not received by the other system, the session is declared to be down.
The second mode is known as Demand mode. In this mode, it is assumed that a system has an independent way of verifying that it has connectivity to the other system. Once a BFD session is established, such a system may ask the other system to stop sending BFD Control packets, except when the system feels the need to verify connectivity explicitly, in which case a short sequence of BFD Control packets is exchanged, and then the far system quiesces. Demand mode may operate independently in each direction, or simultaneously.
An adjunct to both modes is the Echo function. When the Echo function is active, a stream of BFD Echo packets is transmitted in such a way as to have the other system loop them back through its forwarding path. If a number of packets of the echoed data stream are not received, the session is declared to be down. The Echo function may be used with either Asynchronous or Demand mode. Since the Echo function is handling the task of detection, the rate of periodic transmission of Control packets may be reduced (in the case of Asynchronous mode) or eliminated completely (in the case of Demand mode).
Cisco IOS XR software only supports asynchronous mode and has echo enabled by default.
Asynchronous mode without echo will engage various pieces of packet switching paths on local and remote systems. However, asynchronous mode with echo is usually known to provide slightly wider test coverage as echo packets are self-destined packets which traverse same packet switching paths as normal traffic on the remote system.
Cisco IOS XR software supports the asynchronous mode of operation only (i.e. no Demand mode), with or without using echo packets (echo is enabled by default).
When BFD is running asynchronously without echo packets, the following occurs:
Each system periodically sends BFD control packets to one another. Packets sent by BFD router "Peer A" to BFD router "Peer B" have a source address from Peer A and a destination address for Peer B.
Control packet streams are independent of each other and do not work in a request/response model.
If a number of packets in a row are not received by the other system, the session is declared down.
When BFD is running asynchronously with echo packets, the following occurs:
BFD echo packets are looped back through th e forwarding path only of the BFD peer and are not processed by any protocol stack. So, packets sent by BFD router "Peer A" can be sent with both the source and destination address of Peer A.
BFD echo packets are sent in addition to BFD control packets.
In IOS-XR an application must terminate the BDF session. Unlike IOS, direct peering without any application using the session is not allowed.
Adding bfd fast-detect suffix to the normal static route will enable BFD feature. To fine tune BFD behavior, use minimum-interval and multiplier optional parameters inside same command.
BFD on a Static Routes (simplest application):
address-family ipv4 unicast
172.16.1.1/32 10.1.1.1 bfd fast-detect minimum-interval 5000 multiplier 3
ipv4 address 10.1.1.2 255.255.255.0
Provided examples for OSPF and IS-IS routing protocols demonstrate that same BFD commands are used for all protocols.
BFD with IGP Peers (OSPF example):
router ospf 1
bfd minimum-interval 100
bfd multiplier 3
bfd fast-detect ipv4
BFD with IGP Peers (ISIS example):
router isis lab
address-family ipv4 unicast
bfd minimum-interval 500
bfd multiplier 3
bfd fast-detect ipv4
The show bfd session command allows review of configuration details and in addition provides current state for all sessions between the router and neighbors.
The show bfd counters packet provides info for received and transmitted Control and Echo BFD packets (if enabled).
RP/0/RSP0/CPU0:ASR9K-1# show bfd session
Interface Dest Addr Local det time(int*mult) State
--------------- --------------- ---------------- ---------------- ----------
Gi0/2/0/1 10.0.9.1 1500ms(500ms*3) 6s(2s*3) UP
RP/0/RSP0/CPU0:WEST-PE-ASR9K-1# show bfd counters packet
GigabitEthernet0/2/0/1 Recv Xmit Recv Xmit
Async: 44048 44182 Echo: 175384 175384