web-dev-qa-db-ja.com

ntpにもかかわらず、スイッチの1つが2分間オフになるのはなぜですか？

Cisco 4500スイッチの1つでクロックが間違っていることに偶然気づきました。一見機能しているように見えますが、2分以上遅れています 。私の意見では、関係するシステムにとって1秒でも許容できると見なすべきではありません。また、単純な掛け時計と比較していなければ、診断との違いに気付かなかったでしょう。

いくつかの詳細

以下は、フォールバックのために部分的に相互に参照しているホスト（10.0.99.1、10.0.99.2、10.0.1.119、10.0.99.241）のntp情報ですが、主にすべて最終的に10.0.0.1と同期することにより、再び外からの時間。したがって、時間の不一致は、異なる元のタイムソースが原因ではありません。観察により多少偏執狂的になったので、次の意味で「正しい時間を持っている」：show clock（またはdate）は、自分のウォールクロックとローカルシステムクロック（これで問題ありません） http://time.is ）によると、確かに1秒未満のエラーがあります（ローカル時計を見ながらENTERを押す精度）

10.0.1.119（Ubuntu）の時刻が正しい

$ ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+10.0.99.1       10.0.0.1         3 u  855 1024  377    0.904   -2.658   0.113
*10.0.0.1        130.149.17.8     2 u  266 1024  377    0.253    0.909   0.127

10.0.99.241（Cisco 2960）の時刻が正しい

#sho ntp associations 

  address         ref clock       st   when   poll reach  delay  offset   disp
*~10.0.99.1       10.0.0.1         3     28     64   377  1.462  85.288 19.758
+~10.0.99.2       10.0.1.119       4     29     64   377  1.297  83.515  5.369
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

10.0.99.2（Cico 4500）の時刻は正しい

#sho ntp associations 

  address         ref clock       st   when   poll reach  delay  offset   disp
+~10.0.99.1       10.0.0.1         3      6   1024   111  1.148  -1.618 42.875
*~10.0.1.119      10.0.0.1         3     31   1024   377  0.043   1.687  1.064
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

10.0.99.1（Cisco 4500）が約2分6秒遅れている

#sho ntp associations 

  address         ref clock       st   when   poll reach  delay  offset   disp
*~10.0.0.1        130.149.17.8     2    274   1024   377 15.625   3.681 30.403
+~10.0.99.2       10.0.1.119       4    415   1024   376 15.625   0.855 33.276
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

#sho ntp status 
Clock is synchronized, stratum 3, reference is 10.0.0.1      
nominal freq is 250.0000 Hz, actual freq is 249.9988 Hz, precision is 2**6
reference time is DAD8B428.54C6BAEA (20:36:24.331 MESZ Sat May 7 2016)
clock offset is 3.6818 msec, root delay is 32.80 msec
root dispersion is 71.74 msec, peer dispersion is 30.40 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000004720 s/s
system poll interval is 1024, last update was 683 sec ago.

質問

  1. 10.0.99.1はどうしてこんなに遠いのですか？
  2. 10.0.99.1に同期するシステムはどうして正しいのですか？
  3. 10.0.99.1のsho ntp statusの出力から、クロックが実際に完全に同期していないことをどのように知る必要がありますか（allホストと比較して） sho ntp asso）に記載されている基準時計？私にとって、出力は非常に手の込んだ "私は完全に満足しています"のように見えます。

EDIT：一般的な需要により、sho clock detailの出力

10.0.99.1

#sho clock detail 
13:06:38.605 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016

10.0.99.2

#sho clock detail 
13:10:54.083 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
ciscontptime-synchronization
11
Hagen von Eitzen

元の原因はまだ不明なので、これを回答として投稿するのは少し気が進まない。それでも、問題は解決されたようです。少なくとも今のところは。

htm11hのコメントに従い、ファームウェアをアップデートすることにしました。実際、新しいファームウェアで実行しているので、時計は正しい時刻と一致しているようです。

しかし、それは新しいファームウェアが解決策だったことを意味しますか？残念だけど違う。新しいファームウェアをロードする最初の試みで、まだ工場出荷時のデフォルトのままだった構成レジスタを変更するのを忘れていました。したがって、最初の再起動は、ルーターがほぼ4年間（つまり、最初の電源投入から）実行されていたのと同じ元のROMイメージ）になりました。それでも、これで十分でした。これは、再起動するだけで一時的に役立つ可能性があることを示しています。つまり、新しいファームウェアで表示される現在の正しい時刻は、何年にもわたってntp時刻からずれている可能性があります。時計が1日約5秒遅れたかどうか安全にわかるまで数日かかります...

現在、ケースはクローズされています。

2
Hagen von Eitzen

私は90年代半ばからNTPプールプロジェクトでかなりの作業を行い、ここでいくつかのNTP St​​ratum-1GPS同期サーバーを実行しました。他の人が述べているように、時間を取得するには2台以上のサーバーが必要です。上記のRon Maupinが述べた理由から、私は通常ここで4を使用します。また、リストされているように、ループに注意し、サーバーとピアとして設定する必要があります。

時間ドリフトはIOSの既知のバグが原因である可能性があります。これは、ntp.driftを処理するこのIOS更新で削除または更新が正しく行われず、ドリフトの問題が修正されました。また、再起動や更新がない4年間は、IOSセキュリティ更新がかなり頻繁に行われるため、セキュリティに関してかなり悪い場所にいるはずです。

これは、CiscoでNTPを設定するための優れた投稿ですIOS http://packetlife.net/blog/2011/mar/28/Cisco-ios-clocks-and -ntp /

これがお役に立てば幸いです。他に質問や問題があるかどうかを尋ねてください。

1
George Kasica

完全な開示：私はたまにスイッチ構成をいじるだけであり、決してNTPエキスパートではありません）。

とは言っても、RHEL 5.xシステムでNTPデーモンを表示していた（はい、戻ってきますが、スイッチに4年前のイメージがあったと言いました... ）「ハッピー」状態で立ち往生し、完全に同期されたと思われるように見えたが、明らかに同期されていなかった。ClusterSSHセッションを使用して、すべてのシステムで「日付」を同時に実行すると、システム間で5分間のドリフト。正しく思い出せば、デーモンを再起動することによってのみ問題を解決できたようで、最終的にはcronに毎晩サービスを再起動させました...

決して理想的な解決策ではありませんが、cronジョブを使用して同様のアプローチを採用し、スイッチに接続して再起動を開始するか、NTPデーモンをキック」することができる場合があります。スイッチ？

お役に立てれば！

0
Dan