How do I debug NTP not working?

[ddaniels]

(active)> (active)> show ntp

NTP state:
NTP synched to LOCAL
NTP server secondaryNtpIp connected: False
NTP server primaryNtpIp connected: False

I tried debug software restart ntp, waited a while and got the same results. The time's off my system clock by less than a minute.

[panos]

Hi,

seems it is not connecting to your NTP Local.

if it is not mandatory for you use pool.ntp.org and try again.

Do you have service route configured ? Do you use management interface or other for Ntp ?

Also check

https://live.paloaltonetworks.com/docs/DOC-3684

[ddaniels]

Hi,

I'm using the management interface, the routing is working and I'm specifying internal IP's that I've verified are working for other things.

Thanks.

[ddaniels]

For the systems I'm working on right now. The active PA in the HA group is marked as synchronized, the passive PA still isn't, though the passive PA's time matches my local systems time. I can see that by issuing:

show clock

[ddaniels · Accepted solution]

I don't know why, but I fixed this issue by referencing a slightly more stable clock, and switching to only reference that clock.

When in HA mode and having auto-updates, it's important to have updates apply at the same time so both systems should be synchronized to a high stability, low latency, low jitter to access clock.

[mikand]

How much did the box who didnt like to sync to NTP differ from realtime? If im not incorrect the NTP process usually refuse to sync the time if it differes more than 2 hours or something like that. To fix this you must first manually set the clock somewhat close to realtime and then start the NTP process (or make sure that ntpdate is being used during boot to set the clock "hard" before the ntpd client starts).

[ddaniels]

I don't recall exactly now. If there was a difference it was less than a few seconds with a low jitter and a low reach (time servers were local, their were local stratum 4, low jitter, low reach, the source clocks sources during testing were low jitter, low reach, stratum 3).

http://doc.ntp.org/4.1.2/miscopt.htm says the tinker panic is 1000 s.

For authentication related issues http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Clock-Skew.html says "the default value for maximum clock skew is 300 seconds, or five minutes".

Additionally many machines won't synchronize if the stratum is higher than 9. There's also considerations like jitter and reach.

Manually adjusting time on an ntp server can cause all it's clients to see high jitter and should be avoided. There's mechanisms in place by ntp to skew time in the right direction if allowed (see things like ntp reference above).

[mikand]

Setting the time manually was on the box running the ntp client (in case my previous post was confusing