The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

Cisco IOS Clocks and NTP

By stretch | Monday, March 28, 2011 at 2:24 a.m. UTC

Many networkers underestimate the importance of keeping accurate time on all devices across a network. This is particularly true among smaller companies without strong IT policies. Keeping consistent time across network devices is critical to enable accurate comparisons of log messages and other time-sensitive information in the course of troubleshooting or auditing. This article explains how to achieve practical time synchronization on Cisco IOS.

Understanding UTC

Coordinated Universal Time (UTC) is the global standard for time representation. (The odd acronym UTC is a compromise between the English acronym CUT and the French acronym TUC.) Every time zone on Earth can be expressed as offset from UTC by a number of hours and minutes. For example, Eastern Standard Time (EST) can be expressed as UTC -05:00 (five hours behind UTC). Note that UTC is not equivalent to GMT, which is a time zone in its own right with a UTC offset of +00:00.

It is considered best practice to set clocks on all network devices to UTC regardless of their physical location, and then configure the relevant time zone to display the local time if desired.

Setting the system clock by hand

IOS devices, like most computers, have two sources of timing. The first is the hardware clock (sometimes referred to in Cisco documentation as the "calendar"), which includes a battery backup to maintain time while the device is powered off. The second is the software clock, which is initialized at boot time from the hardware clock. We can see what a router believes is the current time and date with the command show clock:

Router# show clock
*02:56:19.323 UTC Sun Mar 27 2011

The leading asterisk before the time indicates that the time is not authoritative; that is, the time is not guaranteed to be accurate. show clock detail reveals that this is because the software clock has been automatically synchronized from the hardware clock:

Router# show clock detail
*02:58:19.871 UTC Sun Mar 27 2011
Time source is hardware calendar

We can use the command clock set (from privilege exec mode, not global configuration) to modify the current time and date. Remember to set the time and date in UTC, not your local time zone.

Router# clock set 17:49:00 27 march 2011
*Mar 27 17:49:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 03:01:05 UTC Sun Mar 27 2011 to 17:49:00 UTC Sun Mar 27 2011, configured from console by console.
Router# show clock detail
17:49:05.271 UTC Sun Mar 27 2011
Time source is user configuration

The time now appears to be authoritative (the asterisk has been removed) and the source of the timing has been changed to "user configuration." The novice could be forgiven for assuming that the router's clock is now correctly set. Notice, however, that the hardware clock has not been updated, as we can see from the output of show calendar:

Router# show calendar
03:04:01 UTC Sun Mar 27 2011

If we were to reboot the router, the software clock would be resynchronized with the hardware clock upon boot and revert to the incorrect time. We could set the hardware clock manually as we did with the software clock using the command calendar set, but given that the software clock has already been set we can use the command clock update-calendar to synchronize the hardware clock to the software clock:

Router# clock update-calendar
Router# show calendar
17:56:29 UTC Sun Mar 27 2011

Finally, we can configure our local timezone and (if applicable) daylight savings time on the router.

Router(config)# clock timezone EST -5
*Mar 27 18:59:32.855: %SYS-6-CLOCKUPDATE: System clock has been updated from 18:59:32 UTC Sun Mar 27 2011 to 13:59:32 EST Sun Mar 27 2011, configured from console by console.
Router(config)# clock summer-time EDT recurring
*Mar 27 19:02:58.459: %SYS-6-CLOCKUPDATE: System clock has been updated from 14:02:58 EST Sun Mar 27 2011 to 15:02:58 EDT Sun Mar 27 2011, configured from console by console.
Router# show clock detail
15:04:43.075 EDT Sun Mar 27 2011
Time source is hardware calendar
Summer time starts 02:00:00 EST Sun Mar 13 2011
Summer time ends 02:00:00 EDT Sun Nov 6 2011

A Better Approach: NTP

Obviously, setting the current time by hand isn't sufficient when dealing in millisecond granularities. Even if we did manage to set the exact correct time on a router, it wouldn't last: commodity electronics are subject to clock drift, which causes the accuracy of a clock to degrade over time, advancing either slower or faster than real time.

A solution to both of these problems is Network Time Protocol (NTP). NTP allows for regular, automatic synchronization of a device clock with one or more time servers which provide accurate time. NTP allows clocks to be synchronized over networks with variable delay, such as the Internet.

NTP servers are described in terms of strata (hierarchical levels); the lower a server's stratum, the more accurate it is. Stratum 0 servers maintain time directly from the Global Positioning System, atomic clocks, or other sources with a high degree of precision. Each NTP server assigned a stratum of one higher than the upstream device with which it is synchronized. Thus, a stratum 0 server feeds a stratum 1 server, which feeds a stratum 2 server, and so on. Typically, you will configure routers and other devices to synchronize with NTP servers designated as stratum 1 or 2.

Basic NTP Configuration

Before you can configure NTP, you must select one or more upstream servers with which to synchronize. Large organizations (particularly governments and militaries) maintain their own stratum 0 and 1 NTP servers. For others, there are a number of public NTP servers available. Only a few devices on your network should pull time from external sources; all others should synchronize with those devices locally.

NTP servers are specified with the command ntp server under global configuration mode. We'll use two servers from the US NIST Internet time service for this example.

Router(config)# ntp server
Translating ""...domain server ( [OK]

Router(config)# ntp server
Translating ""...domain server ( [OK]

Router(config)# ^Z
Router# sh ntp associations

address         ref clock       st   when   poll reach  delay  offset   disp
 ~     .INIT.          16      -     64     0  0.000   0.000 16000.
 ~ .INIT.          16      -     64     0  0.000   0.000 16000.
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

The output of show ntp associations above shows that both of our servers are in the INIT state. For a protocol so obsessed with correct time, NTP certainly is slow: it can take upwards of five minutes to synchronize with an upstream server. This is due to the NTP poll timer of 64 seconds. Eventually, you'll see an association formed with at least one server, indicated by an asterisk. The other server in this example, marked with a +, has been designated a candidate (alternate).

Router# show ntp associations

address         ref clock       st   when   poll reach  delay  offset   disp
+~     .ACTS.           1     12     64    57  0.000  35.390 439.12
*~ .ACTS.           1     24     64    77  0.000  36.610 189.06
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

The argument detail can be appended to the above command for more information on each association. The command show ntp status provides detail on the current NTP synchronization:

Router# show ntp status
Clock is synchronized, stratum 2, reference is
nominal freq is 250.0000 Hz, actual freq is 249.9998 Hz, precision is 2**32
reference time is D13A115F.B0488F52 (15:41:19.688 EDT Sun Mar 27 2011)
clock offset is 0.0366 msec, root delay is 0.01 msec
root dispersion is 0.23 msec, peer dispersion is 0.00 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000000526 s/s
system poll interval is 64, last update was 187 sec ago.

By default, NTP synchronizes only the software clock. We can enable hardware clock synchronization with the command ntp update-calendar. It is also worthwhile to extend your NTP configuration when synchronizing with internal servers to authenticate NTP traffic and restrict which clients can poll your NTP servers.

Further Reading

Posted in System Management


March 28, 2011 at 4:24 a.m. UTC

Very well written , Stretch!

March 28, 2011 at 7:12 a.m. UTC

Hi, thanks for the article.

My c870-adventerprisek9-mz.124-24.T IOS image doesn't find the calendar commands. How could that be? I've no access to it.

I'm from germany. We switched to summer time last weekend. Normally we are at UTC+1 (=GMT+1), our timezone is called CET.

Now with summer time we have an additional hour of offset it seems (UTC+2), or CE_S_T (Central European SUMMER Time). It's a bit confusing. It's 9 am now and if I configure UTC+1, CET, CEST or whatever it's just 7 or 8 am. Only if I configure UTC+2 it's shows the right time.

Anyway to get rid of this summer time issue??

Maybe I haven't understood something important?


March 28, 2011 at 11:41 a.m. UTC

I didn't know the update calander command. Thanks for the heads up.. (But I use NTP whenever I can)

March 28, 2011 at 1:30 p.m. UTC

Informative. Thanks

March 29, 2011 at 11:55 a.m. UTC


For me (I'm also from Germany) this

clock timezone MET 1 0
clock summer-time MEST recurring last Sun Mar 2:00 last Sun Oct 3:00



March 29, 2011 at 3:12 p.m. UTC

Thanks for this. As I transition from being a server guy to a network guy, I'm thrilled that ntp configuration on IOS is actually arguably less involved than it is on Windows 2003:

Really MS? I need to set 7 registry entries, or use a mysterious "fix it for me" link with no documentation about what it does? I think they improved this in S2008 but its one of those things I'm trying to forget.

March 30, 2011 at 6:45 a.m. UTC

@Einstein: Thanks. Worked for me too, but what's in the future? Do I always have to always add an entry when the time changes to let the router know that?

March 30, 2011 at 6:53 a.m. UTC

@Einstein: Also wondering why I have to set CET+1 AND CEST.

Normally CET+1 = CEST. This configuration leads to CET+2...

March 30, 2011 at 3:39 p.m. UTC

Great article! I set this up on our network a few months ago and it makes parsing the logs MUCH easier. I set my LAN switches to synch to the local WAN router which synchs to our core router which synchs to our IAS/RADIUS server which synchs to a nearby NIST server. It works great! The hardest part was getting NTP going on the Windoze 2003 R2 server. I ended up using Meinberg NTP service which was easy to install and configure.

A couple other commands that are useful for logging are:

service timestamps debug datetime localtime show-timezone service timestamps log datetime localtime show-timezone


clock timezone CST -6 clock summer-time CDT recurring

Thanks Stretch! Keep up the good work!!

March 30, 2011 at 7:34 p.m. UTC

Another handy config option to periodically (and automatically) sync the software clock with the hardware clock:

clock save interval hours

This will ensure that after you painstakingly set up NTP on all your equipment, you can rest assured that if any device reboots, the hardware clock will be pretty close to what the software clock was at the time of the reboot.

March 31, 2011 at 2:05 p.m. UTC

@pressureman: That's what the command ntp update-calendar does. The clock save command seems to be intended for devices without a battery-backed clock, as it regularly saves the time to NVRAM (though I don't see how such a feature would be terribly useful).

April 8, 2011 at 1:19 p.m. UTC

I've almost written about, but then I've checked out the link at the bottom of the article. Really weird and really scary that ios has such bugs...

February 1, 2013 at 12:59 p.m. UTC

Hi Jeremy,

I tried configuring NTP on cisco IOS C2600-ADVIPSERVICESK9-M), Version 12.4(25b).

It allows me to configure NTP through VRF only.

R1(config)#ntp server ?
vrf VPN Routing/Forwarding Information

Any ideas on how to do it with VRF ?

David Bullock
May 22, 2013 at 5:51 a.m. UTC

Ivan gives the reason for the existence of the 'clock save' command on routers without a battery-backed clock:

May 2, 2014 at 1:21 a.m. UTC

In regards to the #ntp server command giving only the VRF option just go ahead and place the command with the IP address.

Seems it is a cosmetic issue since you'll see the command after doing a #show run | se ntp

May 15, 2014 at 5:05 p.m. UTC

Anyone have any idea why Cisco 12.4 on a 2811 router won't allow NTP server to be enabled in global mode, instead requiring it to be associated with a VRF? (No VRF configured or even used on the router) Thanks

herr koiner
December 5, 2014 at 3:12 p.m. UTC

Be aware, that if you configure ntp a router will act as an ntp server on any interface it has. If that's not what you like you need to configure "ntp access-group {peer|...}"

August 16, 2015 at 12:34 p.m. UTC

Thank you very much Sir

June 17, 2016 at 8:22 p.m. UTC

Clock is synchronized, stratum 5

Is there any way to manually change this stratum from 5 to 2, so when this broadcast ntp in the network client will get stratum3.



Comments have closed for this article due to its age.