Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Network Device Management, Part 3: Time Syncing & Stamping

Network device management is both eased and improved when a consistent rationale is applied to each and every device on the network. Thus far, I've recommended controlling SNMP, logging, and authentication, authorization, and accounting (AAA) as ways to bring predictability to network infrastructure. An area that's easy to ignore is that of time management.

It's true that a router routes and a switch switches without having to have its local time synchronized centrally, but network device management is better when the time is set correctly. In this post, we'll take a look at managing time as well as timestamps effectively.

Time syncing and stamping
An oft-overlooked network device configuration feature is time synchronization. Some devices think it's 1999. Some have a vague awareness of the time but have drifted several minutes from reality, experiencing network events in an alternate reality all their own.

Yet other devices are perfectly synchronized but stamp events using a time zone unrelated to their locale, headquarters, or even GMT. The time zones seem to have been assigned at random, causing network engineers to do lots of addition and subtraction as they attempt to correlate events across devices. Here are tips for avoiding these problems:

1. Use network time protocol (NTP) to sync time, but be responsible about it. Using NTP is straightforward on almost any sort of network device. There is no excuse not to use NTP, and the downsides of not maintaining synchronized time can range from annoying (can't correlate logs easily) to catastrophic (login failures and related trouble).

Assuming you're committed to using NTP, define two or more central NTP servers in your organization that get time from an authoritative time server, and then point the rest of your organization to those central servers. The idea is to avoid burdening public NTP servers with excessive requests from your organization.

2. Set a common time zone across all devices in your organization. The time zone doesn't have anything to do with NTP; the actual time reflected by NTP is the same no matter what local time zone is configured. The time zone is just a customization to make it easier for network practitioners working on the device.

I've been in a number of discussions over the years about what time zone should be set on network devices. There are usually three positions. First, folks want each device to reflect their local time zone. So in the US, devices in Florida are configured for EST, devices in Oregon for PST, etc. Second, some people favor configuring all network devices to the time zone where the majority of network engineering staffers live. Third, folks recommend that all network devices use GMT as a way to share a common time zone without exhibiting favoritism.

My opinion is to choose one time zone and stick with it. The reason is that the geographic local time zone of a network device that participates in a national or global WAN is irrelevant. What's far more important is being able to correlate log events quickly and easily across those devices. Keeping the time zones the same makes that job easier for humans.

3. Stamp log events with the local time. I have found local log timestamping with the configured time zone helpful when looking at the buffered events on a network device. This is an important point, because not all devices will stamp with the local time zone time. Some will timestamp with NTP time, which is effectively GMT. On Cisco devices, the command you're looking for is "service timestamps log datetime msec localtime show-timezone."

Next steps
With local network device time set correctly, yet another network device management technique worth considering is what I call "topology control." The idea behind topology control is that a network engineering team should define the roles that network devices will play when it comes to spanning-tree and routing protocols like OSPF and EIGRP. Then, with those roles defined, the resulting topology should be defended.

In the next and last installment in this series, I'll raise some ideas around keeping control of the network by configuring inter-device protocols with purposeful intent.