ntp starts working when restarting arp
 

Hi.

I had an issue with one of myservers who didnt want to sync its clock using ntp.

Prior solving the proplem the ntpq status was as below:


In other words, the systen couldnt reach the ntp servers but strange thing was that i could ping and querry the ntpservers without any problems. I found a forum where the guy had a similar problem and he sort it out by clearing the arp cache.

I tried it and it worked for me as well! So as soon i cleared arp table and restarted the ntp everything worked just fine. Thing is that the post was very old and the guy didnt bother to provide further explaination hence i am left with the though "WHY"



How could the ntp corelate with the ntp?
Why when clearing arp ntp works?


Any ideas?

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:
(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 file:
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:
The -g 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 argument.

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 them.

"Reachable" means that you have a DNS server available so you can
Uh-oh: this ain't good. I should be able to ping those servers: let's try something different
That's better.

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.

OK ... so the issue was caused by two main reasons:

1) ntp was configured to operate with IPv6
2) the server for some reason lost its IPv6 gateway hence couldnt communicate to other ntp servers



Solved by switching ntpd to operate with ipv4