NTP Summarize
As everyone knows, the NTP is sync clock protocol.
That knowledge less other protocol.
But there are some attention:
——————————————
1. When you config more than one server in customer network.
Please don’t use the same stratum.
Base on the stratum, refer to
http://www.cisco.com/en/US/docs/ios/netmgmt/command/reference/nm_10.html#wp1093957
If customer use same stratum, it would instability and lost sync.
2013-1-22 更新
There are two reason will lead NTP flapping(lost sync):
1. If you have 2 ntp servers this sort of behavour can happen if the ntp parameters from those servers are similar. This is likely if your peering to two N7Ks. Note also that “prefer” is not a priority selection on XR.
2. NTP version mismatch between V3 and V4Refer to “Prefer” option, may solve this problem, in most of the case but this is not a 100% solution. If the time from the “preferred” source reaches the client earlier than other configured peers, it is taken to be authoritive and independent of the current time and offset. And we sync to it, but before the NTP client is synchronized to this preferred peer (which should take a few seconds in general or a maximum of 5 minutes), if time updates from other configured peers reach the NTP client, the clock selection algorithms are applied to all of these and we have all the time sources pass through the selection algorithms and NTP tunes the client’s time to some peer, considering the other factors of offset, sync distance and dispersion.
We do have more than 2 servers at the same stratum level, in the CASE, We should try using prefer option to see if we have no issues with time stabilities. But if we have the two servers almost at the same distance, even “prefer” option would not help much.
So it is advisable to to have one server per stratum level.
2. After you config the ntp, “ntp clock-period” will auto appear.
It will auto adjust the local clock and base HW auto recreate.
But some customer maybe paste one chassis configuration to other chassis include “ntp clock-period”.
Then the adjust times not exact, it don’t recalculate and recreate the new period.
So lead to sync lost each 17 minutes.
Please customer “no ntp clock-period” and auto recreate it.
Follow are some scenarios for ntp config:
(covers most of the scenarios that you might encounter)
———————————————————————————–
SCENARIO 1: ROUTER SYNCS WITH LOCAL TIME SERVER (also works for a local
time server that syncs with an Internet time server).
The primary command used to configure NTP is “ntp server x.x.x.x”. This
is the same regardless of whether the server is local or on the internet. Afer this
command is entered, the router will commence start-up polling”, sending 1 poll packet
every second for 16 seconds. After that, the router will do “regular polling”, which
normally occurs once every 64 seconds. This poll interval cannot be changed by
configuration. The other two commands, “clock timezone” and “clock summer-time” are not
required; they are for display purposes only.
Clock timezone adjusts the timestamp to the local time and clock
summer-time allows for the daylight savings time adjustment automatically.
+--------+ 10.1.1.2+------+ |ROUTERA |e0----------------|SERVER| +--------+10.1.1.1 +------+ RouterA configuration: router(config)#ntp server 10.1.1.2 router(config)#clock timezone <zone> <hours offset from UTC> router(config)#clock summer-time <zone> recurring * for example, in Dallas: clock timezone CST -6 * for the US, use "recurring"; for other countries, the dates must be specified * the command "ntp clock-period" wil appear automatically in the config
On the local Server:
NTP software (www.ntp.org)
For info on internet clock sources:
(http://www.eecis.udel.edu/~mills/ntp/servers.htm)
———————————————————————————–
SCENARIO 2: ROUTER IS CONFIGURED AS MASTER, OTHER ROUTERS SYNC WITH IT
In this scenario, RouterA is configured to provide the clock for the
network, rather than an internal/external server. This is done through the use of the “ntp
master” command. When specifying the ntp master, a stratum number should be used to
designate how many NTP hops away a machine is from an authoritative time source. The clock
source itself is usually stratum level 1. If no stratum level is specified, the router
will default to 8.
+--------+ 10.1.1.2+--------+ 11.1.1.2+-------+ |ROUTERA |s0----------------s0|ROUTERB |s1--------------s0|ROUTERC| +--------+10.1.1.1 +--------+11.1.1.1 +-------+ RouterA configuration: router(config)#ntp master <value should be +2 to the stratum value of the Inet time server shown on sh ntp status after routerA is synced up with the Internet time server> router(config)#clock timezone <zone> <hours offset from UTC> router(config)#clock summer-time <zone> recurring RouterB configuration: router(config)#ntp server 10.1.1.1 router(config)#clock timezone <zone> <hours offset from UTC> router(config)#clock summer-time <zone> recurring RouterC configuration: router(config)#ntp server 10.1.1.1 router(config)#clock timezone <zone> <hours offset from UTC> router(config)#clock summer-time <zone> recurring
———————————————————————————–
SCENARIO 3: NTP USING SERVERS AND PEERS
In this scenario, RouterA is configured as the source and RouterB syncs with it. RouterC then
syncs with RouterB. This is done through the “ntp peer” command. RouterC will not sync
with RouterB unless RouterB is synchronized with RouterA.
+--------+ 10.1.1.2+--------+ 11.1.1.2+--------+ |ROUTERA|s0--------------s0|ROUTERB |s1--------------s0|ROUTERC | +--------+10.1.1.1 +--------+11.1.1.1 +--------+ RouterA configuration: router(config)#ntp master <1> router(config)#clock timezone <zone> <hours offset from UTC> router(config)#clock summer-time <zone> recurring RouterB configuration: router(config)#ntp server 10.1.1.1 router(config)#clock timezone <zone> <hours offset from UTC> router(config)#clock summer-time <zone> recurring RouterC configuration: router(config)#ntp peer 11.1.1.1 router(config)#clock timezone <zone> <hours offset from UTC> router(config)#clock summer-time <zone> recurring
———————————————————————————–
SCENARIO 4: NTP ON BROADCAST MEDIUM
In this scenario, RouterA is broadcasting ntp packets containing its time to all hosts on the
network. Rather than polling RouterA, RouterB and RouterC will simply listen to and sync
with RouterA.
+--------+10.1.1.1
|ROUTERA |--------------+----------------+
+--------+e0 e0 |10.1.1.2 e0 |10.1.1.3
+--------+ +--------+
|ROUTERB | |ROUTERC |
+--------+ +--------+
RouterA configuration:
router(config)#ntp master <1>
router(config)#clock timezone <zone> <hours offset from UTC>
router(config)#clock summer-time <zone> recurring
router(config)#int e0
router(config-if)#ntp broadcast
RouterB configuration:
router(config)#clock timezone <zone> <hours offset from UTC>
router(config)#clock summer-time <zone> recurring
router(config)#int e0
router(config-if)#ntp broadcast client
RouterC configuration:
router(config)#clock timezone <zone> <hours offset from UTC>
router(config)#clock summer-time <zone> recurring
router(config)#int e0
router(config-if)#ntp broadcast client
———————————————————————————–
SCENARIO 5: REDUNDANT NTP MASTER CLOCKS
In this scenario, more than one router is configured as the ntp master.
Because RouterA has a lower stratum number than RouterB, it becomes the primary NTP
source. RouterC will poll both routers at 64 second intervals. In the event that RouterA
goes down, RouterC will sync up with RouterB.
+--------+ 10.1.1.2+---------+ 11.1.1.2+--------+ |ROUTERA |s0----------------s0|ROUTERB |s1--------------s0|ROUTERC | +--------+10.1.1.1 +---------+11.1.1.1 +--------+ RouterA configuration: router(config)#ntp master 1 router(config)#clock timezone <zone> <hours offset from UTC> router(config)#clock summer-time <zone> recurring RouterB configuration: router(config)#ntp master 2 router(config)#clock timezone <zone> <hours offset from UTC> router(config)#clock summer-time <zone> recurring RouterC configuration: router(config)#ntp server 10.1.1.1 router(config)#ntp server 11.1.1.1 router(config)#clock timezone <zone> <hours offset from UTC> router(config)#clock summer-time <zone> recurring
2011-12-05 更新：
What does NTP considers as a “flaseticker” ?
本文出自 Frank's Blog产生条件：
用户有两个平行的NTP Server，NTP Server的版本是最新的version4，并且下面的client同时指向这两台NTP Server，这时会出现flaseticker，也就是欺骗的意思。NTP原理：
在NTP中，client是如何确认时间的呢？NTP Server发给client的不是一个精确的时间，而是根据网络的延迟，抖动等情况，计算出一个容错范围，例如Server会说现在是14:05，最大错误在5分钟（这仅仅是一个例子，实际情况没有这么大的范围）内，client收到后，会根据算法及这个范围，得出一个自己认为精确的时间。这样就可以达到同步。当client收到两个server发来的信息，范围没有交集时，如：
server A : “14:05, time is between 14:00 and 14:10”
server B : “14:35, time is between 14:30 and 12.40”
那么他就认为这两个Server至少有一个在撒谎，所以谁都不会同步。实际情况：
由于每个NTP版本的算法都不太一样，所以不同版本可能现象也不尽相同。如当NTP为version3时（可以通过“sh ntp ass de”查看ntp的版本），即使两个Server的时间手动同步后，也能顺利的让client同步，但当NTP更新到version4后，算法更为精密、准确了，所以手动同步Server的时间已经达不到要求，所以有的客户会发现越新的版本，在同步时间时越有问题，这主要是由于Server之间的时间差距已经超过了NTP所能容忍的程度，所以导致client收到后发现没有交集，拒绝同步，从而出现flaseticker。解决方法：
找一台设备当作总的NTP Server，这两台Sever同步总Server的时间，这样就保证了Server间的时间是同步的，这样再同步到client，这样就ok了。
由于在NTP配置中，一台设备不能即配“ntp server x.x.x.x”，又配“ntp master x”，这样很容易扰乱NTP，所以在Server与总Server同步时间时用“ntp peer x.x.x.x”就可以了。