Bidirectional Forwarding Detection

Bidirectional Forwarding Detection (BFD) is a standardized failure-detection protocol used between network devices. Its purpose is to detect loss of forwarding connectivity quickly, including failures that leave a physical interface operational. BFD does not advertise prefixes, calculate routes, or select a backup connection. Instead, it reports session failure to a client such as Border Gateway Protocol (BGP), which can then invalidate the affected adjacency and its routes.

In asynchronous mode, the peers periodically exchange BFD control packets. Each peer advertises timing parameters and a detection multiplier, and the resulting detection time depends on the negotiated packet interval and the multiplier advertised by the remote peer. If expected packets stop arriving for the detection interval, the receiving peer declares the session down. The peers can use different detection times in each direction. BFD supports both single-hop and multihop applications, but a cloud service may support only a particular mode or topology.

This matters in hybrid networking because a forwarding failure does not always cause an immediate physical link-down event. For example, a router interface can remain up while an intermediate provider device stops forwarding packets. Without BFD, a BGP session may remain established until its hold timer expires. When BFD is associated with that BGP neighbor, the failure can be reported sooner, allowing BGP to remove the unusable routes and select an available alternative.

For AWS Direct Connect, asynchronous BFD is supported on virtual interfaces, and AWS enables it on its side. The customer must configure compatible BFD settings on the customer router and associate BFD with the relevant BGP neighbor. The AWS-supported minimum interval is 300 milliseconds with a detection multiplier of three, giving an approximately 900-millisecond detection interval at those settings. This is failure-detection time, not a guarantee that application traffic will recover within 900 milliseconds.

Consider two Direct Connect connections that advertise the same on-premises prefixes. If the preferred path stops forwarding but remains physically up, BFD can cause its BGP session to fail sooner than the BGP hold timer would. Traffic can then use the surviving route, provided routing policy, prefix advertisements, return-path routing, and available capacity permit it. BFD cannot create redundancy where none exists, and faster detection alone does not guarantee uninterrupted sessions.

Do not assume BFD is supported on every connection that uses BGP. AWS Site-to-Site VPN does not support BFD on its managed VPN endpoints. Its tunnel and routing failure handling instead involves mechanisms such as IPsec dead peer detection and BGP timers. Dead peer detection checks IPsec peer liveness; it is not another name for BFD. A customer-managed routing overlay may offer its own BFD capability, but that is separate from native support on the managed VPN endpoint.

Aggressive timers trade faster detection for greater sensitivity to packet loss, scheduling delays, and congestion. Excessively short intervals can produce false failures and route flapping, particularly on software routers with constrained CPU resources. Permit the required BFD traffic through relevant filters, use settings supported by both peers, and monitor session transitions alongside interface errors and BGP events. Single-hop BFD control traffic normally uses UDP destination port 3784; other BFD modes use different ports.

For troubleshooting and exam scenarios, distinguish failure detection from routing convergence and application recovery. BFD detects loss of connectivity along the path its packets exercise; it does not prove that every application flow, packet size, or downstream destination is reachable. Validate the complete design with controlled failure tests that measure detection, route withdrawal, alternate-path installation, and actual traffic restoration.