I was once told by a consultant that he could figure out whether a client needed his services after about 30 seconds at a router console.  When I asked how he could be so sure after such a short amount of time, he consoled to a router in his lab and typed in “show clock”.  The lab router returned the now-familiar string of Mar 1, 1993 (he’d just booted it).  As soon as he showed me that one command, it all made sense.  Keeping accurate time in a computer environment is very important to systems.  Directory structures depend on an accurate clock to authorize logins and track audit events.  Novell and Windows both utilize systems to ensure that the clocks of all the servers in the network are synchronized.  And if those clocks drift out of sync, heaven help the server admins.

What about network equipment?  In days past, the routers and switches were typically neglected when it came to clock setting.  In fact, most older Cisco routers didn’t even include an on-board battery to keep the clock accurate.  And when the router would reboot, the software clock didn’t have an accurate hardware clock to refer to, so it used 00:00 1 Mar 1993 as the reference point.  But as systems have increased in complexity over the past several years, the need to have all the time on your equipment accurate has become paramount.  When debugging a call hand-off on a voice gateway, an accurate router clock ensures that you can match the time the call was placed with the debug message output.  If there is a security incursion into your network devices, you need to track the time the device was accessed in order to be able to accurately report the event to the proper authorities.

So how do we get our network clocks to report the right time?  Well, the process is fairly easy, provided you’ve done a little homework about a couple of things.  First, you need to know what timezone you are in and what your GMT offset is.  In today’s world, it is far easier to keep the clock of your device synced to GMT, then apply an offset to show you what the local time is.  That way, if you have devices spread all over the world, you never have to worry about a significant time difference because one clock was synced to local time and the other was synced to GMT with an offset applied.  For the purposes of the examples in this post, I’m going to assume the router is located in the central United States and is in the Central Time Zone.  The fact that I myself am in the Central Time Zone and therefore would not need to do any additional thinking to write my examples is purely coincidental.

In the case of my example, the central United States is in the Central Standard Time Zone (CST).  CST is six hours behind the GMT clock (GMT -6).

When you first connect to the router, you will either see the default time of 00:00 1 Mar 1993 (for older routers), or if you’re on an ISR or newer router, it may be synced fairly close to the actual time.  Starting with the ISR, Cisco started keeping the time synced more closely when the router was shipped from the factory, and the battery keeping the hardware clock time when powered off seemed to last a lot longer.

At this point, we need to set the router’s timezone with this command:

R1(config)# clock timezone <name> <GMT offset>
R1(config)# clock timezone CST -6

Once you’ve done that, the system should update with a message telling you that the current time zone has been updated.  Now, the router should know what time zone it’s in and adjust the clock offset appropriately.  You should also set the daylight savings time conditions as well.  For those not familiar, DST is a law that many countries have adopted that force sleepy engineers to reset the clock on the microwave at 2 a.m. on two days during the year.  Just when we had it down, they went and changed it a couple of years ago.  Hence the reason that Cisco doesn’t hard-code the DST settings on their routers.  They are more than happy to let you do it yourself.  In this example, we’re using the U.S. standard of the second Sunday in March and the first Sunday in November:

R1(config)# clock summer-time <name> recurring <week number start> 
        <day> <month> <time to start> <week number end> <day> <month> <time to end>
R1(config)# clock summer-time CDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00

And just like that, your router will perform just like every other smart device in your house and reset the clock for DST when necessary.  Now, if I could just get my microwave to do that.

Now that your router is in the right time zone, it’s probably a good idea to sync the clock to some kind of external time source.  That’s why Network Time Protocol (NTP) was created.  It allows distributed systems to sync their clocks with a time source directly connected to an atomic clock (the most precise kind).  NTP form as a hierarchy through use of strata. Stratum 0 NTP devices are directly connected to atomic clock sources, usually through RS-232 or other cabling.  The are not connected via a network.  Stratum 1 NTP devices are connected to Stratum 0 devices via a network connection.  These are the systems that are usually referred to as time servers.  These are usually the devices that you will sync one of your clocks to.  Why just one?  Well, while having all your devices synced to external time sources is a great idea, there are two issues that can arise.  First, having that much NTP traffic exiting your network isn’t exactly optimal.  There is no reason for 20 routers to each poll an external NTP server when one router could do the same thing, and the other 19 routers poll the synced router.  You can even designated your NTP-synced router as a Stratum 2 or 3 device if you’d like, then have it start serving time to your other devices.  The second issue with using all external NTP servers deals with security.  Some people are uncomfortable with the idea that all their devices are being told how to manage their clocks by an external device over which they have no control.  By configuring your devices to sync to one clock in your network that you control, there is more consistency and less reliance on systems outside your control that may be overloaded or unreliable.  For more info on what happens when someone starts abusing an NTP server, check out what NETGEAR did to the University of Wisconsin’s NTP server here.

For the sake of your sanity, it’s best to set the clock to something close to the actual time before you set the NTP server.  The reason for this is due to the propensity for NTP to look at your clock and declare it insane if you are too far drifted from the actual time.  I usually try to get my local clock somewhere in the neighborhood of one hour from the actual time, but the closer you are and the faster NTP will sync.  You do this with the following command (note the context)

R1#clock set <HH:MM:SS> <1-31> <Name of Month> <Year>
R1#clock set 01:00:00 10 Jan 2011

You must manually set the clock in enable mode, not global config mode.  Once you’ve gotten the clock close to your time, you can set the NTP server.  If you want to sync your router to an external time source, using the NIST Time Server list is always a good start.  If your router is capable of resolving DNS, a better idea is to use the NTP pool service.  This service is a cluster of NTP servers around the world that is served by round-robin DNS query, so no one server can get overloaded.  If you don’t feel comfortable syncing your clock to a server in France or Japan, you can always narrow down the focus of your query by using narrower DNS entries.  Check out their site for ways to do this.  Once you’ve figured out  how you are going to connect to NTP, and whether you are going to use external or internal servers, the command is pretty easy:

R1(config)# ntp server <name or ip>
R1(config)# ntp server 10.1.1.1
or
R1(config)# ntp server 0.pool.ntp.org

Yep, that’s it.  Simple once you’ve gotten all the planning down.  You can check your NTP sync status with the command show ntp status.  You can see which time servers your are polling with the command show ntp associations.  The commands have a lot of good info, but can be a little cryptic your first couple of trys.

Once you’ve gotten your clock in sync, there’s just two more commands you need to use to ensure that all your logs and debug outputs are using the right clock.  By default, logs and debugs use the system uptime for their output, so you could get a log message that says “1w3d” instead of the real time.  And if you have to start doing math on your debugs to figure out when a call was dropped, you’re going to be a cranky rock star.  From global config mode, go ahead and type in these two commands:

R1(config)# service timestamps log datetime msec
R1(config)# service timestamps debug datetime msec

The “MSEC” keyword on the end tracks the message down to the millisecond level, which I’ve always found very handy when trying to figure out sub-second error messages.  It also helps better match error logs which are all part of the same event, but spread out over multiple messages.

Now, your routers are all in sync and your logs and debugs are all outputting the correct time.  If a consultant tries to access your devices, you will appear to be one cool customer that doesn’t need any help on your networking devices.  You’ll also be able to troubleshoot faster and get all the fame and wealth appropriate to your station as the Network Miracle Worker.

For what it’s worth, I did a lot of searching about why the default time on a Cisco router without a battery backup is March 1, 1993.  No one seemed to have a definitive answer.  According to the Internet, the only really exciting thing that happened that day was George Steinbrenner being reinstated as Yankees owner.  I doubt anyone in San Jose is a Yankees fan, so I didn’t think that was it.  It also didn’t correspond to any neat numbers in the Unix Time Epoch.  1993 was the first year that Cisco acquired a company, but that happened in September of that year.  The only thing that happened early was the release of IOS 10.0.  I guess that Cisco decided that “10” was an important enough number that they wanted to start basing recent history sourced from this date.  The other possibility is that it was just an arbitrary date chosen by IOS engineers so that the router clock didn’t cycle all the way back to 1900.  MS-DOS had a similar functionality, wherein it would see the system BIOS clock set to 1900 and assume that the BIOS had to be wrong.  It would then set the clock to the earliest date it could (January 1, 1980).  Maybe Cisco just decided that 1993 was so early that if they noticed a router clock stuck on that date, it would just be assumed the the clock was not set.  Either than, or they were really big fans of this song…