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情報は次のとおりです。外からの時間。したがって、時間の不一致は、異なる元の時間ソースに起因することはありません。観察がやや妄想的になったので、次の意味で「正しい時間を持っています」：（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.

ご質問

どうして10.0.99.1は遠いですか？
10.0.99.1に同期するシステムが正しいのはなぜですか？
sho ntp status10.0.99.1 の出力から、クロックが実際には完全に同期していないことをどのように知る必要がありますか（で説明したすべてのホストと基準クロックと比較してsho ntp asso）？私にとって、出力は非常に手の込んだ「私は完全に幸せです」のように見えます。

編集：一般的な需要により、の出力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

cisco ntp time-synchronization

— ハーゲン・フォン・アイツェン
ソース

IPアドレスが各デバイスで使用されるntpサーバーとして設定されているシステムを見つけることはできません。そして、ループと、お互いをntpサーバーとして使用しているカップルを見つけました。これらの場合、サーバーではなくntpピアとして指定することになっていると思います。ピアとサーバーのどちらを指定した場合でも、正確にどのような違いがあるのかはわかりませんが、また、単一のホスト（10.0.0.1）を介してすべてを同期させることをお勧めします。しかし、私の観察があなたの現在の問題の原因を直接説明できるとは思いません。

— カスペルド

ntp構成の際立った問題の1つは、各ホストが最悪の数のタイムソースで構成されていることです。「時計を1つ持っている人は何時かを知っているので、時計を2つ持っている人は確実ではありません...」 3つのソース。

— dfc

NTP構成全体を再検討する必要があります。階層レベルで作業する必要があります。@kasperdが指摘したように、ループに問題がある可能性があります。より低い階層レベルのサーバーとのみ同期する必要があり、同じ階層レベルのサーバーはピアリングできますが、サーバーとして相互に使用することはできません。ピアデバイスは、信頼できるソースとして下位階層レベルの1つ以上のサーバーを必要としますが、他のピアとの整合を試みます。ビジーなデバイス（コアスイッチなど）をNTPサーバーとして使用しないでください。

— ロンモーピン

非常に奇妙なことが起こっています。すべてのntp出力はかなり正常であり、良好な同期を示しています。しかし、デバイスから時間を取得するというコマンドは、時間の余裕を与えました。これは、何らかの理由で、オフになっているデバイスがntpサブシステムからシステムクロックを設定していないことを示しています。

— デビッドシュワルツ

バグを発見したように思えますが、おそらく唯一の方法は、それを再起動して、それがなくなるか、シスコに連絡することです。

— デロバート

回答:

元の原因はまだ不明であるため、これを回答として投稿するのは少し消極的です。それでも、問題は解決されたようです-少なくとも今のところは。

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

しかし、それは新しいファームウェアがソリューションだったことを意味しますか？残念だけど違う。新しいファームウェアをロードする最初の試みで、構成レジスタを変更するのを忘れました。これはまだ工場出荷時のデフォルトのままでした。したがって、最初の再起動は、ルーターがほぼ4年間（つまり、最初の電源投入時から）実行していた元のROMイメージと同じものになりました。それでも、これは時計が1つの大きな調整を行ってから同期を保つのに十分でした。これは、単なる再起動が助けになった可能性があることを示唆しています-一時的に。言い換えると、これは、新しいファームウェアで表示されるようになった現在の正しい時刻が、今後数年にわたってntp時間からずれることがあることを意味します。時計が1日に約5秒遅れたかどうかを安全に判断できるようになるまで数日かかります...

今のところ、ケースは閉じられています。

— ハーゲン・フォン・アイツェン
ソース

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

時間のずれは、IOSの既知のバグが原因である可能性があります。このバグは、このIOSアップデートで修正され、ntp.driftが正しく削除または更新されないため、ドリフトの問題が発生します。また、IOSセキュリティの更新がかなり頻繁に行われるため、再起動も更新も行わない4年間で、かなり悪いセキュリティ状態に陥ったはずです。

Cisco IOS http://packetlife.net/blog/2011/mar/28/cisco-ios-clocks-and-ntp/での NTPのセットアップに関する優れた投稿を次に示します。

これがお役に立てば幸いです。他にご質問や問題がある場合はお問い合わせください。

— ジョージ・カシカ
ソース

完全な開示：スイッチ設定をたまにいじるだけで、NTPの専門家ではありません。

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

決して理想的なソリューションではありませんが、スイッチに接続してリブートを開始するためにcronジョブで同様のアプローチを採用することができますか、スイッチ上のNTPデーモンを「キック」しますか？

お役に立てれば！

— ダン
ソース