Troubleshooting Tip: FGSP cluster sandwiched between two cloud routers: achieving full ECMP load sharing across all members

Observed behavior (before the fix):

• ECMP hashed traffic to only 1 FortiGate consistently.
• New TCP sessions were unknown to the other members for the first ~30 seconds (visible in flow traces).
• Asymmetric return traffic during that window hit a member that had no session yet → drops or incorrect handling.

Fix: The root cause is that the session-pickup-delay is enabled. Disable the delay on all four cluster members:

Topology:

FGSP active-active cluster sandwiched between two cloud routers

Non-working scenario (with session-pickup-delay enabled).

1. New connection arrives → hashed to FortiGate #1.
2. FortiGate #1 creates the session but waits 30 seconds before syncing to the cluster.
3. Reply traffic returns → hashed to FortiGate #3 (normal ECMP).
4. FortiGate #3 has no session yet → packet is dropped or handled incorrectly until the 30-second sync arrives.
   
   

Working scenario (after session-pickup-delay disable).

1. New connection arrives → hashed to FortiGate #1.
2. FortiGate #1 creates the session and syncs it immediately (first packet) to all other members.
3. Reply traffic returns → hashed to FortiGate #3 (still normal ECMP).
4. FortiGate #3 already knows the session → forwards correctly, no blind window.

After this change, asymmetric paths no longer cause drops, even if load distribution remains uneven due to ECMP hashing.

Note:

The session-pickup-delay option exists to reduce sync overhead for short-lived sessions. When enabled, the FortiGate that receives the first packet waits 30 seconds before syncing the TCP session. Short sessions that expire before 30 seconds are never synced.

Related documents:

• FGSP session synchronization options 7.6.5
• Improving session sync performance
• FGSP
• Technical Tip: Suggested Parameters for an FGSP cluster