内容

概要

前提条件

要件

使用するコンポーネント

NTP show コマンド

show ntp association

show ntp association detail

show ntp status

デバッグを使用したNTPのトラブルシューティング

NTP パケットが受信されない

NTP パケットが処理されない

同期が失われる

debug ntp validity

debug ntp packets

debug ntp sync and debug ntp events

手動で設定された ntp clock-period

関連情報

概要

このドキュメントでは、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 つの到達可能性の値があります。

- 377（8 進数） = 11111111（2 進数）。NTP プロセスが最後の 8 個のパケットを受信したことを示します。

- 0（8 進数） = 00000000。NTP プロセスがパケットを受信しなかったことを示します。

- 1（8 進数） = 00000001。NTP プロセスが最後のパケットのみを受信したことを示します。

- 357（8 進数） = 11101111。最後の 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

~10.50.44.69  10.50.36.106   5  21231  1024     0    3.8   -4.26  16000.

オフセットは -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

0x01

重複パケットを受信しました

2

0x02

偽造パケットを受信しました

3

0x04

プロトコルが同期されていません

4

0x08

ピアの遅延/分散で境界チェックに失敗しました

5

0x10

ピア認証に失敗しました

6

0x20

ピア クロックが同期されていません（非同期サーバに対して共通）

7

0x40

範囲外のピア ストラタム

8

0x80

ルートの遅延/分散で境界チェックに失敗しました

テスト 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)

rcv time D36968B7.A2F44E2C (02:11:03.636 UTC Fri May 25 2012)

差は 268.3044 ミリ秒のオフセットです。

xmt time

これは、ローカル クライアントがこのピア/サーバに送信する NTP パケットの送信タイム スタンプです。

filtdelay

filtoffset

filterror

これは、各サンプルのラウンド トリップ遅延です（ミリ秒単位）。

これは、各サンプルのクロック オフセットです（ミリ秒単位）。

これは、各サンプルのおおよその誤差です。

サンプルは、受信した最後の NTP パケットです。この例では、プライマリ10.4.2.254には次の値があります。

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

これらの 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は、次の方法で時刻が不明瞭になる可能性があるマシンとの同期を回避します。

1. NTP は、そのマシン自体が同期化されていないマシンとの同期を実行しません。

1. 複数のマシンから報告された時刻を比較し、他のマシンと時刻が大きく異なるマシンとは、そのストラタムがより低くても同期しません。

デバッグを使用した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 を使用します。

1. ACL 101 を作成します。

access-list 101 permit udp any any eq 123

access-list 101 permit udp any eq 123 any
NTP パケットには通常、123 の送信元と宛先のポートがあるため、次のコマンドが役立ちます。

permit udp any eq 123 any eq 123

2. 次の ACL を使用して、debug ip packet コマンドからの出力を制限します。

debug ip packet 101

3. 問題が特定のピアにある場合、それらのピアに 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 です。

関連情報

- サポートフォーラムスレッド：NTP clock-period not configured

- ネットワーク・タイム・プロトコル: ベストプラクティス白書

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

- シスコテクニカルサポートおよびダウンロード