Staff

Troubleshooting Tip: Troubleshooting intermittent traffic issues in FortiGate Session Life Support Protocol (FGSP)

Forum|Forum|6 months ago
February 3, 2026
0 replies
630 views

Description

This article describes common symptoms, root causes, and verification steps when encountering intermittent traffic issues in a FortiGate Session Life Support Protocol (FGSP) deployment, with UTM inspection enabled, such as traffic hairpinning, Layer-2 flapping, or unexpected session timeouts.

Scope

This article applies to FortiGate devices configured in FGSP, with UTM inspection enabled (both NAT and transparent modes) that run identical hardware/VM models and firmware versions.

Solution

This behavior is commonly observed in the FGSP setup, with UTM inspection is enabled. The following issues may be observed intermittently or consistently in an FGSP environment (in both NAT and Transparent modes):

Traffic hairpinning through the same interface on the same FortiGate.
Layer‑2 bouncing or flapping, even when L2 is explicitly set to unavailable or disabled.
Session timeouts when traffic traverses the FGSP peers.

These issues are commonly caused by heartbeat communication problems between FGSP peers. Contributing factors may also include:

Heartbeat packet delays between FGSP peers.
Interface errors or packet drops.
Physical cabling issues between peers.
Peer MAC address learning issues.

If heartbeat packets from FGT‑1 to FGT‑2 are delayed while FGT‑2 continues to send heartbeats, FGT‑2 may reach the configured hb-lost-threshold and incorrectly determine that FGT‑1 is down. As a result, FGSP devbase information for the peer may be removed, leading to inconsistent FGSP behavior.

Verify the session synchronization and heartbeat configuration as shown below:

config system session-sync

edit 1

set down-intfs-before-sess-sync <interfaces>

set hb-interval <integer> # Range: 1–10 seconds

set hb-lost-threshold <integer> # Range: 1–10

config system standalone-cluster
config cluster-peer
edit 1

set hb-interval 2
set hb-lost-threshold 10
next
edit 2

set hb-interval 2
set hb-lost-threshold 10
next

end
end

Ensure that the heartbeat interval and heartbeat loss threshold values are appropriate for the network latency and stability between FGSP peers.

Run the following command on both FGSP peers to check the standalone peer status:

diagnose system ha standalone-peers

Both FortiGates should display Kernel standalone dev_base entries for all standalone member ID values. This confirms that each peer has correctly learned and retained devbase information for the other peer.

Example output (FGT-1):

Group=3, ID=6
Detected-peers=1
Peer ready bitmap=0000d0000000000
Kernel standalone-peers: num=3.
peer0: vfid=0, peerip:port = 10.1.1.8:708, standalone_id=0, ready=1, src_addr = 0.0.0.0
        session-type: send=4, recv=21
         packet-type: send=0, recv=0
peer1: vfid=0, peerip:port = 10.1.1.2:708, standalone_id=2, ready=1, src_addr = 0.0.0.0
        session-type: send=4, recv=36
         packet-type: send=0, recv=0
peer2: vfid=0, peerip:port = 10.1.1.3:708, standalone_id=3, ready=1, src_addr = 0.0.0.0
        session-type: send=4, recv=232
         packet-type: send=0, recv=0
Kernel standalone dev_base:
        standalone_id=0:
                phyindex=0: devname=dmz mac=e0:34:ff:fe:4b:00, linkfail=1
                phyindex=1: devname=mgmt mac=e0:33:ff:fe:4b:01, linkfail=1
                phyindex=2: devname=wan1 mac=e0:33:ff:fe:4b:02, linkfail=1
                phyindex=3: devname=wan2 mac=e0:33:ff:fe:4b:03, linkfail=1
                phyindex=5: devname=ha1 mac=e0:33:ff:fe:4b:05, linkfail=1

        standalone_id=1:
                phyindex=0: devname=port1 mac=56:53:00:07:c7:5f, linkfail=0
                phyindex=1: devname=port2 mac=56:53:00:f4:25:46, linkfail=1
                phyindex=2: devname=port3 mac=56:53:00:5d:9f:6f, linkfail=1

Example output (FGT-2):

diagnose sys ha standalone-peers
Group=3, ID=6
Detected-peers=1
Peer ready bitmap=0000d0000000000
Kernel standalone-peers: num=3.
peer0: vfid=0, peerip:port = 10.1.1.8:708, standalone_id=0, ready=1, src_addr = 0.0.0.0
        session-type: send=4, recv=21
         packet-type: send=0, recv=0
peer1: vfid=0, peerip:port = 10.1.1.2:708, standalone_id=2, ready=1, src_addr = 0.0.0.0
        session-type: send=4, recv=36
         packet-type: send=0, recv=0
peer2: vfid=0, peerip:port = 10.1.1.3:708, standalone_id=3, ready=1, src_addr = 0.0.0.0
        session-type: send=4, recv=232
         packet-type: send=0, recv=0
Kernel standalone dev_base:
        standalone_id=0:

        standalone_id=1:
                phyindex=0: devname=port1 mac=56:53:00:07:c7:5f, linkfail=0
                phyindex=1: devname=port2 mac=56:53:00:f4:25:46, linkfail=1
                phyindex=2: devname=port3 mac=56:53:00:5d:9f:6f, linkfail=1

In this scenario:

standalone-member-id=0 devbase information is present on FGT-1.
standalone-member-id=0 devbase information is missing on FGT-2.

If a peer’s devbase information is missing, it indicates that the FortiGate has deleted the FGSP devbase entry, typically because it considered the peer to be down. In this case, FGT-2 is missing standalone-member-id=0, which indicates that FGT-2 assumes that FGT-1 is dead for one of the following reasons.

This may occur due to:

Delayed heartbeat packet arrival.
Interface drops or errors.
Physical cabling issues.
Failure to learn the peer MAC address.

As a result, FGSP behavior becomes inconsistent, leading to traffic hairpinning, L2 bouncing, or session timeouts.

Recommended actions.

Verify physical cabling between FGSP peers.
Check interface error counters and packet drops.
Validate heartbeat interval and lost-threshold settings.
Ensure peer MAC addresses are learned correctly.
Monitor heartbeat packet latency between peers.

Sign up

Login with SSO

Login to the community

Login with SSO