| When the ADVPN scenario is configured it is necessary to set some SLAs for some Interface selection strategies.
For example:
SPOKE1 (172.16.31.3) ------ VPN_HUB1 ----- (172.16.31.1 HUB ) ------- VPN_HUB1 ----- (172.16.31.2) SPOKE2 LAN1 192.168.13.0/24 LAN HUB 10.254.0.0/24 LAN2 192.168.12.0/24 Ping server 10.254.0.99 Before the shortcut is negotiated between both spokes, all the traffic is sent through the HUB tunnels. After the shortcut is established (VPN_HUB1_0), traffic between networks 192.168.13.0/24 and 192.168.12.0/24 is sent directly between Spokes.
On SD-WAN configuration it was defined a SLA on each spoke to monitor an IP of HUB internal LAN (10.254.0.99).
Spoke1: FGT-SPOKE1 (SLA_LAN_HUB) # show
config health-check
edit "SLA_LAN_HUB"
set server "10.254.0.99" < ---
set members 2 1
config sla
edit 1
set latency-threshold 10
set jitter-threshold 20
set packetloss-threshold 1
next
end
next
end Spoke2: FGT-SPOKE2 (HUB_PIN SERVER) # show
config health-check
edit "HUB_PIN SERVER"
set server "10.254.0.99" < ---
set members 3 1
config sla
edit 1
set packetloss-threshold 1
next
end
next
end This will create a link monitor for each VPN tunnel from spokes to HUB to monitor the server 10.254.0.99.
However, the shortcut between both spokes can not monitor that IP. It will use the overlay IPs instead to validate the VPN tunnel. FGT-SPOKE1 # diagnose sniffer packet VPN_HUB1_0 'none' 4
Using Original Sniffing Mode
interfaces=[VPN_HUB1_0]
filters=[none]
0.168696 VPN_HUB1_0 -- 172.16.31.3 -> 172.16.31.2: icmp: echo request
0.168953 VPN_HUB1_0 -- 172.16.31.2 -> 172.16.31.3: icmp: echo reply
0.327588 VPN_HUB1_0 -- 172.16.31.2 -> 172.16.31.3: icmp: echo request
0.327597 VPN_HUB1_0 -- 172.16.31.3 -> 172.16.31.2: icmp: echo reply
0.669820 VPN_HUB1_0 -- 172.16.31.3 -> 172.16.31.2: icmp: echo request
0.670059 VPN_HUB1_0 -- 172.16.31.2 -> 172.16.31.3: icmp: echo reply
0.828657 VPN_HUB1_0 -- 172.16.31.2 -> 172.16.31.3: icmp: echo request
0.828666 VPN_HUB1_0 -- 172.16.31.3 -> 172.16.31.2: icmp: echo reply
On link-monitor debug these probes are shown: FGT-SPOKE1 # diagnose debug application link-monitor -1 FGT-SPOKE1 # diagnose debug enable 2025-03-11 18:55:26 lnkmtd::monitor_proto_peer_send_request(638): <----- SLA_LAN_HUB-1-VIRTUAL_WAN_LINK-1-VPN_HUB1_0(172.16.31.2:ping) send probe packet, fail count(0)
2025-03-11 18:55:26 lnkmtd::ping_do_addr_up(136): <----- SLA_LAN_HUB-1-VIRTUAL_WAN_LINK-1-VPN_HUB1_0->172.16.31.2(172.16.31.2), rcvd
2025-03-11 18:55:26 lnkmtd::monitor_peer_recv(2172): <----- SLA_LAN_HUB-1-VIRTUAL_WAN_LINK-1-VPN_HUB1_0 send time 1741740926s 354738us, revd time 1741740926s 361269us Even ping server 10.254.0.99 is configured on SLA it is not used for shortcut monitor, however, SD-WAN health check also reports the result for that tests: FGT-SPOKE1 # diagnose sys sdwan health-check
Health Check(SLA_LAN_HUB):
Seq(1 VPN_HUB1): state(alive), packet-loss(0.000%) latency(10.163), jitter(0.167), mos(4.399), bandwidth-up(9999999), bandwidth-dw(9999999), bandwidth-bi(19999998) sla_map=0x0
Seq(1 VPN_HUB1_0 state(alive), packet-loss(0.000%) latency(10.145), jitter(0.133), mos(4.399), bandwidth-up(9999999), bandwidth-dw(9999999), bandwidth-bi(19999998) sla_map=0x0 It is possible to display the link monitor information for a shortcut using the name obtained on the link-monitor debug 'SLA_LAN_HUB-1-VIRTUAL_WAN_LINK-1-VPN_HUB1_0' by the following command: diagnose sys link-monitor status "link_monitor name" In this case:
FGT-SPOKE1 # diagnose sys link-monitor status SLA_LAN_HUB-1-VIRTUAL_WAN_LINK-1-VPN_HUB1_0 Link Monitor: SLA_LAN_HUB-1-VIRTUAL_WAN_LINK-1-VPN_HUB1_0, Status: alive, Server num(1), cfg_version=0 Flags=0x3 init no_src_route, Create time: Tue Mar 11 18:52:10 2025
Source interface: VPN_HUB1_0 (24)
VRF: 0
Interval: 500 ms
Service-detect: disable
Diffservcode: 000000
Class-ID: 0
Transport-Group: 0
Class-ID: 0
Peer: 172.16.31.2(172.16.31.2) < ---
protocol: ping, state: alive < ---
Latency(Min/Max/Avg): 9.974/11.686/10.286 ms
Jitter(Min/Max/Avg): 0.013/1.294/0.315 ms
Packet lost: 0.000%
MOS: 4.399
Number of out-of-sequence packets: 0
Fail Times(0/5)
Packet sent: 7547, received: 7547, Sequence(sent/rcvd/exp): 7548/7548/7549
SLA: id(1), recov_count(0/5), fail_count(0/5), flags=0x0, The above output shows that the peer IP (ping server) for the shortcut link-monitor is 172.16.31.2 (overlay IP) and not the ping server defined on the SLA health-check. | 
