ある Cisco 機器 (router1:192.168.1.1) に上位 NTP サーバ (ts:10.10.10.1) を参照するよう NTP の設定を入れ、さらにその機器を参照するよう別の機器 (router2) にしたところ、うまく router2 が router1 に同期しないという事象がありました。
ネットワーク構成上の理由で router2 は直接 ts を参照できないので、代わりに router1 に同期させなければならないという状況でした。
[router1 NTP 関連設定]
ntp update-calendar
ntp server 10.10.10.1
[router2 NTP 関連設定]
ntp update-calendar
ntp server 192.168.1.1
以下のような階層になります。
[router2] ----> [router1 (192.168.1.1)] ----> [ts (10.10.10.1)] ----> 更に上位の NTP サーバ
さて、設定投入後１週間程度経過してみても router2 はこんな状況でした。
router1 に同期しません。
router2#show ntp associations
Load for five secs: 0%/0%; one minute: 1%; five minutes: 0%
Time source is NTP, .11:47:41.679 JST Mon Aug 16 2010
address ref clock st when poll reach delay offset disp
~192.168.1.1 10.10.10.1 4 297 1024 377 80.8 -63873 3115.8
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
router2#
本来なら 192.168.1.1 の行頭に「*」がついて、マスターとして router1 が選ばれ同期されなければならないのですが、そうならなかったのです。
ここで root disp (dispersion) が 1000 を超えていると同期しないという情報を見つけました。
router2 で確認すると下のように root disp の値が 1000 を超えています。
router2#show ntp associations detail
Load for five secs: 0%/0%; one minute: 1%; five minutes: 0%
Time source is NTP, .11:47:43.799 JST Mon Aug 16 2010
192.168.1.1 configured, insane, invalid, stratum 4
ref ID 10.10.10.1, time D013219E.E1C6AC50 (11:31:58.881 JST Mon Aug 16 2010)
our mode client, peer mode server, our poll intvl 1024, peer poll intvl 1024
root delay 36.30 msec, root disp 8131.24, reach 377, sync dist 11305.618
delay 80.78 msec, offset -638738.7960 msec, dispersion 3115.84
precision 2**18, version 3
org time D01321A4.D66F1EE6 (11:32:04.837 JST Mon Aug 16 2010)
rcv time D0132423.9DE81031 (11:42:43.616 JST Mon Aug 16 2010)
xmt time D0132423.89392A69 (11:42:43.536 JST Mon Aug 16 2010)
filtdelay = 80.78 82.21 81.04 75.70 82.34 81.18 82.69 82.00
filtoffset = -638738 -637128 -635511 -633898 -632285 -630629 -628951 -627338
filterror = 0.02 15.67 31.31 46.97 62.62 78.26 93.92 109.56
router2#
root dispersion とは分散値で、要するに router1 の時刻に揺れがあるので同期しないということのようです。
router1 を見てみるとこんな状況でした。
router1#show ntp associations
Load for five secs: 18%/9%; one minute: 2%; five minutes: 1%
Time source is NTP, 11:36:01.890 JST Mon Aug 16 2010
address ref clock st when poll reach delay offset disp
*~10.10.10.1 11.22.33.44 3 50 64 37 1.0 -461.4 1042.4
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
router1#show ntp associations detail
Load for five secs: 18%/9%; one minute: 2%; five minutes: 1%
Time source is NTP, 11:36:04.959 JST Mon Aug 16 2010
10.10.10.1 configured, our_master, sane, valid, stratum 3
ref ID 11.22.33.44, time D01321B6.77DBD9B0 (11:32:22.468 JST Mon Aug 16 2010)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 35.32 msec, root disp 94.80, reach 37, sync dist 1155.380
delay 0.98 msec, offset -461.4556 msec, dispersion 1042.43
precision 2**6, version 3
org time D013225E.BBF46D24 (11:35:10.734 JST Mon Aug 16 2010)
rcv time D013225F.32366574 (11:35:11.196 JST Mon Aug 16 2010)
xmt time D013225F.31F65E57 (11:35:11.195 JST Mon Aug 16 2010)
filtdelay = 0.98 0.95 0.99 0.98 0.96 0.00 0.00 0.00
filtoffset = -461.46 -355.70 -250.50 -144.79 -105.69 0.00 0.00 0.00
filterror = 0.02 0.99 1.98 2.96 3.94 16000.0 16000.0 16000.0
router1#
offset は参照する NTP サーバとの差を表すのですが、64 秒間隔のポーリングの度に 105ms ずつ進んでいることがわかります。
様子を見ているとこのまま差が大きくなり offset が 1500ms 程度になるとリセットがかかって同期を取り直しているように見えました。
リセットされた後はまたこの出力の様に filtdelay が 0 となります。
つまり router1 自体は上位のサーバをマスターとして同期していて、数ms ～ 1秒強の間を揺れ動いているようです。
そこで思い切って clock-period を変えることにしました。
clock-period の値は本来手動設定すべきでなく、マニュアルにもそのように記されています。
しかし、設定後１週間程度経っても自動調整がうまく働いていないようなので手動設定を試すことにしたのです。
まずは現在の clock-period の値を確認します。
router1#show running-config | include clock-period
ntp clock-period 17208028
設定すべき clock-period の値を n とすると以下の式がなりたちます。
(clock-period の詳細はこちらの記事を参照)
17208028 * (64 - 0.105) 秒 ＝ ｎ * 64 秒
これより n の値を求めます。
n ＝ 17208028 * 63.895 / 64 ≒ 17179796
この値を設定します。
router1(config)#ntp clock-period 17179796
結果を言うと、結局これがうまく効いて、その後 router1 は安定動作し、router2 も router1 に同期するようになりました。以下はしばらく経過してからの出力です。
router1#show ntp associations detail
Load for five secs: 0%/0%; one minute: 1%; five minutes: 1%
Time source is NTP, 15:10:48.679 JST Tue Aug 31 2010
10.10.10.1 configured, our_master, sane, valid, stratum 3
ref ID 11.22.33.44, time D0271AD1.69C39368 (15:08:17.413 JST Tue Aug 31 2010)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 33.89 msec, root disp 80.25, reach 377, sync dist 99.716
delay 0.84 msec, offset -4.5950 msec, dispersion 2.11
precision 2**6, version 3
org time D0271B37.29C39368 (15:09:59.163 JST Tue Aug 31 2010)
rcv time D0271B37.2B0C8C76 (15:09:59.168 JST Tue Aug 31 2010)
xmt time D0271B37.2AD4E20B (15:09:59.167 JST Tue Aug 31 2010)
filtdelay = 0.84 1.40 0.93 0.89 0.95 0.92 20.42 0.93
filtoffset = -4.60 -3.95 -2.50 -1.04 0.62 3.08 -3.37 9.44
filterror = 0.02 0.99 1.97 2.94 3.92 4.90 5.87 6.85
router1#
このように router1 はぐっと安定しました。
router2 についても確認すると以下の出力が得られました。
router2#show ntp associations
address ref clock st when poll reach delay offset disp
*~192.168.1.1 10.10.10.1 4 16 1024 377 11.2 -1.12 2.0
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
router2#
「*」がついていることからわかるように、router2 はきちんと router1 をマスターとして選択し同期しています。
今回はルータを NTP サーバとして参照する構成としたのでこの現象に気づきましたが、ただ上位の外部 NTP サーバを参照するだけだったら気づかなかったと思います。
気になる場合は「show ntp associations detail」を実行して offset の変化を確認すると良いです。
12.4(15)T12 以下の複数のバージョン、複数の機器でこの現象の発生を確認しています。
コマンドの利用は自己責任でお願いします。
ルータのコマンド出力は実際のログ出力を説明のために再構成したもので、表示項目に関して完全には整合性が取れていない可能性があります。
が安いことがわかりました。
DDR2 や DDR3 に比べたら２倍ぐらいの価格ってことになっちゃうんだろうけど、量販店で買うよりずっと安いです。
カミさんはこのデスクトップ PC をメインに使っていたりするので、これをきっかけにメモリも増やすべきかちょっと悩んでみます。
