[ntp:questions] [Solved!] Re: Need help on NTP client
Gao
gao at pztop.com
Tue Jul 28 19:55:51 UTC 2015
So it is the switch blocked all NTP packets.
I upgraded the HP J9450A switch to newest firmware and it still not
working. Then I found this article talking about the exact issue:
http://louwrentius.com/hp-procurve-auto-dos-feature-causing-network-problems.html
"If you enable the Auto DoS feature, traffic is blocked based on one of
these conditions:
--the source port (TCP / UDP) is identical to the destination port (NTP,
SYSLOG, etc)
--the source port (TCP / UDP) is 'privileged' thus in the range of 1
-1023. "
After disable the stupid "Auto DoS" on the switch, now the NTP finally
works!
Thank you everyone for the help.
Gao
On 15-07-28 11:49 AM, Gao wrote:
> 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