BFD – Bidirectional Forwarding Detection

BFD is a network protocol for detecting faults between two routers or switches that are linked together by a connection. It detects errors with minimum overhead even on physical media that don’t enable any form of failure detection, such as Ethernet, virtual circuits, tunnels, and MPLS Label Switched Paths.

• BFD is a mechanism for validating the forwarding plane operation between two routers.
• When a failure is detected, it initiates a routing protocol action (severing a session or adjacency).
• Has two modes of operation:
• Asynchronous.
• Demand
• In either mode, BFD has an Echo feature that allows one side to request that the other loop back a sequence of packets.

• BFD can quickly communicate forwarding plane faults to routing and signaling systems.
• Relying entirely on hellos, KEEPALIVEs, and other similar activities to validate forwarding behaviors can be risky.
• Most routing/signaling protocol implementations are not meant to operate with sub-second keepalive intervals.
• BFD is often implemented on the line card, not the route processor, thus it is unaffected by RP CPU utilization.





• Static routes
• BGP (eBGP, iBGP)

• Only next-hop reachability information is used to verify whether static routes are legitimate.
• BFD is a good option for validating the forwarding path and detecting liveliness for the actual next-hop.

• The IGP has some procedures in place to quickly identify a failure (even at sub-second intervals).
• These capabilities (also known as “quick hellos”) are only functional if the IGP keepalive procedures are verified.
• In a distributed system, IGP protocols are typically punted to the route-processor, avoiding regular packet forwarding. • Because IGPs are typically executed on the route-processor, significant CPU utilization can cause IGP adjacencies to fail.
• In the event of a forwarding path failure, BFD can assist by disconnecting an IGP adjacency.

• BGP has its own keepalive mechanism, similar to IGPs.
• If BGP does not get a KEEPALIVE message from its neighbor before the hold duration expires, it tears down the session.
• Because BGP, like IGP, is typically implemented on route-processors, high RP CPU utilization can likewise cause BGP failure.
• After a forwarding path failure, BFD can shut off the BGP session in less than a second.

• To check the forwarding path, BFD can be activated on an iBGP session between router loopbacks.
• Can be used instead of relying on the IGP to warn you when a router goes down.
• There’s no need to rely on event-driven or periodic nexthop scanning any longer.
• Enhances iBGP convergence by recognizing BGP neighbor failure quickly.

• BGP timings aren’t ideal for detecting failures quickly.
• In instances when you and your neighbor have an L2 device in the center, BFD is ideal. (such as LANs for Internet Exchange or MPLS transport)
• There is no reliable link state notice for transportation between neighbors. (wavelengths)
• Minimum detection thresholds can be provided in ranges using BFD.
• Due to their own constraints or preferences, neighbors may use different timers.
• Timers are discussed on a regular basis and can be changed at any time.

• A pseudowires VCCV (Virtual Circuit Connectivity Verification) control channel can be used with BFD.
• This provides a quick way to discover problems between a pseudowire’s endpoints.
• The fault information might then be transformed into native OAM capabilities for other protocols (ATM, FR, Ethernet).

There are two primary ones:
1. Depending on your scale, BFD might have substantial resource demands.
2. Layer 2 bundling protocols do not see BFD. (POS bundles or Ethernet LAGs)

• How well BFD scales for you depends on the number of BFD sessions on each linecard or router.
• Each platform has its own set of limitations.
• Interface bundles with a minimum tx/rx of 250ms or 2 seconds have been seen.
• Depending on the implementation, BFD instances on a router may need to be run on the route-processor in some scenarios (non-adjacency based BFD sessions).
• Before deploying BFD, test your platform. With your configured parameters, try to place a load on the RP or LC CPU. This can be accomplished by:
• Running CPU-intensive commands
• Flooding packets until the destination’s TTL expires
• What values are safe to experiment with?
• After consulting with multiple operators, it appears that 300ms with a multiplier of 3 (900ms detection) is a safe value that works well on most equipment.
• This is a huge step forward from some of the alternatives.

• BFD is unaware of the members of the underlying L2 link bundle.
• A single L3 adjacency would appear as a 4x10GigE L2 bundle (802.3ad). Instead of using all four links, BFD packets would be sent via a single member link.
• If the BFD-enabled connection fails, the entire L3 adjacency will fail as well.
• However, in some cases, a failed member link may only result in the loss of a single BFD packet. Following packets may be routed over active member links.
• Because it’s often desirable to generate L2 bundles rather than use L3 ECMP to avoid platform-specific scalability concerns and contaminating your IGP, this can be a show-stopper.
• It would be fantastic if BFD could “fork” across each individual link, but this would have its own scale implications. A unique BFD session would be required for each individual member link. This method of operation is not currently supported by any vendor, and there is no public draft detailing it.

• Routers still have flaws in the forwarding plane, although IGP and other control-plane protocols are still operational.
• These occurrences actually occur, and they result in massive outages (as you may have seen in the headlines in 2008…)
• Some protocols’ default hello/keepalive intervals (BGP, IGP, RSVP) are still too long to be effective for failure detection.
• As networks grow in size, there must be a means to handle L2 link bundling (we don’t yet have 100GE, but scaling Nx10G and Nx40G will be critical).
• Always stress-test your setups to ensure that both you and your equipment are happy with what you’ve chosen.