Technical Tip: Link monitor behaviour on an HA cluster

[nalexiou]

Description	This article describes the behavior of the link monitor on the primary and the secondary member(s) of a cluster.
Scope	FortiGate.
Solution	In some cases, after failover, the status of the secondary member(s) may vary from the status on the primary. For example, in the below case, the status is different for the two members of the cluster: primary # di sys link-monitor status Link Monitor: internet, Status: alive, Server num(1), HA state: local(alive), shared(alive) Flags=0x1 init, Create time: Mon Feb 3 02:08:37 2025 Source interface: mgmt (6) VRF: 0 Interval: 500 ms Service-detect: disable Diffservcode: 000000 Class-ID: 0 Peer: 8.8.8.8(8.8.8.8) Source IP(10.10.20.17) Route: 10.10.20.17->8.8.8.8/32, gwy(10.10.31.254) protocol: ping, state: alive Latency(Min/Max/Avg): 1.803/8.816/2.587 ms Jitter(Min/Max/Avg): 0.000/6.976/0.843 ms Packet lost: 0.000% MOS: 4.402 Number of out-of-sequence packets: 0 Fail Times(0/5) Packet sent: 11, received: 11, Sequence(sent/rcvd/exp): 12/12/13 secondary (root) # diagnose sys link-monitor status Monitor (internet), state(dead), ha_state(dead) This output does not indicate an issue on the secondary member. As there is no routing table on the secondary member(s) the link-monitor is not actively running. The status reflected when the command 'di sys link-monitor status' is executed is the latest status when the device had the primary role and it will update again when it is promoted to primary again. therefore when the command 'di sys link-monitor status' is executed the below message is printed: Please run this command on the primary.