Vol: 8-07 - Importance of Time    

Establishing and using accurate and synchronized time is very important for networked services. The Network Time Protocol (NTP) can be used by computers on Internet Protocol (IP) networks to synchronize the clocks running on them.

Accurate time allows for many computer functions to work properly. If the clocks are suffi ciently out of sync in a network, some applications may not function properly, or individual computers may appear to be malfunctioning. Computers running database applications are particularly susceptible to this time differential issue. NTP is based on a hierarchical structure. Each step that a device is removed from the time source is expressed as an increase in the strata number. By convention, stratum 16, or stratum 256 depending on the NTP version, is understood to represent a state of no synchronization.

The Strata
The time source (stratum 0) is a clock. These devices are GPS and radio clocks and atomic clocks. These clocks are connected to a computer (stratum 1) which is in turn connected to the network. There are many regularly used clocks known as public NTP servers such as:
- time.nrc.ca,
- tick.usask.ca
- tock.usask.ca

Stratum 2 devices make requests to stratum 1 devices for time information. Stratum 3 devices make requests to stratum 2 devices and so on. Interestingly, devices at the same stratum level can be configured to talk to each other, and over time will reach agreement on the time. This mesh of time information can be used to create redundancy and accuracy throughout the environment. With NTP, a device which is recognized as being sufficiently out of sync is not included in the calculations until that clock is brought back within acceptable tolerances.

For most organizations, relying on stratum 3 or 4 devices within your network is good enough to establish accurate and synchronized time across the enterprise.

NTP only deals in Universal Time Coordinated (UTC) otherwise know as Zulu or Greenwich Mean Time (GMT). Time zone and daylight savings time calculations are outside of scope for NTP. A policy should be created and enforced on how to deal with time across the network. Will you use UTC or your local time zone? While local time is easier to read, it does pose a problem when there are shifts from daylight-savings to standard time; not all devices or operating systems support logging in local time.

NTP uses UDP port 123 for communicating, so remember to allow outbound access to this port in your fi rewall rules. UNIX servers have an NTP daemon. This runs as a user on the system with special privileges allowing NTP to effect changes to the server’s clock.

Microsoft servers run a scaled-down version of NTP called Windows Time Service. Starting with Windows Server 2003, Microsoft claims that Windows Time Service is fully compatible with NTP v3. This has not been my experience and I have found that 3rd party applications work better.

As well as allowing applications to run in sync, implementing NTP on your network means you’re recording accurate log file timestamps across the enterprise. This improves trouble-shooting capabilities and speeds up analysis times. Database servers allow data to be entered into and read from, all with a dependence on time. When you have two such servers communicating for the purpose of redundancy, and the time clocks are out of synch, data losses may occur.

Managing NTP deployment can be reasonably simple if the hierarchal design of the protocol is kept in mind. Select two devices, preferably core routers or switches, confi gure these network devices with three NTP servers, two external and then each other, this will allow for synchronization and redundancy with the external time source.

All other devices and servers requiring NTP receive clock time from these two sources. By creating a template for standard deployment, configuration is simplified. If you decide to use a new external NTP clock source, you only have two devices to visit. Another benefit of this strategy is that your most critical servers will reliably obtain time as your Local Area Network will typically be more reliable then any public Internet connection.

NTP predates the public Internet as we know it today. Commercialization of the Internet began around 1988 while NTP has been with us since before 1985. There have not been any signifi cant changes to the NTP protocol since its inception. Ironically, NTP is often overlooked when establishing a baseline for server confi guration. It is a good protocol. Make sure you make it a part of your standard server configuration.

Originally published July, 2008

PDF this Page
Fragment - Current Release


IT Roles and Responsibilities
On Passwords
Spending Enough
Planning to Fail
Living With the Enemy
A Reason for Policy
Mission Critical Messaging – Do you have a policy
Globalizing the SMB
High Availability: People and Processes
Case for Project Management
Risk Management

On Routing
VLAN Tutorial
IPs 4 Golden Rules
WAN Technology primer
DHCP Primer
Your Head in the Cloud(s)
DNS: Terms and Process
VPN Surfing Challenge
Network Slowdown
Importance of Time
High Availability: Technologies

Spammers Go Full Circle
Beyond the Lock
The Guardian at the Gate
A Web of Trust
Data Breach Notification

Electricity Primer
Data Control
Open Source in the Enterprise
Closing the Loop
Helping IT to help you
Your ICT Keystone

eSubnet Services

Contact us regarding your network,
security and Internet services needs

All content © eSubnet 2003-2017