はじめに
このドキュメントでは、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とストレージの移行に起因する総時間修正のために、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® NTPサーバ、あるいは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（=バイナリ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サーバを指すように設定することです。
フィードバック