はじめに
このドキュメントでは、IM and Presence（IM&P）でのネットワーク タイム プロトコル（NTP）の同期のトラブルシューティング方法について説明します。
前提条件
このドキュメントを参照する前に、NTPとIM&Pコマンドラインインターフェイス(CLI)の基本的な知識を持っていることが推奨されます。
要件
このドキュメントに関してはハードウェアまたはソフトウェアの個別の要件はありません。
使用するコンポーネント
このドキュメントの情報は、IM&P に基づくものです。
注：この情報の多くは、他のユニファイドコミュニケーション(UC)プラットフォームにも適用されます。ただし、このドキュメントではIM&Pに焦点を当てています。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
IM&P の NTP について
Cisco Unified Communications Manager(CUCM)パブリッシャは、IM&PのNTPソースです。IM&PはNTPウォッチドッグを使用して、CUCMパブリッシャと時刻の同期を維持します。仮想マシン上の IM&P プラットフォームの場合、NTP ウォッチドッグはデフォルトで CUCM パブリッシャを 64 秒おきにポーリングします。 NTPのオフセットが3秒を超えると、NTPデーモンが自動的に再起動します。
注:NTPウォッチドッグは、直前の1時間にNTPデーモンが再起動した回数を監視します。1 時間の NTP デーモンの再起動回数が 10 回を超えると、以降の再起動は一時的に延期されます。
NTP ソースの要件
CUCMパブリッシャの外部NTPリファレンスとして、ストラタム1、ストラタム2、またはストラタム3のNTPサーバを使用することを強くお勧めします。CUCM パブリッシャのどの NTP ソースにも、ストラタム 4 を超えるストラタムを使用しないでください。
互換性、精度、およびネットワーク ジッタの問題を回避するために、CUCM パブリッシャ ノードに指定する外部 NTP サーバは、NTP v4 にする必要があります。NTPバージョン4はバージョン3と下位互換性がありますが、異なるNTPバージョンを使用すると多くの問題が発生します。
警告: Windows Time ServicesのNTPサーバーとしての使用はサポートされていません。多くの場合、Windows Time サービスは簡易ネットワーク タイム プロトコル（SNTP）を使用し、CUCM は SNTP と正常に同期できません。
注：すべてのNTP要件は、Cisco Collaboration System SRNDで明確に示されています。
NTP ステータス出力について
IM&P での NTP の現在のステータスを判断するには、IM&P サーバの CLI から utils ntp status コマンドを実行します。
admin:utils ntp status
ntpd (pid 28589) is running...
remote refid st t when poll reach delay offset jitter
==============================================================================
10.0.0.1 192.0.2.0 2 u 40 64 1 0.292 0.041 0.000
synchronised to NTP server (10.0.0.1) at stratum 3
time server re-starting
poll server every 64 s
Current time in UTC is : Fri Sep 16 19:41:55 UTC 2016
Current time in America/New_York is : Fri Sep 16 15:41:55 EDT 2016
ここでは、NTPステータス出力に表示される列について説明します
- remote 列は、時間が同期されるリモートピアを定義します。LOCAL に設定されている場合、ローカル ハードウェア クロックが使用されています。
- refid列は、リモートサーバの時刻源を定義します。.LOCL.に設定すると、リモートサーバのローカルハードウェアクロックが参照されます。.INIT. に設定されている場合、初期化はまだ成功していません。
- st 列は、リモート NTP ピアのストラタムを示します。ストラタム列の値が16の場合、システムは外部NTPソースの代わりに内部クロックを使用することを意味します。独自のクロックを使用するシステムは、無効なタイムプロバイダーによって引き起こされる可能性があります。
- t列は、使用中の伝送タイプ（l：ローカル、u：ユニキャスト、m：マルチキャスト、またはb：ブロードキャスト）を示します。
- when 列は、リモート ピアが最後にポーリングされてから経過した秒数を示します。
- poll列は、ポーリング間隔（秒単位）を示します。IM&Pのデフォルトポーリング値は64秒です。ただし、この値は、64 ~ 1,024 秒のどの値にも設定できます。
- reach 列は、到達可能性テストの傾向を 8 進単位で示します。各桁は、バイナリに変換されると、特定のポーリングが成功（バイナリ 1）か失敗（バイナリ 0）かを表します。 たとえば、「1」は、これまでに実行されたポーリングが1回だけで、成功したことを意味します。「3」（=バイナリ11）は、最後の2回のポーリングが成功したことを意味します。「7」（=バイナリ111）は、最後の3回のポーリングが成功したことを意味します。「17」（=バイナリ1 111）は、最後の4回のポーリングが成功したことを意味します。
- delay 列には、リモート ピアに対するラウンド トリップ遅延が表示されます。これは、要求から応答までの時間を測定することで決定されます。
- offset 列は、ローカル サーバ クロックとリモート サーバ クロック間の推定偏差です。
- jitter 列は、ポーリング要求間の遅延の変動性を表します。 ジッタ値が高いと、サーバでNTPを正確に同期する機能が制限されます。
NTP のトラブルシューティング
NTP CLI の診断
例に示されているコマンドは、IM&PのCLIから実行されます。これらのコマンドを使うと、NTP ピアがシスコの基準を満たしているか簡単に確認できます。
ヒント：これらの3つの診断モジュールはすべて、他のいくつかの診断モジュールとともに、utils diagnose test使用されるコマンド
ntp_reachability 診断モジュールは、設定されたすべての NTP ピアに対する ping テストを実行します。
admin:utils diagnose module ntp_reachability
Log file: platform/log/diag2.log
Starting diagnostic test(s)
===========================
test - ntp_reachability : Passed
Diagnostics Completed
ntp_clock_drift 診断モジュールは、NTP ピアのドリフト オフセットが 15,000 ミリ秒を超えていないか確認します。
admin:utils diagnose module ntp_clock_drift
Log file: platform/log/diag3.log
Starting diagnostic test(s)
===========================
test - ntp_clock_drift : Passed
Diagnostics Completed
ntp_stratum 診断モジュールは、IM&P の NTP ストラタム値を確認します。CUCMパブリッシャがIM&Pの外部NTPソースであるため、CUCMパブリッシャのNTPストラタムの値が5以下であれば、このテストは成功します。
admin:utils diagnose module ntp_stratum
Log file: platform/log/diag4.log
Starting diagnostic test(s)
===========================
test - ntp_stratum : Passed
Diagnostics Completed
ヒント:ntp_stratumモジュールがシステムで失敗した場合は、このドキュメントの「NTPソースの要件」を参照してください
NTP の通信とバージョンの確認
NTP は、ポート 123 で、User Datagram Protocol（UDP）を介して通信するクライアント/サーバ プロトコルです。NTP通信およびNTPバージョンを確認するには、IM&Pサーバでパケットキャプチャ(pcap)を実行する必要があります。
ヒント:pcapでIM&PによるNTP要求の送信が確認できる場合でも、NTP応答がなく、ネットワークの問題が原因である可能性があります。同時にpcapを収集する CUCMサーバとIM&Pサーバで、IM&Pから送信された要求がCUCM側で受信されたことを確認します。CUCMも要求に応答していることを確認します。
パケットキャプチャには、NTPクライアント要求ごとに1つのNTPサーバ応答が表示されます。 NTP Client\Serverメッセージには、使用中のNTPバージョンが表示されます。クライアント要求とサーバ応答の両方が NTPv4 を使用していることを確認します。
CLI コマンド utils network capture port 123 を実行して、ポート 123 のパケット キャプチャを作成します。このコマンドは、IM&P でも CUCM でも同じです。
IM&P CLI
admin:utils network capture port 123
Executing command with options:
size=128 count=1000 interface=eth0
src=dest= port=123
ip=
09:44:43.106325 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.109866 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.109931 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.112815 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.112895 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.113305 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.113361 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.114157 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
CUCM パブリッシャの CLI
admin:utils network capture port 123
Executing command with options:
size=128 count=1000 interface=eth0
src=dest= port=123
ip=
09:44:43.106744 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.106872 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.109866 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.109914 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.112637 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.112719 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.113532 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.113575 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
フィードバック