BFD negotiates to the slower peer, so your failover is as fast as their config

Without Bidirectional Forwarding Detection, a BGP session over Direct Connect or a VPN detects a dead path when the hold timer expires. AWS's default hold timer is 90 seconds, with a keepalive of 30. That is ninety seconds of traffic going into a path that no longer works.

BFD reduces that to under a second, and it is why anyone configures it. The part worth understanding before you promise a number to anyone is that the number is negotiated.

The mechanics#

AWS supports a minimum BFD interval of 300 ms with a minimum multiplier of 3, giving detection at roughly 900 ms. Per the Direct Connect BGP settings documentation, BFD is enabled on the AWS side by default but only becomes active once you configure it on your router.

The negotiation is the important bit. Each side advertises its desired transmit interval and its minimum receive interval, and the operating interval settles on the slower of the two. It can also be asymmetric — the two directions do not have to run at the same rate.

So a 300 ms interval configured on your router does not give you 900 ms detection. It gives you 900 ms detection if the other end agreed to something at least that fast. Set 300 ms against a peer asking for 1000 ms and you get 1000 ms, in that direction, with no error and nothing in your own configuration to indicate it.

Two consequences#

Your failover target is a joint property. If you have an SLO that depends on detection time, it depends on a device someone else configures. That needs to be in the runbook and ideally in the contract with whoever operates the far end. Verify the operating interval on the session rather than reading your own configuration back.

Asymmetry means one direction can fail slowly. Traffic leaving you might be redirected in under a second while traffic coming toward you keeps arriving on the dead path for longer, or the reverse. Which produces a window of unidirectional blackholing, and unidirectional blackholing is the hardest kind of failure to interpret from either end — one side sees traffic flowing and the other sees nothing.

Do not combine BFD with graceful restart#

AWS recommends not enabling BGP graceful restart and BFD at the same time, and the reason is that the two features want opposite things.

BFD's purpose is to tear the session down fast when the path is gone. Graceful restart's purpose is to keep forwarding across a control-plane restart on the assumption the path is still fine. Run both and you get a fast detection feeding a mechanism designed to ignore it, which can extend convergence rather than shortening it — exactly the opposite of why you turned BFD on.

Pick one based on what you are protecting against. BFD protects against path failure. Graceful restart protects against a peer's routing process restarting while the path stays up. If you genuinely need both, that is a conversation with AWS support rather than a configuration change.

The other constraint on Direct Connect#

BGP over Direct Connect uses TTL 1 and does not support multihop. So the BGP session has to terminate on the device the cross-connect lands on. You cannot terminate BGP on a router two hops inside your network with a layer 2 path to the Direct Connect location.

This surprises people designing a centralised routing tier, and it is a hard constraint rather than a tuning parameter. The same applies to BFD, which rides the same single-hop relationship.

What to check#

Read the operating state, not your configuration:

# On your router, the exact command varies by vendor
show bfd neighbors detail

The fields to compare are your configured transmit interval against the negotiated one in each direction. A negotiated value slower than what you configured means the peer is the constraint.

On the AWS side, confirm BFD is actually up rather than merely enabled:

aws directconnect describe-virtual-interfaces \
  --query 'virtualInterfaces[].[virtualInterfaceId,virtualInterfaceState,bgpPeers[].bgpStatus]' \
  --output json

Detection time is one term in the equation#

Worth keeping in proportion. Total time to recover is detection plus propagation plus convergence, and shaving detection from 90 seconds to 900 ms only helps if the rest is comparable.

If your backup path is a VPN that needs to bring up an IPsec tunnel, tunnel establishment dominates and sub-second detection buys you very little. If the backup path is already up and carrying a less-preferred route, detection genuinely is the dominant term and BFD is the highest-value change you can make.

So the sequence is: make sure the backup path is already established and advertising, then optimise detection. In the other order you are tuning the fast part of a slow process.

The hybrid connectivity guide works through the full timeline with the numbers, including where the time actually goes on each kind of backup path. For the routing side of hybrid failures — priority, propagation, and asymmetry — the VPN route propagation lab is a working example of a path that is up and not carrying traffic.