NTP troubleshooting can involve checking configuration settings in ntp.conf, basic network connectivity and firewalls. Sometimes the problem is immediately apparent, but not always. While attempting to set up one XenServer 5 system as the NTP server for others (rather than having all of them contacting NTP servers on the Internet, and writing broader firewall rules to support that), I bumped into the following problem.
- The client system can
pingthe NTP server.
- No network switch is imposing an ACL, nor is there a firewall between the two systems.
- A diagnostic check with
ntpq -preveals the following:
ntpq: read: No route to host
Quite the misleading error message! Obviously the ping test proves that there is indeed a route to the host, so what could this mean? Although there was no network-based firewall between the two hosts, it turns out that XenServer 5 enables iptables by default. The last line of output from iptables -L shows:
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
In glibc, the
ICMP_UNREACH_HOST_PROHIB message is translated to an
EHOSTUNREACH error and reported as “no route to host”, regardless of the real underlying cause. If the last rule did not have the special reject-with clause, the rejection would have defaulted to icmp-port-unreachable, which in turn would translated to
ECONNREFUSED, and a resulting error message that would have provided an immediate clue. To resolve the issue, the host-based firewall must be disabled (not recommended) or extended with rules to allow NTP traffic. I added rules as follows:
# iptables -nL -v --line-numbers ... [Output will show where the rules can be inserted.] ... # iptables -I RH-Firewall-1-INPUT 13 -p udp --dport 123 -j ACCEPT # iptables -I RH-Firewall-1-INPUT 14 -p tcp --dport 123 -j ACCEPT # service iptables save
The last command writes the currently installed rules to /etc/sysconfig/iptables so that the rules persist across restarts of iptables or system reboots.
After this, NTP started functioning normally.