音声とユニファイド コミュニケーション : Cisco Unified Communications Manager(CallManager)

Cisco Unified Communications Manager の NTP トラブルシューティング

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

概要

この資料に Cisco Unified Communications Manager (CUCM)および Cisco Unified Communications (UC)製品の Network Time Protocol (NTP)問題を解決する方法を記述されています。

Vasanth Kumar K によって貢献される、Cisco TAC エンジニア。

背景説明

CUCM は NTP が確認するために設定されることを必要とします:

  • CUCM ノードの時間は同期されます。
  • 時間は認証再生成のようなあらゆる時間に依存 する コンフィギュレーション変更前に正しいです。
  • データベース複製はクラスタのすべてのノードで同期されます。

UC 製品の NTP ポーリングメカニズム

CUCM は時間を NTP サーバと同期しておくために NTP ウオッチドッグを使用します。 NTP ウオッチドッグは定期的に時間が 3 秒以上までに相殺される場合設定された外部 NTP サーバをポーリングし、NTP を再起動します。

NTP デーモンは規則的に 1ミリ秒時間目盛の正しい時刻を。 NTP の再始動は総体時間修正を行い、継続的だった規則的なマイクロ修正のための NTP デーモンの再始動と続くためにワン・ショット NTP を実行すること含みます。

NTP ウオッチドッグは分および一度物理マシンの 30 分毎に NTP を VMware の一度ポーリングします。 ポーリング間隔は仮想マシン(VM)のクロックが VMotion のような物理マシンおよび VMware 機能でよりより少なく安定 して いるので VMware のためにより短いです、ストレージ 移行不利に影響を与えます時間に。

VMware で動作するプライマリ ノードは時間ドリフトの高度を補正するか、または VM で遅らせるために物理マシンで動作する外部 NTP サーバによって同期するために常に設定する必要があります。 セカンダリ ノードは常に自動的にクラスタ内のすべてのノードが時間に密接であることを確認するためにプライマリ ノード NTP サーバを参照するように設定されます。

NTP ウオッチドッグは VMWare VMotions およびストレージ移行による総体時間修正のための NTP デーモンを再起動する比率を把握します。 この比率が時間毎に 10 の再起動を超過する場合、NTP ウオッチドッグは再起動の必須比率が時間ごとに 10 の下で下るまでそれ以上の再起動を延期します。 VMotions およびストレージ移行の結合された比率はこの比率が余分考慮されるので時間ごとに 10 を超過するべきではありません。

このような理由で NTP ウオッチドッグ実装、utils NTP ステータスで見られるポーリング間隔に続きません。 スニファー キャプチャは 60 秒毎に 8 つの NTP ポーリング(サンプル)を明らかにしました。 これは主に NTP 実装が NTP ウオッチドッグを使用するどのように ntpdate が UC 実装の NTP サーバをポーリングするのであり。

使用される NTP バージョンを確認して下さい

: CUCM パブリッシャは外部 NTP サーバで設定され、クラスタに追加されるサブスクライバはパブリッシャに同期します。

: CUCM バージョン 9.x および それ 以降は NTPv4 サーバが優先 する NTP サーバで設定されることを必要とします。

設定された 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 という結果に終る NTP の CUCM 実装は変わります、:

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

問題を解決するために、Cisco は使用し、Linuxベース 外部 NTP サーバか Cisco IOS ® または IOS XE ベースの NTP サーバを NTPv4 が設定されるようにします推奨します。

NTP ステータス 出力の NTP 用語の説明はここにあります:

  • refid カラムは遠隔の時刻源を示します。 LOCAL(0) はローカルハードウエア クロックです。 .INIT は初期化がまだ成功していないことを意味します。

  • st カラムはリモート NTP サーバの層です。 16 は「このサーバ時間プロバイダ」とはみなされないことを意味すること無効 な 層値です。 もっとも一般的ながこと「同期されない」時間プロバイダである層は「設定されたソース 存在 しません」、または「動作しない」NTP サーバさまざまな理由で無効である場合もあります。

  • T カラムはサーバタイプ(l を示します: ローカル; u: ユニキャスト; m: マルチキャスト、か b: ブロードキャスト)。

  • 何秒前に遠隔が問い合わせられたかカラムが示す

  • Poll カラムは秒のポーリング間隔を示します。 たとえば、"64" は遠隔が 64 秒毎にポーリングされることを意味します。 最も短い間隔 NTP 使用は 64 秒毎にであり、最も長いの 1,024 秒です。 よりよく NTP ソースが一定時間にわたり評価されれば、より長い間隔。 (UC 実装はここに定義される間隔に続きません。)

  • 範囲カラムは特定のポーリングは正常だったかどうかバイナリかに変換されたとき、各ディジットが表すところで、8 の到達可能性 テストの傾向を示します(1) バイナリか不成功(0) バイナリ。 たとえば、"1" は 1 つのポーリングだけこれまでに行われ、正常だったことを意味します。 最後の 2 つのポーリングが正常だったことを "3" (= バイナリは 11)意味します。 最後の 3 つのポーリングが正常だったことを "7" (= バイナリは 111)意味します。 最後の 4 つのポーリングが正常だったことを "17" (= バイナリ 1 は 111)意味します。 最後の 2 つのポーリングが正常だったことを "15" (= バイナリ 1 は 101)意味します、それ前のポーリングは不成功であり、それ前のポーリングは正常でした。

  • 遅延オフセットおよびジッタ カラムはミリ秒の往復遅延、分散およびジッタです。

CUCM の NTP 関連の問題を診断して下さい

NTP 関連の問題を診断するためにこれらのステップを完了して下さい:

  1. CUCM がポート 123 の NTP サーバと通信できるようにして下さい。

  2. utils NTP ステータスの出力を得て下さい。

    • 階層レベルは最適化されたパフォーマンスのためのパブリッシャの 4 つより小さいはずです
    • 複数の NTP サーバが設定される場合、サーバで少なくともです到達可能確認して下さい; CUCM によって参照として使用される NTP サーバに対して(*)記号を見るはずです。


  3. syslog アラームを検討し、処置をそれに応じてとって下さい。 syslog アラームの推定 原因は次のとおりです:

    • 外部 NTP サーバは到達可能ではないです。
    • NTP 層は許容可能な限界より高いです。
    • パブリッシャはダウンしています、従ってサブスクライバ NTP は非同時性です。
    • ntpdate なら-有効に なる(KoD)機能災いの種を用いる NTP バージョン 4.2.6+ があること q 関連アラートは、それです可能性のある見られます。 (意図的に、バースト間の最小間隔およびこの制約に違反しないあらゆるクライアントが送信する iburst パケットは 2 です。 イネーブルになった)この制約に廃棄される違反するおよび戻る KoD パケット他の実装によって送信されるパケット。 UC 製品のために NTP サーバとしてそのバージョンを使用するときこの機能をディセーブルにすることを推奨します。


  4. NTP サーバが設定されることを確認するためにこの診断 モジュールを使用して下さい。

    • utils はモジュール ntp_reachability を診断します
    • utils はモジュール ntp_clock_drift を診断します
    • utils はモジュール ntp_stratum を診断します


  5. クライアント/サーバ NTP を再起動するために utils NTP 再始動を入力して下さい。 このコマンドはまたは外部サーバがまだ到達可能および正常に動作しているすぐに発生する必要があるか、同期は失敗しますが時はいつでも総体時間修正が役立ちます。 外部 NTP サーバの動作状態を判別するために utils NTP status コマンドを使用して下さい。

CUCM の NTP アソシエーションにおいてのよくある既知の問題

Cisco バグ ID CSCue18813: CLI によってパラメータ制御 NTP 設定「TOS maxdist」

解決策: Cisco Technical Assistance Center ケースは手動で ntp.conf ファイルTOS maxdist パラメータを追加するために上げる必要があります。

Cisco バグ ID CSCuq70611: NTP 層テストは単一 NTP サーバときちんと検証しません

修正済み バージョン: 10.5(2.10000.005)

Cisco バグ ID CSCui85967: 6.1.5 から 9.1.2 まで CUCM ジャンプ アップグレードは NTP 参照行方不明が原因で失敗します

解決策: ジャンプ アップグレード ドキュメントはアップデートされ、NTP 設定はアップグレード前の作業のとしてリストされています。

Cisco バグ ID CSCtw46611:  NTP 同期化は capture.txt の不正確なファイル システム分類が原因で失敗します

修正済み バージョン: 8.6(2.24900.017)

Cisco バグ ID CSCur94973: 時間同期に関する問題 betn VMHost 及び M1 移行の間の VM 例

解決策: この回避策の使用の ESXi ホストの VM の NTP 同期化をディセーブルにして下さい。 別の回避策は同じ NTP サーバを指すために ESXi サーバおよび CUCM パブリッシャを設定することです。 



Document ID: 118718