There are a couple of perhaps interesting places you may want to look at about Address Resolution Protocol (ARP): http://en.wikipedia.org/wiki/Address...ution_Protocol
and, maybe, https://supportforums.cisco.com/disc...lear-arp-cache
Something to know is what ARP does:
ARP is the process of resolving a mac address from an IP address. It is broadcasted to every host on the local subnet. The very purpose of an ARP cache, is to store the IP to MAC combination in the case that you might be sending traffic to that same host (IP/Mac address). Having the ARP cache allows you to not have to send an APR broadcast to every node on your local subnet, because you already have it in the cache!
Clearing the APR cache will cause all request that were in the ARP cache to go through the APR process again (if the node tries to communicate with them).
(from the second link above).
That is, it's local, not external.
This suggests a question or two: what does the server you're having a problem with use for DNS service (an external DNS server, BIND, a DNS server on you LAN, a DNS server in your router/switch)? It also suggests perhaps a large time difference between an external time source and your hardware or system clock (when NTP refuses to initialize it generally (but not always) means that your system clock is too far out of time for NTP to use it.
Looking at the result of your nptq -p
above I note that you do not have a local server defined; I'd suggest that you add one to the server area of your /etc/ntp.conf
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
# NTP server (list one or more) to synchronize with:
#server pool.ntp.org iburst
Defining a stratum 10 local clock lets NTP synchronize with itself when there is no external time source available (obviously, you would want to replace "us" in the above with "de").
Also, look at your start up for NTPD. Somewhere in the shell program that starts the daemon you should have a line that looks similar to this:
is important: it lets the first time adjustment to be big (if the system time offset is more than 1000 seconds NTPD will not synchronize, the -g
argument allows it to adjust the clock).
You may want to look at your hardware clock time (in the BIOS); the (software) system clock is set from the hardware clock on boot, NTPD synchronizes the system clock while you're running and on shutdown the system clock time is written to the hardware clock. If you've not been synchronized for some period of time your system clock may have drifted enough to more than then panic threshold (1000 seconds) which is subsequently saved to the hardware clock and when you reboot you're not going to get synchronized without the above -g
You can set the system time with ntpd
This sets the time (from your list of servers in /etc/ntp.conf
) and quits. You should shut down NTPD if it's running before doing this. The command mimics the behavior of the ntpdate
program (which will be retired). The important thing is that the servers are reachable; i.e., you can ping
"Reachable" means that you have a DNS server available so you can
ping -c 5 ntp1.server.de
ping: unknown host ntp1.server.de
Uh-oh: this ain't good. I should be able to ping those servers: let's try something different
ping -c 5 0.de.pool.ntp.org
PING 0.de.pool.ntp.org (184.108.40.206) 56(84) bytes of data.
64 bytes from belgarath.bunkus.org (220.127.116.11): icmp_seq=1 ttl=40 time=1404 ms
64 bytes from belgarath.bunkus.org (18.104.22.168): icmp_seq=2 ttl=40 time=1121 ms
64 bytes from belgarath.bunkus.org (22.214.171.124): icmp_seq=3 ttl=40 time=688 ms
64 bytes from belgarath.bunkus.org (126.96.36.199): icmp_seq=4 ttl=40 time=716 ms
64 bytes from belgarath.bunkus.org (188.8.131.52): icmp_seq=5 ttl=40 time=715 ms
--- 0.de.pool.ntp.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4044ms
rtt min/avg/max/mdev = 688.596/929.138/1404.677/287.131 ms, pipe 2
Are your server addresses LAN addresses? If so, that explains why clearing the ARP cache got you going; you forced it to go through the ARP process again, ARP has nothing to do with external addresses.
So, anyway, that's a long, round about way of getting to what may be your problem.
Hope this helps some.