Голосовая связь и система унифицированных коммуникаций : Cisco Unified Communications Manager (CallManager)

Устранение проблем NTP на Cisco Unified Communications Manager

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Отзыв

Введение

Этот документ описывает, как решить проблемы Протокола NTP на Cisco Unified Communications Manager (CUCM) и продуктах Унифицированной связи (UC) Cisco.

Внесенный Васантом Кумаром K, специалистом службы технической поддержки Cisco.

Общие сведения

CUCM требует, чтобы NTP был настроен для обеспечения:

  • Время на узлах CUCM синхронизируется.
  • Время корректно до любого критичного по времени изменения конфигурации, такого как регенерация сертификата.
  • Репликация базы данных синхронизируется на всех узлах в кластере.

Механизм опроса NTP в продуктах UC

CUCM использует сторожевой таймер NTP для хранения, время синхронизировалось с NTP server. Если время смещено больше чем на три секунды, Сторожевой таймер NTP периодически опрашивает настроенный внешний сервер (ы) NTP и перезапускает NTP.

Демон NTP регулярно исправляет время, но на шкале времени миллисекунды. Перезапуск NTP включает это, вы выполняете NTP, один вбежавший заказ выполнить грубое исправление времени и придержаться с перезапуском демона NTP для длительных обычных микроисправлений.

Сторожевой таймер NTP опрашивает NTP один раз минута на VMware и один раз в 30 минут на физических машинах. Интервал опроса короче для VMware, потому что часы в Виртуальных машинах (VM) менее стабильны, чем на физических машинах, и функции VMware, такие как VMotion, Миграция Хранилища оказывает негативное влияние на время.

Основной узел, который работает на VMware, должен всегда настраиваться для синхронизации с внешними серверами NTP, которые работают на физической машине (ах) для компенсации более высокую степень дрейфа времени или задержки VM. Вторичные узлы всегда автоматически настраиваются для ссылки на NTP server основного узла, чтобы гарантировать, что все узлы в кластере близки своевременно.

Сторожевой таймер NTP отслеживает скорость, на которой он перезапускает демона NTP для грубых исправлений времени из-за VMware Миграции Хранилища и VMotions. Если эта скорость превышает 10 перезапусков в час, Сторожевой таймер NTP откладывает дальнейшие перезапуски до требуемой скорости падений перезапусков ниже 10 в час. Комбинированная ставка VMotions и Миграций Хранилища не должна превышать 10 в час, потому что эту скорость считают чрезмерной.

Из-за этой Сторожевой реализации NTP вы не придерживаетесь интервала опроса, который замечен в utils статусе ntp. Перехват анализатора показывал 8 опросов NTP (выборка) каждые 60 секунд. Это прежде всего, потому что реализация NTP использует Сторожевой таймер NTP и как ntpdate опрашивает NTP server в Реализации UC.

Определите используемую версию NTP

Примечание: Издатель CUCM настроен с Внешним сервером NTP, и абонент, добавленный к кластеру, синхронизируется с Издателем.

Примечание: Версия 9.x CUCM и позже требует, чтобы сервер NTPv4 был настроен как предпочтительный NTP server.

Выполните перехват анализатора для определения версии NTP, используемой настроенным NTP server:

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, реализация CUCM NTP варьируется, который приводит к несинхронизованному 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

Для устранения проблемы Cisco рекомендует, чтобы вы использовали основанный на Linux внешний сервер NTP или Cisco IOS® или IOS основанный на XE NTP server и гарантировали, что настроен NTPv4.

Вот описание терминологии NTP в выходных данных статуса NTP:

  • Столбец переклина указывает на источник времени перепятнышка. ЛОКАЛЬНЫЙ (0) часы локального оборудования..INIT. означает, что еще не успешно выполнилась инициализация.

  • Столбец Св. является стратой удаленного NTP server. 16 недопустимое значение страты, которое означает, что "этот сервер не считают поставщиком времени". Страта может быть недопустима по различным причинам, наиболее распространена, из которых то, что ""not synchronized" поставщик времени", "настроенный источник не существует", или "ntp server, не работающий".

  • T столбец указывает на тип сервера (l: локальный; u: индивидуальная рассылка; m: групповая адресация или b: широковещание).

  • Когда столбец указывает, сколько несколько секунд назад делали запрос удаленное.

  • В секундах столбец опроса указывает на интервал опроса. Например, "64" означает, что удаленное опрашивается каждые 64 секунды. Самое короткое использование NTP интервала каждые 64 секунды, и самыми длинными составляют 1,024 секунды. Чем лучше NTP source оценен в течение долгого времени, тем дольше интервал. (Реализация UC не придерживается интервала, определенного здесь.)

  • Столбец досягаемости указывает на тенденцию тестов достижимости в восьмеричном, где каждая цифра, когда преобразовано в двоичные файлы, представляет, был ли определенный опрос успешен (двоичные файлы 1) или неуспешен (двоичные файлы 0). Например, "1" означает, что только один опрос был сделан к настоящему времени, и это было успешно. "3" (= двоичные файлы 11) означает, что последние два опроса были успешны. "7" (= двоичные файлы 111) означает, что последние три опроса были успешны. "17" (= двоичные файлы 1 111) означает, что последние четыре опроса были успешны. "15" (= двоичные файлы 1 101) означает, что последние два опроса были успешны, опрос до этого был неуспешен, и опрос до этого был успешен.

  • Задержка, смещение и столбцы дрожания являются задержкой приема-передачи, дисперсией и дрожанием в миллисекундах.

Диагностируйте связанные с NTP проблемы в CUCM

Выполните эти шаги для диагностирования связанных с NTP проблем:

  1. Гарантируйте, что CUCM может связаться с NTP server на порту 123.

  2. Получите выходные данные utils статуса ntp.

    • Уровень декомпозиции должен быть меньше чем 4 на издателе для оптимальной производительности
    • Если множественный Ntp server настроен, убеждается, по крайней мере, на сервере, достижимо; необходимо видеть (*) символ против NTP server, используемого в качестве ссылки CUCM.


  3. Рассмотрите системный журнал, встревожили и принимают меры соответственно. Вероятные причины сигналов тревоги системного журнала:

    • Внешний сервер NTP не достижим.
    • Страта NTP выше, чем приемлемый предел.
    • Издатель не работает, таким образом, NTP Абонента несинхронизован.
    • Если ntpdate-q связанные предупреждения замечены, возможно, что у вас есть версия 4.2.6 NTP + с активированной опцией Поцелуя смерти (KoD). (Дизайном минимальному интервалу между пакетом и iburst пакетами, переданными любым клиентом, два года, который не нарушает это ограничение. Пакеты, переданные другими реализациями, которые нарушают это ограничение, будут отброшены, и пакет KoD возвратился, если включено). Когда вы используете ту версию в качестве NTP server для продукта UC, рекомендуется отключить эту опцию.


  4. Используйте этот модуль диагноза, чтобы проверить, что настроен NTP server.

    • utils диагностируют модуль ntp_reachability
    • utils диагностируют модуль ntp_clock_drift
    • utils диагностируют модуль ntp_stratum


  5. Введите utils перезапуск ntp для перезапуска клиента NTP / сервер. Эта команда полезна каждый раз, когда грубое исправление времени должно сразу произойти или каждый раз, когда внешние серверы все еще достижимы и в рабочем состоянии, но сбои синхронизации. Используйте команду utils ntp status для определения рабочего состояния внешних серверов NTP.

Общие известные неполадки с сопоставлением NTP на CUCM

Идентификатор ошибки Cisco CSCue18813: Конфигурация NTP "вершина стека maxdist" параметр управляется через CLI

Разрешение: случай Центра технической поддержки Cisco должен быть повышен для ручного добавления вершины стека maxdist параметр в ntp.conf файле.

Идентификатор ошибки Cisco CSCuq70611: тест Страты NTP не проверяет должным образом с одиночным NTP Server

Исправленная версия: 10.5 (2.10000.005)

Идентификатор ошибки Cisco CSCui85967: CUCM переходят обновление от 6.1.5 до 9.1.2 сбоев из-за ссылочных без вести пропавших NTP

Разрешение: документация обновления Перехода была обновлена, и конфигурация NTP перечислена как на задач, предшествующих обновлению.

Идентификатор ошибки Cisco CSCtw46611: синхронизация NTP отказывает из-за неправильной маркировки файловой системы capture.txt

Исправленная версия: 8.6 (2.24900.017)

Идентификатор ошибки Cisco CSCur94973: синхронизование Времени выполняет betn VMHost & VM Instance во время миграции M1

Разрешение: Отключите синхронизование NTP VM с хостом ESXi с использованием этого обходного пути. Альтернативный обходной путь должен настроить сервер ESXi и Издателя CUCM для обращения к тому же NTP server. 


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.