Hello
I tried to send a courtesy email to ask AT ntp DOT org let someone know that 2.uk.pool.ntp.org is not responding to pings. The other servers with prefixes of 0, 1 and 3 appear to be responding to pings normally. However, the message was undeliverable to due a “user unknown” error.
Having explored the ntp.org website, this is the only email address I could find. Does anyone happen to know the correct email address I should use to report this issue?
Many thanks.
Are you saying none of the servers in 2.uk.pool.ntp.org respond to ping, or none of them respond to NTP queries? Only the latter is required.
From outside the UK, at least one IP is a working NTP server for me. (I didn’t check all of them.)
I don’t think Ask has an ntp.org email address. The NTP and NTP Pool projects are operated separately except for the ntp.org domain name.
Edit: And there about 200 active IPv4 servers and 100 active IPv6 servers in the uk zone; presumably almost all of them work.
Let me point out, 2.uk.pool.ntp.org is not a singular server. You got assigned a random volunteer run server for your ping, and it isn’t obligated to respond to pings.
The “2.” at the beginning is also the only way to get IPv6 servers assigned. Does your IPv6 connectivity work?
Hi mnordhoff
None of the servers in the pool appeared to respond to ping. I wasn’t aware that this isn’t a requirement, and was just trying to let someone know as a courtesy. If it isn’t an issue then fair enough.
I’m configuring an IoT router with all four pools as NTP sources, so provided they’re responding to NTP queries, then all should be good. 
Hi Badeand
Thanks for taking the time to reply. I’m aware that the address relates to a pool as opposed to a singular server. I was just surprised that I was able to ping the other addresses but not this one. If this isn’t an issue then I’m happy to accept that. I’m just of the mindset that if there is a potential problem I’d rather report it than assume that someone else has done so.
I’m only working with IPv4 connectivity at present so will check IPv6 connectivity when required.
One of my NTP servers (outside UK) receives around 50 ICMP echo requests per second, just because some people think it’s a good idea to check connectivity to NTP servers (or to the Internet in general) by pinging them. I have ended up blocking pings to my NTP servers, and I might not be the only one.
Trying to understand/wanting to learn (to see whether I should take similar action):
What were the issues that those ICMP echo requests were causing?
You can check availability of an NTP server by this web address:
It may not respond ping but can still serve as NTP server (udp 123), acctually most NTP’s work that way
I didn’t previously pay attention to this and notice anything, but taking an explicit look indeed shows some noticeable ICMP Echo Request background traffic. Without in-depth analysis, just eyeballing iftop output, this seems to typically be around 10-15 kbit/s, sometimes briefly exceeding 30 kbit/s.
The pattern seems interesting as well, e.g., same ID values from different sources (Linux ping by default sets this randomly, Windows ping seems to have a constant, version-specific value according to Wikipedia), or constant sequence numbers from individual sources (mostly 0, sometimes 1 or 3, other values seem rare). Sometimes alongside NTP requests, sometimes without simultaneous NTP traffic from a source (though again just observing for short time windows).
So seems not so much (human) users manually troubleshooting specific connectivity issues, but some sort of automated ping generation for unknown purposes (connectivity probes, heartbeats, keep-alives, destination probing, …).
At the same time, I am personally always happy when a destination responds to (manual) ping probes when I need to troubleshoot connectivity issues. And compared to the other traffic, mostly NTP at between 2Mbit/s and 12Mbit/s and above, the ping traffic doesn’t noticeably affect my exceeding my monthly uplink traffic quota (I have crossed having consumed half my quota last night, so one way or another, I will have to reduce my bandwidth setting before the month is out).
Also, responding to pings seems relatively light-weight for the machine compared to other tasks, foremost the NTP server daemon, but also stray HTTP connections/connection requests and other random (assumed) scanning activities.
So I decided to not introduce any restrictions on ICMP pings at this time - for now. YMMV.
Though I will monitor the situation, and still would be interested in background info from other people as to potential technical reasons why it might be a good idea to block incoming ICMP pings.
Hahah, what are the odds, pool responds to pings, except on 2.pool.ntp.org.
C:\Users\Badeand>ping pool.ntp.org
Pinging pool.ntp.org [193.150.22.36] with 32 bytes of data:
Reply from 193.150.22.36: bytes=32 time=23ms TTL=56
Reply from 193.150.22.36: bytes=32 time=23ms TTL=56
Reply from 193.150.22.36: bytes=32 time=21ms TTL=56
Reply from 193.150.22.36: bytes=32 time=22ms TTL=56
Ping statistics for 193.150.22.36:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 21ms, Maximum = 23ms, Average = 22ms
C:\Users\Badeand>ping 2.pool.ntp.org
Pinging 2.pool.ntp.org [83.109.34.152] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 83.109.34.152:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Users\Badeand>ping 1.pool.ntp.org
Pinging 1.pool.ntp.org [80.89.32.121] with 32 bytes of data:
Reply from 80.89.32.121: bytes=32 time=48ms TTL=51
Reply from 80.89.32.121: bytes=32 time=48ms TTL=51
Reply from 80.89.32.121: bytes=32 time=48ms TTL=51
Reply from 80.89.32.121: bytes=32 time=48ms TTL=51
Ping statistics for 80.89.32.121:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 48ms, Maximum = 48ms, Average = 48ms
C:\Users\Badeand>ping 3.pool.ntp.org
Pinging 3.pool.ntp.org [162.159.200.1] with 32 bytes of data:
Reply from 162.159.200.1: bytes=32 time=27ms TTL=57
Reply from 162.159.200.1: bytes=32 time=27ms TTL=57
Reply from 162.159.200.1: bytes=32 time=27ms TTL=57
Reply from 162.159.200.1: bytes=32 time=27ms TTL=57
Ping statistics for 162.159.200.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 27ms, Maximum = 27ms, Average = 27ms
C:\Users\Badeand>ping 0.pool.ntp.org
Pinging 0.pool.ntp.org [80.203.110.169] with 32 bytes of data:
Reply from 80.203.110.169: bytes=32 time=26ms TTL=58
Reply from 80.203.110.169: bytes=32 time=26ms TTL=58
Reply from 80.203.110.169: bytes=32 time=26ms TTL=58
Reply from 80.203.110.169: bytes=32 time=26ms TTL=58
Ping statistics for 80.203.110.169:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 26ms, Average = 26ms
My servers are also responding to pings. As long as they cope and don’t exceed the bandwidth caps, I don’t see a problem.
Like the previous posters said, response to the ping command is not necessary, the pool just requires responses for ntp requests.
For me, I don’t get responses to ping but the server provides seemingly valid time:
gunnar@dev:~$ sudo ntpdate -qvv 83.109.34.152
24 Jun 12:50:14 ntpdate[27275]: ntpdate 4.2.8p10@1.3728-o Sun Feb 25 21:22:56 UTC 2018 (1)
server 83.109.34.152, stratum 2, offset 0.000198, delay 0.05815
I am one of said previous posters. I just found it to be an absurd coincidence that I got the same ping results as OP.
True. Then again, nobody claimed it was. It’s just a tool that can help troubleshoot certain issues.