Colaboração : Cisco ICM Router Software

Roteador de Chamada ICM/IPCC fora da condição da sincronização

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento esboça as etapas recomendadas e os níveis de rastreamento necessários pesquisar defeitos um evento fora de sincronia em Roteador de Chamada duplexed unificados Cisco do Intelligent Contact Management de um centro de contato (ICM).

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

  • ICM Cisco

  • Compreensão de nível elevado da funcionalidade do Controle Central de ICM

  • Regedit

  • Microsoft SQL

Componentes Utilizados

A informação neste documento é baseada na versão do ICM 5.x de Cisco e mais tarde.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Descrição

Nas instâncias raras, os ICM CallRouter podem tornar-se fora de sincronia com seu parceiro duplex. O disparador principal para este evento é uma falha de checksum entre o Roteador de Chamada e seu par. Quando os Roteador de Chamada se tornam fora de sincronia, um arquivo padrão da descarga do objeto (GRAMA) está gerado que seja um dump de memória do roteador no ponto da falha.

Um evento fora de sincronia pode conduzir aos atendimentos que são roteados incorretamente pelo Roteador de Chamada.

Qualquens um métodos podem ser usados para verificar para ver se há circunstâncias fora de sincronia:

  • Os Roteador de Chamada executam automaticamente uma verificação da sincronização entre os dois tomam partido cada 15 segundos. Se detecta uma condição fora de sincronia, o Roteador de Chamada cria um arquivo da GRAMA dentro deste diretório:

    <drive>:\icm\<instance>ra 
    and 
    <drive>:\icm\<instance>rb
  • Esta mensagem é gerada no log do aplicativo dentro do visualizador de eventos de Windows no Roteador de Chamada. Estão aqui os detalhes da mensagem:

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

    Uma armadilha de SNMP é gerada igualmente.

  • Do Roteador de Chamada (rtr) registra (exemplo somente):

    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: Os arquivos padrão da GRAMA que gerenciem em consequência quando os Roteador de Chamada vão fora de sincronia têm suas limitações e lá são as épocas em que projetar exige um nível mais granulado da eliminação de erros isolar melhor a causa. Se você executa ICM 5.0 (0) SR8 ou mais tarde, você tem duas chaves de registro que podem ser permitidas de aumentar a eliminação de erros dos arquivos da GRAMA.

Permita estes registro debuga em ambos os Roteador de Chamada:

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

Há dois entradas, MessageTrackingEnabled e MessageTrackingLimit.

Ajuste estes valores:

  • MessageTrackingEnabled = 1

  • MessageTrackingLimit = 10000 (valor decimal)

Nota: Estes são valores dinâmicos e tomam o efeito imediatamente. Isto não causa nenhum comportamento anormal com ICM. Quando você ajusta estes bit do traço, permite um arquivo mais detalhado da GRAMA debuga se uma outra condição fora de sincronia ocorrer. Não há nenhuma necessidade de desabilitar estes bit de dois traços, eles deve permanecer sobre. Contudo, estes bit do traço revertem de volta ao valor padrão (isto é fora) se a instalação é executada nos Roteador de Chamada. Se isto ocorre, precisam re-de ser permitidos manualmente.

Levantamento de dados

Estes dados e informação são precisados quando você pede o apoio do tac Cisco para a indisponibilidade:

  1. Note o tempo exato da falha.

  2. Recolha os logs do Roteador de Chamada dos ambos os lados (rtr, DM, nanômetro, ccag) para o timeframe da indisponibilidade.

  3. Recolha os logs do visualizador de eventos (sistema e aplicativo) exportados no formato de texto por um clique de mouse direito no dobrador respectivo do log e escolha a salvaguarda como. Escolha o texto sob a salvaguarda como o tipo suspenso.

  4. Recolha os arquivos da GRAMA de ambos os Roteador de Chamada.

  5. Recolha os registros de CallTypeHalfHour, TCD, e RCD que período de 2.5 horas antes que o Roteadores foi fora de sincronia e 1 hora depois que recupera.

    Estes precisam de estar no formato limitado aba e precisam de ser despejadas dos ambos os lados dos registadores. Estes registros DEVEM vir dos ambos os lados dos registadores.

    Esta é uma pergunta do exemplo 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. Recolha arquivos do vrutrace em cada Peripheral Interface Manager do Voice Response Unit (VRUPIM) em ambos os lados dos gateways periféricos (PG) essa tampa o timeframe pelo menos 1 hora antes que o roteador esteja fora de sincronia e 30 minutos depois que recupera.

    Refira como usar o utilitário vrutrace para mais informação.

  7. Execute a utilidade do dumpcfg contra ambas as bases de dados de logger do tempo antes que foram fora de sincronia ao tempo em seguida.

    Consulte para usar a ferramenta de administração do dumpcfg para seguir mudanças de configuração de ICM para mais informação.

  8. Use o ICMDBA a fim exportar a configuração de ambos os registadores.

  9. Exporte o ramo inteiro do registro ICM dos ambos os lados dos Roteador de Chamada.

    HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems,Inc.

Solução

Estas são as duas opções de solução:

  • Dê um ciclo ambos os Roteador de Chamada fechando ambos os processos de roteador de chamada e então começando os alternativos outra vez. Esta é a maneira a mais limpa de trabalhar em torno desta circunstância.

  • Lado do reinício um dos Roteador de Chamada.

Both of these opções causam os Roteador de Chamada ao ressincronizar e são-nos executado na sincronização. Isto significa que ambos os lados do Roteador de Chamada distribuirão outra vez chamam a mesma maneira.

A opção 1 é o método preferido e os resultados em uma semelhança mais elevada de ambos os Roteador de Chamada que distribuem todos os atendimentos corretamente quando reiniciada. Contudo, se você não pode tomar a possibilidade de ter ambos os Roteador de Chamada para baixo ao mesmo tempo, a opção 2 pode ser usada pelo contrário.

A opção 2 pode conduzir ao mesmo nível do sucesso como a opção 2 da opção 1. causa aos Roteador de Chamada ao ressincronizar e rota dos ambos os lados chamam a mesma maneira. Contudo, se o Roteador de Chamada que não foi reiniciado teve um estado incorreto após o resynchronization, o Roteador de Chamada indica nos ambos os lados está incorreto. Este caso pode conduzir ambos os Roteador de Chamada, embora sincronizado, para distribuir incorretamente alguns atendimentos. A possibilidade que esta ocorrerá pôde ser levemente mais alta do que se as etapas na opção 1 são tomadas.

Nota: Recomenda Cisco altamente que uma janela de manutenção esteja programada a fim executar estas ações de recuperação a respeito de diminui o impacto ao roteamento de chamada da produção.


Informações Relacionadas


Document ID: 81904