Technical Tip: How to review the SLA link monitor status for an ADVPN shortcut tunnel

[ojacinto]

Description	This article describes how to display the SLA link monitor status for an ADVPN shortcut tunnel.
Scope	FortiGate v7.2.0 and later, v7.4.0 and later.
Solution	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.