This topic is to discuss the following lesson:
1 Like
Great job Rene…thanks for add this topic in our lesson we will enjoy with this…
Thanks & Regards,
Arindom
Cant wait to dive into this lesson once I put my daughter to bed tonight!
Hi Scott,
Sorry didn’t reply you last day i went to bed at same time 
Hope you are doing good…
Thanks & Regards,
Arindom
2 Likes
Hello,
I am a bit confused using NTP over IPv6. This lesson and the Cisco documentation, states that NTPv4 adds this capability. However, in my lab i was able to use it with NTPv3.
R2#sh run | s ntp
ntp server 2A12::1 version 3
R2#sh ntp associations
address ref clock st when poll reach delay offset disp
*~2A12::1 127.127.1.1 3 9 128 377 3.950 -10.232 2.610
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
R2#sh ntp associations detail
2A12::1 configured, ipv6, our_master, sane, valid, stratum 3
ref ID 127.127.1.1 , time E62F2054.468B1A4C (07:35:48.275 UTC Wed May 18 2022)
our mode client, peer mode server, our poll intvl 128, peer poll intvl 128
root delay 0.00 msec, root disp 0.39, reach 377, sync dist 26.36
delay 3.95 msec, offset -10.2324 msec, dispersion 4.89, jitter 17.47 msec
precision 2**18, version 3
assoc id 35834, assoc name 2A12::1
assoc in packets 49, assoc out packets 49, assoc error packets 0
org time 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
rec time E62F2060.478E3275 (07:36:00.279 UTC Wed May 18 2022)
xmt time E62F2060.478E3275 (07:36:00.279 UTC Wed May 18 2022)
filtdelay = 14.85 27.25 16.03 23.64 15.97 39.84 3.95 12.36
filtoffset = 1.99 -7.86 0.96 6.20 -15.63 12.93 -10.23 -42.18
filterror = 0.00 0.03 1.97 2.00 4.02 4.05 6.03 6.06
minpoll = 6, maxpoll = 10
And also confirmed from a packet capture
Apparently IPv6 can be used with NTPv3. Am i missing something here?
1 Like
Hello Ilias
When we say that NTPv4 has some improvements that also support the IPv6 address family, we are not stating that only NTPv4 can be encapsulated within an IPv6 packet. In your packet capture, an NTPv3 packet is encapsulated within a UDP datagram, which in turn is encapsulated within an IPv6 packet.
The phrase “supports the IPv6 address family” simply means that some mechanisms and fields in the NTP header have been modified to take into account the use of IPv6 addresses, but this only refers to background processes such as MD5 hash generation, and the use of site-local multicast for IPv6, for example. Take a look at the NTPv4 RFC found below that details these changes:
Ultimately, you won’t see any particular change in the configuration of NTPv4 compared to NTPv3, even if you use IPv6 addresses, as you have done in your example.
It may also be helpful to take a look at this cloudshark capture that shows the communication of an NTPv4 client with an NTPv3 server:
https://www.cloudshark.org/captures/30ea2044f399
I hope this has been helpful!
Laz
Hello Laz,
many thanks for your reply. However, I still think that the documentation is misleading on this topic. From the below configuration guide:
It states that NTPv4 provides the following capabilities:
-
NTPv4 supports IPv6, making NTP time synchronization possible over IPv6.
-
Security is improved over NTPv3. The NTPv4 protocol provides a whole security framework based on public key cryptography and standard X509 certificates.
-
Using specific multicast groups, NTPv4 can automatically calculate its time-distribution hierarchy through an entire network. NTPv4 automatically configures the hierarchy of the servers in order to achieve the best time accuracy for the lowest bandwidth cost. This feature leverages site-local IPv6 multicast addresses.
The first bullet implies that NTPv3 doesn’t support IPv6 which is obviously not true. It is not even an advantage when comparing the 2 versions.
Also, I quickly went through the RFC for NTPv3 and there is not a single line for IPv6 support, which is even more confusing.
Anyway, I will stick to your reply which makes much more sense. Honestly, the details behind the scenes is beyond my scope for the CCIE lab. IPv6 is supported on both versions and it is not a key factor to pick one version over the other.
Thanks,
Ilias
2 Likes
Hello Ilias
I agree with you. I will let Rene know to take a look and make any necessary clarifications to the lesson.
Laz
1 Like
Hello Laz,
In data center environment , to sync servers do software sync is sufficient or hardware clock sync also needs to be added? finally we update hardware sync with software sync.
which is the best practice?
BR//
Nitin Arora
Hello Nitin
In general, whether in a datacenter or not, keeping hardware and software clocks synchronized is important. Depending upon the platform, you will find that the timestamp on Syslog events and other time-dependent monitoring uses the hardware clock. This is done because it is faster and more efficient, especially if you are logging information on a per-packet basis.
Now, synchronization between the hardware and software clocks should be implemented. This can be done using several commands.
The clock update-calendar command forces a single update to the hardware clock from the software clock. However, the ntp update-calendar command used by Rene in the lesson updates the hardware clock periodically with NTP. Actually, this command will periodically update the hardware clock with the time specified by the NTP source. The hardware clock will be updated only if NTP has synchronized to an authoritative time server. So it is generally best practice to ensure that the hardware clock is indeed periodically updated and synchronized with NTP as well as the software clock.
Take a look at this Cisco documentation for more information about this particular command.
For other platforms like Nexus, which are used extensively in datacenters, there are some best practices that can be applied according to the following documentation:
I hope this has been helpful!
Laz
1 Like