Proper management and operation of a Cisco Unified Communication solution requires that a common time source is used throughout all systems. This is ultimately necessary so that log, traces, debugs, etc., can be compared between devices to aid in troubleshooting and accurate statistical gathering.
Keep in mind that you will want your Cisco Unified Communication servers and equipments to have a synchronized time source with the underlying network equipment. This primer should get your understanding of NTP juices flowing. I will touch on configuring an NTP time source within CUCM in a later post.
Most Cisco routers have two clocks: a battery-powered hardware clock (referenced in CLI commands as the "calendar") and a software clock (referenced in CLI commands as the "clock"). These two clocks are managed separately.
The primary source for time data on your system is the software clock. This clock runs from the moment the system starts up and keeps track of the current date and time. The software clock can be set from a number of sources and in turn can be used to distribute the current time through various mechanisms to other systems. When a router with a hardware clock is initialized or rebooted, the software clock is initially set based on the time in the hardware clock. Your software clocks can therefore be coordinated using a valid NTP source.
The software clock keeps track of time internally based on Coordinated Universal Time (UTC), also known as Greenwich Mean Time (GMT). You can configure information about the local time zone and summer time (daylight saving time) so that the time is displayed correctly relative to the local time zone. However, if you have any plans to deploy routers across multiple time zones, I'd recommend that you use UTC/GMT as a basis throughout your solution.
NTP Overview
The NTP is a protocol designed to time-synchronize a network of machines. NTP runs over UDP port 123, which in turn runs over IP. NTP Version 3 is documented in RFC 1305.
An NTP network usually gets its time from an authoritative time source, such as a radio clock or an atomic clock attached to a time server. NTP then distributes this time across the network. NTP is extremely efficient; no more than one packet per minute is necessary to synchronize two machines to the accuracy of within a millisecond of one another.
NTP uses the concept of a "stratum" to describe how many NTP "hops" away a machine is from an authoritative time source. A "stratum 1" time server typically has an authoritative time source (such as a radio or atomic clock, or a Global Positioning System (GPS) time source) directly attached, a "stratum 2" time server receives its time via NTP from a "stratum 1" time server, and so on.
NTP has two ways to avoid synchronizing to a machine whose time may not be accurate. First, NTP will never synchronize to a machine that is not in turn synchronized itself. Second, NTP will compare the time reported by several machines, and will not synchronize to a machine whose time is significantly different than the others, even if its stratum is lower. This strategy effectively builds a self-organizing tree of NTP servers.
See the stratum(st) displayed for each ntp association below:
show ntp associations;
address ref clock st when poll reach delay offset disp
+~1.11.12.55 125.220.128.123 2 970 1024 377 -0.0 -0.42 0.3
+~1.11.12.56 125.220.128.123 2 74 1024 377 -0.0 -0.01 0.2
*~1.11.12.57 125.220.128.123 2 619 1024 377 -0.0 1.85 0.1
~1.11.12.58 125.220.128.123 2 74d 1024 0 -0.0 -0.64 16000.
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
The Cisco implementation of NTP does not support stratum 1 service; in other words, it is not possible to connect to a radio or atomic clock (for some specific platforms, however, you can connect a GPS time-source device). We recommend that time service for your network be derived from the public NTP servers available in the IP Internet.
What If A Public NTP Server Cannot Be Reached?
If the network is isolated from the Internet, the Cisco implementation of NTP allows a machine to be configured so that it acts as though it is synchronized via NTP, when in fact it has determined the time using other means. Other machines can then synchronize to that machine via NTP. "Other machines" here includes CUCM, Unity, and other Cisco Unified Communications servers.
A number of manufacturers include NTP software for their host systems, and a publicly available version for systems running UNIX and its various derivatives is also available. This software also allows UNIX-derivative servers to acquire the time directly from an atomic clock, which would subsequently propagate time information along to Cisco routers.
The communications between machines running NTP (known as "associations") are usually statically configured; each machine is given the IP address of all machines with which it should form associations. Accurate timekeeping is made possible by exchanging NTP messages between each pair of machines with an association.
However, in a LAN environment, NTP can be configured to use IP broadcast messages instead. This alternative reduces configuration complexity because each machine can simply be configured to send or receive broadcast messages. However, the accuracy of timekeeping is marginally reduced because the information flow is one-way only.
The time kept on a machine is a critical resource, so we strongly recommend that you use the security features of NTP to avoid the accidental or malicious setting of incorrect time. Two mechanisms are available: an access list-based restriction scheme and an encrypted authentication mechanism.
When multiple sources of time (VINES, hardware clock, manual configuration) are available, NTP is always considered to be more authoritative. NTP time overrides the time set by any other method.
Related Posts
Cisco IOS NTP Configuration
Cisco CUCM NTP Configuration
More Information
Cisco IOS Network Management Configuration Guide, Release 12.4
No comments:
Post a Comment