How do I debug NTP not working?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

How do I debug NTP not working?

Not applicable

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

1 accepted solution

Accepted Solutions

Not applicable

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.

View solution in original post

7 REPLIES 7

L6 Presenter

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

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.

Not applicable

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

Not applicable

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.

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

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

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

  • 1 accepted solution
  • 18813 Views
  • 7 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!