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.
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
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 Router# *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
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 Router(config)# *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 Router(config)# *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 time-a.nist.gov Translating "time-a.nist.gov"...domain server (184.108.40.206) [OK] Router(config)# ntp server nist1-pa.ustiming.org Translating "nist1-pa.ustiming.org"...domain server (220.127.116.11) [OK] Router(config)# ^Z Router# sh ntp associations address ref clock st when poll reach delay offset disp ~18.104.22.168 .INIT. 16 - 64 0 0.000 0.000 16000. ~22.214.171.124 .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 +~126.96.36.199 .ACTS. 1 12 64 57 0.000 35.390 439.12 *~188.8.131.52 .ACTS. 1 24 64 77 0.000 36.610 189.06 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
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 184.108.40.206 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.
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
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
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 pool.ntp.org, 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
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 ?
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: http://blog.ioshints.info/2007/03/save-approximated-date-and-time-in.html