Frequent HA switching after setting link-monitor

[VDOM001]

We have been using link-monitor to monitor ping to GW, but after setting up link-monitor, HA switchover due to link monitor failure occurred frequently during periods of high traffic spikes.
When we checked the ping statistics of link-monitor, we found a temporary maximum latency of 475 ms, which is a very bad value. No switching occurred at that time.
The reason for the frequent occurrences is that the line became unstable due to user traffic.
Is it safe to assume that the ICMP packets in the link monitor are likely to have been affected by the unstable state of the line due to user traffic?
If so, can this be resolved by changing the timer value of the link monitor?
The current settings are interval 5000, failtime 3, and other default values.

[Toshi_Esumi]

What's the ping destination? If it's not immediately connected, like pinging 8.8.8.8 or 1.1.1.1 on the internet, there are many hops inbetween and ICMP packets are often the least prioritized traffic on those routers.
Try using different protocol. I see other options below. The destination needs to respond though.

FortiGate-60F (testmon) # set protocol ?
ping PING link monitor.
tcp-echo TCP echo link monitor.
udp-echo UDP echo link monitor.
http HTTP-GET link monitor.
https HTTPS-GET link monitor.
twamp TWAMP link monitor.

Toshi

[VDOM001]

@Toshi_Esumi 

Thank you for contacting us.
The destination for ping monitoring is the VIP of HSRP on the upper L3SW.
Forti----->L2SW----->L3SW

I don't think ICMP packets will be lost if the line is not tight, but speed/duplex from forti to L3SW is fixed 10/full.

[Toshi_Esumi]

Did you mean 10Mbps or 10Gbps?
If 10Gig, and if the 10Gig is nearly maxed out during the peaks, you probably have a capacity/topology design issues in your switching network, which has nothing to do with FGT HA. The failover wouldn't solve the traffic issue and the new HA primary would experience the same problem as long as the peak traffic continues.

You should address the root problem instead of tweaking the parameters of link-monitor.

Toshi

[VDOM001]

@Toshi_Esumi 

The target line is 10 Mbps.
Although the amount of traffic does not appear to be that large, there seems to be a ping response delay, so it is possible that the load is temporarily high.
First, we would like to observe if the problem can be resolved by delaying the failure detection of the link monitor.

[Toshi_Esumi]

Why do you need to make the L3SW port 10Mbps? If the other ports are like 1Gbps or even 100Mbps, the 10Mbps ports very quickly clogged up and easily run out of the buffer and would cause dropping packets if the buffer is full.

Toshi

[VDOM001]

@Toshi_Esumi 

This is because the service is contractually provided as 10 Mbps. It is possible to change the contract and increase the speed, but after setting the link monitor, HA switching occurs frequently, causing users' communication to be delayed. Before the link monitoring was set, there was almost no delay. We are looking for a way to prevent the HA from switching with the current contract line.

[funkylicious]

is the link monitor really required ?

i mean, if the wan link goes down or a destination in the internet is unreachable, do you want for the HA to failover ?

[VDOM001]

@funkylicious 

L3SW#1,#2 are also connected to L2SW#3, so there is no crossing between L2SW#1 and L2SW#2 in this special configuration. (to avoid loops).

All links are on the same segment.
If a failure occurs on L3SW, the FW cannot detect the failure of the upper L3SW, so the address of L3SW must be monitored by the link monitor.

Forti#1----L2SW#1----L3SW#1
Forti#2----L2SW#2----L3SW#2
　　　　     L2SW#3----

[funkylicious]

would it be easier to monitor the svi/management interface of the L3SW rather than go outside the network, in this case ?