HA remote link monitoring

Remote link monitoring (also known as Remote IP Monitoring or PING server Monitoring) allows an FGCP cluster to detect failures beyond the directly connected network segment. By probing remote hosts, the primary unit can detect "soft" failures in the network path, such as a failed ISP gateway or a downstream router, and trigger an HA failover to a unit with a healthy path.

Prerequisites and constraints

• Cluster Mode: Units must be in an Active-Passive (A-P) FGCP cluster.

• Primary-Only Probing: In an FGCP cluster, only the primary unit performs active link monitoring.

• Routing Table: The secondary unit does not have an active routing table. While you can technically "ping" from a secondary unit, the ICMP requests are proxied through the primary unit via the HA heartbeat link.

• Multiple Servers: If a link monitor contains multiple servers, the monitor is only marked as failed if all configured servers stop responding.

General configuration steps

This section breaks down the configuration for this example into smaller procedures:

1. Configure the Link Monitor

2. Integrate monitoring into HA settings

3. Verify

Configure the Link Monitor

The link monitor defines the targets to be probed and the "penalty" (HA priority) to be applied if those targets become unreachable.

To configure the link monitor via the CLI:

config system link-monitor
    edit "WAN_Link_Monitor"
        set srcintf "port1"
        set server "8.8.8.8" "1.1.1.1"
        set protocol ping
        set ha-priority 10
        set interval 500
        set failtime 5
    next
end

Command	Description
srcintf	The Interface that receives the traffic to be monitored.
server	The IP address of the server(s) to be monitored.
protocol	The protocols used to monitor the server. Default is Ping
ha-priority	The penalty value added to the unit's health score upon failure. Default is 1.
interval	Detection interval in milliseconds (20 - 3600 * 1000 msec, default = 500).
failtime	Number of retry attempts before the server is considered down (1 - 3600, default = 5).

Integrate monitoring into HA settings

Once the monitor is defined, you must configure the HA to monitor the interface and set the threshold for failover.

To configure the HA failover logic:

config system ha
    set pingserver-monitor-interface "port1"
    set pingserver-failover-threshold 10
    set pingserver-flip-timeout 60
    set pingserver-secondary-force-reset disable
end

Command	Description
pingserver-monitor-interface	The Interfaces to check for remote IP monitoring.
pingserver-failover-threshold	Remote IP monitoring failover threshold (0 – 50, default = 0).
pingserver-flip-timeout	Time to wait in minutes before renegotiating after a remote IP monitoring failover. (6 - 2147483647, default = 60).
pingserver-secondary-force-reset	Enable/Disable force reset of secondary member after PING server failure. Default is enable

The Logic of failover

The FortiGate tracks a Global Penalty. When a link monitor fails, its ha-priority is added to this penalty. A failover is triggered only when the Global Penalty reaches or exceeds the pingserver-failover-threshold.

If...	Then...
ha-priority < threshold	No failover occurs.
ha-priority ≥ threshold	Failover is triggered immediately when the link is marked "dead."

Managing failback (the FLIP timer)

When a failover occurs, the cluster starts a FLIP Timer (defined by pingserver-flip-timeout). This prevents the cluster from rapidly switching back and forth if a link is flapping.

pingserver-secondary-force-reset

This setting dictates what happens when the FLIP timer expires:

• Enabled (Default): The penalty on the original primary is reset. If override is enabled, the original primary will attempt to take back the primary role. If the link is still down, it will fail over again once the timer expires, creating a FLIP-FLOP loop.

• Disabled: The penalty is not reset. The cluster remains on the new primary even if the link is restored on the original side. This is safer for unstable links but requires a manual reset or a failure on the new primary to switch back.

Verify

Verifying link status:

Run the following command to Check if the FortiGate considers the remote link "alive" or "dead":

# diagnose sys link-monitor status

Alive example:

Link Monitor: L_M_Port1, Status: alive, Server num(3), Flags=0x1 init, Create time: Thu March 12 10:45:46 2026
Source interface: port1 (11)
Interval: 500 ms
  Peer: 8.8.8.8(8.8.8.8)
        Source IP(192.168.1.1)
        Route: 192.168.1.1->8.8.8.8/32, gwy(192.168.1.2)
        protocol: ping, state: alive   
        Latency(Min/Max/Avg): 1.921/2.103/1.973 ms
        Jitter(Min/Max/Avg): 0.003/0.142/0.034
        Packet lost: 0.000%
        Number of out-of-sequence packets: 0
                  Fail Times(0/5)
                  Packet sent: 4749, received: 4749, Sequence(sent/rcvd/exp): 4750/4750/4751

Dead example:

Link Monitor: L_M_Port1, Status: die, Server num(3), Flags=0x9 init, Create time: Thu March 12 10:45:46 2026
Source interface: port1 (11)
Interval: 500 ms
  Peer: 8.8.8.8(8.8.8.8)
        Source IP(192.168.1.1)
        Route: 192.168.1.1->8.8.8.8/32, gwy(192.168.1.2)
        protocol: ping, state: die  
        Packet lost: 100.000%
        Number of out-of-sequence packets: 0
                  Recovery times(0/5) Fail Times(3/5)
                  Packet sent: 5862, received: 5563, Sequence(sent/rcvd/exp): 5863/5564/5565