[ntp:questions] Need help on NTP client

Gao gao at pztop.com
Tue Jul 28 18:49:35 UTC 2015


Today I moved my test box to my server room and have it connected to the 
same switch of our local ntp server. Then I mirrored the port and 
monitor from wireshark for port 123 on both side. Here are my observations:
1. "ntpdate -q" succeeded. I can see the NTP request from client and NTP 
response from server.
2. "systemctl restart ntpd" from the client will force my test 
box(client) send out NTP requests to multiple servers, including my 
local server. But on the local server side no NTP packet received.
3. nmap scan port 123 against the server succeeded. Both end works fine.
4. Both ntpd and ntpdate on my test box (CentOS7) is NTP4. My 
server(CentOS6) is NTP3.

I googled "NTP4 client with NTP3 server" and it doesn't seems having 
known issue. So I am thinking there may be something going on with my 
switch. The switch is a HP 24port 1810G (J9450A) switch running on 
firmware P.2.10. I found out there is a bug fix for a newer version 
P.2.13, the document says:

"SNTP
CR_0000142367 The switch might stop requesting SNTP updates after it 
receives a Kiss-of-Death (KoD) packet with an INIT or STEP code. After 
it receives such a packet, the switch should retransmit using an 
exponential backoff algorithm if no other NTP server is available, but 
instead, it stops requesting SNTP updates altogether."
Source: http://h20564.www2.hp.com/hpsc/doc/public/display?docId=c04722978

I am not total understand what this means. Is this related to my 
saturation? Since this switch is in production so I can't do the upgrade 
now. Maybe later today.


Gao




On 15-07-27 09:48 PM, Brian Inglis wrote:
> Hi Gao,
> I have not seen any output from commands like these posted.
> What are the results from the preceding working traceroute command, 
> the failing traceroute command, and the subsequent ntpdate commands?
>
> Do not expect NTP responses from traceroute commands, they only hit 
> the network layer, not the NTP server, and are intended only to 
> identify possible network filtering, when compared to the preceding 
> working generic traceroute.
>
> Similarly, the unprivileged port ntpdate command output compared to 
> the privileged port ntpdate command output may show where the network 
> is being filtered.
>
> It may be that all NTP traffic from that client is going via your 
> router which may block it, or it could be a switch rule.
>
> Check the routes on your working and non-working clients with netstat 
> -r, and change the non-working client if different.
> Check your IP addresses are unique by doing nslookup by name and 
> address, to ensure they map both ways to the same host:
> I have seen cloned systems using the same static IP address, which 
> really messes up traffic delivery!


-- 



More information about the questions mailing list