In this article, we take a look at the configuration for implementing NTP with authentication on Cisco IOS-XE devices, both for the NTP Server and NTP Client role, and take a look at common NTP topologies for different use cases.
Introduction
Time and date are essential components of any network (or IT environment, for that matter) that should be treated with the utmost importance. In the event of an incident or breach, correlating logs from various points of the network is crucial to decipher what has happened and in what order. If time and date is not properly synchronized time across the environment, troubleshooting can become very hard.
The Network Time Protocol, or NTP, is commonly used across the network to provide accurate and synchronized time and date. To enhance the use of NTP you should use authentication to make sure the time and date given to you comes from a valid (intended) NTP server.
One important thing to notice is that NTP can be enhanced with authentication, but not with encryption. For encrypted NTP communication, you will need a separate protocol to provide encryption, which we will not cover in this article.
The following hardware and software were used in this article:
Cisco Catalyst C9200L-48P-4X Switch running IOS-XE 17.9.4a (“Core”)
Cisco Catalyst C9200CX-12P-2X2G Switch running IOS-XE 17.9.4a (“Access”)
Common NTP Topologies
A proper NTP source can be one or several NTP GPS hardware servers deployed on your network that fetches time and date using GPS, or a set of public NTP Masters located near you that you can use to get time from. A common setup is to have one unit (like a core switch) inside your network get its time from an NTP Master, and then use that core switch to act as an NTP Server for other units (like access switches) in the network.
When multiple NTP Servers are configured in a Cisco device, it will pick the server with the lowest “stratum”, which in general should be the most accurate clock.
The difference between an NTP Master and an NTP Server is that NTP Master are considered authoritative (meaning they are believed to be accurate) and should be considered a valid time source, while an NTP Server is just any unit that others can query for time. You can say all NTP Masters are also NTP Servers, but not every NTP Server is an NTP Master.
If you have a proper NTP GPS hardware server in your internal network, you can configure NTP with authentication between it and your core switch, but if you are using public NTP Masters to fetch time you will probably not be using authentication between that NTP Master and your core switch.
However, you can still use NTP with authentication between your core switch and your access switches. This is the scenario we will take a look at in this article, while NTP communication between the core switch and the NTP Master will run without authentication.
If you have a Distribution layer, you can build a chain of NTP communication: Access switches gets time from Distribution switches, Distributions switches gets time from Core switches and Core switches gets time from an authoritative NTP source.
An important thing about NTP sources is that you should never have exactly 2 of them, it’s better to have only 1 (then every device has the same source, but without redundancy) or at least 3 (for proper quorum functionality in addition to redundancy).
One thing to note is that any Cisco switch that gets time from NTP automatically becomes its own NTP Server which other units can send NTP requests to to ask for time.
NTP Authentication Algorithm Options
There are several authentication algorithms to choose from in this version of IOS-XE to secure your NTP key with. If possible, I would choose one of the algorithms that uses SHA256.
Sometimes, mixing different switch models and software versions can cause you to have support for one algorithm on one switch, and another one on another switch.
Most switches should at the very least be able to use the MD5 algorithm. Although weak in terms of protection, it’s better than nothing.
In this article we will use the HMAC-SHA2-256 algorithm as it is one of the NIST-approved (link) authentication algorithms for NTP.
NTP Server Configuration (Core / Distribution Switch)
! Configure Time Zone and Summer-Time as needed:
clock timezone CET 1
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
! Configure Core Switch to fetch time using plain NTP from Public NTP Masters (Servers).
! You can use both IPv4 and IPv6 addresses, or hostnames (requires DNS configured):
ntp server 209.165.201.5
ntp server 209.165.201.6
ntp server 209.165.201.7
! If you are running VRFs, use the commands below instead:
ntp server vrf MGMT-VRF 209.165.201.5
ntp server vrf MGMT-VRF 209.165.201.6
ntp server vrf MGMT-VRF 209.165.201.7
! Configure Source interface for initiating NTP requests (same command if using VRFs):
ntp source Loopback0
ntp authenticate
ntp authentication-key 5 hmac-sha2-256 MYS3CR3TNTPK3Y!!
ntp trusted-key 5
NTP Client Configuration (Access Switch)
clock timezone CET 1
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
! Configure NTP Authentication Key to use between Core Switch and Access Switches:
ntp authenticate
ntp authentication-key 5 hmac-sha2-256 MYS3CR3TNTPK3Y!!
ntp trusted-key 5
! Configure Source interface for initiating NTP requests (same command if using VRFs):
ntp source Vlan 10
! Configure Access Switch to fetch time from Core Switch using configured NTP Key:
ntp server 10.10.10.1 key 5
Verification
Verifying NTP functionality can be done using various commands, but do note that it can take up to 20 minutes before the clock is updated in a Cisco switch.
Use the “show clock details” command to see what the clock is currently set to in the switch. Depending on the clock’s current state, a symbol may be preceding the time and date.
Asterisk (*) = time is NOT authoritative (probably not accurate/manually set)
Dot (.) = time is authoritative, but NTP is not synchronized
No symbol (blank) = time is authoritative (this is what we want!)
Use the “show ntp associations” to see which NTP servers the switch is configured to send NTP requests to, and which of them are actually being used by the switch. Use the various symbol explanations found at the bottom of the command output to help you:
Asterisk (*) = sys.peer (Time is currently synchronized to this NTP Server)
Hash (#) = selected
Plus (+) = candidate
Minus (-) = outlyer
Cross (x) = falseticker
Tilde (~) = configured
Use the “show ntp associations details” command for more details.
Use various forms of the “debug ntp…” commands to see NTP requests and responses in real-time. If you are waiting for a switch to synchronize its clock, wait until you see this log message:
Feb 19 09:02:09.618 CET: %PKI-6-AUTHORITATIVE_CLOCK: The system clock has been set.When you see this output, running “show clock details” again should now show the current time and date without any asterisk or dot in front of the clock.
Use the “show ntp status” command to confirm the synchronization of the clock to the NTP server.