はじめに
このドキュメントでは、Cisco Unified Communications(UC)製品のネットワークタイムプロトコル(NTP)の問題をトラブルシューティングする方法について説明します。
前提条件
要件
このドキュメントに関する固有の要件はありません。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
Cisco Unified Communications Manager(CUCM)では、次のことを確認するためにNTPを設定する必要があります。
- CUCMノードの時刻が同期されます。
- 証明書の再生成など、時間に依存する設定変更の前に時間が正しく設定されている。
- データベースレプリケーションは、クラスタ内のすべてのノードで同期されます。
UC製品のNTPポーリングメカニズム
CUCMはNTPウォッチドッグを使用して、NTPサーバとの時刻の同期を維持します。NTPウォッチドッグは、設定されている外部NTPサーバを定期的にポーリングし、3秒を超えるオフセットが設定されている場合はNTPを再起動します。
NTPデーモンは定期的に時間を修正しますが、単位はミリ秒です。NTPの再起動では、NTPワンショットを実行して重大な時刻修正を実行し、続けて定期的なマイクロ修正を行うためにNTPデーモンを再起動します。
NTPウォッチドッグは、VMwareで1分に1回、物理マシンで30分ごとに1回NTPをポーリングします。VMwareの場合はポーリング間隔が短くなります。これは、仮想マシン(VM)のクロックは物理マシンほど安定しておらず、VMotionやストレージ移行などのVMwareの機能は時間に悪影響を及ぼすためです。
VMware上で稼働するプライマリノードは、物理マシン上で稼働する外部NTPサーバと同期してVM内の高度な時間ドリフトや遅延を補正するように、常に設定する必要があります。セカンダリノードは、クラスタ内のすべてのノードが時間内に閉じていることを保証するために、常にプライマリノードのNTPサーバを参照するように自動的に設定されます。
NTPウォッチドッグは、VMWare VMotionsおよびStorage Migrationsに起因する重大な時刻修正のために、NTPデーモンを再起動する速度を追跡します。この再起動レートが1時間あたり10回を超えると、NTPウォッチドッグは、必要な再起動レートが1時間あたり10回を下回るまで、それ以上の再起動を延期します。VMotionsとStorage Migrationsの合計レートは、1時間あたり10を超えることはできません。これは、このレートが超過していると見なされるためです。
このNTPウォッチドッグの実装により、utils ntp statusに表示されるポーリング間隔に従っていません。スニファキャプチャにより、60秒ごとに8回のNTPポール（サンプル）があることが判明しました。これは主に、NTP実装でNTPウォッチドッグを使用することと、UC実装でntpdateがNTPサーバをポーリングする方法が原因です。
使用するNTPバージョンの特定
注:CUCMパブリッシャは外部NTPサーバで設定され、クラスタに追加されたサブスクライバはパブリッシャと同期されます。
注:CUCMバージョン9.x以降では、優先NTPサーバとしてNTPv4サーバを設定する必要があります。
スニファキャプチャを実行して、設定されたNTPサーバで使用されるNTPバージョンを特定します。
admin:utils network capture port 123
Executing command with options:
size=128 count=1000 interface=eth0
src=dest= port=123
ip=
16:03:03.689725 IP cucmlab.cisco.local.34063 > linux.local.ntp: NTPv4,Client, length 48
16:03:03.690174 IP linux.local.ntp > cucmlab.cisco.local.34063: NTPv3,Server, length 48
CUCMがNTPv4パケットを送信し、応答としてNTPv3パケットを受信します。NTPv4はNTPv3と下位互換性がありますが、NTPのCUCM実装は異なるため、NTPは同期されません。
admin:utils ntp status
ntpd (pid 22458) is running...
remote refid st t when poll reach delay offset jitter
=================================================================
172.28.5.9 .INIT. 2 u 45 64 377 0.374 492.965 18.189
unsynchronised
time server re-starting
polling server every 64 s
この問題を解決するには、Linuxベースの外部NTPサーバまたはCisco IOS®またはCisco IOS® XE NTPサーバを使用して、NTPv4が設定されていることを確認することをお勧めします。
次に、NTPステータス出力のNTP用語について説明します。
- refidカラムは、リモートの時刻源を示します。LOCAL(0)はローカルハードウェアクロックです。.INIT.は、初期化がまだ成功していないことを意味します。
- st列は、リモートNTPサーバのストラタムです。16は無効なストラタム値です。つまり、このサーバはタイムプロバイダーと見なされません。ストラタムは、さまざまな理由で無効になる可能性があります。最も一般的な原因は、タイムプロバイダーが同期されていない、設定されたソースが存在しない、またはntpサーバが実行されていないことです。
- t列は、サーバタイプ（l：ローカル、u：ユニキャスト、m：マルチキャスト、またはb：ブロードキャスト）を示します。
- when列は、リモートが照会された秒数を示します。
- poll 列は、ポーリング間隔（秒数）を示します。たとえば、64は、リモートが64秒ごとにポーリングされることを意味します。NTPが使用する最短の間隔は64秒ごとで、最長は1,024秒です。時間の経過に伴ってNTPソースの評価が向上するほど、間隔が長くなります。（UCの実装は、ここで定義されている間隔に従いません）。
- reach 列は、到達可能性テストの傾向を 8 進単位で示します。各桁は、バイナリに変換されると、特定のポーリングが成功（バイナリ 1）か失敗（バイナリ 0）かを表します。たとえば、「1」は、ポーリングがこれまでに1回だけ実行され、成功したことを意味します。3（=バイナリ11）は、最後の2つのポーリングが成功したことを意味します。7（=バイナリ111）は、最後の3回のポーリングが成功したことを意味します。17（=バイナリ1 111）は、最後の4回のポーリングが成功したことを意味します。15(= binary 1 101)は、最後の2つのポーリングが成功したことを意味します。それ以前のポーリングは失敗し、それ以前のポーリングは成功しました。
- 遅延、オフセット、およびジッタのカラムは、ラウンドトリップ遅延、分散、およびジッタ（ミリ秒単位）です。
CUCMでのNTP関連の問題の診断
NTP関連の問題を診断するには、次の手順を実行します。
- CUCMがポート123のNTPサーバと通信できることを確認します。
- utils ntp statusの出力を取得します。
- 最適なパフォーマンスを得るには、パブリッシャのストラタムレベルを4より小さくします。
- 複数のNTPサーバが設定されている場合は、少なくとも1つのサーバに到達できることを確認します。CUCMによって参照として使用されるNTPサーバに対する(*)記号を確認できます。
- syslogアラームを確認し、それに応じたアクションを実行します。Syslogアラームの考えられる原因は次のとおりです。
- 外部NTPサーバに到達できない。
- NTPストラタムが許容可能な制限を超えています。
- パブリッシャがダウンしているため、サブスクライバNTPは同期されていません。
- ntpdate -q関連のアラートが表示される場合は、NTPバージョン4.2.6+でKiss of Death(KoD)機能が有効になっている可能性があります。(設計上、任意のクライアントによって送信されるバーストパケットとiバーストパケットの最小間隔は2つですが、この制約に違反することはありません。この制約に違反する他の実装から送信されたパケットはドロップされ、KoDパケットが返されます（イネーブルになっている場合）。このバージョンをUC製品のNTPサーバとして使用する場合は、この機能を無効にすることを推奨します。
- この診断モジュールを使用して、NTPサーバが設定されていることを確認します。
- utils diagnoseモジュールntp_reachability
- utils diagnoseモジュールntp_clock_drift
- utils diagnoseモジュールntp_stratum
- utils ntp restartと入力して、NTPクライアント/サーバを再起動します。このコマンドは、総時間の修正をすぐに行う必要がある場合、または外部サーバに到達可能で稼働しているにもかかわらず同期が失敗する場合に役立ちます。外部NTPサーバの動作ステータスを確認するには、utils ntp statusコマンドを使用します。
CUCMでのNTPアソシエーションに関する一般的な既知の問題
Cisco Bug ID CSCue18813:CLIで制御されるNTP設定tos maxdistパラメータ
解決策：ntp.confファイルにtos maxdistパラメータを手動で追加するために、Cisco Technical Assistance Center(TAC)サービスリクエストを呼び出すことができます。
Cisco Bug ID CSCuq70611：単一のNTPサーバでNTPストラタムテストが適切に検証されない
修正バージョン：10.5(2.10000.005)
Cisco Bug ID CSCui85967:NTP参照がないために、6.1.5から9.1.2へのCUCMジャンプアップグレードが失敗する
解決策：ジャンプアップグレードに関するドキュメントが更新され、NTP設定がアップグレード前のタスクと同じように表示されます。
Cisco Bug ID CSCtw46611:capture.txtの誤ったファイルシステムラベルが原因でNTP同期が失敗する
修正バージョン：8.6(2.24900.017)
Cisco Bug ID CSCur94973:M1移行中のVMHostとVMインスタンス間の時刻同期の問題
解決策：この回避策を使用して、VMのNTPによるESXiホストとの同期を無効にします。別の回避策として、ESXiサーバとCUCMパブリッシャが同じNTPサーバをポイントするように設定します。
フィードバック