SG350-28P / NTP offset

[Mr. S. (archive)]

Dear all,

I  am having continuous trouble with NTP setup and the resulting offset. For testing purposes and to eliminate any side effects, here is the show. I would be grateful for any support:

A. TOPOLOGY

. Router [Fritzbox 7590 with OS 7.25] connected with FTTH to the internet.

. Switch SG350-28P 28-Port Gigabit PoE Managed Switch and firmware 2.5.7.85 updated

. both in same LAN, upfront firewall temporarily disabled for testing

B. CONFIGURATION

. I have the switch set to obtain time stamp from a German stratum 1 university server "ntp0.fau.de" that is continuosly "up". The functionality is verified by other clients.

. I now want to set my switch to obtain its time by NTP from above server. Unfortunately, time deviation there between source (server) and client (switch) is typically 1000-1500 milliseconds no matter what I do.

. See screenshots for switch config. All IP v4/v6 SNTP Multicast/Anycast options are "off" and even turning them "on" does not change behavior below. At the following times I hit "apply" on this page with strongy varying results, see screenshots.

11:27 h     Hit „Apply“, result in „21 0419 diagnose 01“. Offset at 83 msec.

11:30 h     Hit "Apply" again, now offset is 258 ms, „21 0419 diagnose 02“. Strange!

11:44 h     Hit „Apply“ again. Offset is now 1105 ms, „21 0419 diagnose 04“. Stranger!!

C. QUESTION

. The last result 11:44 h is now in the typical range I described under [B.] (> 1 s). This delta does not appear to converge within weeks of operation.

Kindly support with your experience and give me a hint on what might be wrong or where I set the wrong buttons. Since I am new to Cisco hardware, please guide me trough as simple as possible (preferably via GUI and not console)

Thank you very much for any reply and support!

Steffen

[Mr. S. (archive)]

I  am having continuous trouble with NTP setup and the resulting offset. For testing purposes and to eliminate any side effects, here is the show. I would be grateful for any support:

A. TOPOLOGY

. Router [Fritzbox 7590 with OS 7.25] connected with FTTH to the internet.

. Switch SG350-28P 28-Port Gigabit PoE Managed Switch and firmware 2.5.7.85 updated

. both in same LAN, upfront firewall temporarily disabled for testing

B. CONFIGURATION

. I have the switch set to obtain time stamp from a German stratum 1 university server "ntp0.fau.de" that is continuosly "up". The functionality is verified by other clients.

. I now want to set my switch to obtain its time by NTP from above server. Unfortunately, time deviation there between source (server) and client (switch) is typically 1000-1500 milliseconds no matter what I do.

. See screenshots for switch config. All IP v4/v6 SNTP Multicast/Anycast options are "off" and even turning them "on" does not change behavior below. At the following times I hit "apply" on this page with strongy varying results, see screenshots.

11:27 h     Hit „Apply“, result in „21 0419 diagnose 01“. Offset at 83 msec.

11:30 h     Hit "Apply" again, now offset is 258 ms, „21 0419 diagnose 02“. Strange!

11:44 h     Hit „Apply“ again. Offset is now 1105 ms, „21 0419 diagnose 04“. Stranger!!

C. QUESTION

. The last result 11:44 h is now in the typical range I described under [B.] (> 1 s). This delta does not appear to converge within weeks of operation.

Kindly support with your experience and give me a hint on what might be wrong or where I set the wrong buttons. Since I am new to Cisco hardware, please guide me trough as simple as possible (preferably via GUI and not console)

Thank you very much for any reply and support!

Steffen

[Mr. S. (archive)]

I  am having continuous trouble with NTP setup and the resulting offset. For testing purposes and to eliminate any side effects, here is the show. I would be grateful for any support:

A. TOPOLOGY

. Router [Fritzbox 7590 with OS 7.25] connected with FTTH to the internet.

. Switch SG350-28P 28-Port Gigabit PoE Managed Switch and firmware 2.5.7.85 updated

. both in same LAN, upfront firewall temporarily disabled for testing

B. CONFIGURATION

. I have the switch set to obtain time stamp from a German stratum 1 university server "ntp0.fau.de" that is continuosly "up". The functionality is verified by other clients.

. I now want to set my switch to obtain its time by NTP from above server. Unfortunately, time deviation there between source (server) and client (switch) is typically 1000-1500 milliseconds no matter what I do.

. See screenshots for switch config. All IP v4/v6 SNTP Multicast/Anycast options are "off" and even turning them "on" does not change behavior below. At the following times I hit "apply" on this page with strongy varying results, see screenshots.

11:27 h     Hit „Apply“, result in „21 0419 diagnose 01“. Offset at 83 msec.

11:30 h     Hit "Apply" again, now offset is 258 ms, „21 0419 diagnose 02“. Strange!

11:44 h     Hit „Apply“ again. Offset is now 1105 ms, „21 0419 diagnose 04“. Stranger!!

C. QUESTION

. The last result 11:44 h is now in the typical range I described under [B.] (> 1 s). This delta does not appear to converge within weeks of operation.

Kindly support with your experience and give me a hint on what might be wrong or where I set the wrong buttons. Since I am new to Cisco hardware, please guide me trough as simple as possible (preferably via GUI and not console)

Thank you very much for any reply and support!

Steffen

[pieterh]

some remarks:
ntp is not continously syncing with the ntp-server, but priodically,
in between the clock on your switch is free-running and may deviate from the ntp-servers time

from your output i do not see the switch has really syncronized with ntp1.fau.de as the master?
you may need to add another ntp server (ntp2.fau.de ?) to obtain proper syncronization
your switch will compare time of both servers and only sync when both times are within limits.
I also see no reference of the time-zone and if it matches that of the time server

last the time server as being stratum-1 may refuse your requests for synchronization and only accept requests from selected hosts
try using another ntp server from  pool.ntp.org, see if this behaves differently.

[Mr. S. (archive)]

Dear Pieterh,

thanks for taking the time. Meanwhile a few more tests from my side:

1. If what you say is true and the switch only syncs periodically, this breaches with the official NTP standard according to RFC 2030 (polling interval 64-1024 sec). It would explain offset behavior partially. If however the NTP service were properly implemented in the firmware, a max polling of 1024 sec cannot explain a clock deviation of 1000 msec within two polling events. The internal clock would be of dreadful quality!

2. Your' re right. The clock is not syncronized wth ntp1.fau.de as master. It simply does not converge, There is no difference in using a second (or multiple) masters OR pointing to fritz.box only (router which distributes time within LAN. It obtains the time from stratum 1-2 servers.

3. I checked availabiltiy and response of ntp0.fau.de, ntp1.fau.de, ntp2.fau.de, ntp3.fau.de to the switch and to my router (fritz.box). All clean and no issues at all. Please see attached proper behaviour of my main server with fritz.box.

4. As proof for firmware bug from Cisco side I see the fact that even using their default servers only, NTP offset does not converge. They are also off by 1000-1500 msec.

5. Final option. Maybe you were able to configure a switch with PERMANENT acceptable NTP offset (e. g. < 300 msec). Please send a screenshot of your config and results on SNTP unicast window. Please then also send a list of configuration settings how you reached this.

Thanks!

Steffen  

[pieterh]

the offset should reflect the deviation from source which for  UTC+1 should be  3600
My guess it the current time (in UTC) on the switch differs more than 1 hour from the ntp reference,
this is the cause the switch will not sync

go to your system time tab and check time-zone and daylight saving setting
disable SNTP and set the correct time manually

then reenable SNTP

[Mr. S. (archive)]

Dear pieterh,

in the meantime, I tried four different settings, all failed:

1. Option May 10, 2021 [21 0510 NTP log.zip]. On switch GUI >Administration >Time Settings >System Time >Time Zone Settings, I have selected UTC to avoid any interference with an offset in time signal. Also, there is no daylight savings time offset selected. In total there should be no effect of time zone offset or similar to the NTP signal received. You can see the time difference on the switch and local time on the smart phone in the top left corner (UTC +1 h and daylight savings time +1 h, in total UTC +2 h) . I started by adding two servers in the list and hitting “apply”. Initially both were status “up”. However, after about 20 minutes or so, server “ntp0.fau.de” went to status “down”. I cannot explain that behavior because in another test, see [Option 2], it goes to “up” immediately after hitting “apply” again. It is also reachable by using ping function. I let the test run anyway: you can observe convergence up to time stamp 09:56 h, then it spreads again without any obvious reason.

2. Option  May 13, 2021 [21 0513 NTP log.zip]. Same basic configuration with respect to UTC as in [Option 1]. Again you can observe the toggle from “up” to “down” without any interaction from my side. And again no predictable behavior with respect to convergence.

3. Option [no screenshots]. After these two disappointing tests I tried the same setting with only two external servers “ntp0.fau.de” and “ntp1.fau.de”. This eliminates interference with my LAN settings. Again no convergence or predictable behavior with respect to NTP. I stopped taking screenshots because of frustration.

4. Option [no screenshots]. UTC again, no daylight savings. I simply used the default servers. Again no convergence.

At last [Option 4] the should prove that there is something totally wrong with the NTP implementation in the Cisco switch. No matter what I do, the best permanent offset I can get is somewhere between 1000 and 1500 ms.

Grateful for any solutions.

Best regards,
Steffen

[Mr. S. (archive)]

Dear pietrh,

in the meantime, case is with CISCO support. We found that apparently NTP communication breaks with unicast servers (even the default ones). Traffic protocol uploaded to support and is now under investigation.

BR

Steffen

[pieterh]

Hi Steffen,

thank you for your updates