New Member

Question

Performance SLAs are down

Forum|Forum|2 years ago
July 8, 2024
4 replies
4585 views

Hi All,
I am having an issue with the SD-WAN performance SLA.
The server is pingable from WAN1 and the VPN tunnels, latency is below 10ms.

execute ping 192.168.100.

PING 192.168.100.1 (192.168.100.1): 56 data bytes

64 bytes from 192.168.100.1: icmp_seq=0 ttl=255 time=0.4 ms
64 bytes from 192.168.100.1: icmp_seq=1 ttl=255 time=0.1 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=255 time=0.0 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=255 time=0.0 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=255 time=0.0 ms

SLA Config.png SLA Details.png

But it is still showing a dead state.

SLA health.PNG

SD-WAN

janonuevo

Staff

Hi @mudvayne16,

Try to configure a source ip for the sdwan performance sla and make sure that the source IP address is allowed on the IPsec Phase2 selector.

config system sdwan
config health-check
edit <name> <----- Health Check name.
set source <IP address> <----- source-IP to be used for the health check.
end

You may also refer to this link:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-configure-source-IP-for-Secure-SD-WAN/ta-p/198515

mudvayne16Author

New Member

Hi @janonuevo, thanks for your advice.
Would that limit the source to a single IP address? The configuration has multiple members in the performance SLA.

edit "Health-check"
set server "192.168.100.1"
set update-static-route disable
set embed-measured-health enable
set members 6 4 5 7 8 10 11 13 15
config sla
edit 1
set latency-threshold 100
set jitter-threshold 10
set packetloss-threshold 2
next
end
next

I tested below that all active interfaces can receive a response from the server.

2024-07-10 10:22:51.389874 root out 10.255.212.122 -> 192.168.100.1: icmp: echo request
2024-07-10 10:22:51.389882 root in 10.255.212.122 -> 192.168.100.1: icmp: echo request
2024-07-10 10:22:51.389904 root out 192.168.100.1 -> 10.255.212.122: icmp: echo reply
2024-07-10 10:22:51.389907 root in 192.168.100.1 -> 10.255.212.122: icmp: echo reply
2024-07-10 10:22:51.391552 root out 10.255.216.122 -> 192.168.100.1: icmp: echo request
2024-07-10 10:22:51.391555 root in 10.255.216.122 -> 192.168.100.1: icmp: echo request
2024-07-10 10:22:51.391573 root out 192.168.100.1 -> 10.255.216.122: icmp: echo reply
2024-07-10 10:22:51.391577 root in 192.168.100.1 -> 10.255.216.122: icmp: echo reply
2024-07-10 10:22:51.391633 root out 192.168.51.34 -> 192.168.100.1: icmp: echo request
2024-07-10 10:22:51.391637 root in 192.168.51.34 -> 192.168.100.1: icmp: echo request
2024-07-10 10:22:51.391652 root out 192.168.100.1 -> 192.168.51.34: icmp: echo reply
2024-07-10 10:22:51.391655 root in 192.168.100.1 -> 192.168.51.34: icmp: echo reply

mudvayne16Author

New Member

I tried using a source but its not working as well.
I sourced from the loopback IP which can reach the server

hbac

Staff

Hi @mudvayne16,

You can run packet sniffer to see which source IP is being used. Change the source IP accordingly.

di sniffer packet any 'host 192.168.100.1 and icmp' 4 0 l

Regards,

mudvayne16Author

New Member

Thanks for the advice, this was result of the command.

filters=[host 192.168.100.1 and icmp]
2024-07-10 10:22:51.389874 root out 10.255.212.122 -> 192.168.100.1: icmp: echo request
2024-07-10 10:22:51.389882 root in 10.255.212.122 -> 192.168.100.1: icmp: echo request
2024-07-10 10:22:51.389904 root out 192.168.100.1 -> 10.255.212.122: icmp: echo reply
2024-07-10 10:22:51.389907 root in 192.168.100.1 -> 10.255.212.122: icmp: echo reply
2024-07-10 10:22:51.391552 root out 10.255.216.122 -> 192.168.100.1: icmp: echo request
2024-07-10 10:22:51.391555 root in 10.255.216.122 -> 192.168.100.1: icmp: echo request
2024-07-10 10:22:51.391573 root out 192.168.100.1 -> 10.255.216.122: icmp: echo reply
2024-07-10 10:22:51.391577 root in 192.168.100.1 -> 10.255.216.122: icmp: echo reply
2024-07-10 10:22:51.391633 root out 192.168.51.34 -> 192.168.100.1: icmp: echo request
2024-07-10 10:22:51.391637 root in 192.168.51.34 -> 192.168.100.1: icmp: echo request
2024-07-10 10:22:51.391652 root out 192.168.100.1 -> 192.168.51.34: icmp: echo reply
2024-07-10 10:22:51.391655 root in 192.168.100.1 -> 192.168.51.34: icmp: echo reply

All 3 IP addresses 192.168.51.34, 10.255.212.122, 10.255.216.122 are getting a reply from the destination server.

fdsantos

Staff

Hello,

May I know where does 192.168.100.1 resides in your FortiGate?

The health check behavior will only make the state "up" if the traffic is sent and received to the same interface (e.g. wan1). Checking on the packet capture it seems that 192.168.100.1 is sent and received from the root interface.

Would be able to share the following commands below? So we can determine where 192.168.100.1 resides.

get router info routing-table database
get router info kernel

Thank you.

mudvayne16Author

New Member

Hi @fdsantos,

Thanks for this, I think we found out that the source ping seems to be coming from the root interface not the actual SD-WAN member interface.

Do you have any idea to resolve this?

2024-07-10 10:22:51.391633 root out 192.168.51.34 -> 192.168.100.1: icmp: echo request
2024-07-10 10:22:51.391637 root in 192.168.51.34 -> 192.168.100.1: icmp: echo request
2024-07-10 10:22:51.391652 root out 192.168.100.1 -> 192.168.51.34: icmp: echo reply
2024-07-10 10:22:51.391655 root in 192.168.100.1 -> 192.168.51.34: icmp: echo reply

ezhupa

Staff

Hello,

From what I can see only the PING SLA are failing but at the same time you can reach the configured server.
Can you reach it from a host behind the FGT as well?
Also, do you have a possibility to test with a different kind of protocol? (DNS or HTTP)
There is an internal issue that impacts only PING probes that will show the configured server in healthcheck as down when in fact it is reachable and you might be matching it.

Hope this helps!

Sign up

Login with SSO

Login to the community

Login with SSO