This topic is to discuss the following lesson:
Hi
Due to high root dispersion , NTP clock and local clock have a time difference . Please suggest how to troubleshoot root dispersion .
Hello Sumit
Root dispersion is a rough estimate of of how much the local time has drifted away from some reference time. This reference time is often referred to as the root source. Root dispersion occurs when there is some malfunction in the time source. A disruption in service or a bad network connection can cause a steady increase in root dispersion. For Cisco IOS devices, any root dispersion in excess of one second will cause an NTP association to fail.
Root dispersion is also included in NTP updates so that NTP clients receiving them can choose to use them, or ignore them in favour of another NTP server.
In any case, root dispersion is not something that you can deal with directly from the local device. If you are experiencing problems with root dispersion, the best thing to do is to choose another time source. If the time source you are using is administrated by you, then you should troubleshoot that time source and verify that it is functioning correctly.
Root dispersion will also be seen in special cases where Cisco IOS devices are attempting to gain NTP information from Windows Active Directory. This is further detailed in the following Cisco documentation:
I hope this has been helpful!
Laz
1 Like
Hi,
I’m a bit confused about some NTP issues on my GNS3 lab.
on R1 ( NTP MASTER ):
ntp authentication-key 1 md5 <xxxxx> 7
ntp authenticate
ntp trsusted-key 1
ntp master 1
on R2:
clock set 00:00:00 01 jun 1996
ntp server X.X.X.X
I’m expecting on R2 nothing happen but it syncronize the clock with the master…
I saw with “debug ntp packets” comand.
How can It be possible?
Thank you
Hello Giovanni
One of the most common misconceptions of NTP authentication is the direction of authentication. By configuring authentication on the NTP master, what you have done is to configure R1 to synchronize only to systems providing the authentication key 1 in their NTP packets. In other words, R1 will synchronize (as a client) to any NTP server that has the configured authentication key. This configuration does not affect R2 synchronizing with R1, but affects R1 synchronizing with some other source.
If you configure authentication on R2 and not on R1, then you will see that synchronization will not occur, which is the scenario you are trying to reproduce here. To get authentication to function between these two devices, you will have to configure authentication on both devices.
I hope this has been helpful!
Laz
2 Likes
Hello Rene/Laz,
I have a question about NTP which i’ve not been able to find an answer to in the config guides.
Let’s say R1-R2 have formed an NTP association. R1 is then configured with ntp access-group serve-only 2 - see ACL details below. In this case the IP address of R2 does not match access-list 2 on R1. What is the expected behaviour of R2 in terms of its association?
When labbing this I was expecting that R2 would tear down the association, but R2 actually continues to maintain it. Is it the case that R2 would simply no longer receive any more replies from R1 for NTP requests due to being filtered by the access-group, but it will still maintain its system clock which was previously set by R1? And over time it might become more inaccurate due to not receiving any more NTP updates from R1 ect…
R1: 192.168.12.1
R2: 192.168.12.2
access-list 2 permit 192.168.12.22
edit: Ok so after some time (approx 8/9 ntp requests later) R2 did finally move to unsynchronized and removed R1’s IP as its reference. Looks like it takes some time.
Thanks
Hello Bhawandeep
Thanks for updating your post and letting us know of the results of your experimentation. Just to add to your conclusions, NTP uses what is known as a poll timer. If you issue the show ntp association command, you will see a column titled poll. This will have a value somewhere between 64 and 1024 seconds. This is the interval with which NTP associations are “refreshed” so to speak, or polled. This value is actually dynamic and it is not possible to adjust it. It is based on various parameters including network conditions and lost NTP packets. If an NTP device is unreachable for some time, the poll interval is increased to conserve network bandwidth.
The detailed methodology used to set this poll interval is further described in RFC 5905.
https://datatracker.ietf.org/doc/html/rfc5905#page-51
I hope this has been helpful!
Laz
Thanks Laz. I will try this again and observe the poll value.
On a related note, I noticed during authentication mismatch, or even when authentication is only configured on the client (and not server), despite seeing the client ntp status as unsynchronised, stratum 16, insane, invalid, I still see the word authenticated. Perhaps this is an IOL bug.
R2#show ntp associations detail | include sane
192.168.12.1 configured, ipv4, authenticated, insane, invalid, unsynced, stratum 16
R2#show ntp status | inc sync
Clock is unsynchronized, stratum 16, no reference clock
R1#show run | sec ntp
ntp master 3
!
R2#show run | sec ntp
ntp authentication-key 1 md5 14343B382F2B 7
ntp authenticate
ntp trusted-key 1
ntp source Ethernet0/0
ntp server 192.168.12.1 key 1 source Loopback0
As you mentioned, the direction of NTP authentication is server to client. We are authenticating the source. So R2 should not sync with R1, and it doesn’t. But I’m not sure why R2 still displays authenticated. I got the same results when R1 was using authentication but with a different key value to that on R1.
Hello Bhawandeep
NTP can sometimes be a pain when you want to update associations. Often, the indicators are not up to date, and resetting may be necessary. After doing some research, and doing some labbing, I have found that in such situations, it may be helpful to remove and re-add the server command.
Alternatively, in order to determine exactly what the NTP state is and why, take a look at the NTP troubleshooting and debugging tools NetworkLessons note.
I hope this has been helpful!
Laz
1 Like