Colaboración : Cisco ICM Router Software

El CallRouter ICM/IPCC fuera de sincroniza la condición

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Traducción Manual (15 Abril 2008) | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento delinea los pasos recomendados y los niveles de traza necesarios para resolver problemas un evento del hacia fuera-de-sincronizar en los CallRouters duplicados unificados Cisco del Intelligent Contact Management del Centro de contacto (ICM).

prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

  • ICM de Cisco

  • Comprensión de alto nivel controlador central ICM de las funciones

  • Regedit

  • Microsoft SQL

Componentes Utilizados

La información en este documento se basa en la versión 5.x y posterior del Cisco ICM.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Descripción

En las instancias poco frecuentes, los CallRouteres ICM pueden convertirse hacia fuera-de-sincronizan con su partner dúplex. El activador principal para este evento es un checksum con fallas entre el CallRouter y su par. Cuando se convierten los CallRouters hacia fuera-de-sincronice, un archivo estándar del volcado del objeto (CÉSPED) se genera que sea un vaciado de memoria del router actualmente el error.

Un evento del hacia fuera-de-sincronizar puede llevar a las llamadas que son encaminadas erróneamente por el CallRouter.

Ninguno de estos métodos se pueden utilizar para marcar para hacia fuera-de-sincronizan las condiciones:

  • Los CallRouters realizan automáticamente un control del sincronizar entre los dos echan a un lado cada 15 segundos. Si detecta una condición del hacia fuera-de-sincronizar, el CallRouter crea un archivo del CÉSPED dentro de este directorio:

    <drive>:\icm\<instance>ra 
    and 
    <drive>:\icm\<instance>rb
  • Este mensaje se genera en el log de aplicaciones dentro del visor de eventos de Windows en el CallRouter. Aquí están los detalles del mensaje:

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

    Un SNMP trap también se genera.

  • Del CallRouter (rtr) registra (ejemplo solamente):

    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

Registro adicional

Nota: Los archivos estándar del CÉSPED que generan como consecuencia cuando van los CallRouters hacia fuera-de-sincronizan tienen sus limitaciones y hay las épocas en que el dirigir requiere un nivel más granular de debugging aislar mejor la causa. Si usted ejecuta ICM 5.0 (0) SR8 o más adelante, usted tiene dos claves de registro que se puedan habilitar para aumentar el debugging de los archivos del CÉSPED.

Habilite estos debugs del registro en ambos CallRouters:

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

Hay dos entradas, MessageTrackingEnabled y MessageTrackingLimit.

Fije estos valores:

  • MessageTrackingEnabled = 1

  • MessageTrackingLimit = 10000 (valor decimal)

Nota: Éstos son valores dinámicos y toman el efecto inmediatamente. Esto no causa ninguna conducta anormal con el ICM. Cuando usted fija estos bits de la traza, habilita un debug más detallado del archivo del CÉSPED si ocurre otro hacia fuera-de-sincroniza la condición. No hay necesidad de inhabilitar estos bits de dos trazas, ellos debe quedar orientado. Sin embargo, estos bits de la traza invierten de nuevo al valor predeterminado (es decir apagado) si la configuración se funciona con en los CallRouters. Si ocurre esto, necesitan ser vueltos a permitir manualmente.

Recolección de datos

Estos datos e información es necesarios cuando usted pide el soporte del TAC de Cisco para la caída del sistema:

  1. Observe la hora exacta de error.

  2. Recoja los registros del CallRouter de los ambos lados (rtr, los mds, nanómetro, ccag) para el timeframe de la caída del sistema.

  3. Recoja el visor de eventos (sistema y aplicación) que los registros exportados en el formato de texto por un derecho del mouse hacen clic en la carpeta respectiva del registro y elija la salvaguardia como. Elija el texto bajo salvaguardia como extracción-abajo del tipo.

  4. Recoja los archivos del CÉSPED de ambos CallRouters.

  5. Recoja el CallTypeHalfHour, el TCD, y RCD los expedientes que palmo a partir de 2.5 horas antes de que fue el Routers hacia fuera-de-sincronice y 1 hora después de que se recupera.

    Éstos necesitan estar en el formato delimitado lengueta y necesitan ser vaciadas de ambos lados de los madereros. Estos expedientes DEBEN venir de ambos lados de los madereros.

    Esto es una consulta SQL del ejemplo:

    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. Recoja los archivos del vrutrace en cada Peripheral Interface Manager del Voice Response Unit (VRUPIM) a ambos lados de los gatewayes periféricos (PGS) esa cubierta el timeframe por lo menos 1 hora antes de que el router está hacia fuera-de-sincroniza y 30 minutos después de que se recupera.

    Refiérase a cómo utilizar la utilidad vrutrace para más información.

  7. Funcione con la utilidad del dumpcfg contra ambas bases de datos de registrador a partir del tiempo antes de que fueran hacia fuera-de-sincronicen al tiempo después.

    Refiera al uso la herramienta de administración del dumpcfg de seguir los cambios de configuración del ICM para más información.

  8. Utilice el ICMDBA para exportar la configuración de ambos madereros.

  9. Exporte la bifurcación entera del registro ICM de ambos lados de los CallRouters.

    HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems,Inc.

Solución Aternativa

Éstas son las dos opciones alternativas:

  • Complete un ciclo los CallRouters apagando ambos Procesos de CallRouter y después comenzándolos de reserva otra vez. Ésta es la manera más limpia de trabajar alrededor de esta condición.

  • Reinicio un lado de los CallRouters.

Ambas opciones hacen los CallRouters resincronizar y rodarse sincronice. Esto significa que ambos lados del CallRouter rutearán otra vez llaman la misma manera.

La opción 1 es el método preferido y los resultados en una mayor probabilidad de ambos CallRouters que rutean todas las llamadas correctamente cuando está recomenzada. Sin embargo, si usted no puede tomar la ocasión del tener ambos CallRouters abajo al mismo tiempo, la opción 2 se puede utilizar en lugar de otro.

La opción 2 puede dar lugar al mismo nivel de éxito que la opción 2 de la opción 1. hace los CallRouters resincronizar y ruta de los ambos lados llaman la misma manera. Sin embargo, si el CallRouter que no fue recomenzada tenía un estado incorrecto después de la resincronización, el CallRouter estado en los ambos lados es incorrecto. Este caso puede llevar ambos CallRouters, aunque esté sincronizado, para rutear algunas llamadas incorrectamente. La ocasión que ocurra ésta pudo ser levemente más alta que si las medidas en la opción 1 se toman.

Nota: El cisco altamente recomienda que una ventana de mantenimiento esté programada para realizar estas acciones de recuperación en cuanto a aminora el impacto al ruteo de llamadas de la producción.


Información Relacionada


Document ID: 81904