Cisco IOS Clocks and NTP

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
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 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
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 (208.67.220.220) [OK]

Router(config)# ntp server nist1-pa.ustiming.org
Translating "nist1-pa.ustiming.org"...domain server (208.67.220.220) [OK]

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

address         ref clock       st   when   poll reach  delay  offset   disp
 ~129.6.15.28     .INIT.          16      -     64     0  0.000   0.000 16000.
 ~206.246.122.250 .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
+~129.6.15.28     .ACTS.           1     12     64    57  0.000  35.390 439.12
*~206.246.122.250 .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 206.246.122.25
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

• It's Good to be on Time - Ivan Pepelnjak
• Troubleshooting NTP - Cisco
• Removing NTP servers configured from a pool - Fragmentation Needed