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! -- Take care. Thanks, Brian Inglis On 2015-07-27 18:13, Gao wrote:
If you read my previous email you see all these tests you recommended works, except this one: traceroute -U -p 123 $other I think the reason is the server side don't response/echo back for UDP. But when I running this command on the CentOS7, I also running tcpdump at the server end amd it DOES received lot packets on port 123: [root@ovpn ~]# tcpdump -s0 port 123 and host 192.168.123.22 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:09:40.978465 IP 192.168.123.22.54055 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32 17:09:40.978495 IP 192.168.123.22.59641 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32 17:09:40.978503 IP 192.168.123.22.37803 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32 17:09:40.978513 IP 192.168.123.22.47468 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32 17:09:40.978519 IP 192.168.123.22.39741 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32 17:09:40.978525 IP 192.168.123.22.44615 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32 17:09:40.978531 IP 192.168.123.22.59443 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32 17:09:40.978566 IP 192.168.123.22.44037 > ovpn.sjv.lan.ntp: NTPv0, unspecified, length 32 I think this proves that the port 123 on server received packets from client. So the question is why the ntpd's NTP request to the server is lost somewhere, although tcpdump shows it sent out NTP request?
On 15-07-27 04:17 PM, Brian Inglis wrote:Hi, Check from each end to the other that: nslookup $other ping -c 5 $other traceroute $other traceroute -U -p 123 $other ntpdate -qu $other ntpdate -q $other all work - any failure compared to the previous result should point you to the source of the problem.
_______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
