Administración de redes y automatización : Cisco Prime Network

Inundación ciscoConfigManEvent del desvío de la red primera

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe la causa, las repercusiones, y la solución a un problema donde usted recibe una inundación de los desvíos (ciscoConfigManEvent) de la notificación de evento de la Administración de configuración de Cisco en la red de la prima de Cisco.

Contribuido por Thomas Maneri, ingeniero de Cisco TAC.

Problema

Los dispositivos de red pudieron ser configurados de una manera tal que cuando ingresan un funcionamiento o a un comando conf t de la demostración en un dispositivo, el dispositivo envíe un desvío ciscoConfigManEvent. Si el dispositivo es monitoreado por la red de la prima de Cisco, usted puede ver estos desvíos en la lengueta del desvío del evento Vision como eventos de la notificación de evento de la Administración de configuración de Cisco.

Una inundación de estos desvíos ocurre porque la red primera de Cisco ejecuta un comando del id> del <interface de la interfaz del funcionamiento de la demostración a los dispositivos para cada interfaz definida dentro del dispositivo. Esto ocurre cada ciclo de sondeo, que es cada 15 minutos por abandono. La mayoría de los clientes ahora experimenta una inundación de estos tipos de eventos. Los proveedores de servicio grandes pueden tener un número alto de interfaces en cada dispositivo, y es común considerar varios millares de estos eventos dentro de la red de la prima de Cisco cada minuto.

Esto causa muchos efectos secundarios, por ejemplo:

  • La base de datos (DB) se convierte por completo, y el espacio temporario se ejecuta hacia fuera.
  • Los clientes experimentan el rendimiento debido lento GUI al número grande de eventos en el DB.
  • Hay un número alto de eventos huérfanos en el DB (los eventos que no se asocian a un boleto y no están archivados).
  • Hay un proceso más lento del elemento del desvío y de red virtual (VNE) debido el número grande de eventos.

Solución

La mejor solución para este problema es cambiar la configuración de los dispositivos de red de modo que no envíen estos tipos de desvíos al servidor de red primero. Sin embargo, esto no es práctico en algunos sistemas grandes del proveedor de servicio. Esta sección proporciona una solución alternativa para este problema. La meta de esta solución alternativa es filtrar los desvíos tan pronto como alcancen el colector del evento (AVM 100).

Nota: Para las versiones de la red 4.0 de la prima de Cisco y posterior, refiera a la guía de administrador de la red de la prima de Cisco, 4.0 para obtener una solución a este problema. La solución alternativa que se describe en este documento está para todas las versiones así como todas las versiones de la red 3.11 de la abstracción de la red activa (ANECDOTARIO) de la prima de Cisco y anterior.

Precaución: Si usted habilita el filtro ciscoConfigManEvent del desvío, después los desvíos ciscoConfigManEvent no se guardan al archivo del evento; por lo tanto, no están disponibles para los informes.

Normalmente, los desvíos se filtran en el nivel VNE después de que se escriban en la persistencia del evento (EP) DB (conocida comúnmente como el archivo del evento). Para prevenir este proceso, se requiere un filtro global opcional:

Ingrese estos comandos como la ANECDOTARIO o al usuario de la red primero del directorio ~/Main para filtrar este tipo de desvío tan pronto como ingrese en el sistema:

./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"

Ingrese estos comandos para inhabilitar los comandos anteriores:

./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

Nota: Algunos clientes hacen los dispositivos configurar para enviar cada desvío encapsulado en un Syslog. Si éste es el caso, usted debe agregar una regla en el procesador del Syslog para ésos también.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 117695