IP : ネットワーク タイム プロトコル(NTP)

Network Time Protocol(NTP)問題のトラブルシューティングおよびデバッグ ガイド

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

このドキュメントでは、ネットワーク タイム プロトコル(NTP)の問題をトラブルシューティングするためのデバッグの使用について、また主な show ntp コマンドの出力について説明します。

著者:Cisco TAC エンジニア、Mani Ganesan および Krishna Nagavolu

NTP show コマンド

NTP の問題の原因を調べる前に、以下のコマンドの使用方法およびその出力内容について理解しておく必要があります。

  • show ntp association
  • show ntp association detail
  • show ntp status

: このセクションで使用されているコマンドの詳細を調べるには、Command Lookup Tool登録ユーザ専用)を使用してください。

: 特定の show コマンドがアウトプット インタープリタ ツール登録ユーザ専用)でサポートされています。 show コマンド出力の分析を表示するには、アウトプット インタープリタ ツールを使用します。

show ntp association

NTP アソシエーションは、ピア アソシエーション(1 つのシステムを別のシステムと同期する、または別のシステムをそのシステムに同期させる)またはサーバ アソシエーション(1 つのシステムを別のシステムと同期する、その逆は不可)のいずれかにできます。

以下は show ntp association コマンドの出力例です。

CLA_PASA#sh ntp association
      address         ref clock     st  when  poll reach  delay  offset    disp
 ~127.127.7.1      127.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      86.79.127.250     4     7   256  377     0.8   -0.29     0.2
*~10.50.36.42      86.79.127.250     4   188   256  377     0.7   -0.17     0.3
+~10.50.38.50      86.79.127.250     4    42   256  377     0.9    1.02     0.4
+~10.50.36.50      86.79.127.250     4    20   256  377     0.7    0.87     0.5
 * master (synced), # master (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 個のパケットが失われる前のパケットを示します。

到達可能性は、低品質のリンク、CPU の問題、その他の断続的な問題によって NTP パケットがドロップされたかどうかを示すのに適したインジケータです。

Convert octal < - > binary」は、この例やその他多くの変換にも使用できるオンラインの単位変換ツールです。

遅延

ピアへのラウンド トリップ遅延がミリ秒単位で報告されます。 クロックをより正確に設定するには、クロック時間を設定するときにこの遅延を考慮に入れます。

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
~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_master, 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 ntp association セクションですでに定義されている用語は繰り返しません。

用語

説明

configured

この NTP クロック ソースはサーバとして設定されています。 ピア/サーバが動的に検出された場合、この値も動的である可能性があります。

our_master

ローカル クライアントがこのピアに同期されます。

selected

「our_master」が失敗する、またはクライアントが同期を失うと、可能な同期に対してピア/サーバが選択されます。

sane

サーバから受信した NTP パケットをテストするために健全性テストが使用されます。 これらのテストは、『RFC 1305、ネットワーク タイム プロトコル(バージョン 3)仕様書、実装と分析』に詳細が示されています。 テストは以下のとおりです。

テストマスク説明
10x01重複パケットを受信しました
20x02偽造パケットを受信しました
30x04プロトコルが同期されていません
40x08ピアの遅延/分散で境界チェックに失敗しました
50x10ピア認証に失敗しました
60x20ピア クロックが同期されていません(非同期サーバに対して共通)
70x40範囲外のピア ストラタム
80x80ルートの遅延/分散で境界チェックに失敗しました

テスト 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 ntp association 」セクションの「disp」についての説明を参照してください。

sync dist.

これは、ストラタム 0(ソース)の時間とクライアントによって測定される時間の最大差の推定値です。 これは、最後のストラタム ソースが実際に読み取られてからのラウンド トリップ時間、システム精度、およびクロック ドリフトの要素で構成されます。

複数のストラタムにサーバ/クライアントを持つ大規模な NTP セットアップ(インターネットにストラタム 1 の NTP サーバ、および異なるストラタムのソース時刻を持つサーバ)では、最高の精度を実現するために、NTP 同期トポロジを編成する必要がありますが、時間同期ループが決して形成されないようにしなければなりません。 その他に、ストラタムの各増分には潜在的に信頼できないタイム サーバが含まれていて、これによって追加の測定誤差が生じる可能性があるということを念頭に置く必要があります。 NTP で使用される選択アルゴリズムでは、プライマリ サーバをルートにする最小重量スパニング ツリーを計算するために、ベルマンフォード分散ルーティング アルゴリズムのバリアントが使用されます。 アルゴリズムで使用される距離メトリックは、ストラタムに同期距離を足したもので構成され、同期距離は、分散に絶対遅延の半分を足したもので構成されます。 したがって、同期パスは、常にルートへの最小数のサーバを取ります。 関係は最大誤差に基づいて解決されます。

遅延

これは、ピアへのラウンド トリップ遅延です。

precision

これは、ピア クロックの精度です(Hz 単位)。

バージョン

これは、ピアが使用する 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 ntp association セクションまたはshow ntp association details セクションですでに定義されている用語は繰り返しません。

用語説明

precision

精度は自動的に判別され、2 の累乗として測定されます。 この例では、2** 18 は 2^(-18)、または 3.8 マイクロ秒を意味します。

NTP のピア間、またはマスターとクライアント間の同期が失われる場合、さまざまな原因が考えられます。 NTP は、次の方法で時間が正確でない可能性があるマシンとの同期を避けます。

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

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

NTP で発生する問題の最も一般的な原因は次のとおりです。

  • NTP パケットが受信されない。
  • NTP パケットは受信されるが、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 packetdebug 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 (71.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 (71.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 つのテストが定義されています。

テストマスク説明
10x01重複パケットを受信しました
20x02偽造パケットを受信しました
30x04プロトコルが同期されていません
40x08ピアの遅延/分散で境界チェックに失敗しました
50x10ピア認証に失敗しました
60x20ピア クロックが同期されていません(非同期サーバに対して共通)
70x40範囲外のピア ストラタム
80x80ルートの遅延/分散で境界チェックに失敗しました

以下は 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.196.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 163.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.196.113.57 failed 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 163.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 163.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.196.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 163.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.196.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 (71.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 で、ピアの reach には 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 (71.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 (71.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 サイトでは、以下が警告されています。

copy running-configuration startup-configuration コマンドを入力してコンフィギュレーションを NVRAM に保存すると、常に変化している補正係数を反映するために ntp clock-period コマンドが自動的に生成されます。 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 に切り替えることを予定しています。

これらの問題に気付かないと、手動でこの値を修正しようとするかもしれません。 1 台のデバイスから別のデバイスに移行する際に、古い設定をコピーして、新しいデバイスに貼り付けようとするかもしれません。 残念ながら 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 です。

関連情報



Document ID: 116161