Interface monitoring and remote link monitoring can be configured together in an FGCP cluster. The two methods are complementary and detect different types of connectivity failures.
In this topology, interface monitoring detects a failure if the monitored FortiGate interface goes down. However, if the interface remains up while connectivity fails further upstream, such as a failure between the upstream switch and a router, interface monitoring does not detect the failure.
Remote link monitoring extends the failure detection beyond the local interface by monitoring reachability to a remote destination. If the remote path through the active member becomes unavailable, remote link monitoring can trigger an HA failover, allowing the other FortiGate member to use the available upstream path.
Interface monitoring:
Interface monitoring detects a failure when the monitored interface goes down.
config system ha
set monitor "wan1"
end
If wan1 on the primary FortiGate goes down, FGCP detects the interface failure and can initiate an HA election.
Remote link monitoring:
Remote link monitoring can detect connectivity failures beyond the directly connected interface.
config system link-monitor
edit "WAN-Remote-Monitor"
set srcintf "wan1"
set server "4.2.2.2"
set protocol ping
set interval 500
set failtime 5
set recoverytime 5
set ha-priority 10
next
end
To allow the remote link monitor to influence HA:
config system ha
set pingserver-monitor-interface "wan1"
set pingserver-failover-threshold 10
end
When the remote target becomes unreachable, the failed link monitor contributes the configured ha-priority value to the HA penalty. An HA election can occur when the accumulated penalty reaches the pingserver-failover-threshold.
The following table summarizes the behavior when both monitoring methods are configured.
Failure condition | Interface monitoring | Remote link monitoring |
|---|
Monitored FortiGate interface goes down. | Detected. | Remote probe also becomes unavailable. | FortiGate interface remains up but the upstream path fails. | Not detected. | Detected. | Failure is common to both upstream paths. | Not detected if the interface remains up. | Detected, but HA failover may not restore connectivity. |
Benefits and considerations:
Using both methods provides coverage for local interface failures and failures beyond the directly connected interface.
Remote monitoring should be configured according to the network topology and failure domain. If the failure affects a path that is common to both HA members, the new primary may experience the same failure after failover. In this situation, changing the active HA member may not restore connectivity.
Remote monitoring targets and the interval, failtime, recoverytime, ha-priority, and pingserver-failover-threshold settings should be selected according to the required failure detection and HA behavior.
Verification:
Verify the remote link-monitor status:
diagnose sys link-monitor status
Verify the HA status:
get system ha status
If required, verify that probes are transmitted and replies are received on the monitored interface:
diagnose sniffer packet wan1 'host 4.2.2.2 and icmp' 4 0 l
When introducing remote link monitoring to an existing cluster, validate the link-monitor operation before allowing it to influence HA failover. Existing interface monitoring can remain configured because the two mechanisms protect against different failure conditions.
| 
