Networking

07:00 AM
Ethan Banks
Ethan Banks
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
100%
0%

Network Device Management, Part 3: Time Syncing & Stamping

An area that's often overlooked in managing network devices is time management. Follow these tips for effective network device time synchronization and timestamps.

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.

Ethan Banks, CCIE #20655, is a hands-on networking practitioner who has designed, built and maintained networks for higher education, state government, financial institutions, and technology corporations. Ethan is also a host of the Packet Pushers Podcast. The technical ... View Full Bio
Comment  | 
Print  | 
More Insights
Cartoon
Hot Topics
7
VMware NSX Banks On Security
Marcia Savage, Managing Editor, Network Computing,  8/28/2014
5
How To Survive In Networking
Susan Fogarty, Editor in Chief,  8/28/2014
White Papers
Register for Network Computing Newsletters
Current Issue
2014 Private Cloud Survey
2014 Private Cloud Survey
Respondents are on a roll: 53% brought their private clouds from concept to production in less than one year, and 60% ­extend their clouds across multiple datacenters. But expertise is scarce, with 51% saying acquiring skilled employees is a roadblock.
Video
Slideshows
Twitter Feed