AWS Transit Gateway Connect uses a default BGP keepalive interval of 10 seconds and a hold timer of 30 seconds. If a local router is configured with timers 15 45, the session does not simply copy the full AWS timer pair. BGP uses the lower proposed hold time, so the operational hold timer should be 30 seconds. That behavior explains why a silent path failure can take about 30 seconds to converge while recovery of the preferred path can complete in only 1 to 2 seconds.
The short answer
Your router does not use the complete AWS timer pair simply because the AWS values are lower. The BGP OPEN message carries a proposed hold time. Each peer uses the lower proposed value:
local hold time: 45 seconds AWS hold time: 30 seconds negotiated hold time = min(45, 30) negotiated hold time = 30 seconds
The keepalive interval is different. BGP does not negotiate 15 45 against 10 30 as one inseparable pair. Each peer generates its own keepalives according to its implementation and the operational hold time.
The operational result should be a 30 second hold timer. The router configuration can still display timers 15 45. Verify the live BGP neighbor state to determine the keepalive interval that the platform is actually using.
How the configured values interact
45 second proposed hold time
30 second proposed hold time
| Parameter | BGP behavior | Expected result |
|---|---|---|
| Hold time | The lower proposed value is used by both peers | 30 seconds |
| Keepalive | Generated locally and not negotiated as a timer pair | Verify the operational neighbor output |
| Local configuration | Remains configured as entered | timers 15 45 can remain visible in the configuration |
A 30 second hold timer is measured from the last valid BGP KEEPALIVE or UPDATE message. The failure can therefore be detected in somewhat less than 30 seconds depending on where the fault occurs within the keepalive cycle.
Why failover is slower
The original explanation correctly identifies route withdrawal, best path calculation, RIB programming, FIB programming, and route propagation as parts of convergence. Those operations can add delay. They probably do not account for most of an observed outage that consistently lands near 30 seconds.
The more direct explanation is:
Did the failed TGW Connect BGP peer send an immediate TCP reset, BGP NOTIFICATION, or withdrawal? If not, the surviving peer can continue treating the session as established until the negotiated hold timer expires.
traffic recovers →
Route withdrawal and forwarding table programming occur after the session is declared unusable. They can add time, but a repeatable result near 30 seconds strongly points to the negotiated BGP hold timer as the primary delay.
Why failback is faster
Failback does not need to detect a dead peer. The primary path returns, the BGP session is established again, and the preferred route is advertised. Assuming the routing policy still favors that path, the route wins the BGP best path decision and is installed.
A recovery time of 1 to 2 seconds is plausible in a controlled test. It is not a universal guarantee because BGP connection establishment, routing policy, platform load, and the exact failure mode can affect the result.
The BFD nuance
AWS documents that BFD is not supported on the Transit Gateway Connect BGP overlay. BFD may still protect an underlying Direct Connect VIF, but rapid detection on the underlay does not automatically close the BGP session running across the GRE overlay.
AWS provides an example for a pinned TGW Connect tunnel with approximately 0.9 seconds of minimum Direct Connect BFD detection plus 30 seconds for the TGW Connect overlay, producing approximately 30.9 seconds in total. That example is consistent with a measured outage near 30 seconds.
Should the router be changed to timers 10 30?
Matching the AWS values is reasonable because it makes the intended settings explicit and reduces ambiguity during operations and troubleshooting.
router bgp <local_asn> neighbor <aws_bgp_peer> timers 10 30
Changing the local configuration from 15 45 to 10 30 may not materially improve the maximum failover time in this scenario. The existing session should already use a 30 second operational hold timer because AWS proposes the lower value.
Lower timers are not automatically safer. More aggressive control plane timers can increase sensitivity to packet loss, congestion, transient underlay events, and router CPU pressure. Validate the change against the platform and AWS design requirements.
How to verify the operational timers
Use the live neighbor state rather than relying only on the configuration. On Cisco IOS or IOS XE, start with:
show ip bgp neighbors <aws_bgp_peer> show ip bgp neighbors <aws_bgp_peer> | include hold time|keepalive show logging | include BGP|ADJCHANGE
Confirm the following:
- The operational hold time is 30 seconds.
- The keepalive interval shown by the router.
- The last BGP reset reason.
- The timestamp of the underlay failure.
- The timestamp when the overlay BGP adjacency goes down.
- The timestamp when the backup route enters the RIB and FIB.
- The timestamp when application traffic recovers.
Precise wording for the test report
Failover took approximately 30 seconds because the Transit Gateway Connect BGP session remained established until the negotiated hold timer of 30 seconds expired. BFD can accelerate failure detection on an underlying Direct Connect VIF, but BFD is not supported on the TGW Connect overlay itself. Once the hold timer expired, routes learned over the primary path were invalidated, the backup route was selected, and the RIB, FIB, and related BGP advertisements were updated.
Failback was faster because recovery does not require a hold timer to expire. Once connectivity and the BGP session were restored, the preferred primary route was advertised again, selected by BGP policy, and installed in the forwarding table.
The conclusion
The measured behavior is consistent with normal BGP timer processing on a TGW Connect overlay. The lower AWS hold time of 30 seconds becomes the operational hold time. A silent failure may therefore remain undetected by the overlay until that timer expires. Failback can complete much faster because the router is processing a restored and preferred route rather than waiting to declare a failed session dead.
Local configuration: timers 15 45 AWS documented defaults: timers 10 30 Operational hold time: 30 seconds Observed failover: about 30 seconds Observed failback: about 1 to 2 seconds The hold timer explains most of the failover interval. Positive route restoration explains the faster failback.
References
- AWS Transit Gateway documentation: Connect attachments and Connect peers
- AWS Networking and Content Delivery Blog: Best Practices to Optimize Failover Times for Overlay Tunnels on AWS Direct Connect
- IETF RFC 4271: A Border Gateway Protocol 4
- AWS re:Post Knowledge Center: Configure a Transit Gateway Connect attachment and BGP peering
// a 30 second hold timer can dominate silent failure detection. route restoration does not have the same wait.