Collaboration : Cisco ICM Router Software

Condition de non-synchronisation au niveau du CallRouter ICM/IPCC

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document trace les grandes lignes des étapes et des niveaux de suivi recommandés requis pour dépanner un événement de -de-sync dans des CallRouters duplexés d'un Intelligent Contact Management de Cisco Unified Contact Center (missile aux performances améliorées).

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

  • Missile aux performances améliorées de Cisco

  • Compréhension de haut niveau de la fonctionnalité de contrôleur central d'ICM

  • Regedit

  • Microsoft SQL

Composants utilisés

Les informations dans ce document sont basées sur le Cisco ICM version 5.x et ultérieures.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Description

Dans des exemples rares, les CallRouters missile aux performances améliorées peuvent devenir -de-sync avec son partenaire duplexé. Le déclencheur principal pour cet événement est une somme de contrôle défectueuse entre le CallRouter et son pair. Quand les CallRouters deviennent -de-sync, on génère un fichier standard de vidage mémoire d'objet (GAZON) qui est un vidage mémoire de mémoire du routeur au moment où la panne.

Un événement de -de-sync peut mener aux appels misrouted par le CallRouter.

L'un de ces méthodes peuvent être utilisées pour vérifier des états de -de-sync :

  • Les CallRouters exécutent automatiquement un contrôle de sync entre les deux dégrossit toutes les 15 secondes. S'il détecte un état de -de-sync, le CallRouter crée un fichier de GAZON dans ce répertoire :

    <drive>:\icm\<instance>ra 
    and 
    <drive>:\icm\<instance>rb
  • Ce message est généré dans le journal d'application dans le visualisateur d'événements de Windows sur le CallRouter. Voici les détails de message :

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

    Un déroutement SNMP est également généré.

  • Du CallRouter (rtr) se connecte (exemple seulement) :

    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

Se connecter supplémentaire

Remarque: Les fichiers standard de GAZON qui se produisent en conséquence quand les CallRouters disparaissent le -de-sync ont leurs limites et là sont des périodes où la construction exige un niveau plus granulaire de l'élimination des imperfections d'isoler mieux la cause. Si vous exécutez le missile aux performances améliorées 5.0 (0) SR8 ou plus tard, vous avez deux clés de registre qui peuvent être activées augmenter l'élimination des imperfections des fichiers de GAZON.

Activez les ces registre met au point sur les deux CallRouters :

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

Il y a deux entrées, MessageTrackingEnabled et MessageTrackingLimit.

Placez ces valeurs :

  • MessageTrackingEnabled = 1

  • MessageTrackingLimit = 10000 (valeur décimale)

Remarque: Ce sont des valeurs dynamiques et les prennent effet immédiatement. Ceci n'entraîne aucun comportement anormal avec le missile aux performances améliorées. Quand vous placez ces bits de suivi, il active un fichier plus détaillé de GAZON mettent au point si un autre état de -de-sync se produit. Il n'y a aucun besoin de désactiver ces bits de deux suivis, ils devrait rester allumé. Cependant, ces bits de suivi reviennent à la valeur par défaut (c.-à-d. hors fonction) si l'installation est exécutée sur les CallRouters. Si ceci se produit, ils doivent être manuellement réactivés.

Collecte de données

Ces données et informations sont nécessaires quand vous demandez le support de Cisco TAC pour la panne :

  1. Notez l'heure exacte de la panne.

  2. Collectez les logs de CallRouter des deux côtés (rtr, MDS, nanomètre, ccag) pour le délai de la panne.

  3. Collectez le visualisateur d'événements (système et application) que les logs exportés dans le format texte par une droit-souris cliquent sur en fonction le répertoire respectif de log et choisissez la sauvegarde As. Choisissez le texte sous la sauvegarde en tant que type déroulant.

  4. Collectez les fichiers de GAZON des deux CallRouters.

  5. Collectez les enregistrements de CallTypeHalfHour, TCD, et RCD dont le répartissez pendant 2.5 heures avant que les Routeurs sont allés le -de-sync et pendant 1 heure après qu'il récupère.

    Ceux-ci doivent être dans le format délimité par onglet et ils doivent être vidés des deux côtés des enregistreurs. Ces enregistrements DOIVENT être livré des deux côtés des enregistreurs.

    C'est une requête SQL d'exemple :

    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. Collectez les fichiers de vrutrace sur chaque gestionnaire d'interface périphérique d'unité de réponse vocale (VRUPIM) des deux côtés des passerelles d'accès aux périphériques (PGs) cette couverture le délai au moins pendant 1 heure avant que le routeur est -de-sync et 30 minutes après qu'il récupère.

    Référez-vous à comment utiliser le pour en savoir plus d'utilitaire de vrutrace.

  7. Exécutez l'utilitaire de dumpcfg contre les deux bases de données de l'enregistreur du temps avant qu'ils soient allés le -de-sync au temps ensuite.

    Référez-vous à l'utilisation l'outil d'administration de dumpcfg de dépister le pour en savoir plus de modifications de configuration missile aux performances améliorées.

  8. Employez ICMDBA afin d'exporter la configuration des deux enregistreurs.

  9. Exportez le branchement entier de registre missile aux performances améliorées des deux côtés des CallRouters.

    HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems,Inc.

Contournement

Ce sont les deux options de contournement :

  • Faites un cycle les deux CallRouters en arrêtant les deux processus de CallRouter et en les commençant alors sauvegardez de nouveau. C'est la manière la plus propre de fonctionner autour de cette condition.

  • Côté de la reprise une des CallRouters.

Chacun des deux options font resynchroniser et fonctionner les CallRouters dans le sync. Ceci signifie que les deux côtés de CallRouter conduiront de nouveau appelle la même manière.

L'Option 1 est la méthode préférée et les résultats dans une probabilité plus élevée des deux CallRouters conduisant tous les appels correctement une fois redémarré. Cependant, si vous ne pouvez pas prendre les risques de avoir les deux CallRouters vers le bas en même temps, l'option 2 peut être utilisée à la place.

L'Option 2 peut avoir comme conséquence le même niveau du succès que l'Option 2 de l'option 1. fait resynchroniser les CallRouters et les deux côtés l'artère appelle la même manière. Cependant, si le CallRouter qui n'a pas été redémarré avait un état incorrect après la resynchronisation, le CallRouter énonce dans les deux côtés sont incorrect. Ce cas peut mener les deux CallRouters, bien que synchronisé, pour conduire quelques appels inexactement. L'occasion que ceci se produira pourrait être légèrement supérieur à si les mesures dans l'option 1 sont prises.

Remarque: Cisco recommande fortement qu'une fenêtre de maintenance soit programmée afin d'exécuter ces actions de reprise quant à diminuent l'incidence au routage d'appels de production.


Informations connexes


Document ID: 81904