Hi Peter,
stratum 0 in a network packet is possibly displayed as stratum 16, and
it's an indicator for a Kiss-o'-Death (KoD) packet.
A server can send KoD packets if rate limits have been configured at the server and a client polls the server too often.
Such packets should also have something like "RATE" as a refid, but the
refid in your packet trace is only displayed as "(unspec)", so we can't
see the real contents of the refid field.
Regards,
Martin
Peter Volkov wrote:
Hello,
Recently, our monitoring started alerting because the ntpd server intermittently returns the error Leap indicator: clock unsynchronized (192).
Our monitor is a Python script (similar to this example https://www.mattcrampton.com/blog/query_an_ntp_server_from_python/)
that queries the NTP server and checks the response time.
I captured packets with tcpdump and see that most responses return
correct time, but some return this unsynchronized leap indicator with
zero timestamps:
ion 009:37:48.443219 IP (tos 0x0, ttl 62, id 6086, offset 0, flags [DF],
proto UDP (17), length 76)
10.254.253.100.34106 > 10.254.253.1.123: [udp sum ok] NTPv3,
Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precis=
spec)Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (un=
spec)Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 0.000000000
09:37:48.443280 IP (tos 0xb8, ttl 64, id 2192, offset 0, flags [DF],
proto UDP (17), length 76)
10.254.253.1.123 > 10.254.253.100.34106: [bad udp cksum 0x10ac -> 0xe3de!] NTPv3, Server, length 48
Leap indicator: clock unsynchronized (192), Stratum 0
(unspecified), poll 3 (8s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (un=
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 0.000000000
(377):Ntpd logs look normal, no obvious errors, and ntpq -p shows stable
peers with normal offsets (~7 ms), stratum 2=E2=80=933, and good reach =
jitterntpq> pe
remote refid st t when poll reach delay offset=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3.463-185.116.194.200 80.241.0.72 2 u 15 64 377 40.310 +25.548 =
2.112*boris.esilnet.k 194.190.168.1 2 u 6 64 377 32.532 +6.037 =
1.870+nntp.hoster.kz 80.241.0.72 2 u 9 64 377 43.705 +16.318 =
3.344+time.cloudflare 10.199.8.4 3 u 11 64 377 23.630 +7.168 =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dntpq> as
ind assid status conf reach auth condition last_event cnt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
.64.46,1 59040 933a yes yes none outlier sys_peer 3
2 59041 966a yes yes none sys.peer sys_peer 6
3 59042 944a yes yes none candidate sys_peer 4
4 59043 941a yes yes none candidate sys_peer 1
ntpq> rv
associd=3D0 status=3D0615 leap_none, sync_ntp, 1 event, clock_sync, version=3D"ntpd 4.2.8p17@1.4004-o Sun Apr 14 17:08:41 UTC 2024 (1)", processor=3D"x86_64", system=3D"Linux/6.12.31", leap=3D00, stratum=3D3, precision=3D-24, rootdelay=3D84.000, rootdisp=3D42.497, refid=3D176.108=
tc=3D6,reftime=3Dec18df02.e7f4a192 Wed, Jul 9 2025 12:28:50.906, clock=3Dec18e095.7cf33ecf Wed, Jul 9 2025 12:35:33.488, peer=3D59041,=
73,mintc=3D3, offset=3D+7.088290, frequency=3D-18.999, sys_jitter=3D9.1608=
clk_jitter=3D21.942, clk_wander=3D0.501
ntpdate against a public pool confirms time difference is just a few milliseconds.
The server time is correct and stable. Still, this leap unsynchronized response appears occasionally.
What else should I check to understand why ntpd suddenly starts
returning this error? Any ideas what conditions cause this partial unsynchronized state? How to debug it further?
Thanks in advance.
--
Peter.
--
Martin Burnicki
Senior Software Engineer
Email: martin.burnicki@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/
MEINBERG Funkuhren GmbH & Co. KG
Lange Wand 9
31812 Bad Pyrmont, Germany
Registry Court: Amtsgericht Hannover 17 HRA 100322
Managing Directors: Natalie Meinberg, Daniel Boldt, Andre Hartmann,
Heiko Gerstung
Websites: https://www.meinberg.de https://www.meinbergglobal.com
Meinberg - The Synchronization Experts.
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 1,064 |
Nodes: | 10 (0 / 10) |
Uptime: | 148:08:46 |
Calls: | 13,691 |
Calls today: | 1 |
Files: | 186,936 |
D/L today: |
33 files (6,120K bytes) |
Messages: | 2,410,932 |