[ntp:questions] Reachable and rejected
david at ex.djwhome.demon.co.uk.invalid
Sat Sep 13 08:43:52 UTC 2008
Richard B. Gilbert wrote:
> What, if anything, leads you to believe that "server1" or "server2" are
> actually running NTP, are connected to the network, etc, etc?
That they respond to NTP queries with well formed responses, even if the
response indicates the time is too unreliable to use and in other ways
looks like a failing SNTP implementation attempt, which is not directly
connected to a reference clock.
The lack of response here is consistent with something that is not the
reference implemenation of NTP, but could be the result of network and
server security policies. To be honest, I would have been very
surprised if there had been a response, as the server is simply not
behaving in a way that is consistent with the reference implementation.
> What happens if you say:
> ping serveri
> ping server2
Total waste of time. We already know that something responds to those
addresses and a ping failure is very likely in the modern, paranoid, world.
Some basic SNMP queries are much more likely to be useful, as, if there
is a response, it will tell us what OS we are dealing with. Although my
original thought was Windows, I think that would have produced a
precision of -6. -7 suggests something with a 100Hz clock interrupt
rate, which is the typical Unix rate.
We could be dealing with a router, an appliance time server, or a weird
choice of NTP software on Unix. Although I believe that NTP should
indicate an unsynchronised state if the incoming root dispersion goes
excessive, I have seen an example here that seemed to contradict this,
so it is even possible that the real culprit is the stratum one server.
However, I think that the zero root delay is a strong clue that this
is an SNTP server operating outside the scope of SNTP, and possibly not
handling root dispersion validly.
> Getting a response to ping will show that they are connected to the
> network, have network software installed, etc, etc. If they respond to
> ping but not to nptq, that would suggest that ntpd is not running.
The respond to NTP client requests but not NTP management requests. No
need for the pings. Even the first word in the subject tells you that
they are responding to NTP!
More information about the questions