Совместная работа : Cisco ICM Router Software

Состояние рассинхронизации ICM/IPCC CallRouter

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


Содержание


Введение

Этот документ выделяет рекомендуемые шаги, и уровни трассировки должны были устранить неполадки события out-of-sync в Cisco Унифицированный Intelligent Contact Management (ICM) Contact Center дуплексный CallRouters.

Предварительные условия

Требования

Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:

  • Cisco ICM

  • Понимание высокого уровня функциональности Центрального устройства управления icm

  • Regedit

  • Microsoft SQL

Используемые компоненты

Сведения в этом документе основываются на Cisco ICM Version 5.x и позже.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.

Описание

В редких случаях ICM CallRouter могут стать из синхронизования с его дуплексным партнером. Основной спусковой механизм для этого события является неверной контрольной суммой между CallRouter и его узлом. Когда CallRouters становятся из синхронизования, файл Дампа стандартного объекта (SOD) генерируется, который является дампом памяти маршрутизатора при сбое.

Событие out-of-sync может привести к вызовам, являющимся неверно маршрутизованным CallRouter.

Любой из этих методов может использоваться для проверки для условий из синхронизования:

  • CallRouters автоматически выполняют синхронизирующую проверку между этими двумя сторонами каждые 15 секунд. Если это обнаруживает условие из синхронизования, CallRouter создает файл SOD в этом каталоге:

    <drive>:\icm\<instance>ra 
    and 
    <drive>:\icm\<instance>rb
  • Это сообщение генерируется в Журнале приложения в Windows Event Viewer на CallRouter. Вот подробные данные сообщения:

    the router has detected that it no longer synchronized with its partner

    Trap-сообщение SNMP также генерируется.

  • От CallRouter (rtr) журналы (только пример):

    ra-rtr The router has detected that it is no longer synchronized with its partner 
    ra-rtr Trace: RunningSyncCheck failure: SideA reported 0A7FDF68, B reported FF1319C5 
    ra-rtr Trace: Wrote 719296 records to sync32932.sod, total length = 1871522788 bytes 
    ra-rtr Trace: Router dump created in sync32932.sod 
    rb-rtr The router has detected that it is no longer synchronized with its partner 
    rb-rtr Trace: RunningSyncCheck failure: Side A reported 0A7FDF68, B reported FF1319C5 
    rb-rtr Trace: Wrote 719296 records to sync32932.sod, total length = 187152790 bytes 
    rb-rtr Trace: Router dump created in sync32932.sod

Дополнительная Регистрация

Примечание: Стандартные файлы SOD, которые генерируют в результате, когда CallRouters выходят, имеют свои ограничения и существуют времена, когда разработка требует, чтобы более гранулированный уровень отладки лучше изолировал причину. При выполнении ICM 5.0 (0) SR8 или позже у вас есть два ключа реестра, которым можно позволить увеличить отладку файлов SOD.

Включите эти отладки реестра на обоих CallRouters:

HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\
<cust_instance>\RouterX\Router\CurrentVersion\Debug

Существует две записи, MessageTrackingEnabled и MessageTrackingLimit.

Установите эти значения:

  • MessageTrackingEnabled = 1

  • MessageTrackingLimit = 10000 (десятичное значение)

Примечание: Они - динамические значения и сразу вступают в силу. Это не вызывает непредусмотренного поведения с ICM. То, когда вы устанавливаете эти трассовые биты, это включает более подробную отладку файла SOD, должно другое условие из синхронизования происходить. Не требуется для отключения этих двух трассовых битов они должны остаться на. Однако эти трассовые биты возвращаются назад к значению по умолчанию (т.е. прочь), если настройка выполнена на CallRouters. Если это происходит, им нужно вручную реактивировать.

Сбор данных

Эти данные и информация необходимы при запросе поддержки Центра технической поддержки Cisco простоя:

  1. Примечание точное время сбоя.

  2. Соберите журналы CallRouter от обеих сторон (rtr, mds, нм, ccag) для временной рамки простоя.

  3. Соберите Просмотр событий (Система и Приложение) журналы, экспортируемые в текстовом формате щелчком правой кнопкой мыши по соответствующей регистрационной папке, и выберите Save As. Выберите Text под Сохранением, Поскольку выпадает Тип.

  4. Соберите файлы SOD от обоих CallRouters.

  5. Соберите CallTypeHalfHour, TCD и записи RCD, которые охватывают с 2.5 часов, прежде чем маршрутизаторы вышли и спустя 1 час после того, как это восстанавливается.

    Они должны быть в разграниченном формате вкладки, и они должны быть разгружены от обеих сторон Logger. Эти записи MUST прибывают из обеих сторон Logger.

    Это - SQL-запрос в качестве примера:

    SELECT * FROM Call_Type_Half_Hour 
    WHERE DateTime >= 'yyyy-mm-dd hh:mm' /* At least 2.5 hours before the 
    out of sync error occurred */ 
    AND DateTime < 'yyyy-mm-dd hh:mm' /* At least 1 hour after the 
    out of sync error occurred or less 
    if run within an hour of the problem happening */ 
    
    SELECT * FROM Termination_Call_Detail 
    WHERE DateTime >= 'yyyy-mm-dd hh:mm' /* At least 2.5 hours before the 
    out of sync error occurred */ 
    AND DateTime < 'yyyy-mm-dd hh:mm' /* At least 1 hour after the 
    out of sync error occurred or less 
    if run within an hour of the problem happening */ 
    
    SELECT * FROM Route_Call_Detail 
    WHERE DateTime >= 'yyyy-mm-dd hh:mm' /* At least 2.5 hours before the 
    out of sync error occurred */ 
    AND DateTime < 'yyyy-mm-dd hh:mm' /* At least 1 hour after the 
    out of sync error occurred or less 
    if run within an hour of the problem happening*/
  6. Соберите файлы vrutrace на каждом Peripheral Interface Manager устройства с речевым ответом (VRUPIM) с обеих сторон Периферийных шлюзов (PG), которые покрывают временную рамку по крайней мере за 1 час до того, как маршрутизатор будет из синхронизования и спустя 30 минут после того, как это восстанавливается.

    Обратитесь к тому, Как Использовать утилиту vrutrace для получения дополнительной информации.

  7. Выполните утилиту dumpcfg против обеих баз данных журналов событий (logger database) со времени, прежде чем они вышли ко времени после.

    Отнеситесь для Использования Инструмента администрирования dumpcfg для Отслеживания Изменений Конфигурации ICM для получения дополнительной информации.

  8. Используйте icmdba для экспорта конфигурации от обоих Logger.

  9. Экспортируйте все ответвление реестра ICM от обеих сторон CallRouters.

    HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems,Inc.

Обходной путь

Это эти два параметра обхода:

  • Циклически повторите оба CallRouters путем завершения, оба Процесса CallRouter и затем запуская их выполняют резервное копирование снова. Это - самый чистый способ обойти это условие.

  • Перезапустите одну сторону CallRouters.

Обе из этих опций заставляют CallRouters повторно синхронизовать и работать в синхронизовании. Это означает, что обе стороны CallRouter снова направят, вызывает тот же путь.

Опция 1 является предпочтительным способом и приводит к более высокой вероятности обоих CallRouters, направляющих все вызовы правильно, когда перезапущено. Однако, если вы не можете рискнуть наличия обоих CallRouters вниз в то же время, опция 2 может использоваться вместо этого.

Опция 2 может привести к тому же уровню успеха как опция 1. Опция 2 заставляет CallRouters повторно синхронизовать, и маршрут обеих сторон вызывает тот же путь. Однако, если CallRouter, который не был перезапущен, имел неверное состояние после того, как пересинхронизация, состояния CallRouter в обеих сторонах являются неправильными. Этот случай может вести оба CallRouters, невзирая на то, что синхронизируется, направлять некоторые вызовы неправильно. Шанс, что это произойдет, мог бы быть немного выше, чем если бы сделаны шаги в опцию 1.

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

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

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


Дополнительные сведения