内容

概要

前提条件

要件

使用するコンポーネント

機能の目的

設定

ネットワーク図

インストールプロセス

インストール後、OS Admin Webページを使用します

インストール後は、コマンドラインインターフェイス(CLI)を使用します。

トラブルシュート

収集するデータ

分析例

CUCMのPCAPレビュー – ファイルなし

CUCM用PCAPレビュー – ファイルあり

CUCMのCLI出力レビュー

その他の考慮事項

関連情報

概要

このドキュメントでは、Cisco Unified Communications Manager(CUCM)のネットワークタイムプロトコル(NTP)について説明します。

前提条件

要件

このドキュメントに特有の要件はありません。

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

機能の目的

このドキュメントでは、CUCMを使用したNTPの目的、NTPの設定、トラブルシューティングのために収集するデータ、データの分析例、および追加調査のための関連リソースについて説明します。

CUCMを使用したNTPの目的は、サーバが正しい時刻を認識できるようにすることです。Voice Over Internet Protocol(VOIP)は時間の変動に非常に敏感であるため、CUCMサーバの時間は重要です。CUCMクラスタは、クラスタ内の他のサーバに近い時刻の同期を維持する必要があります。これは、データベースのレプリケーション要件が原因です。

最後に、正しいタイムスタンプをログに記録する必要があるため、トラブルシューティングに要する時間は重要です。

設定

CUCMには特定のNTPサーバが必要であることに注意してください。

Windows NTPサーバはCUCMではサポートされていませんが、Linux NTPソース、Cisco IOS® NTPソース、Nexus OS NTPソースなどの他のタイプは使用できます。他のシスコソリューションではNTPソリューションにWindowsサーバを使用できますが、CallManager、Cisco Unity、Instant Messaging and PresenceなどのUCソリューションでは使用できず、LinuxベースまたはCisco IOS®ベースのNTPソリューションが必要です。これは、Windows Time ServicesがSNTPを使用することが多く、Linuxシステムとの同期が困難であるためです。

ネットワーク図

CUCMパブリッシャには、CUCMクラスタのメンバではないNTPソースが必要です。そのため、CUCMパブリッシャは自身の時刻をNTPサーバと同期します。この交換では、CUCMパブリッシャはNTPクライアントです。

CUCMサブスクライバは、CUCMパブリッシャと時刻を同期します。この交換では、CUCMパブリッシャは、CUCMサブスクライバがNTPクライアントであるNTPサーバです。

注意:Cisco Instant Messaging & Presence(IM&P)サーバもCUCMクラスタのサブスクライバと見なされるため、CUCMのNTPにも依存することに注意してください。つまり、IM&PサーバでNTPが同期されていない場合、データベースレプリケーションとハイアベイラビリティに関する問題がシステムに発生します。

インストールプロセス

CUCMをインストールすると、サーバがクラスタ内の最初のノードかどうかを確認するプロンプトが表示されます。

サーバがクラスタ内の最初のノードでない場合、インストールウィザードはNTP設定フェーズを過ぎて移動します。ただし、クラスタ内の最初のノードである場合は、NTPサーバの入力が求められます。

インストール後、OS Admin Webページを使用します

インストール後は、コマンドラインインターフェイス(CLI)を使用します。

図に示すように、CUCMサーバ内のNTPサーバへのアクセスと変更に使用するコマンドを確認できます。

- コマンドutils ntp server listは、システムに設定されているNTPサーバを表示します。

- コマンドutils ntp server add ntp_addressは、システムに新しいNTPサーバを追加します。

注：新しいNTPサーバを追加する場合、CUCMサーバは追加する前に到達可能性をテストし、失敗すると次のエラーが表示されることに注意してください。

- utils ntp server deleteコマンドを使用すると、システム内ですでに設定されているNTPを削除できます。

トラブルシュート

収集するデータ

NTPの問題をトラブルシューティングする場合は、NTPの問題があるCUCMサーバから次のデータを収集する必要があります。

- utils diagnose testコマンドの出力

- utils ntp statusの出力

- Cisco Real-Time Monitor Tool(RTMT)から収集されたCUCMからのNTPログ

分析例

たとえば、CUCMパブリッシャとNTPからの次の情報が使用されています。

CUCMパブリッシャ

バージョン：11.5(1) SU5

FQDN:cucm-115.home.lab

IPアドレスは192.X.X.Xで始まる

NTP

Google NTPサーバから

FQDN:time1.example.com.ntp

IPアドレスは216.X.X.Xで始まる

CUCMのPCAPレビュー – ファイルなし

ポート番号が123であることに注意してください。これはNTPのポートです。テキストボックス内のコマンドの出力には、「NTPv4」で示されているように、NTPバージョンが4であることが示されています。パブリッシャは、「time1.example.com」との通信を確立するときにクライアントとして機能しますが、cucm-sub1、cucm-sub2、およびcucm-sub3との通信を確立するときにサーバとして機能します。

From the CLI of the publisher run the command "utils network capture port 123"

Wait until you see traffic (this can take a little time, or it may be instant) then hit

ctrl+c. Look in the traffic to find where your publisher is communicating with its NTP

server and the NTP server is communication with the publisher (if the NTP server isn't

replying then it is an issue in the network or with the NTP server). The primary focus of

this output is the NTP version. In CUCM 9 and later NTP version 3 (NTPv3) can cause issues

and an NTP source using NTPv4 should be the NTP server for the publisher.

admin:utils network capture size all count 10000000 port 123

Executing command with options:

size=128                count=1000              interface=eth0

src=dest=                   port=123

ip=

16:08:43.199710 IP cucm-sub3.home.lab.39417 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:08:43.199737 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.39417: NTPv4, Server, length 48

16:08:43.199823 IP cucm-sub3.home.lab.39417 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:08:43.199859 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.39417: NTPv4, Server, length 48

16:09:01.640980 IP cucm-115.home.lab.50141 > time1.example.com.ntp: NTPv4, Client, length 48

16:09:01.654675 IP time1.example.com.ntp > cucm-115.home.lab.50141: NTPv4, Server, length 48

16:09:01.654733 IP cucm-115.home.lab.50141 > time1.example.com.ntp: NTPv4, Client, length 48

16:09:01.667368 IP time1.example.com.ntp > cucm-115.home.lab.50141: NTPv4, Server, length 48

16:09:01.668612 IP cucm-115.home.lab.50141 > time1.example.com.ntp: NTPv4, Client, length 48

16:09:01.681366 IP time1.example.com.ntp > cucm-115.home.lab.50141: NTPv4, Server, length 48

16:09:01.681518 IP cucm-115.home.lab.50141 > time1.google.com.ntp: NTPv4, Client, length 48

16:09:01.694108 IP time1.google.com.ntp > cucm-115.home.lab.50141: NTPv4, Server, length 48

16:09:01.875016 IP cucm-115.home.lab.48422 > time1.google.com.ntp: NTPv4, Client, length 48

16:09:01.884476 IP cucm-sub3.home.lab.58072 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:01.884568 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.58072: NTPv4, Server, length 48

16:09:01.884954 IP cucm-sub3.home.lab.58072 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:01.884999 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.58072: NTPv4, Server, length 48

16:09:01.885381 IP cucm-sub3.home.lab.58072 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:01.885423 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.58072: NTPv4, Server, length 48

16:09:01.886147 IP cucm-sub3.home.lab.58072 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:01.886184 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.58072: NTPv4, Server, length 48

16:09:01.888555 IP time1.google.com.ntp > cucm-115.home.lab.48422: NTPv4, Server, length 48

16:09:01.888642 IP cucm-115.home.lab.48422 > time1.google.com.ntp: NTPv4, Client, length 48

16:09:01.900926 IP time1.google.com.ntp > cucm-115.home.lab.48422: NTPv4, Server, length 48

16:09:01.901017 IP cucm-115.home.lab.48422 > time1.google.com.ntp: NTPv4, Client, length 48

16:09:01.913497 IP time1.google.com.ntp > cucm-115.home.lab.48422: NTPv4, Server, length 48

16:09:01.913566 IP cucm-115.home.lab.48422 > time1.google.com.ntp: NTPv4, Client, length 48

16:09:01.926693 IP time1.google.com.ntp > cucm-115.home.lab.48422: NTPv4, Server, length 48

16:09:02.038981 IP cucm-sub2.home.lab.42078 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.039117 IP cucm-115.home.lab.ntp > cucm-sub2.home.lab.42078: NTPv4, Server, length 48

16:09:02.039281 IP cucm-sub2.home.lab.42078 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.039345 IP cucm-115.home.lab.ntp > cucm-sub2.home.lab.42078: NTPv4, Server, length 48

16:09:02.039434 IP cucm-sub2.home.lab.42078 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.039535 IP cucm-115.home.lab.ntp > cucm-sub2.home.lab.42078: NTPv4, Server, length 48

16:09:02.039607 IP cucm-sub2.home.lab.42078 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.039814 IP cucm-115.home.lab.ntp > cucm-sub2.home.lab.42078: NTPv4, Server, length 48

16:09:02.066544 IP cucm-sub1.home.lab.46400 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.066622 IP cucm-115.home.lab.ntp > cucm-sub1.home.lab.46400: NTPv4, Server, length 48

16:09:02.066751 IP cucm-sub1.home.lab.46400 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.066892 IP cucm-115.home.lab.ntp > cucm-sub1.home.lab.46400: NTPv4, Server, length 48

16:09:02.066968 IP cucm-sub1.home.lab.46400 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.067104 IP cucm-115.home.lab.ntp > cucm-sub1.home.lab.46400: NTPv4, Server, length 48

16:09:02.067155 IP cucm-sub1.home.lab.46400 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.067189 IP cucm-115.home.lab.ntp > cucm-sub1.home.lab.46400: NTPv4, Server, length 48

CUCM用PCAPレビュー – ファイルあり

パケットキャプチャでNTPの問題をトラブルシューティングするために使用されるフィルタは、udp.port == 123です。このフィルタを使用すると、CUCMパブリッシャがGoogle NTPサーバとの通信を確立し、CUCMパブリッシャがCUCMサブスクライバとも通信していることを確認できます。

CUCMのCLI出力レビュー

utils ntp status output

NOTE: All nodes will show the current time in UTC regardless of the time zone of the server

(listed in UTC time). This makes it easy to compare times on the different CUCM nodes.

NOTE: If there is a time difference of 15 minutes or more, it is expected that DB replication

will be broken

1) If the publisher is ahead by 15 minutes, this can result in the pub send data to the

sub and the sub would have a delay to process the data because it has not yet reached the time

in the timestamp of the packets from the publisher (this is expected behavior in this type of situation)

2) If  the subscriber is ahead by 15 minutes, this would result in the subscriber drop

the data from the publisher because the subscriber sees it as old data (15 minutes old)

admin:utils ntp status

ntpd (pid 28435) is running...

remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

203.0.113.0    .GOOG.           1 u   44   64    3   11.724   -0.021   0.064

unsynchronised

polling server every 8 s

Current time in UTC is : Fri Sep  6 20:54:50 UTC 2019

Current time in America/New_York is : Fri Sep  6 16:54:50 EDT 2019

admin:

前の出力を詳細に説明しているので、次の情報を読んでください。

The very first column contains the "tally code" character. Short overview:

* the source you are synchronized to (syspeer)

# source selected, distance exceeds maximum value

o the PPS(Pulse Per Second) source if your ntpd (ppspeer, only if you have a PPS capable system and refclock)

+ candidate, i.e. it is considered a good source

- outlyer, i.e. quality is not good enough

x falseticker, i.e. this one is considered to distribute bad time

blank: source discarded, failed sanity

See the Select field of the Peer status word on the NTP Event Messages and

Status Words page for more information on the tally codes.

remote

the hostname or IP of the remote machine.

refid

the identification of the time source to which the remote machines is synced.

May be (for example) a radio clock or another ntp server)

st

the stratum of the remote machine. 16 is "unsynchronized". 0 is the best

value, that could be (for example) a radio clock or the ntp servers private

caesium clock (see http://www.eecis.udel.edu/~mills/ntp/html/index.html#intro

for more information about ntp in general).

t

types available:

l = local (such as a GPS, WWVB)

u = unicast (most common)

m = multicast

b = broadcast

- = netaddr

when

how many seconds since the last poll of the remote machine.

poll

the polling interval in seconds.

reach

an 8-bit left-rotating register. Any 1 bit means that a "time packet" was

received. The right most bit indicate the status of the last connection

with the NTP server. It is Octal number. Use calculator in progammer

interface to translate from OCT to BIN: For example 377 translates to

11111111. Each 1 means a successful connection to the NTP server. If you

just start a NTP service, and it connects successfully with its server, this

number will change as follows (if connectivity is good):

00000001 = 001

00000011 = 003

00000111 = 007

00001111 = 017

00011111 = 037

00111111 = 077

01111111 = 177

11111111 = 377

delay

the time delay (in milliseconds) to communicate with the remote.

offset

the offset (in milliseconds) between our time and that of the remote.

jitter

the observed jitter (in milliseconds) of time with the remote.

Utils diagnoseテスト出力

admin:utils diagnose test

Log file: platform/log/diag1.log

Starting diagnostic test(s)

===========================

test - disk_space          : Passed (available: 6463 MB, used: 12681 MB)

skip - disk_files          : This module must be run directly and off hours

test - service_manager     : Passed

test - tomcat              : Passed

test - tomcat_deadlocks    : Passed

test - tomcat_keystore     : Passed

test - tomcat_connectors   : Passed

test - tomcat_threads      : Passed

test - tomcat_memory       : Passed

test - tomcat_sessions     : Passed

skip - tomcat_heapdump     : This module must be run directly and off hours

test - validate_network    : Passed

test - raid                : Passed

test - system_info         : Passed (Collected system information in diagnostic log)

test - ntp_reachability    : Passed

test - ntp_clock_drift     : Passed

test - ntp_stratum         : Passed

skip - sdl_fragmentation   : This module must be run directly and off hours

skip - sdi_fragmentation   : This module must be run directly and off hours

Diagnostics Completed

The final output will be in Log file: platform/log/diag1.log

Please use 'file view activelog platform/log/diag1.log' command to see the output

admin:

utils diagnoseテストの出力でNTPが失敗する場合は、次のような出力が表示されます。

admin:utils diagnose test

Log file: platform/log/diag1.log

Starting diagnostic test(s)

===========================

test - disk_space          : Passed (available: 6463 MB, used: 12681 MB)

skip - disk_files          : This module must be run directly and off hours

test - service_manager     : Passed

test - tomcat              : Passed

test - tomcat_deadlocks    : Passed

test - tomcat_keystore     : Passed

test - tomcat_connectors   : Passed

test - tomcat_threads      : Passed

test - tomcat_memory       : Passed

test - tomcat_sessions     : Passed

skip - tomcat_heapdump     : This module must be run directly and off hours

test - validate_network    : Passed

test - raid                : Passed

test - system_info         : Passed (Collected system information in diagnostic log)

test - ntp_reachability    : Warning

The NTP service is restarting, it can take about 5 minutes.

test - ntp_clock_drift     : Warning

The local clock is not synchronised.

None of the designated NTP servers are reachable/functioning or legitimate.

test - ntp_stratum         : Warning

The local clock is not synchronised.

None of the designated NTP servers are reachable/functioning or legitimate.

skip - sdl_fragmentation   : This module must be run directly and off hours

インストール時にNTPが正常であったことを確認します。次のコマンドを実行します：

cdrtime > getCurrTime()を使用して、デバイスからCDRTIMEとしてsql select pkid,name,dbinfo('utc_to_datetime', cdrtime)を実行します。

このコマンドは、現在の時刻をcdrtime（テーブルが変更されたとき）と比較します。インストール/アップグレードで誤ったNTPを使用し、その後NTPを修正した場合、変更が行われるたびにデータベースの同期が失われます。この問題は、不正なNTPソースから適切なNTPソースに移動したため、一般的なNTPコマンド(utils ntp statusなど)を実行しても発生しません。

問題のあるNTPから問題のないNTPに移行した方が良いのですが、問題のないNTPソースに移行しても、インストール/アップグレード中に作成されたテーブルは修正されません。

このコマンドを実行すると、予想される出力は次のようになります。

admin:run sql select pkid,name,dbinfo('utc_to_datetime', cdrtime) as CDRTIME  from device where cdrtime > getCurrTime()

pkid name cdrtime

==== ==== =======

admin:

次の出力と同様の出力がある場合は、インストール/アップグレードに使用されたNTPが使用されておらず、データベースの複製に影響する問題が発生していることを示しています。

admin:run sql select pkid,name,dbinfo('utc_to_datetime', cdrtime) as CDRTIME from device where cdrtime > getCurrTime()

pkid                                    name          cdrtime

=============================           =====         =====================

bf80dd31-9911-43ce-81fd-a99ec0333fb5    MTP_2         2016-09-11 14:38:14.0

4c38fc05-760d-4afb-96e8-69333c195e74    CFB_2         2016-09-11 14:38:14.0

90878c80-e213-4c7e-82b9-6c780aac72f3    ANN_2         2016-09-11 14:38:14.0

08b5bff4-da94-4dfb-88af-ea9ffa96872c    MOH_2         2016-09-11 14:38:14.0

93320e4d-1b73-4099-9a7c-c4cddfadb5d9    MTP_3         2016-09-11 14:38:14.0

a6850d42-5f0a-49ce-9fa3-80d45b800e23    CFB_3         2016-09-11 14:38:14.0

9963c9cb-58b0-4191-93e1-8676584f6461    ANN_3         2016-09-11 14:38:14.0

def79fb7-c801-4fb3-85fb-4e94310bf0bd    MOH_3         2016-09-11 14:38:14.0

4cd64584-089b-4331-9291-79774330cbc     2 MTP_4       2016-09-11 14:38:14.0

27b18882-db83-4d14-8bce-d3f8dc439610    CFB_4         2016-09-11 14:38:14.0

a40da882-e04f-4649-b2eb-2f79d1289e81    ANN_4         2016-09-11 14:38:14.0

36575ff4-cdea-4945-87e7-638cc555463e    MOH_4         2016-09-11 14:38:14.0

その他の考慮事項

1) VMハードウェアの考慮事項を考慮せずにESXiホストをアップグレードすると、NTPの問題が発生する可能性があります。

2) ESXiのバージョンが仮想化マトリックスに準拠していることを確認します。

3) ESXiバージョンとハードウェアバージョンに互換性があることを確認します。

関連情報

- テクニカルサポートとドキュメント – Cisco システムs

- Cisco Collaboration System 10.xソリューションリファレンスネットワークデザイン(SRND)

- CLIからのCUCMでのNTPソースの変更およびその他の役立つ情報

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

- ネットワーク・タイム・プロトコル: ベストプラクティス白書

- CUCMアプライアンスモデルでのパケットキャプチャ