Skip to main content
yzayani
Staff
Staff
March 25, 2026

Technical Tip: Unexpected 3–4 second outage during HA failover when using BGP with BFD in multi‑DC FortiGate clusters

Description

This article describes why a short outage (approximately 3–4 seconds) occurs during HA failover in FortiGate clusters that use BGP with BFD enabled. The issue is commonly observed in multi‑datacenter Active‑Passive or Active‑Active clusters where BGP peers are upstream carrier routers. Even when BGP Graceful Restart is configured, traffic interruption may still occur due to BFD behavior during the HA transition.

Scope

FortiOS

Solution

Observed behavior:

  • A 4‑node FortiGate cluster is deployed across two datacenters (2 nodes in DC1, 2 nodes in DC2).  
  • A VDOM acts as the BGP peer for two redundant uplinks (one in each DC).  
  • BGP neighbors are configured with: bfd enable, link-down-failover enable, aggressive timers (keepalive 1s, holdtime 3s).
  • During an HA failover triggered by 'diagnose sys ha reset-uptime', Internet traffic drops for 3.5 seconds.  
  • BGP Graceful Restart is configured but does not prevent the outage.  
  • BGP sessions re‑establish cleanly after failover, but upstream routers stop forwarding traffic during the 3.5‑second window.

 

Cause:

 

The outage is caused by BFD expiring before the new primary FortiGate becomes operational, which prevents BGP Graceful Restart from functioning.

 

Sequence of events during failover:

 

  1. The old primary stops forwarding traffic and shuts down its control plane.  
  2. The new primary takes over, which typically requires 1–2 seconds before routing processes resume.  
  3. During this 1–2 second gap, BFD packets stop being sent to the upstream routers.  
  4. With BFD configured at ~1 second detection (999ms × multiplier 3), the upstream router’s BFD timer expires after ~3 seconds.  
  5. The upstream router immediately tears down the BGP session, ignoring the BGP holdtimer and bypassing Graceful Restart.  
  6. Because the BGP session is hard‑reset, the upstream router withdraws the user prefixes and stops forwarding traffic.  
  7. Traffic resumes only after the new primary re‑establishes BFD and BGP, resulting in a 3–4 second outage.
  • Graceful Restart only functions when BGP itself signals a planned restart.  
  • BFD bypasses this mechanism entirely:
  1. BFD expiration = immediate session teardown.
  2. No GR notification is sent.
  3. Upstream router removes routes immediately.
  4. Traffic drops until the session is rebuilt.

 

Resolution:

 

  •  Remove BFD from BGP neighbors:

Removing BFD allows the upstream router to rely on the 3‑second BGP holdtimer, giving the new primary enough time to re‑establish the session before the holdtimer expires.

 

config router bgp

    config neighbor

        edit "216.244.171.124"

            unset bfd

        next

        edit "216.244.171.192"

            unset bfd

        next

              (Repeat for IPv6 neighbors.)

    end

end

 

 

Expected result:  

Failover downtime decreases from ~3.5 seconds to <1 second, because:

  1. The upstream router does not tear down the session.
  2. Graceful Restart remains active.
  3. The new primary sends keepalives before the holdtimer expires.
  4. Traffic continues uninterrupted.
  • Tune BFD/BGP timers (if BFD must remain enabled): Increasing BFD intervals and multipliers reduces the chance of expiration during HA failover.

    Thought Leadership. Security Summit. Thursday, November 12th, PGA National Resort, Palm Beach Gardens, FL.
    Thought Leadership. Security Summit. Thursday, October 8th. Disney's Grand Californian Hotel & SPA, Anaheim, CA.
    Security Operations Summit: Modernize SecOps. Operate AI-Native.AMER: November 4 | 9:00 AM PST. India and SAARC: November 5 | 10:00 AM IST. EMEA: November 5 | 10:30 AM CET. APAC: November 5 | 11:00 AM SGT