Configuring NTP on a Cisco Device

Configuring NTP on a Cisco Device

UPDATED: 7/7/2023

Configuring NTP on a Cisco device is an easy, and essential, step when configuring a new router or switch. Why, you might be asking? One example is that SYSLOG log entries are all stamped with the time. If the time is off from device to device it will make t-shooting events and event correlation that much more difficult. So, the solution is to use NTP, or Network Time Protocol, and synch all of your network devices to a common time source. Additionally, many other networking services rely on network devices to be in sync. Devices stay in sync by using NTP to periodically poll a time source for the time.

First a little bit about NTP

NTP stands for Network Time Protocol and uses UDP port 123. Currently, there are four versions of NTP, with v4 being the most recent. However, v3 and v4 are both widely accepted, with v4 being backward compatible with v3. NTPv4 is defined in RFC 5905, and NTPv3 is defined in RFC 1305.

As stated previously, NTP utilizes UDP to share time stamps. The time stamps are basically counting the number of seconds from a known point in time. There is no data around timezones or anything like that shared in NTP timestamps. Time zones are configured locally on the client device, generally speaking, and then the client device does the math to display the human friendly version of the time.

Sources of Time

Around the world there are many atomic clocks that keep very accurate track of the time. In short they super cool atoms to slow them down and then measure the atoms vibrations using lasers. Crazy huh?!?

NTP uses stratums to define how far away from an atomic clock a given NTP server is. A device getting it’s time directly from an Atomic Clock is said to be stratum 1. A device getting its time from a Stratum 1 server is a Stratum 2, or 1 hop away. The stratum is important because using the stratum NTP can make corrections and align itself more closely with an atomic clock, so that regardless of the stratum level your device is getting it’s time from all devices will be within milliseconds of one another, and that’s some pretty accurate time!

Time Source Options

So, what are your time source options? Simple, you can go direct to the source and connect to a NIST time server. NIST is the National Institute of Standards and Technology and manages several Atomic clocks in the United States, and collaborates with other standards organizations around the world. You can use time.nist.gov to sync to your nearest NIST time server.

Another popular time source is pool.ntp.org, which is the home for the Network Time Foundation, creators of NTP.

And of course, Google is in on the action too! You can also use time.google.com and get your time from the atomic clocks located in Google’s data centers around the world!

In a Windows based network you can use any Domain Controller. Any Domain Controller in a domain get’s it’s time using NTP from the PDC Emulator. In larger AD Forests the PDC Emulator in a child domain get’s it’s time from any DC in a parent Domain or the PDC Emulator of the Root Forest Domain. The Root Forest Domain PDC Emulator then syncs with an external time source, by default it uses the Microsoft hosted time server of time.windows.com. (Note this all happens by default and does not need to be configured)

Finally, you can configure Cisco devices to act as a time servers, also known as NTP Masters, on your network. Then point all other devices to the NTP Masters to sync. It’s not uncommon for core switches or routers to be configured as NTP Masters with all other network devices pointing to them for their time.

In larger networks regional NTP Servers may be appropriate.

NTP Client Config

By default the clock on a Cisco device uses Universal Coordinated time as its default time zone. I’m very familiar with UTC but when I’m looking through logs and such I prefer to see local time. So, let’s start by setting my timezone.

switch(config)#clock timezone EST -5

Clock timezone and then a WORD. This word should be something meaningful for you so you know the timezone you’re setting. For me, I used EST because I am in the Eastern Standard Timezone. Then, set your offset in hours from Universal Coordinated Time. Not sure what your offset is? Check here.

Next, let’s configure Day Light savings time. The commands will be similar:

switch(config)#clock summer-time EDT recurring

So just as in the above command the syntax is looking for a WORD after ‘summer-time.’ This should be something meaningful to you as an administrator, so the Daylight equivalent abbreviation for your time-zone. The recurring lets the device know that daylight savings time happens regularly and without any other input it will follow the normal start and stop for daylight savings time.

Next, before we attempt to sync up with an NTP server we need to set the time manually to within pretty close to the current time. Otherwise, in my experience, if the current time on the device is years, or decades, off from the current time a sync may never happen.

switch#clock set 12:00:00 1 AUG 2019

So the above command sets the date and time to noon on August 1st, 2019. Adjust your command accordingly. I like to set the time to within 10 minutes of the time on my PC, this way when synchronization occurs the time will change and it is apparent that something has happened.

So, now it’s time to set our NTP Server. If you have the IP Address of your preferred time source you can set it using the following command:

switch(config)#ntp server 198.111.152.100

Alternatively if you wanted to use a FQDN like time.nist.gov or pool.ntp.org you’d need to set up DNS servers first, and make sure ip domain-lookup is enabled. To configure DNS servers use the command ip name-server followed by the IP(s) of the DNS server you’d like to use. I like to use Cisco Umbrella DNS servers so the command looks like this:

ip domain-lookup
ip name-server 208.67.222.222 208.67.220.220
ntp server time.nist.gov

To check and see if your work was successful you’ll use the command ‘show ntp status’ and get an output that looks like this:

switch#show ntp status
Clock is synchronized, stratum 5, reference is 10.1.1.10
nominal freq is 286.1023 Hz, actual freq is 286.0962 Hz, precision is 2**20
ntp uptime is 232331300 (1/100 of seconds), resolution is 3496
reference time is DD7CD87B.1D86F11B (11:23:39.115 EDT Mon Oct 2 2017)
clock offset is -48.4549 msec, root delay is 131.86 msec
root dispersion is 314.69 msec, peer dispersion is 15.63 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000021145 s/s
system poll interval is 1024, last update was 6009 sec ago.

The key word you’re looking for is in the first line of the output is “synchronized.” If you see that then you’re clock is synchronized. You can also do a show clock to get the current date and time and it now should be spot on with your local computer, smart phone, or just about anything else connected to the internet.

Now, in my personal experience I have had occasion where when I do a show ntp status the status says “unsynchronized,” but in fact the time has changed and is accurate. I’m not sure why devices do this. But, I usually just find another source and then the next time it syncs right up.

Here is all the above code rolled all together for your viewing pleasure:

switch(config)#clock timezone EST -5
switch(config)#clock summer-time EDT recurring 
switch#clock set 12:00:00 1 AUG 2019
switch(config)#ntp server 198.111.152.100
switch#show ntp status

NTP Server Configuration

Cisco devices can serve as NTP servers, also known as NTP Masters. An NTP Master can utilize either an upstream NTP clock or it’s own internal hardware clock – which may be useful if you’re working in a lab setting not connected to the internet.

A note about hardware clocks. Hardware clocks are dedicated chips onboard the device motherboard that keep track of the time and carry it through power outages – as long as the BIOS battery is good. If the battery is bad the hardware clock will reset after loss of power.

Upon initial boot up the software clock gets it’s time from the hardware clock until it has a chance to pool the configured NTP server. You can tell IOS to update the hardware clock utilizing the configured NTP Server but using the command ntp update-calendar.

First, configure you NTP server as an NTP client to get it’s time from an upstream NTP server, such a public facing one described earlier.

R1(config)#clock timezone EST -5
R1(config)#clock summer-time EDT recurring 
R1(config)#ntp server 216.239.35.12

Now, do a show ntp status to get the stratum level of the upstream source:

#show ntp status
 Clock is synchronized, stratum 2, reference is 216.239.35.12
 nominal freq is 250.0000 Hz, actual freq is 250.0010 Hz, precision is 2**22
 ntp uptime is 154300 (1/100 of seconds), resolution is 4000
 reference time is E0EEB4D4.9B754904 (13:10:44.607 UTC Fri Aug 2 2019)
 clock offset is 2.5880 msec, root delay is 36.14 msec
 root dispersion is 9.13 msec, peer dispersion is 4.20 msec
 loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000004214 s/s
 system poll interval is 64, last update was 52 sec ago.
 R1#

Notice on the first line it says “stratum 2.” Using this information we can configure R1 as a stratum 3 time server, because it’s time source is a stratum 2.

R1(config)#ntp master 3

Now we can use the IP address of R1 as the ntp server on our other devices.

NTP Peers

So far we have NTP server which is used to activate the NTP client on an IOS device. Multiple NTP Servers can be identified. You can even use the keyword prefer to give preference to your preferred time source.

ntp server 192.168.254.1 prefer

NTP Master activates the IOS device as an NTP Time source or server to other devices on the network.

NTP Peers can serve both roles. When an NTP peer is identified you’re telling IOS to use this device as another NTP source, and to keep time in sync with each other. If you have multiple NTP Masters in your environment you should have them peer with one another so all of your time sources stay in sync.

Securing NTP

Like anything else NTP should be secured. In the past NTP has been utilized in DDoS attacks. In IOS you can secure NTP utilizing ACLs and NTP Authentication.

NTP Authenticationn

You can use NTP keys to authenticate clients with NTP servers. First you create the key, enable NTP authentication, and then associate the key with the NTP server.

!On the NTP Master
R1(config)#ntp authenticate
R1(config)#ntp authentication-key 1 md5 NTPp@ssw0rd
R1(config)#ntp trusted-key 1
! On a NTP Client
SW1(config)#ntp server 192.168.254.1 key 1

The first line – ntp authenticate – enables NTP authentication in IOS. Next, you define a key to be used. Multiple keys can be defined and used with different sources.

NTP trusted key identifies the key an NTP Master will look for in packets coming from downstream NTP clients looking to sync with it.

The NTP server command identifies the server and key that should be used with that server in order to successful learn the time.

NTP Access Lists

You can define a standard ACL that will be used to tell the NTP Master to allow NTP traffic from a defined range of clients. Then you can further restrict the actions allowed from the network identified in the ACL.

! Define the ACL
R1(config)#access-list 5 permit 192.168.254.0 0.0.0.255
! 
R1(config)#ntp access-group <option> 5

The NTP access-group command has many options: (From the Cisco Documentation)

ipv4 – configures IPv4 access lists.

ipv6 – Configures IPv6 access lists

peer – Allows time requests and NTP control queries, and allows the device to sync itself to a device in the defined ACL

serve – Allows ONLY time requests and NTP control queries.

serve-only – Allows only time requests

query-only – Only allows NTP control queries.

Changing How Time is Displayed in your Logs

We aren’t done just yet. If we want the local time to be displayed in the logs, and even the timezone identifiers we created earlier, we have to modify the timestamp service. We do that using the following command:

service timestamp dateimte msec localtime show-timezone

Let’s break it down:

“service timestamp” addresses the Timetamping service. The following are optional attributes.

datetime – displays the date and time in the timestamps. The alternative is the “uptime” which is the number of seconds since the last boot. Since the date and time is what we are focusing on let’s go with that.

msec – is milliseconds. This is optional, but it will display the time down to the millisecond. Since things tend to happen very fast I like to see time down to the millisecond.

localtime – this displays the local time, rather than UTC. Now, if you work in a large network environment it might be easier to use UTC when t-shooting issues across timezones.

show-timezone – Remeber those identifiers we configured earlier? Using this option will display those in the the timestamps.

In Summary

Configuring accurate time is an essential part of networking. Accurate time is critical to many network features and for accurate troubleshooting. Hopefully, the steps I’ve outline here will help you get your network devices in-synch!