Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up
Network + Systems Infrastructure
W O R K S H O P  
Keeping Time With Your Network

  July 10, 2003
  By Mike Fratto


TOC Issue TOC
Printer Print full article
Printer Print this page
Printer Download as PDF
E-Mail E-Mail this URL
Discuss Discuss this article
flame author Flame the author
 
  In this article
arrow
Introduction
arrow
Setting Your NTP Time Model
arrow
Step by Step

Think time is on your side? That depends on whether you synchronize the clocks of your network devices, servers and workstations. Many organizations don't bother with time synchronization, but it's gradually becoming a best practice: Being able to construct a time line of events can be key to resolving a network failure or security breach.

Time-sensitive applications, such as e-business transactions and Windows 2000 Active Directory, also require accurate time. Active Directory relies on time synchronization for event-log time stamping, directory replication, authentication using Kerberos and other processes.



One way to synchronize is to set each network device and PC clock manually. That's like a Navy quartermaster keeping accurate time at sea by synchronizing his watch with a reference clock or chronometer on the ship, and then setting each clock onboard to his watch. This method requires military-like discipline and more resources than most IT departments have. A clock's time can drift several seconds each day if it's left unattended. Time discrepancies among clocks can go from minutes to hours quickly and cause problems with automated actions, data logging and synchronization.

An easier way to keep time is to automate time synchronization in your servers and workstations. Two of the most common approaches use NTP (Network Time Protocol, RFC 1305) 3 and SNTP (Simple Network Time Protocol, RFC 2030) 4. NTP and SNTP synchronize time across geographically dispersed networks over UDP (User Datagram Protocol) Port 123. NTP supports multiple, redundant time sources for always-on, accurate time synchronization, and it can synchronize time to the millisecond.



NTP Network Map

click to enlarge

How It Works

NTP servers operate in a hierarchal network; each level of the hierarchy is called a stratum. Stratum 0, the first level, represents the reference clock. The reference clock can be a GPS (Global Positioning System) signal or the National Institute for Standards and Technology's Automated Computer Time Service (ACTS)--both time-dissemination services. No NTP servers operate at Stratum 0.

Stratum 1 NTP servers get their time data from the reference clock. Stratum 2 NTP servers synchronize with Stratum 1 servers. You can have up to 15 levels. For a list of public Stratum 1 and 2 servers see www.eecis.udel.edu/~mills/ntp/servers.html. Be sure to read and honor the access policy of the public NTP servers you use.

NTP servers and NTP clients get time data from Stratum 1 servers, though in practice, NTP clients shouldn't do so because thousands of individual client requests would place too much of a burden on a Stratum 1 server. It's best to set up a local NTP server that your clients use for time services.

The NTP hierarchy is fault-tolerant and redundant. In the diagram below, two Stratum 2 NTP servers are synchronizing to six different Stratum 1 servers, each going over independent paths. The internal hosts are synchronizing with the internal NTP servers. The two Stratum 2 NTP servers coordinate time between themselves. If a path to a Stratum 1 server fails or a Stratum 2 server fails, the redundant Stratum 2 server continues the synchronization process.

Likewise, Stratum 3 hosts and devices can use either of the Stratum 2 NTP servers. More important, using a redundant network of NTP servers ensures that time servers are always available. By synchronizing with multiple time servers, NTP uses the data from all the sources to calculate the most accurate time.

NTP doesn't actually set time. It adjusts the local clock using a time offset, which is the difference between the NTP server's time and the local clock. NTP servers and clients update their times by adjusting the local clock to the current time gradually or all at once.

You can configure the NTP client and server parameters to "step" the local clock to the current time if an offset gets too high. But if the offset is less than the maximum offset value of 128 ms, for example, the clock will be changed to the current time gradually. (The gradual change keeps the time continuous). If the clock offset is exceptionally large, however--greater than 1,000 seconds--the NTP server or client will stop adjusting time and wait for human intervention.

Meanwhile, the risk of using any Internet-based service, of course, is that it can become unavailable. So if your organization requires an accurate reference clock to create receipts for real-time transactions or for PKI (public key infrastructure) for authentication/validation, you should set up an internal Stratum 1 time server for more accurate time. These commercial time server platforms, from vendors such as Symmetricom and EndRun Technologies, provide the accurate time via GPS, radio or dial-up modem for internal timekeeping.

Infrastructure Sites to See
Like a network of public NTP servers, an internal time-server platform should be synchronized to multiple reference clocks. And you should deploy multiple Stratum 2 NTP servers that offer multiple paths to the Stratum 1 server.

Timing It Right

So how do you go NTP? First, set up the NTP daemon (see "Step by Step," below), which is available at www.ntp.org. When an NTP client or server first initiates synchronization, it needs to establish which time servers it will use, and that's defined in the ntp.conf file. Next, the NTP daemon needs to determine the properties of the local clock. Within about 15 minutes, the NTP client is synchronized with the NTP server.

The alternative to NTP is SNTP, which comes packaged with Windows 2000. At the protocol level, SNTP is just like NTP, and NTP servers can answer SNTP or NTP queries. But SNTP's timing algorithms for determining time offsets and resolution and redundancy features are different from NTP.

The SNTP client takes the time stamp at face value and sets the clock accordingly, without the in-depth validation process that NTP uses. SNTP should not be used with multiple NTP and SNTP servers because it doesn't have the algorithms to determine the best time source. And in contrast to NTP, SNTP synchronizes down to the nearest second rather than the nearest millisecond.

Windows 2000 machines in a domain use SNTP and W32time to automatically synchronize with the Windows Primary Domain Controller (PDC) in a process transparent to the user. But Windows 2000 uses a time source derived from SNTP to synchronize other hosts, so it's a good idea to have an NTP client in the PDC to synchronize to an external source.

Mike Fratto is a senior technology editor based in Network Computing's Syracuse University Real-World Labs®; he covers all security-related topics. Prior to joining this magazine, Mike worked as an independent consultant in central New York. Write to him at mfratto@nwc.com.

Post a comment or question on this story.


start top Introduction Setting Your NTP Time Model 

Research and Reports

Hypervisor Derby
August 2011

Network Computing: August 2011

TechWeb Careers