ネットワークタイムプロトコル(NTP)の問題のトラブルシューティングとデバッグ
ダウンロード オプション
偏向のない言語
この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
翻訳について
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。
概要
このドキュメントでは、Network Time Protocol(NTP)の問題をトラブルシューティングする方法について説明します。 debug コマンドと show ntp コマンドが表示されない場合もあります。
前提条件
要件
このドキュメントに特有の要件はありません。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
NTP show コマンド
NTPの問題の原因を調べる前に、次のコマンドの使用方法と出力について理解しておく必要があります。
- show ntp association
- show ntp association detail
- show ntp status
注：このセクションで使用されているコマンドの詳細を調べるには、Command Lookup Tool（登録ユーザ専用）を使用してください。シスコの登録済みユーザのみが内部ツールおよび情報にアクセスできます。
注：特定のshowコマンドは、アウトプットインタープリタツール（登録ユーザ専用）でサポートされています。show コマンドの出力の分析を表示するには、Output Interpreter Tool を使用します。 シスコの登録済みユーザのみが内部ツールおよび情報にアクセスできます。
show ntp association
NTP アソシエーションは、ピア アソシエーション（1 つのシステムを別のシステムと同期する、または別のシステムをそのシステムに同期させる）またはサーバ アソシエーション（1 つのシステムを別のシステムと同期する、その逆は不可）のいずれかにできます。
以下は show ntp association コマンドの出力例です。
CLA_PASA#sh ntp association
address ref clock st when poll reach delay offset disp
~10.127.7.1 10.127.7.1 9 50 64 377 0.0 0.00 0.0
~10.50.44.69 10.50.36.106 5 21231 1024 0 3.8 -4.26 16000.
+~10.50.44.101 10.50.38.114 5 57 64 1 3.6 -4.30 15875.
+~10.50.44.37 10.50.36.50 5 1 256 377 0.8 1.24 0.2
~10.50.44.133 10.50.38.170 5 12142 1024 0 3.2 1.24 16000.
+~10.50.44.165 10.50.38.178 5 35 256 357 2.5 -4.09 0.2
+~10.50.38.42 10.79.127.250 4 7 256 377 0.8 -0.29 0.2
*~10.50.36.42 10.79.127.250 4 188 256 377 0.7 -0.17 0.3
+~10.50.38.50 10.79.127.250 4 42 256 377 0.9 1.02 0.4
+~10.50.36.50 10.79.127.250 4 20 256 377 0.7 0.87 0.5
* primary (synced), # primary (unsynced), + selected, - candidate, ~ configured
| ターム | 説明 |
|---|---|
| アドレスの前の文字は、次のように定義されています。
|
|
| アドレス |
これは、ピアの IP アドレスです。この例では、最初のエントリは 127.127.7.1 です。これは、ローカル マシンがそれ自体に同期していることを示しています。通常は、NTPプライマリだけが自身と同期します。 |
| ref clock |
これは、ピアの参照クロックのアドレスです。この例では、最初の6台のピア/サーバは参照クロックとしてプライベートIPを持っているため、それらのプライマリはローカルネットワーク内のルータ、スイッチ、またはサーバである可能性があります。最後の4つのエントリでは、基準クロックはパブリックIPであるため、そのプライマリはおそらくパブリックの時刻源です。 |
| st |
NTP では、ストラタムという概念を使用して、信頼できる時間ソースからマシンがどれだけ離れているかを NTP ホップ数で示します。たとえば、ストラタム 1 のタイム サーバに電波時計または原子時計が直接接続されているとします。このタイム サーバからストラタム 2 のタイム サーバに NTP によって時刻が送信され、同様にストラタム 16 まで順番に時刻が送信されます。NTPを実行しているマシンは、通信可能なストラタム番号が最も低いマシンを自動的に選択し、そのタイムソースとしてNTPを使用します。 |
| when |
ピアから最後の NTP パケットを受信してから経過した時間を秒単位で報告します。この値は、ポーリング間隔より小さくなければなりません。 |
| poll |
ポーリング間隔を秒単位で報告します。間隔は通常、最小の 64 秒のポーリング間隔で開始されます。この RFC は、2 台のマシンを同期させるためには、1 分間に 1 回より多い NTP トランザクションは不要であることを示します。NTPがクライアントとサーバの間で安定すると、ポーリング間隔が64秒から1024秒までの小さなステップで増加する可能性があり、通常はその間のどこかで安定します。しかし、この値はクライアントとサーバの間のネットワークの状態、および NTP パケットの損失に基づいて動的に変化します。しばらくの間サーバに到達できない場合、ネットワークのオーバーヘッドを減らすため、ポーリング間隔は 1024 秒まで少しずつ増加します。 ヒューリスティック アルゴリズムによって内部が決定されるため、ルータで NTP ポーリング間隔を調整することはできません。 |
| reach |
ピアの到達可能性は 8 進数値で示されるビット文字列です。このフィールドは、Cisco IOS® ソフトウェアの NTP プロセスによって最後の 8 個のパケットが受信されたかどうかを示します。パケットは、NTP IP パケットを受信するルータやスイッチのみではなく、NTP プロセスによって受信および処理され、また有効として受け入れられる必要があります。 伝達可能性は、タイムアウトのポーリング間隔を使用して、パケットが受信されたかどうかを判別します。ポーリング間隔は、パケットが失われたと判断するまでに NTP が待機する時間です。ピアが異なるとポーリング時間も異なる場合があるため、パケットが失われたと到達可能性が判断する時間もピアごとに異なる可能性があります。 この例では、4 つの到達可能性の値があります。
Reachは、リンク不良、CPUの問題、およびその他の断続的な問題が原因でNTPパケットがドロップされたかどうかを示す優れたインジケータです。 Unit Converterは、これや他の多くの変換のためのオンラインユニットコンバータです。 |
| 遅延 |
ピアへのラウンド トリップ遅延がミリ秒単位で報告されます。クロックをより正確に設定するには、クロック時間を設定するときにこの遅延を考慮に入れます。 |
| offset |
Offsetは、ピア間またはプライマリとクライアント間のクロック時間差です。この値は、クライアント クロックを同期するために適用される補正値です。正の値はサーバ クロックのほうが高いことを示しています。負の値はクライアント クロックのほうが高いことを示しています。 |
| disp |
分散は、ローカル クロックとサーバ クロックとの間で測定されたクロックの最大時間差です（秒単位で報告されます）。この例では、サーバ 10.50.36.42 の分散は 0.3 です。ローカル クロックとサーバ クロックとの間のローカルで測定される最大時間差は 0.3 秒です。 クロックが最初に同期している場合は、高い値が表示されます。しかし、それ以外のときに分散が高すぎる場合、クライアントの NTP プロセスは、サーバからの NTP メッセージを受け入れません。最大分散は16000です。この例では、サーバ10.50.44.69と10.50.44.133の分散であるため、ローカルクライアントはこれらのサーバからの時間を受け入れません。 reachがゼロで、分散が非常に高い場合、クライアントはそのサーバからのメッセージを受け入れない可能性があります。例の 2 行目に注目してください。 address ref clock st when poll reach delay offset disp オフセットは -4.26 ですが、分散が非常に高く（おそらく過去のイベントが原因）、到達可能性はゼロです。したがって、このクライアントはこのサーバから時刻を受け入れません。 |
show ntp association detail
以下は show ntp association detail コマンドの出力例です。
Router#sho ntp assoc detail
10.4.2.254 configured, our_primary, sane, valid, stratum 1
ref ID .GPS., time D36968AA.CC528FE7 (02:10:50.798 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.44, reach 377, sync dist 207.565
delay 2.99 msec, offset 268.3044 msec, dispersion 205.54
precision 2**19, version 3
org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012)
rcv time D36968B7.A2F44E2C (02:11:03.636 UTC Fri May 25 2012)
xmt time D36968B7.A21D3780 (02:11:03.633 UTC Fri May 25 2012)
filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72
filtoffset = 268.30 172.15 -452.49 -253.59 -462.03 -81.98 -58.04 22.38
filterror = 0.02 0.99 1.95 1.97 2.00 2.01 2.03 2.04
10.3.2.254 configured, selected, sane, valid, stratum 1
ref ID .GPS., time D36968BB.B16C4A21 (02:11:07.693 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 3.34, reach 377, sync dist 192.169
delay 0.84 msec, offset 280.3251 msec, dispersion 188.42
precision 2**19, version 3
org time D36968BD.E69085E4 (02:11:09.900 UTC Fri May 25 2012)
rcv time D36968BD.9EE9048B (02:11:09.620 UTC Fri May 25 2012)
xmt time D36968BD.9EA943EF (02:11:09.619 UTC Fri May 25 2012)
filtdelay = 0.84 0.75 663.68 0.67 0.72 968.05 714.07 1.14
filtoffset = 280.33 178.13 -286.52 42.88 41.41 -444.37 -320.25 35.15
filterror = 0.02 0.99 1.97 1.98 1.98 2.00 2.03 2.03
10.1.2.254 configured, insane, invalid, stratum 1
ref ID .GPS., time D3696D3D.BBB4FF24 (02:30:21.733 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 4.15, reach 1, sync dist 15879.654
delay 0.98 msec, offset 11.9876 msec, dispersion 15875.02
precision 2**19, version 3
org time D3696D3D.E4C253FE (02:30:21.893 UTC Fri May 25 2012)
rcv time D3696D3D.E1D0C1B9 (02:30:21.882 UTC Fri May 25 2012)
xmt time D3696D3D.E18A748D (02:30:21.881 UTC Fri May 25 2012)
filtdelay = 0.98 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filtoffset = 11.99 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filterror = 0.02 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
[関連付けの表示(show up association)]セクションですでに定義されている用語は、ここでは繰り返しません。
| ターム |
説明 | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| configured |
この NTP クロック ソースはサーバとして設定されています。ピア/サーバが動的に検出された場合、この値も動的である可能性があります。 |
|||||||||||||||||||||||||||
| our_primary |
ローカル クライアントがこのピアに同期されます。 |
|||||||||||||||||||||||||||
| selected |
'our_primary'が失敗するか、クライアントが同期を失うと、ピア/サーバが同期の対象として選択されます。 |
|||||||||||||||||||||||||||
| sane |
サーバから受信した NTP パケットをテストするために健全性テストが使用されます。これらのテストは、『RFC 1305、ネットワーク タイム プロトコル（バージョン 3）仕様書、実装と分析』に詳細が示されています。テストは以下のとおりです。
テスト 1 ～ 4 をパスした場合、パケット データは有効です。このデータを使用して、オフセット、遅延、および分散が計算されます。 テスト 5 ～ 8 をパスした場合、パケット ヘッダーは有効です。ピアを同期用に選択できるかどうかを判別するためには、有効なヘッダーを含むパケットのみを使用できます。 |
|||||||||||||||||||||||||||
| insane |
健全性チェックが失敗したため、サーバからの時刻は受け入れられません。サーバは同期されません。 |
|||||||||||||||||||||||||||
| valid |
ピア/サーバ時刻が有効です。このピアがプライマリになると、ローカルクライアントはこの時間を受け入れます。 |
|||||||||||||||||||||||||||
| 無効 |
ピア/サーバーの時刻が無効です。時刻を受け入れることができません。 |
|||||||||||||||||||||||||||
| ref ID |
各ピア/サーバにリファレンス ID（ラベル）が割り当てられます。 |
|||||||||||||||||||||||||||
| 時間 |
時刻は、ピア/サーバから受信した最新のタイムスタンプです。 |
|||||||||||||||||||||||||||
| our mode/ peer mode |
これは、ローカル クライアント/ピアの状態です。 |
|||||||||||||||||||||||||||
| our poll intvl/ peer poll intvl |
これは、シスコのポーリングからこのピアへの、またはピアからローカル マシンへのポーリング間隔です。 |
|||||||||||||||||||||||||||
| root delay |
ルート遅延は NTP セットアップのルートに対する遅延です（ミリ秒単位）。ストラタム 1 のクロックが、NTP セットアップ/設計のルートであると見なされます。この例では、3 台のサーバすべては、ストラタム 1 であるため、ルートになります。 |
|||||||||||||||||||||||||||
| root dispersion |
ルート分散は、ローカル クロックとルート クロックの間で測定されたクロックの最大時間差です。詳細については、show up associationの下の「disp」の説明を参照してください。 |
|||||||||||||||||||||||||||
| sync dist. |
これは、ストラタム0のソースの時間とクライアントが測定した時間との最大差の推定値です。ストラタム0は、ストラタムソースの最後の実際の読み取り以降のラウンドトリップ時間、システム精度、およびクロックドリフトの要素で構成されます。 複数のストラタムにサーバ/クライアントを持つ大規模なNTPセットアップ（インターネット内のストラタム1のNTPサーバ、異なるストラタムで時刻をソースするサーバ）では、NTP同期トポロジは最高の精度を実現するために編成する必要がありますが、時刻同期ループの形成を許可する必要はありません。その他に、ストラタムの各増分には潜在的に信頼できないタイム サーバが含まれていて、これによって追加の測定誤差が生じる可能性があるということを念頭に置く必要があります。NTP で使用される選択アルゴリズムでは、プライマリ サーバをルートにする最小重量スパニング ツリーを計算するために、ベルマンフォード分散ルーティング アルゴリズムのバリアントが使用されます。アルゴリズムで使用される距離メトリックは、ストラタムに同期距離を足したもので構成され、同期距離は、分散に絶対遅延の半分を足したもので構成されます。したがって、同期パスは常に最小の数のサーバをルートに使用し、接続は最大エラーに基づいて解決されます。 |
|||||||||||||||||||||||||||
| 遅延 |
これは、ピアへのラウンド トリップ遅延です。 |
|||||||||||||||||||||||||||
| precision |
これは、ピア クロックの精度です（Hz 単位）。 |
|||||||||||||||||||||||||||
| version |
これは、ピアが使用する NTP バージョンの番号です。 |
|||||||||||||||||||||||||||
| org time |
これは、NTPパケットの発信元のタイムスタンプです。つまり、NTPパケットを作成したときに、パケットをローカルクライアントに送信する前のピアのタイムスタンプです。 |
|||||||||||||||||||||||||||
| rcv time |
これは、ローカル クライアントがメッセージを受信した時点のタイム スタンプです。org time と rcv time の差は、このピアのオフセットです。この例では、プライマリ10.4.2.254に次の時間があります。 org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012) 差は 268.3044 ミリ秒のオフセットです。 |
|||||||||||||||||||||||||||
| xmt time |
これは、ローカル クライアントがこのピア/サーバに送信する NTP パケットの送信タイム スタンプです。 |
|||||||||||||||||||||||||||
| filtdelay |
これは、各サンプルのラウンド トリップ遅延です（ミリ秒単位）。 サンプルは、受信した最後の NTP パケットです。この例では、プライマリ10.4.2.254には次の値があります。 filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72 これらの 8 個のサンプルは、ローカル クライアントが最後の 8 個の NTP パケットを受信したかどうかを示す reach フィールドの値に対応しています。 |
show ntp status
以下は show ntp status コマンドの出力例です。
USSP-B33S-SW01#sho ntp status
Clock is synchronized, stratum 2, reference is 10.4.2.254
nominal freq is 250.0000 Hz, actual freq is 250.5630 Hz, precision is 2**18
reference time is D36968F7.7E3019A9 (02:12:07.492 UTC Fri May 25 2012)
clock offset is 417.2868 msec, root delay is 2.85 msec
root dispersion is 673.42 msec, peer dispersion is 261.80 msec
show up associationセクションまたはshow ntp association detailセクションですでに定義されている用語は繰り返されません。
| ターム | 説明 |
|---|---|
| precision |
精度は自動的に判別され、2 の累乗として測定されます。この例では、2** 18 は 2^(-18)、または 3.8 マイクロ秒を意味します。 NTPピア間、またはプライマリとクライアント間の同期が失われる原因は、さまざまです。NTPは、次の方法で時刻が不明瞭になる可能性があるマシンとの同期を回避します。
|
デバッグを使用したNTPのトラブルシューティング
NTP で発生する問題の最も一般的な原因は次のとおりです。
- NTP パケットが受信されない。
- NTPパケットは受信されますが、Cisco IOSのNTPプロセスでは処理されません。
- NTP パケットは処理されるが、エラー要素またはパケット データが原因で同期が失われる。
- ntp clock-period が手動で設定された。
これらの問題の原因を見極めるのに役立つ以下のような重要なデバッグ コマンドがあります。
- debug ip packets <acl>
- debug ntp packets
- debug ntp validity
- debug ntp sync
- debug ntp events
次のセクションでは、これらの一般的な問題を解決するためにデバッグを使用する方法について説明します。
注：このセクションで使用されているコマンドの詳細を調べるには、Command Lookup Tool（登録ユーザ専用）を使用してください。シスコの登録済みユーザのみが内部ツールおよび情報にアクセスできます。
注：debug コマンドを使用する前に、『debug コマンドの重要な情報』を参照してください。
NTP パケットが受信されない
debug ip packet コマンドを使用して、NTP パケットが送受信されているかどうかを確認します。デバッグ出力が過剰になる可能性があるため、アクセス コントロール リスト（ACL）を使用して、デバッグ出力を制限できます。NTP は、User Datagram Protocol（UDP）ポート 123 を使用します。
- ACL 101 を作成します。
access-list 101 permit udp any any eq 123
NTP パケットには通常、123 の送信元と宛先のポートがあるため、次のコマンドが役立ちます。
access-list 101 permit udp any eq 123 any
permit udp any eq 123 any eq 123
- 次の ACL を使用して、debug ip packet コマンドからの出力を制限します。
debug ip packet 101
- 問題が特定のピアにある場合、それらのピアに ACL 101 の範囲を絞り込みます。ピアが 172.16.1.1 である場合、ACL 101 を次のように変更します。
access-list 101 permit udp host 172.16.1.1 any eq 123
access-list 101 permit udp any eq 123 host 172.16.1.1
次の出力例は、パケットが送信されていないことを示しています。
241925: Apr 23 2012 15:46:26.101 ETE: IP: s=10.50.38.70 (Tunnel99), d=10.50.44.101, len 76, input feature
241926: Apr 23 2012 15:46:26.101 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0, forus FALSE,
sendself FALSE, mtu 0
241927: Apr 23 2012 15:46:26.101 ETE: IP: s=10.50.38.70 (Tunnel99), d=10.50.44.101, len 76, input feature
241928: Apr 23 2012 15:46:26.101 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0, forus FALSE,
sendself FALSE, mtu 0
NTPパケットが受信されていないことを確認したら、次の手順を実行します。
- NTP が正しく設定されているかを確認します。
- ACLがNTPパケットをブロックしているかどうかを確認します。
- 送信元または宛先 IP へのルーティング問題がないかを確認します。
NTP パケットが処理されない
debug ip packetコマンドとdebug ntp packetsコマンドの両方をイネーブルにすると、送受信されたパケットを確認でき、これらのパケットに対してNTPが動作していることを確認できます。（debug ip packetで示されているように）受信したNTPパケットごとに、debug ntp packetsで生成された対応するエントリがあります（このエントリはNTPパケットのデバッグに使用されます）。
以下は、受信したパケットで NTP プロセスが機能している場合のデバッグ出力です。
Apr 20 00:16:34.143 UTC: IP: tableid=0, s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), routed via FIB
.Apr 20 00:16:34.143 UTC: IP: s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), len 76, sending
.Apr 20 00:16:34.143 UTC: IP: s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), len 76, sending full packet
.Apr 20 00:16:34.143 UTC: NTP: xmit packet to 10.1.2.254:
.Apr 20 00:16:34.143 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Apr 20 00:16:34.143 UTC: rtdel 0021 (0.504), rtdsp 1105E7 (17023.056), refid 0A0102FE (10.1.2.254)
.Apr 20 00:16:34.143 UTC: ref D33B2922.24FEBDC7 (00:15:30.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:34.143 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:34.143 UTC: xmt D33B2962.24CAFAD1 (00:16:34.143 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: IP: s=10.1.2.254 (Vlan2), d=10.3.2.31, len 76, rcvd 2
.Apr 20 00:16:34.143 UTC: NTP: rcv packet from 10.1.2.254 to 10.3.2.31 on Vlan2:
.Apr 20 00:16:34.143 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.Apr 20 00:16:34.143 UTC: rtdel 0000 (0.000), rtdsp 009D (2.396), refid 47505300 (10.80.83.0)
.Apr 20 00:16:34.143 UTC: ref D33B2952.4CC11CCF (00:16:18.299 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: org D33B2962.24CAFAD1 (00:16:34.143 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: rec D33B2962.49D3724D (00:16:34.288 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: xmt D33B2962.49D997D0 (00:16:34.288 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: inp D33B2962.25010310 (00:16:34.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: IP: tableid=0, s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), routed via FIB
.Apr 20 00:16:36.283 UTC: IP: s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), len 76, sending
.Apr 20 00:16:36.283 UTC: IP: s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), len 76, sending full packet
.Apr 20 00:16:36.283 UTC: NTP: xmit packet to 10.8.2.254:
.Apr 20 00:16:36.283 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Apr 20 00:16:36.283 UTC: rtdel 002F (0.717), rtdsp 11058F (17021.713), refid 0A0102FE (10.1.2.254)
.Apr 20 00:16:36.283 UTC: ref D33B2962.25010310 (00:16:34.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:36.283 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:36.283 UTC: xmt D33B2964.48947E87 (00:16:36.283 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: IP: s=10.8.2.254 (Vlan2), d=10.3.2.31, len 76, rcvd 2
.Apr 20 00:16:36.283 UTC: NTP: rcv packet from 10.8.2.254 to 10.3.2.31 on Vlan2:
.Apr 20 00:16:36.283 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.Apr 20 00:16:36.283 UTC: rtdel 0000 (0.000), rtdsp 0017 (0.351), refid 47505300 (10.80.83.0)
.Apr 20 00:16:36.283 UTC: ref D33B295B.8AF7FE33 (00:16:27.542 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: org D33B2964.48947E87 (00:16:36.283 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: rec D33B2964.4A6AD269 (00:16:36.290 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: xmt D33B2964.4A7C00D0 (00:16:36.290 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: inp D33B2964.498A755D (00:16:36.287 UTC Fri Apr 20 2012)
以下は、受信したパケットで NTP が機能していない場合の例を示しています。NTP パケットは受信されます（debug ip packets によって示されます）が、NTP プロセスがそれらのパケットで機能しません。送信された NTP パケットでは、NTP プロセスがパケットを生成する必要があるため、対応する debug ntp packets の出力が存在します。この問題は、受信したNTPパケットが処理されないことに特有のものです。
071564: Apr 23 2012 15:46:26.100 ETE: NTP: xmit packet to 10.50.44.101:
071565: Apr 23 2012 15:46:26.100 ETE: leap 0, mode 1, version 3, stratum 5, ppoll 1024
071566: Apr 23 2012 15:46:26.100 ETE: rtdel 07B5 (30.106), rtdsp 0855 (32.547), refid 0A32266A
(10.50.38.106)
071567: Apr 23 2012 15:46:26.100 ETE: ref D33FDB05.1A084831 (15:43:33.101 ETE Mon Apr 23 2012)
071568: Apr 23 2012 15:46:26.100 ETE: org 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071569: Apr 23 2012 15:46:26.100 ETE: rec 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071570: Apr 23 2012 15:46:26.100 ETE: xmt D33FDBB2.19D3457C (15:46:26.100 ETE Mon Apr 23 2012)
PCY_PAS1#
071571: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, input feature
071572: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0, forus FALSE,
sendself FALSE, mtu 0
071573: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, input feature
071574: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0, forus FALSE,
sendself FALSE, mtu 0
071575: Apr 23 2012 15:47:31.497 ETE: FIBipv4-packet-proc: route packet from Tunnel99 src 10.50.38.78 dst
10.50.44.69
071576: Apr 23 2012 15:47:31.497 ETE: FIBfwd-proc: base:10.50.44.69/32 receive entry
PCY_PAS1#
071577: Apr 23 2012 15:47:31.497 ETE: FIBipv4-packet-proc: packet routing failed
071578: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, rcvd 2
071579: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123
071580: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, stop process pak
for forus packet
071581: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123
PCY_PAS1#
071582: Apr 23 2012 16:03:30.105 ETE: NTP: xmit packet to 10.50.44.101:
071583: Apr 23 2012 16:03:30.105 ETE: leap 0, mode 1, version 3, stratum 5, ppoll 1024
071584: Apr 23 2012 16:03:30.105 ETE: rtdel 0759 (28.702), rtdsp 087D (33.157), refid 0A32266A
(10.50.38.106)
071585: Apr 23 2012 16:03:30.105 ETE: ref D33FDF05.1B2CC3D4 (16:00:37.106 ETE Mon Apr 23 2012)
071586: Apr 23 2012 16:03:30.105 ETE: org 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071587: Apr 23 2012 16:03:30.105 ETE: rec 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071588: Apr 23 2012 16:03:30.105 ETE: xmt D33FDFB2.1B1D5E7E (16:03:30.105 ETE Mon Apr 23 2012)
PCY_PAS1#
071589: Apr 23 2012 16:04:35.502 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, input feature
071590: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0, forus FALSE,
sendself FALSE, mtu 0
071591: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, input feature
071592: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0, forus FALSE,
sendself FALSE, mtu 0
071593: Apr 23 2012 16:04:35.506 ETE: FIBipv4-packet-proc: route packet from Tunnel99 src 10.50.38.78 dst
10.50.44.69
071594: Apr 23 2012 16:04:35.506 ETE: FIBfwd-proc: base:10.50.44.69/32 receive entry
PCY_PAS1#
071595: Apr 23 2012 16:04:35.506 ETE: FIBipv4-packet-proc: packet routing failed
071596: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, rcvd 2
071597: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123
071598: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, stop process pak
for forus packet
071599: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123
PCY_PAS1#
同期が失われる
サーバの分散値や遅延値が非常に大きくなると、同期が失われる可能性があります。高い値は、クロックのルートを基準として、サーバ/ピアからクライアントにパケットが到達するまでに時間がかかりすぎることを示します。そのため、ローカル マシンは、パケットがそこに到達するまでにかかった時間を判別できないため、パケットに存在する時刻の精度を信頼することができません。
NTPは時間に関して細心の注意を払っており、信頼できない別のデバイスと同期したり、信頼できるように調整したりすることはできません。
飽和状態のリンクがあり、バッファリングが途中で発生する場合、パケットが NTP クライアントに到達する際に遅延が発生します。そのため、後続の NTP パケットに含まれるタイムスタンプが大きく異なる場合がありますが、ローカル クライアントはその差異を実際には調整できません。
NTP では、SNTP（Simple Network Time Protocol）を使用する場合を除き、これらのパケットの検証をオフにする手段はありません。SNTPはソフトウェアで広くサポートされていないため、代替手段としてはあまり適していません。
同期が失われる場合は、リンクを確認する必要があります。
- リンクが飽和していないか。
- ワイドエリア ネットワーク（WAN）リンクで何らかのドロップが発生していないか。
- 暗号化は行われますか。
show ntp associations detail コマンドの reach 値をモニタリングします。最大値は 377 です。値が0または低い場合、NTPパケットは断続的に受信され、ローカルクライアントはサーバと同期しなくなります。
debug ntp validity
debug ntp validity コマンドは、NTP パケットが健全性チェックや妥当性チェックに失敗したかどうかを示し、その失敗の理由について明らかにします。サーバから受信した NTP パケットをテストするために使用される RFC1305 で指定された健全性テストとこの出力を比較します。8 つのテストが定義されています。
| テスト |
マスク |
説明 |
|---|---|---|
| 1 |
0x01 |
重複パケットを受信しました |
| 2 |
0x02 |
偽造パケットを受信しました |
| 3 |
0x04 |
プロトコルが同期されていません |
| 4 |
0x08 |
ピアの遅延/分散で境界チェックに失敗しました |
| 5 |
0x10 |
ピア認証に失敗しました |
| 6 |
0x20 |
ピア クロックが同期されていません（非同期サーバに対して共通） |
| 7 |
0x40 |
範囲外のピア ストラタム |
| 8 |
0x80 |
ルートの遅延/分散で境界チェックに失敗しました |
以下は debug ntp validity コマンドの出力例です。
PCY_PAS1#debug ntp validity
NTP peer validity debugging is on
009585: Mar 1 2012 09:14:32.670 HIVER: NTP: packet from 192.168.113.57 failed validity tests 52
009586: Mar 1 2012 09:14:32.670 HIVER: Authentication failed
009587: Mar 1 2012 09:14:32.670 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009588: Mar 1 2012 09:14:38.210 HIVER: NTP: packet from 192.168.56.1 failed validity tests 14
009589: Mar 1 2012 09:14:38.210 HIVER: Authentication failed
PCY_PAS1#
009590: Mar 1 2012 09:14:43.606 HIVER: NTP: packet from 10.110.103.27 failed validity tests 14
009591: Mar 1 2012 09:14:43.606 HIVER: Authentication failed
PCY_PAS1#
009592: Mar 1 2012 09:14:48.686 HIVER: NTP: packet from 192.168.113.57failed validity tests 52
009593: Mar 1 2012 09:14:48.686 HIVER: Authentication failed
009594: Mar 1 2012 09:14:48.686 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009596: Mar 1 2012 09:14:54.222 HIVER: NTP: packet from 10.110.103.35 failed validity tests 14
009597: Mar 1 2012 09:14:54.222 HIVER: Authentication failed
PCY_PAS1#
009598: Mar 1 2012 09:14:54.886 HIVER: NTP: synced to new peer 10.50.38.106
009599: Mar 1 2012 09:14:54.886 HIVER: NTP: 10.50.38.106 synced to new peer
PCY_PAS1#
009600: Mar 1 2012 09:14:59.606 HIVER: NTP: packet from 10.110.103.27 failed validity tests 14
009601: Mar 1 2012 09:14:59.606 HIVER: Authentication failed
PCY_PAS1#
009602: Mar 1 2012 09:15:04.622 HIVER: NTP: packet from 192.168.113.137 failed validity tests 52
009603: Mar 1 2012 09:15:04.622 HIVER: Authentication failed
009604: Mar 1 2012 09:15:04.622 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009605: Mar 1 2012 09:15:10.238 HIVER: NTP: packet from 192.168.56.1 failed validity tests 14
009606: Mar 1 2012 09:15:10.238 HIVER: Authentication failed
PCY_PAS1#
009607: Mar 1 2012 09:15:15.338 HIVER: NTP: packet from 10.83.23.140 failed validity tests 52
009608: Mar 1 2012 09:15:15.338 HIVER: Authentication failed
009609: Mar 1 2012 09:15:15.338 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009610: Mar 1 2012 09:15:20.402 HIVER: NTP: packet from 192.168.113.92 failed validity tests 74
009611: Mar 1 2012 09:15:20.402 HIVER: Authentication failed
009612: Mar 1 2012 09:15:20.402 HIVER: Peer/Server Clock unsynchronized
009613: Mar 1 2012 09:15:20.402 HIVER: Peer/Server Stratum out of bound
debug ntp packets
debug ntp packets コマンドを使用して、受信したパケットのピア/サーバによって示される時刻を確認できます。時刻に関するローカル マシンも、送信パケットでそのローカル マシンが認識している時刻をピア/サーバに伝達します。
| フィールド | rcv パケット | xmit パケット |
|---|---|---|
| org | 送信元のタイム スタンプ。これはサーバの時刻です。 | クライアントがパケットを送信した時点の送信元（クライアント）のタイム スタンプ。（クライアントがサーバにパケットを送信します。） |
| rec | クライアントがパケットを受信した時点のクライアントのタイム スタンプ。 | クライアントの現在時刻。 |
この出力例では、サーバから受信したパケットのタイム スタンプと別のサーバに送信されるパケットのタイム スタンプが同じです。これは、クライアント NTP が同期されていることを示します。
USSP-B33S-SW01#debug ntp packets
NTP packets debugging is on
USSP-B33S-SW01#
May 25 02:21:48.182 UTC: NTP: rcv packet from 10.1.2.254 to 10.3.2.31 on Vlan2:
May 25 02:21:48.182 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
May 25 02:21:48.182 UTC: rtdel 0000 (0.000), rtdsp 00F2 (3.693), refid 47505300 (10.80.83.0)
May 25 02:21:48.182 UTC: ref D3696B38.B722C417 (02:21:44.715 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: org D3696B3C.2EA179BA (02:21:48.182 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: rec D3696B3D.E58DE1BE (02:21:49.896 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: xmt D3696B3D.E594E7AF (02:21:49.896 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: inp D3696B3C.2EDFC333 (02:21:48.183 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: NTP: xmit packet to 10.4.2.254:
May 25 02:22:46.051 UTC: leap 0, mode 3, version 3, stratum 2, ppoll 64
May 25 02:22:46.051 UTC: rtdel 00C0 (2.930), rtdsp 1C6FA (1777.252), refid 0A0402FE (10.4.2.254)
May 25 02:22:46.051 UTC: ref D3696B36.33D43F44 (02:21:42.202 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: org D3696B37.E72C75AE (02:21:43.903 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: rec D3696B36.33D43F44 (02:21:42.202 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: xmt D3696B76.0D43AE7D (02:22:46.051 UTC Fri May 25 2012)
以下はクロックが同期されていない場合の出力例です。xmit パケットと rcv パケット間の時間差に注意してください。ピアの分散は最大値の16000に設定でき、ピアの到達範囲は0に設定できます。
USSP-B33S-SW01#
.May 25 02:05:59.011 UTC: NTP: xmit packet to 10.4.2.254:
.May 25 02:05:59.011 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.May 25 02:05:59.011 UTC: rtdel 00A3 (2.487), rtdsp 1104D0 (17018.799), refid 0A0402FE (10.4.2.254)
.May 25 02:05:59.011 UTC: ref D3696747.03D8661A (02:04:55.015 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.May 25 02:05:59.011 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.May 25 02:05:59.011 UTC: xmt D3696787.03105783 (02:05:59.011 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: NTP: rcv packet from 10.4.2.254 to 10.3.2.31 on Vlan2:
.May 25 02:05:59.011 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.May 25 02:05:59.011 UTC: rtdel 0000 (0.000), rtdsp 0014 (0.305), refid 47505300 (10.80.83.0)
.May 25 02:05:59.011 UTC: ref D3696782.C96FD778 (02:05:54.786 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: org D3696787.03105783 (02:05:59.011 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: rec D3696787.281A963F (02:05:59.156 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: xmt D3696787.282832C4 (02:05:59.156 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: inp D3696787.03C63542 (02:05:59.014 UTC Fri May 25 2012)
debug ntp sync and debug ntp events
debug ntp sync コマンドによって、クロックが同期されているか、または同期が変更されているかを示す 1 行の出力が生成されます。このコマンドは通常 debug ntp events で有効になります。
debug ntp eventsコマンドは、発生したNTPイベントを表示します。このコマンドは、NTPの変更によってクロックの同期が失われるなどの問題が引き起こされたかどうかを判断するのに役立ちます。（つまり、適切に同期されていたクロックが突然同期されなくなった場合、変更またはトリガーを調べてください）。
以下は両方のデバッグの例です。最初に、クライアントのクロックは同期されていました。debug ntp events コマンドでは、NTP ピア ストラタムの変更が発生し、クロックが同期されなくなったことが示されています。
USSP-B33S-SW01#debug ntp sync
NTP clock synchronization debugging is on
USSP-B33S-SW01#
USSP-B33S-SW01#
USSP-B33S-SW01#debug ntp events
NTP events debugging is on
USSP-B33S-SW01#
USSP-B33S-SW01#
May 25 02:25:57.620 UTC: NTP: xmit packet to 10.4.2.254:
May 25 02:25:57.620 UTC: leap 0, mode 3, version 3, stratum 2, ppoll 64
May 25 02:25:57.620 UTC: rtdel 00D4 (3.235), rtdsp 26B26 (2418.549), refid 0A0402FE (10.4.2.254)
May 25 02:25:57.620 UTC: ref D3696BF5.C47EB880 (02:24:53.767 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: org D3696BF7.E5F91077 (02:24:55.898 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: rec D3696BF5.C47EB880 (02:24:53.767 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: xmt D3696C35.9ED1CE97 (02:25:57.620 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: NTP: rcv packet from 10.4.2.254 to 10.3.2.31 on Vlan2:
May 25 02:25:57.620 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
May 25 02:25:57.620 UTC: rtdel 0000 (0.000), rtdsp 000E (0.214), refid 47505300 (10.80.83.0)
May 25 02:25:57.620 UTC: ref D3696C37.D528800E (02:25:59.832 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: org D3696C35.9ED1CE97 (02:25:57.620 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: rec D3696C37.E5C7AB3D (02:25:59.897 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: xmt D3696C37.E5D1F273 (02:25:59.897 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: inp D3696C35.9F9EA2C4 (02:25:57.623 UTC Fri May 25 2012)
May 25 02:25:59.830 UTC: NTP: peer stratum change
May 25 02:25:59.830 UTC: NTP: clock reset
May 25 02:25:59.830 UTC: NTP: sync change
May 25 02:25:59.830 UTC: NTP: peer stratum change
May 25 02:26:05.817 UTC: NTP: xmit packet to 10.1.2.254:
May 25 02:26:05.817 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
May 25 02:26:05.817 UTC: rtdel 00C2 (2.960), rtdsp 38E9C (3557.068), refid 0A0402FE (10.4.2.254)
May 25 02:26:05.817 UTC: ref D3696C35.9F9EA2C4 (02:25:57.623 UTC Fri May 25 2012)
May 25 02:26:05.817 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
May 25 02:26:05.817 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
May 25 02:26:05.817 UTC: xmt D3696C3D.D12D0565 (02:26:05.817 UTC Fri May 25 2012)
手動で設定された ntp clock-period
Cisco.com の Web サイトでは、以下が警告されています。
「ntp clock-periodコマンドは、copy running-configuration startup-configurationコマンドを入力して設定をNVRAMに保存するときに絶えず変化する補正係数を反映して自動的に生成されます。ntp clock-period コマンドは、手動で使用しないでください。コンフィギュレーションファイルを他のデバイスにコピーする際は、必ずこのコマンドラインを削除してください。
clock-period 値はハードウェアに依存しているため、デバイスごとに異なります。
NTP を有効にすると ntp clock-period コマンドがコンフィギュレーションに自動的に表示されます。このコマンドは、ソフトウェア クロックを調整するために使用されます。「調整値」は 4 ミリ秒のティック間隔を補正します。そのため、微調整を行うと、間隔の終わりに 1 秒が余ります。
デバイスのシステムクロックが時間を失ったと計算された場合（おそらくルータのベースレベルからの周波数補償が必要です）、デバイスは自動的にシステムクロックにこの値を追加して、その同期性を維持します。
注：このコマンドは、ユーザが変更することはできません。
ルータのデフォルト ntp clock-period は 17179869 で、NTP プロセスを開始するため、基本的にこの値が使用されます。
変換式は 17179869 * 2^(-32) = 0.00399999995715916156768798828125、または約 4 ミリ秒です。
たとえば、Cisco 2611 ルータ（Cisco 2600 シリーズ ルータの 1 つ）のシステム クロックが同期された状態から若干ずれていることが判明した場合、このコマンドを使用して再同期することができます。
ntp clock-period 17208078
これは、17208078 * 2^(-32) = 0.0040065678767859935760498046875 に等しく、4 ミリ秒より少し長くなります。
シスコでは、ルータを通常のネットワーク状態で 1 週間ほど実行し、wr mem コマンドを使用して値を保存することを推奨します。これによって次のリブート時に正確な数値が得られ、NTP をより迅速に同期させることができます。
別のデバイスで使用するために設定を保存するときに、no ntp clock-period コマンドを使用します。このコマンドは、その特定のデバイスのデフォルトに clock-period を戻すためです。真の値を再計算できます（ただし、その再計算期間中のシステムクロックの精度を下げることができます）。
この値はハードウェアに依存しているため、設定をコピーして異なるデバイスでその設定を使用すると問題が発生する可能性があることに注意してください。シスコでは、この問題を解決するために、NTP バージョン 3 からバージョン 4 に切り替えることを予定しています。
これらの問題に気づいていない場合は、この値を手動で調整できます。あるデバイスから別のデバイスに移行するには、古い設定をコピーして、新しいデバイスに貼り付けます。残念ながら ntp clock-period コマンドは running-config および startup-config で表示されるため、NTP clock-period は新しいデバイスに貼り付けられます。この問題が発生した場合は必ず、ピアの分散値が高くなり、新しいクライアントの NTP はサーバと同期されなくなります。
代わりに、ntp clock-period コマンドを使用して NTP clock-period をクリアし、その設定を保存します。最終的にルータはルータ自体の適切な clock-period を計算します。
ntp clock-periodコマンドは、Cisco IOSソフトウェアバージョン15.0以降では使用できなくなりました。パーサは次のエラーを含むコマンドを拒否します。
"%NTP: This configuration command is deprecated."
clock-periodを手動で設定することは許可されておらず、clock-periodはrunning-configでは許可されていません。startup-config で設定されている場合（12.4 などの以前の Cisco IOS バージョン）、パーサーはコマンドを拒否するため、ブートアップ時にパーサーが startup-config を running-config にコピーすると、コマンドが拒否されます。
新しい代替コマンドは ntp clear drift です。
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
2.0 |
15-Feb-2023 |
形式と情報を更新。CCWを修正。再認定。 |
1.0 |
06-May-2013 |
初版 |
フィードバック