Technical Tip: How to troubleshoot the error 'no server suitable for synchronization found' on FortiGate HA

[ojacinto]

Description	This article describes how to troubleshoot the error 'no server suitable for synchronization found' for the NTP server configured on the FortiGate HA environment.
Scope	FortiGate v7.2.0 and later, v7.4.0 and later.
Solution	After the FortiGate HA cluster is configured and synchronized, in some cases it is possible to see that the date/time on FortiGate is not properly updated when the NTP server is used. FGVM04-HA02 (global) # show system ntp config system ntp     set ntpsync enable     set type fortiguard     set syncinterval 1     set server-mode enable end Ntpd process debug shows the following error: FGVM04-HA02 (global) # diagnose debug application ntpd -1 Debug messages will be on for 30 minutes. FGVM04-HA02 (global) # diagnose debug enable 2024-07-11 11:52:28 name=ntp2.fortiguard.com, id=2000, cb=0x12ef6c0 2024-07-11 11:52:28 waiting for 0 seconds ... 2024-07-11 11:52:28 DNS ntp2.fortiguard.com -> 208.91.112.62 2024-07-11 11:52:28 DNS ntp2.fortiguard.com -> 208.91.112.60 2024-07-11 11:52:28 ntp_dns_cb:1980 in_flight=1 resolved=0 ipv6=0 2024-07-11 11:52:28 waiting for 0 seconds ... 2024-07-11 11:52:28 name=ntp1.fortiguard.com, id=2008, cb=0x12ef6c0 2024-07-11 11:52:28 waiting for 1 seconds ... 2024-07-11 11:52:28 DNS ntp1.fortiguard.com -> 208.91.112.61 2024-07-11 11:52:28 DNS ntp1.fortiguard.com -> 208.91.112.63 2024-07-11 11:52:28 ntp_dns_cb:1980 in_flight=1 resolved=0 ipv6=0 2024-07-11 11:52:28 waiting for 0 seconds ... 2024-07-11 11:52:29 sys_update_timer_func:1803 synchronized=0 2024-07-11 11:52:29 Sorted NTP endpoints. 2024-07-11 11:52:29 NTP daemon uses a upper end of -2000000000.000000 and a lower end of 2000000000.000000. 2024-07-11 11:52:29 no server suitable for synchronization found  <--- When doing a sniffer to NTP server IPs, there is only traffic going out: FGVM04-HA02 (root) # diagnose sniffer packet any 'host 208.91.112.61 or host 208.91.112.62' 4 Using Original Sniffing Mode interfaces=[any] filters=[host 208.91.112.61 or host 208.91.112.62] 0.609638 port9 out 10.0.1.100.123 -> 208.91.112.62.123: udp 48 0.609754 port9 out 10.0.1.100.123 -> 208.91.112.61.123: udp 48 42.617123 port9 out 10.0.1.100.123 -> 208.91.112.62.123: udp 48 42.617269 port9 out 10.0.1.100.123 -> 208.91.112.61.123: udp 48 However, the traffic is sent over the interface port9 while the default route on the device is defined over the interface port1: FGVM04-HA02 (root) # get router info routing-table all Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP        O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area        V - BGP VPNv4        * - candidate default Routing table for VRF=0 S*          0.0.0.0/0 [10/0] via 192.168.170.1, port1, [1/0]  <--- C           172.16.32.0/24 is directly connected, port6 C           192.168.170.0/24 is directly connected, port1 Looking at HA settings, port9 is defined as mgmt interface, and ha-direct is enabled: FGVM04-HA02 (global) # show system ha config system ha     set group-id 16     set group-name "HA-TACMEX"     set mode a-p     set hbdev "port10" 0     set ha-mgmt-status enable         config ha-mgmt-interfaces             edit 1                 set interface "port9"                 set gateway 10.0.1.254             next         end     set override disable     set priority 160     set monitor "port1" "port2"     set ha-direct enable end Due to ha-direct being enabled mgmt traffic including NTP traffic is forwarding through interface port9. The solution to this problem is: Ensure that the connection to NTP servers can be established through interface port9. In this scenario, disable the ha-direct setting under system ha and let the NTP traffic go through the default route: FGVM04-HA02 (global) # config system ha FGVM04-HA02 (ha) # set ha-direct enable FGVM04-HA02 (ha) # end When ha-direct is enabled, source ip may not work. We recommend to unset all log-related, netflow and sflow source ip. By selecting to continue, all source ip will be unset. Do you want to continue? (y/n)y FGVM04-HA02 (global) # diagnose sys ntp status HA primary: yes, HA primary ip: 169.254.0.2, management_vfid: 0 ha_direct=0, ha_mgmt_vfid=3 synchronized: yes, ntpsync: enabled, server-mode: enabled ipv4 server(ntp1.fortiguard.com) 208.91.112.63 -- reachable(0xff) S:3 T:0             server-version=4, stratum=2             reference time is ea42a0e2.fe84164b -- UTC Wed Jul 17 19:58:26 2024             clock offset is 0.000133 sec, root delay is 0.076584 sec             root dispersion is 0.010483 sec, peer dispersion is 0 msec ipv4 server(ntp2.fortiguard.com) 208.91.112.62 -- reachable(0xff) S:3 T:0 selected             server-version=4, stratum=2             reference time is ea42a0dd.9d8d8c81 -- UTC Wed Jul 17 19:58:21 2024             clock offset is 0.000105 sec, root delay is 0.076767 sec             root dispersion is 0.010315 sec, peer dispersion is 1 msec ipv4 server(ntp1.fortiguard.com) 208.91.112.61 -- reachable(0xff) S:3 T:0           server-version=4, stratum=2           reference time is ea42a0e1.470bb892 -- UTC Wed Jul 17 19:58:25 2024           clock offset is 0.000098 sec, root delay is 0.076767 sec           root dispersion is 0.010315 sec, peer dispersion is 1 msec Note: Another possible cause of this issue is that DNS is not resolvable. If the following output is observed from NTP debug, verify if DNS can resolve the NTP server hostname.