[HPE FlexFabric 5820] Cannot sync via NTP

[smsc_1]

Hello community,

I have a problem with NTP, I always got:

Clock status: unsynchronized

I'm running my own NTP server on local PC, and it works perfect, here is the NTP server test from another Windows PC on the network:

w32tm /stripchart /computer:192.168.56.1 /dataonly /samples:3
Rilevamento di 192.168.56.1 [192.168.56.1:123] in corso.
Data e ora corrente: 22/09/2019 07:23:02.
07:23:02, +00.0061680s
07:23:04, +00.0060420s
07:23:06, +00.0047262s

Here is the Switch configuration:

display ntp-service sessions
source reference stra reach poll now offset delay disper
********************************************************************************
[25]192.168.56.1 0.0.0.0 3 255 64 8 295173 3.2653 16.754
Notes: 1 source(master), 2 source(peer), 3 selected, 4 candidate, 5 configured.
Total sessions: 1

display ntp-service status
Clock status: unsynchronized
Clock stratum: 16 
Reference clock ID: none
Clock jitter: 0.000000 s
Stability: 0.000 pps 
Clock precision: 2^-12
Root delay: 0.00000 ms 
Root dispersion: 0.18311 ms 
Reference time: 00000000.00000000 Thu, Feb 7 2036 8:28:16.000

display current-configuration | include ntp
clock protocol ntp
ntp-service enable
ntp-service unicast-server 192.168.56.1

display clock
23:18:21 CET Sat 09/21/2019
Time Zone : CET add 02:00:00

display ntp-service trace
Local host: Not synchronized.

Could someone help me to understand what's wrong? Thank you.

[parnassus]

Hi Lucas, (silly) question first: do you ping your NTP Server from Switch's console (are they on the same subnet)? I suspect the answer is a sound Yes but keep asking.

Which software version is the 5820 running?

[smsc_1]

Sure, I can ping the NTP server, hosted on Windows PC, from switch, and Windows Firewall is disabled on server side, so UDP port 123 is reachable

[SWI81]ping 192.168.56.1
Ping 192.168.56.1 (192.168.56.1): 56 data bytes, press CTRL_C to break
56 bytes from 192.168.56.1: icmp_seq=0 ttl=128 time=4.920 ms
56 bytes from 192.168.56.1: icmp_seq=1 ttl=128 time=1.942 ms
56 bytes from 192.168.56.1: icmp_seq=2 ttl=128 time=3.616 ms

and here is the software version:

[SWI81]display version
H3C Comware Software, Version 7.1.059, Alpha 7159

As I wrote in the first post, the NTP server works perfect since other server (Windows and Red Hat) can use it without any issue. I don't understand why, with the switch, doesn't work. Maybe it doesn't like the software, I'm currently using Network Time SYstem app: https://nts.softros.com/

For now I have only the default VLAN1 configured on the switch with IP: 192.168.56.2, so I can telnet/ssh from Windows server 192.168.56.1 (where NTP server is hosted) without problem.

[smsc_1]

Well, here is the result from Red Hat OS. NTP server works as expected:

---

# ntpdate -v 192.168.56.1
23 Sep 08:22:56 ntpdate[5668]: ntpdate 4.2.6p5@1.2349-o Tue May 3 14:43:01 UTC 2016 (1)
23 Sep 08:23:02 ntpdate[5668]: adjust time server 192.168.5.175 offset 0.000095 sec

Definitely, for unknown reason, the switch doesn't like the NTP server. In production I have other switches (with exactly the same ntp-service config except for server address) who sync without problem with other time server. So doesn't matter, this is a test switch, I was just curious to find the root cause.

I'll try to find information about debugging NTP-Service, any advice here will be appreciated!

EDIT: here is the debug output, can't see anythibng interesting except maybe for:   SWI81 NTP/7/ACL: Access restrict: 0x00000008.

---

<SWI81>*Sep 22 16:44:41:959 2019 SWI81 NTP/7/PACKET_SEND:
packet to 192.168.56.1, length: 48
leap: 3, version: 4, mode: 3, vrfindex: 0
stratum: 16, poll: 6, precision: 2^-11
rdel: 0.000, rdsp: 0.992, refid: INIT
reftime: 00000000.00000000 Thu, Feb 7 2036 8:28:16.000
orgtime: e132e7c4.1db22cec Mon, Sep 23 2019 8:42:12.116
rectime: e1320717.4e91af47 Sun, Sep 22 2019 16:43:35.306
xmttime: e1320759.f366ba72 Sun, Sep 22 2019 16:44:41.950

*Sep 22 16:44:41:964 2019 SWI81 NTP/7/PACKET_RECV:
packet from 192.168.56.1 to 192.168.56.2 on Vlan-interface9
leap: 0, version: 4, mode: 4, vrfindex: 0
stratum: 3, poll: 10, precision: 2^-6
rdel: 0.000, rdsp: 0.000, refid: 0.0.0.0
reftime: e132e77e.00000000 Mon, Sep 23 2019 8:41:02.000
orgtime: e1320759.f366ba72 Sun, Sep 22 2019 16:44:41.950
rectime: e132e80c.476c8af1 Mon, Sep 23 2019 8:43:24.279
xmttime: e132e80c.476c8af1 Mon, Sep 23 2019 8:43:24.279
inptime: e1320759.f61df955 Sun, Sep 22 2019 16:44:41.961

*Sep 22 16:44:41:965 2019 SWI81 NTP/7/ACL: Access restrict: 0x00000008.
*Sep 22 16:44:41:966 2019 SWI81 NTP/7/AUTH: Received a packet at 25066, from 192.168.56.1, mode 4, key ID 00 000000, length 48, authentication result 0
*Sep 22 16:44:41:967 2019 SWI81 NTP/7/PARAM: Clock filter param: number 8, offset 57522.322909, delay 0.0106 09, dispersion 0.017012, jitter 28.570803, burst 0
*Sep 22 16:44:41:969 2019 SWI81 NTP/7/SELECT: peer 192.168.56.1, flash 0x00000c00, flags 0x00000401, reach 2 55, root distance 28.593119
*Sep 22 16:44:41:972 2019 SWI81 NTP/7/ADJUST: Reset clock state, time count difference 67, state 1->1, poll 3, count 0, offset 0.000

---

[parnassus]

Is your NTP Server working in NTPv3 or NTPv4 mode? if it works in NTPv4 mode...it's possible that your HPE FlexFabric 5820 (well...I'm not totally sure you're working with an HP/HPE branded device...given the old software version you reported...you're dealing with an H3C branded switch...which is somewhat strange these days...speaking about an HP/HPE 5820 I expected to see a Comware 5 based NOS reference with a software release like latest Comware 5.20 R1810P16 or, eventually, an older one) doesn't like the NTPv4 at all...

To debug you would use: terminal monitor, terminal debugging, terminal logging and debugging ntp-service all commands, those ones should provide you some output about what is going on and why it is failing; if there is too much spam on the terminal you can just do a undo terminal debugging to stop.

[VoIP-Buddy]

Make sure that your switch time is as close to real time as possible.  NTP will not make huge changes in time when it gets going.  The switch needs to be within about 15 minutes or so for it to be able to sync.

You can also try to turn on NTP debugging to see what is happening...

debug ntp event

term debug

term monitor

and then see what it says.

Regards,

David