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!
--
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
