Network Time Protocol（NTP; ネットワーク タイム プロトコル）のトラブルシューティング

はじめに

このドキュメントでは、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 で発生する可能性がある一般的な問題の一覧とそのソリューションを紹介しています。

NTP を W32 ベースの時刻サービスに同期できない

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 コマンドを使用）。

エラー：Strata too high - too many indirections from sensor to master NTP server

このエラー メッセージは、ストラタムが 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 つ大きい値として報告されます。

関連情報

• ネットワーク・タイム・プロトコル: ベストプラクティス白書
• The Network Time Protocol (NTP) Distribution
• NTP Debugging Techniques
• テクニカル サポートとドキュメント - Cisco Systems