Volume VII, No. 9, September 2006
Detection Protocol Speeds Router Convergence and Improves Network Availability
All network operators want their networks to be available for as much of the time as possible. One aspect of achieving this objective is to install mechanisms for quickly detecting failures between routing peers.
Traditional link-layer detection mechanisms miss some outages, such as those in the control plane. They also do not happen in a consistent amount of time across different media types. In fact, most failure detection mechanisms take far too long to accommodate time-sensitive applications.
To help network operators quickly detect failures in a consistent time frame and accelerate routing convergence and network uptime, an Internet Engineering Task Force (IETF) Internet-Draft has defined a protocol called Bidirectional Forwarding Detection (BFD). The protocol can be used between routing peers independent of the underlying media and Layer 3 data and routing protocols, determining whether a connection between two routing peers is live in subsecond time frames. Cisco IOS Software supports BFD and an extension to it, called BFD Echo Function, to perform fast failure detection and recovery if there is an alternate path available.
Technology Background
Traditionally, networks use relatively slow "Hello" mechanisms in routing protocols to detect failures. The time to detect failures available in routing protocols is no better than a second. This is far too long for some applications and represents a great deal of lost data at gigabit rates.
To correct this issue, the BFD protocol detect faults in the bidirectional path between two forwarding engines—including physical interfaces, subinterfaces, and data link(s)—with very low latency. As noted, it operates
independently of media, data protocols, and routing protocols; BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network.
Protocol Design and Operation
BFD is designed to detect failures in communication with a forwarding plane next hop. BFD operates on top of any data protocol being forwarded between two systems. It is always run in a unicast, point-to-point mode. Multiple BFD sessions can be established between the same pair of systems when multiple paths are present in at least one direction, even if fewer paths are available in the other direction.
A pair of systems transmits BFD packets periodically over each path between the two systems, and if a system stops receiving BFD packets for long enough, some component in the bidirectional path to the neighboring system is assumed to have failed. Each peer system estimates how quickly it can send and receive BFD packets in order to come to an agreement with its neighbor about how rapidly detection of failure will take place Figure. These estimates can be modified in real time in order to adapt to unusual situations. This design also allows for fast systems on a shared medium with a slow system to be able to more rapidly detect failures between the fast systems while allowing the slow system to participate to the best of its ability.
Multiple Modes
BFD has two operating modes: asynchronous mode and demand mode. In asynchronous mode, the systems periodically exchange BFD control packets, and if a number of those packets in a row are not received by the other system, the session is presumed down. Demand mode, by contrast, assumes that each system has an independent way of verifying connectivity to the other system. Once a BFD session is established, the systems stop sending BFD control packets, except when either system feels the need to verify connectivity explicitly. In such cases, a short sequence of BFD control packets is sent.
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 presumed down. Since the echo function is handling the task of detection, the rate of periodic transmission of BFD control packets may be reduced in the case of asynchronous mode or eliminated completely in the case of demand mode.
Pure asynchronous mode is advantageous in that it requires half as many packets to achieve a particular detection time as the echo function. The echo function, though, has the advantage of truly testing only the forwarding path on the remote system. This may reduce round-trip jitter and thus allow more aggressive detection times, as well as potentially detect some classes of failure that might not otherwise be detected.
Demand mode is useful in situations where the overhead of a periodic protocol might prove onerous, such as a system with a very large number of BFD sessions. It is also useful when the echo function is being used symmetrically. Demand mode has the disadvantage that detection times are essentially driven by the heuristics of the system implementation and are not known to the BFD protocol. Demand mode also may not be used when the path round trip time is greater than the desired detection time.
Configuration Considerations
Bidirectional Forwarding Detection was first supported in Cisco IOS Software Releases 12.2(18)SXE and 12.4(4)T. The echo function was first supported in Cisco IOS Release 12.4(9)T. The implementation works consistently across Ethernet, Fast Ethernet, and Gigabit Ethernet networks.
Summary
Detecting and correcting failures quickly between peer routers in a consistent manner is critical to operating a network carrying low-latency traffic that runs at predictable performance levels. Many of the failure-detection mechanisms in today’s data and routing protocols are too slow to accommodate time-sensitive networks. They also must be implemented differently—and perform differently— across different underlying network media types.
Cisco IOS BFD with echo function addresses these requirements by accelerating detection and re-routing time using a media-independent protocol that detects failures in subsecond response time.
;){kind=link}