Putting a Clock In It with Network Time Protocol

By James Hanback

Homer Simpson, that wise old sage of Nuclear family living in the information age, once astutely observed—in his own simplistic way—the importance of timekeeping to the human race. “I don’t know, Herb,” he said while examining his brother’s new invention: a baby talk translator intended to revolutionize the way mothers relate to their infants. “People are afraid of new things. You should have taken an existing product and put a clock in it or something.”

Indeed, if you take a quick look around yourself, you’ll probably see a clock on your wall, or perhaps on your wrist, most likely on your mobile phone, on your microwave, on your television, on your computer screen, on the nightstand beside your bed, on the dashboard of your car, and on the sign outside your bank to name a few places. The majority of us center our entire lives around the time of day. We rise from bed at a certain time. We eat meals generally around the same times every day. We need to be at our jobs or classes or doctor appointments at given times (and be on our commutes by a certain time in order to arrive at those appointments on time). Even many forms of our entertainment—television, movies, live shows—have, for much of their history, required a certain amount of creative rearranging of time in our schedules to enable us to indulge.

To a network or security administrator, accurate timekeeping is also of the essence because knowing precisely when a particular event happened on a network can be significant when attempting to determine the cause of a problem or the culprit in a security breach. Additionally, synchronized network time, meaning time that is consistent across all devices on a network, is important to the correct functioning of many services that are running on network devices. One example of a service running on network devices is Kerberos, which provides authentication services on a network. If time is not synchronized between clients and servers on the network, Kerberos authentication can fail. Additionally, it may become difficult to analyze network logs if a logging server is storing information from various sources that are all showing different event times.

Enter Network Time Protocol (NTP), a User Datagram Protocol (UDP) service that was originally developed in the 1980s and is still used on networks everywhere. NTP was designed to synchronize device clocks across a network. If you’ve ever wondered why your computer listens for connections on UDP port 123 (and don’t we all wonder that from time to time?), that’s the reason. NTP will not necessarily guarantee that the date and time on the network are accurate. Rather, it will attempt to make the date and time the same across every device in the network, provided those devices are all configured to synchronize their clocks with the same NTP source. The accuracy of the date and time across the network depends on the accuracy of the source with which the NTP clients are synchronizing. If too wide a gap exists between the NTP server’s time and the client’s time, the client might not synchronize at all. Additionally, an NTP client’s distance from its reference source in the NTP hierarchy known as strata can prevent the client from synchronizing its clock.

The NTP strata are hierarchical layers that represent an NTP device’s distance from the reference source. Reference sources, such as the atomic clocks at the United States Naval Observatory, are in Stratum 0, which is the topmost layer of the hierarchy. Computers that are connected to the devices in Stratum 0 are said to be at Stratum 1. Stratum 1 devices are typically physically connected to Stratum 0 devices, not connected over a network. Stratum 2 devices connect to Stratum 1 devices over a network. Stratum 3 devices connect to Stratum 2 devices over a network, and so on down the layers of the hierarchy. The farther down the hierarchy, the less likely it is that a device is synchronized with universal coordinated time (UTC) because network connections introduce delays. A device at Stratum 16 is considered to be unsynchronized.

So now that you know what NTP is and why it’s important, how do you implement it? Fortunately, that’s a relatively simple task on a Cisco device. The first thing you should do is make sure that the clock on the device you are configuring is already within a few strands of hairs-breadth of accurate. You can do that on a Cisco router by issuing the show clock detail command in privileged EXEC mode and comparing the time you see there to your smart phone’s clock, which is likely to be synchronized with an authoritative time source. Not only will the show clock detail command display the time that is configured on the Cisco device, but it will also tell you the source with which the clock was set or is synchronized. If the clock is being synchronized to an NTP server, the output will say so. Otherwise, you might see the words No time source.

Be aware that if you have not set the time zone on your Cisco device, the output you see will most likely be in UTC format. So before you assume that your router’s clock is wrong, look at the time zone in the output. To configure the router to output the time in the local time zone, issue the clock timezone timezone offset command in global configuration mode, where timezone is the string you want to use to describe the time zone you are setting and offset is the difference in hours between your local time zone and UTC. For example, the clock timezone CST -6 command configures the time zone to use an identifier of CST with a UTC offset of -6 because Central Standard Time (CST) is six hours behind UTC. The CST in this sample command is not a keyword, but an identifier string. Time zone identifier strings can be up to seven characters in length and are used to provide a friendly name for the time zone you are configuring. You could issue the clock timezone OUTATYM -6 command if you really wanted to, but using an actual time zone abbreviation is probably more helpful.

You can also configure the device to automatically account for seasonal clock adjustments as a result of Daylight Saving Time (DST) in the United States by issuing the clock summer-time timezone recurring command in global configuration mode, where timezone again is an identifying string up to seven characters in length. For example, the clock summer-time CDT recurring command, where CDT stands for Central Daylight Time (CDT), will configure the device to automatically adjust the clock based on normal United States DST criteria. When this command is issued, the device will automatically set the clock an hour ahead (spring forward) at 2 a.m. on the second Sunday in March and an hour back (fall back) at 2 a.m. on the first Sunday in November, provided you are not using a really old version of IOS that doesn’t support the 2007 changes in DST criteria. You can also manually configure the start and end dates and times of summer clock settings by issuing the clock summer-time timezone date start-date start-month start-year start-hour:start-minute end-date end-month end-year end-hour:end-minute number-of-minutes-to-add command, but who wants to do all that typing and math?

Once the time zone configuration is localized, you can configure the date and time itself by issuing the clock set hh:mm:ss day month year command, where hh:mm:ss is the time you want to set, day is the numeric calendar day of the month, month is the name of the month, and year is the four-digit year. One big gotcha when attempting to set the clock on a Cisco device is remembering that the clock set command must be issued from privileged EXEC mode instead of global configuration mode. If you forget to exit global configuration mode before issuing the clock set command, you’ll get the old % Invalid input detected at ‘^’ marker error and end up spinning your wheels over exactly what portion of the date and time you mistyped. Correctly issuing the clock set 08:00:00 25 Jun 2014 command in privileged EXEC mode would configure the local clock to 8 a.m. on June 25, 2014, in whatever time zone you previously configured. If you haven’t configured the time zone, the time you set will be configured in UTC.

From that point, configuring a Cisco router to synchronize with an NTP server is as simple as issuing the ntp server server command in global configuration mode, where server is the host name or IP address of the NTP server from which you want to obtain the time. You can issue the show ntp status command from privileged EXEC mode to determine whether the device is synchronized and the stratum at which it resides. The show ntp associations command provides some similarly helpful output. Naturally, you can also issue the show clock detail command to verify that the time is accurate.

Assuming the Cisco router you are configuring is synchronizing with an authoritative time source, you can then configure the router to provide NTP service to other devices on the network. Accomplishing that task is as simple as issuing the ntp master stratum command in global configuration mode, where stratum is the NTP stratum at which you want the device to reside. By default, this value is eight. Therefore, any devices that synchronize to the Cisco router will be at the ninth stratum. After you’ve configured the ntp master command, you can configure individual hosts on the network to use the router’s IP address as an NTP source. If you then issue the show ntp associations command on the router, you should see output that provides information about both the router’s synchronization with the remote NTP server and the NTP services that the router itself is providing to other hosts.

After you’ve configured all the NTP clients on your network, you should be able to set up some other common fanciful daydreams of a network administrator, such as a logging server, and feel relatively confident that the timestamps on the information you find stored on those devices are accurate. Essentially, you’ve done what Homer Simpson suggested in the beginning: taken an existing product (your network) and put a clock in it.

See how much improved it is?

Are you preparing for an IT certification exam? We can help. Download our NetSim Network Simulator and practice exam demos and see how we can help you learn and pass.