Network Time Protocol(NTP)の問題のトラブルシューティングとデバッグ
ダウンロード オプション
偏向のない言語
この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
翻訳について
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。
はじめに
このドキュメントでは、debugコマンドとshow ntpコマンドを使用してNetwork Time Protocol(NTP)の問題をトラブルシューティングする方法について説明します。
前提条件
要件
このドキュメントに関する特定の要件はありません。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
NTP show コマンド
NTP問題の原因を調べる前に、次のコマンドの使用方法と出力について理解しておく必要があります。
- show ntp association
- show ntp association detail
- show ntp status
注：このセクションで使用されているコマンドの詳細を調べるには、Command Lookup Tool（登録ユーザ専用）を使用してください。シスコの登録ユーザのみが内部ツールおよび情報にアクセスできます。
注：アウトプットインタープリタツールでは、特定のshowコマンドがサポートされています。シスコの登録ユーザのみが内部ツールおよび情報にアクセスできます。
show ntp associationコマンド
NTPアソシエーションは次のうちいずれかにすることができます。
- ピアアソシエーション（一方のシステムが他方のシステムと同期するか、他方のシステムが他方のシステムと同期できるようにする）
- サーバの関連付け（一方のシステムだけが他方のシステムと同期し、もう一方のシステムとは同期しない）
以下は 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 つの到達可能性の値があります。
到達可能性は、リンクの不良、CPUの問題、およびその他の断続的な問題が原因でNTPパケットがドロップされたかどうかを示す適切なインジケータです。 Unit Converterは、この変換やその他の多くの変換のためのオンラインユニットコンバータです。 |
| 遅延 |
ピアへのラウンド トリップ遅延がミリ秒単位で報告されます。クロックをより正確に設定するには、クロック時間を設定するときにこの遅延を考慮に入れます。 |
| offset |
オフセットは、ピア間、またはプライマリとクライアント間のクロック時間の差です。この値は、クライアント クロックを同期するために適用される補正値です。正の値はサーバ クロックのほうが高いことを示しています。負の値はクライアント クロックのほうが高いことを示しています。 |
| disp |
分散は、ローカル クロックとサーバ クロックとの間で測定されたクロックの最大時間差です（秒単位で報告されます）。この例では、サーバ 10.50.36.42 の分散は 0.3 です。ローカル クロックとサーバ クロックとの間のローカルで測定される最大時間差は 0.3 秒です。 クロックが最初に同期されている場合は、高い値が表示されます。しかし、それ以外のときに分散が高すぎる場合、クライアントの NTP プロセスは、サーバからの NTP メッセージを受け入れません。最大分散は16000です。この例では、サーバ10.50.44.69と10.50.44.133の分散であるため、ローカルクライアントはこれらのサーバからの時間を受け入れません。 到達範囲がゼロで、分散が非常に高い場合、クライアントはそのサーバからのメッセージを受け入れないことになります。例の 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
関連付けの表示セクションですでに定義されている用語は、ここでは繰り返しません。
| ターム |
説明 | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 |
ルート分散は、ローカル クロックとルート クロックの間で測定されたクロックの最大時間差です。詳細については、「関連付けの表示」の下の表示の説明を参照してください。 |
|||||||||||||||||||||||||||
| sync dist. |
これは、ストラタム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がそれらのパケットで動作することを確認できます。受信したすべての NTP パケット（debug ip packet によって示されます）には、debug ntp packets によって生成される対応するエントリがあります。
以下は、受信したパケットで 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には、Simple Network Time Protocol(SNTP)を使用しない限り、これらのパケットの検証をオフにする方法はありません。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および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 を計算します。
Cisco IOS®ソフトウェアバージョン15.0以降では、ntp clock-periodコマンドは使用できなくなりました。パーサーがコマンドをエラーで拒否するようになりました。
"%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 です。
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
4.0 |
12-Nov-2024 |
タイトル、ブランディング要件、フォーマットを更新。 |
3.0 |
15-Aug-2024 |
再認定 |
2.0 |
15-Feb-2023 |
形式と情報を更新。CCWを修正。再認定 |
1.0 |
06-May-2013 |
初版 |
フィードバック