このドキュメントでは、Network Time Protocol(NTP; ネットワーク タイム プロトコル)の一般的な問題のトラブルシューティング方法に関する情報を提供しています。
このドキュメントの読者は、NTP の動作の仕組みと、ネットワーク タイム プロトコルについて十分に理解していることが推奨されます。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
Network Time Protocol(NTP; ネットワーク タイム プロトコル)は、インターネット タイム サーバや、無線、衛星レシーバ、電話モデム サービスなどの他のソースにコンピュータを同期するために広く使用されています。一般的に、LAN 上ではミリ秒未満、WAN 上では最大数ミリ秒の精度が提供されます。標準的な NTP の設定では、高い精度と信頼性を実現するために、複数の冗長サーバと多様なネットワーク パスを利用します。
NTPでは、現在のバージョンのNTPと時刻を同期するために、Marzulloのアルゴリズムが使用されます。これによって、パブリック インターネット上では時刻を 10 ミリ秒内に維持でき、LAN 上ではさらに正確な実行が可能です。NTP タイム サーバは TCP/IP スイート内で動作し、User Datagram Protocol(UDP; ユーザ データグラム プロトコル)ポート 123 に依存しています。
通常、NTP サーバは、ネットワークの同期先として使用できる単一の時間基準が使用される、専用の NTP デバイスです。多くの場合、この時間基準は Coordinated Universal Time(UTC; 世界標準時)ソースです。UTC は、インターネット、特殊業務用長波無線伝送、または Global Positioning System(GPS)ネットワークを介して、原子時計から配布されるグローバルな時間スケールです。セキュリティ、保護、精度、合法性、および制御に関して専用の NTP サーバが必要になります。
NTP アルゴリズムでは、システムまたはネットワーク クロックの時間をどの程度調整するのかを判断するために、この時間基準が使用されます。NTP では、タイムスタンプ値、エラーの頻度、およびその安定性が分析されます。NTP サーバでは、基準クロックと NTP サーバ自体の品質の推定値が維持されます。
このセクションでは、NTP で発生する可能性がある一般的な問題の一覧とそのソリューションを紹介しています。
Active Directory に配置された NTP サーバを使用するように Cisco ルータが設定されていると、Cisco ルータでは NTP サーバからの NTP パケットが受信されません。この問題は、Cisco ルータでは NTP が使用され、Active Directory ドメインでは W32Time サービスが使用されることが原因で発生します。W32Time では、時刻の同期に NTP のサブセットである Simple Network Time Protocol(SNTP; 簡易ネットワーク タイム プロトコル)が使用されます。SNTP と NTP で使用されるネットワーク パケット形式は同じです。SNTP と NTP の主な違いは、NTP では提供されるエラーチェックとフィルタリングの機能が SNTP では提供されないことです。Cisco ルータとスイッチでは NTP が使用され、NTP v3 によって提供されるエラーチェックとフィルタリングの機能を使用できます。
Windows W32Time では、(Windows W32Time 自体が NTP とはされず)SNTP の内部的な実装であると表示されます。 W32Time との同期が試行される Cisco IOS-NTP では、W32Time に送信される独自のルート(root)分散値が取得され、この値は Cisco IOS-NTP の同期には大きすぎるものと認識されます。Cisco IOS-NTP のルート(root)分散値が 1,000 ミリ秒を超えるため、Cisco IOS-NTP 自体の同期が解除されます(クロック選択プロシージャ)。 Cisco IOS ベースのルータでは NTP の完全な RFC 実装が稼働しているため、SNTP サーバへの同期は行われません。この場合、show ntp associations detail コマンドの出力には、サーバが insane, invalid(不正確、無効)としてフラグが付けられます。ルート(root)分散値が 1,000 ミリ秒を超えており、Cisco IOS NTP 実装による関連付け拒否の原因となっています。W32Time サービスが稼働しているのが Windows システムである場合、Cisco IOS が稼働するルータによる NTP サーバへの同期が不可能になる可能性があります。サーバが同期されない場合、ルータではサーバとのパケットの送受信ができません。
この問題を回避し、Cisco IOS ベースのルータを同期させるには、インターネット上の正規の NTP サーバ、NTPD が稼働する UNIX ボックス、または特定のプラットフォーム上の GPS を使用します。また、代替案として、Windows システム上では W32Time サービスを稼働させないという選択も可能です。代わりに、NTP 4.x を使用できます。Windows 2000 以降のすべてのバージョンでは、NTP サーバとしてのサービスの提供が可能です。これにより、ネットワーク上の他のマシンでは、NTP サーバを使用して時刻を同期することができます。
ルータでパブリック タイム サーバへの同期ができない場合に、疑われる原因には次のものがあります。
アクセス コントロール リストによって UDP ポート 123 のパケットの着信が許可されない。
ルータで clock timezone コマンドと clock summer-time コマンドが欠落しているなどのルータでの誤設定。
パブリック タイム サーバがダウンしている。
NT または UNIX 上の NTP サーバ ソフトウェアの設定が誤っている。
さらに多くのトラフィックがルータ上にあり、さらに多くのトラフィックがサーバへ向かっている。
NTP マスターで同期が失われ、ルータで散発的に同期が失われる。
CPU 使用率が高い。
サーバとルータ間での高いオフセット(これを確認するには show ntp association detail コマンドを使用)。
このエラーメッセージは、センサーがストラタム15を報告するサーバーに同期しようとすると表示されます。これは、サーバーのストラタム値15がセンサーのストラタム値16を不正にするためです。結果として、センサーによってサーバが拒否され、Strata too high - too many indirections from sensor to master NTP server エラー メッセージが表示されます。
NTP では、正規の時刻源から各マシンが何段階隔たっているかを表すために、ストラタムという概念が使用されます。このエラー メッセージは、NTP サーバによって報告される NTP ストラタムが大きすぎることを示しています。ストラタムは 1 ~ 15 の数値で、正確な基準クロックからサーバがどのくらい隔たっているのかを示しています。一般的に、原子時計へ直接同期されるシステムでは、ストラタムが 1 として報告されます。ストラタムが 1 の NTP サーバへ同期されながら、他のホストに対しては NTP サーバとしてのサービスを提供するホストでは、親よりも 1 つ大きいストラタムを持つサーバの各後継レイヤで、それらのホストに対してストラタムが 2 として報告されます。
NTP サーバとして Linux ホストを使用する場合、自動的にストラタムを計算させるのではなく、報告されるストラタムをハードコードします。Linux または UNIX ボックスの場合、NTP サーバはファイル /etc/ntp.conf で設定され、fudge コマンドがストラタムのハードコードに使用されます。サーバでは、ストラタム値は常にそのクライアントの fudge 値よりも 1 つ大きい値として報告されます。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
05-Nov-2008 |
初版 |