Pour les partenaires
Vous êtes déjà partenaire?
ConnexionAvez-vous un compte?
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.
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 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).
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
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
01-Jul-2014 |
Première publication |