Le redémarrage de Logger génère d'anciennes interruptions SNMP

Introduction

Ce document décrit les messages déroutés SNMP (Simple Network Management Protocol) dans un environnement d'entreprise Cisco Unified Intelligent Contact Management (ICM) et fournit deux méthodes possibles pour empêcher que ces messages d'information ne soient signalés.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Cisco ICM Enterprise

• Compréhension du protocole SNMP

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

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

Informations générales

Le journal d'ICM collecte les événements et les messages de tous les composants du système. L'enregistreur transmet ces informations au processus CSFS (Customer Support Forwarding Service) qui reçoit les événements, les filtre et les garde en mémoire sur l'enregistreur comme le montre la Figure 1. Le flux SNMP est une fonctionnalité ICM facultative qui vous permet de recevoir un flux d'événements via une interface compatible SNMP (TCP/IP). Lorsque vous utilisez le flux SNMP, vous pouvez le configurer pour envoyer les déroutements SNMP au client de gestion souhaité.

Problème

Par conception, après avoir redémarré un enregistreur dans un environnement duplexé, ou si un enregistreur rebondit, des interruptions SNMP obsolètes peuvent être générées et affichées dans les stations de gestion SNMP configurées. Lorsque le processus CSFS est démarré dans le cadre de l'enregistreur, il reçoit un événement (alarme) à signaler au client distant (via SNMP, Syslog ou le service de surveillance à distance [RMS]) et enregistre une copie de l'événement en mémoire, appelée enregistrement de base. Dans un environnement duplexé et tolérant aux pannes, lorsque le processus CSFS d'un côté tombe en panne puis redémarre, il reçoit tous les enregistrements de base en attente de l'autre côté et les transmet au client de gestion.

Solutions

Cette section décrit les méthodes que vous pouvez utiliser pour empêcher le signalement d'informations SNMP obsolètes. La solution 1 vous montre comment purger les informations SNMP obsolètes du journal et la solution 2 vous montre comment supprimer ou filtrer les informations SNMP obsolètes du client de gestion.

Solution 1

Purger les enregistrements de base. Pour ce faire, arrêtez les Loggers des deux côtés simultanément, puis redémarrez-les. Ce processus purge tous les déroutements SNMP obsolètes du processus CSFS.

Remarque : Cette procédure doit être effectuée pendant une période de maintenance ou pendant les périodes d'impact de route faible.

1. Arrêter l'enregistreur B.

2. Arrêter l'enregistreur A.

3. Démarrez l'enregistreur A.

4. Démarrez l'enregistreur B.

Solution 2

Une autre solution consiste à faire en sorte que les alarmes du client de gestion soient plus anciennes que certaines durées, par exemple une semaine. Chaque déroutement que le service SNMP envoie à l'application tierce du client (telle que HP OpenView) contient un horodatage indiquant le moment où l'événement réel se produit. Les clients peuvent ensuite configurer leur application tierce pour ignorer les alarmes avec un horodatage plus ancien qu'un nombre donné de jours ou de semaines. Il est important de noter que le centre d'assistance technique du centre de contact Cisco (TAC) n'aide pas à la configuration de l'application tierce particulière que le client choisit d'utiliser pour gérer ces événements/pièges.

Informations connexes

• Documentation d'assistance Cisco Unified Intelligent Contact Management Enterprise
• Support et documentation techniques - Cisco Systems