Technical Tip: SD-WAN Performance SLA is down though target server is pingable

[Adryan_you]

Description	This article shows how to fix the issue where SD-WAN Performance SLA is down though the target server is ping-able.
Scope	FortiGate, SD-WAN SLA.
Solution	FortiGate can still ping the target server. But the SLA is showing 'dead'. Case 1: Example: exec ping 10.100.2.210 PING 10.100.2.210 (10.100.2.210): 56 data bytes 64 bytes from 10.100.2.210: icmp_seq=0 ttl=64 time=700.6 ms 64 bytes from 10.100.2.210: icmp_seq=1 ttl=64 time=700.5 ms 64 bytes from 10.100.2.210: icmp_seq=2 ttl=64 time=700.5 ms 64 bytes from 10.100.2.210: icmp_seq=3 ttl=64 time=700.4 ms 64 bytes from 10.100.2.210: icmp_seq=4 ttl=64 time=700.5 ms --- 10.100.2.210 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 700.4/700.5/700.6 ms diagnose sys sdwan health-check  Health Check(TESTSLA): Seq(3 port3): state(dead), packet-loss(100.000%) sla_map=0x0 <<=== This is due to the SLA default probe timeout setting. If the probe (ping) timeout exceeds 500ms, SLA will render the target host not reachable, thus, the SLA status is 'dead'. To ensure that the ping test from FortiGate will use the outgoing interface which needs to be checked, use the FortiGate 'ping-options' feature: exec ping-options interface <interface-name> exec ping <target server IP> Note: This can be common for satellite network setups or high-latency networks. To solve the issue, edit the probe timeout setting in SLA. config sys sdwan   config health-check  edit TESTSLA <<=== SLA object name set probe-timeout 800 <-- unit in ms. default is 500 end end After making the changes, the SLA status is 'Alive'. diagnose sys sdwan health-check Health Check(TESTSLA): Seq(3 port3): state(alive), packet-loss(0.000%) latency(700.495), jitter(0.049) sla_map=0x0 Case 2: If IPsec overlay interfaces are part of an SD-WANzone in a Hub and Spoke scenario, Spoke shortcut tunnels may show the SLA as 'dead' in the Performance SLA configuration. This behavior is noted when ping health checks are configured for Spokes, however, ping is not allowed in the tunnel interface. As a result, incorrect SD-WAN rules can be matched. For this case, the solution would be to enable ping access to both tunnel interfaces for each spoke.