Inondation de déroutement de CiscoConfigManEvent pour Prime Network

Introduction

Ce document décrit la cause, les répercussions et la solution d'un problème où vous recevez un déluge d'interruptions de notification d'événement de gestion de configuration Cisco (ciscoConfigManEvent) dans le réseau Cisco Prime.

Problème

Les périphériques réseau peuvent être configurés de telle manière que lorsqu'une commande show run ou conf t est entrée sur un périphérique, le périphérique envoie un déroutement ciscoConfigManEvent. Si le périphérique est surveillé par Cisco Prime Network, vous pouvez afficher ces déroutements dans l'onglet Trap de Vision d'événement en tant qu'événements de notification d'événement de gestion de configuration Cisco.

Un déluge de ces déroutements se produit parce que Cisco Prime Network exécute une commande show run interface <interface id> sur les périphériques pour chaque interface définie dans le périphérique. Ceci se produit chaque cycle d'interrogation, qui est toutes les 15 minutes par défaut. La majorité des clients connaissent aujourd'hui un flot de ce type d'événements. Les grands fournisseurs de services peuvent avoir un grand nombre d'interfaces sur chaque périphérique, et il est courant de voir plusieurs milliers de ces événements dans le réseau Cisco Prime chaque minute.

Cela entraîne de nombreux effets secondaires, notamment :

• La base de données (DB) devient saturée et l'espace temporaire est épuisé.
• Les clients connaissent des performances de l'interface utilisateur graphique lentes en raison du grand nombre d'événements dans la base de données.
• Il y a un grand nombre d'événements orphelins dans la base de données (événements qui ne sont pas associés à un ticket et ne sont pas archivés).
• Le déroutement et le traitement VNE (Virtual Network Element) sont plus lents en raison du grand nombre d'événements.

Solution

La meilleure solution pour ce problème est de modifier la configuration des périphériques réseau de sorte qu'ils n'envoient pas ces types de déroutements au serveur Prime Network. Cependant, cela n'est pas pratique dans certains grands systèmes de fournisseurs de services. Cette section fournit une solution de contournement pour ce problème. L'objectif de cette solution de contournement est de filtrer les déroutements dès qu'ils atteignent le collecteur d'événements (AVM 100).

Note: Pour les versions 4.0 et ultérieures de Cisco Prime Network, reportez-vous au Guide de l'administrateur réseau Cisco Prime, 4.0 afin d'obtenir une solution à ce problème. La solution de contournement décrite dans ce document concerne toutes les versions ANA (Active Network Abstraction) ainsi que toutes les versions 3.11 et antérieures de Cisco Prime Network.

Attention : Si vous activez le filtre de déroutement ciscoConfigManEvent, les déroutements ciscoConfigManEvent ne sont pas enregistrés dans l'archive des événements ; par conséquent, ils ne sont pas disponibles pour les rapports.

Normalement, les pièges sont filtrés au niveau VNE après avoir été écrits dans la base de données de persistance des événements (EP) (généralement appelée archive des événements). Pour empêcher ce traitement, un filtre global facultatif est requis :

Entrez ces commandes en tant qu'utilisateur ANA ou Prime Network du répertoire ~/Main afin de filtrer ce type de déroutement dès qu'il entre dans le système :

./runRegTool.sh -gs 127.0.0.1 set 0.0.0.0 site/trap/agents/trap/processors
 /snmp-processors/snmp-processor4/enable true

./runRegTool.sh -gs 127.0.0.1 set 0.0.0.0 site/trap/agents/trap/processors
 /snmp-processors/snmp-processor4/matcher/classcom.sheer.metrocentral.
 framework.instrumentation.trap.matcher.RawEventSnmpMatcher

./runRegTool.sh -gs 127.0.0.1 add 0.0.0.0 site/trap/agents/trap/processors
 /snmp-processors/snmp-processor4/matcher/matcher-conf

./runRegTool.sh -gs 127.0.0.1 add 0.0.0.0 site/trap/agents/trap/processors
 /snmp-processors/snmp-processor4/matcher/matcher-conf/rule-1

./runRegTool.sh -gs 127.0.0.1 add 0.0.0.0 site/trap/agents/trap/processors
 /snmp-processors/snmp-processor4/matcher/matcher-conf/rule-1/varbinds

./runRegTool.sh -gs 127.0.0.1 set 0.0.0.0 site/trap/agents/trap/processors
 /snmp-processors/snmp-processor4/matcher/matcher-conf/rule-1/varbinds
 /varbind-1 ".1.3.6.1.6.3.1.1.4.1={o}.1.3.6.1.4.1.9.9.43.2.0.1"

Entrez ces commandes afin de désactiver les commandes précédentes :

./runRegTool.sh -gs 127.0.0.1 set 0.0.0.0 site/trap/agents/trap/processors
 /snmp-processors/snmp-processor4/enable false

./runRegTool.sh -gs 127.0.0.1 set 0.0.0.0 site/trap/agents/trap/processors
 /snmp-processors/snmp-processor4/matcher/class com.sheer.metrocentral.
 framework.instrumentation.trap.matcher.ExcludeAllMatcher

./runRegTool.sh -gs 127.0.0.1 remove 0.0.0.0 site/trap/agents/trap/processors
 /snmp-processors/snmp-processor4/matcher/matcher-conf

Note: Certains clients ont configuré les périphériques de sorte que chaque déroutement soit envoyé encapsulé dans un syslog. Si c'est le cas, vous devez ajouter une règle sur le processeur syslog pour ceux-ci également.

Historique de révision