Propósito
Este artículo proporcionará un ejemplo del uso de opEvents para activar opConfig para hacer un cambio operacional.
Caso práctico
Si una interfaz empieza a registrar errores de entrada, queremos desplazar automáticamente el tráfico fuera del circuito para mantener la calidad de la transmisión.
Páginas relacionadas
Antes de intentar esta configuración, el administrador debe estar familiarizado con los siguientes artículos de la wiki.
- Umbrales básicos y avanzados en NMIS8
- Acciones y escalada de eventos
- Automatización de los cambios de configuración con opConfig
Resumen de la secuencia
- NMIS sondea un router con una consulta SNMP.
- El router devuelve un valor de contador de "error de entrada de la interfaz" que ha aumentado; activando así un umbral predefinido.
- NMIS genera una alerta de "error de entrada" que es procesada por opEvents.
- opEvents tiene una regla de acción predefinida que coincide con los errores de nodo, interfaz y entrada. Esta acción disparará un opConfig 'Conjunto de configuración'.
- El conjunto de configuración opConfig asociado aumentará el coste OSPF en las interfaces asociadas, haciendo que el router seleccione otra ruta si está disponible.
Configuración
NMIS
Por defecto NMIS tiene la configuración necesaria para alertar sobre los errores de entrada. Esto se hace con el sistema de umbrales de NMIS. Los umbrales para los diferentes niveles de alerta pueden ajustarse en la sección correspondiente de /usr/local/nmis8/models/Common-threshold.nmis. Los niveles siguientes representan un porcentaje de paquetes de error de entrada en comparación con los paquetes buenos.
/usr/local/nmis8/models/Common-threshold.nmis
'pkt_errors_in' => {
'item' => 'ifInErrorsProc',
'event' => 'Proactive Interface Error Input Packets',
'title' => "Paquetes de error de entrada",
Unidad" => "paquetes",
'select' => {
'default' => {
'valor' => {
'fatal' => '0.5',
'critical' => '0.25',
'major' => '0.1',
'minor' => '0.05',
'warning' => '0.02',
}
}
}
},
opEvents
Por defecto, opEvents procesa el registro de eventos NMIS. Todos los eventos son evaluados por /usr/local/omk/conf/EventActions.nmis. Si un evento coincide con una regla, se tomarán las acciones apropiadas. EventActions.nmis es también donde definimos los scripts que los opEvents pueden disparar. El primer paso es definir los scripts que cambiarán el tráfico de un enlace que está ejecutando errores de entrada. Como queremos desplazar todo el tráfico de este enlace, necesitaremos ejecutar scripts para ambos extremos del circuito. Fíjate en la referencia a un conjunto de configuraciones; éstas se definirán en la sección opConfig.
Los cambios en /usr/local/omk/conf/EventActions.nmis requieren que se reinicie el servicio omkd.
/usr/local/omk/conf/EventActions.nmis
'script' => {
'bnelab_p2_fa0_0_route_not' => {
arguments => 'act=push_configset name=bnelab-p2_fa0-0_route_not at=now+1minute nodes=bnelab-p2',
exec => '/usr/local/omk/bin/opconfig-cli.exe',
output => 'save'
},
'bnelab_rr1_e1_2_route_not' => {
arguments => 'act=push_configset name=bnelab-rr1_e1-2_route_not at=now+1minute nodes=bnelab-rr1',
exec => '/usr/local/omk/bin/opconfig-cli.exe',
output => 'save'
},
},
Con los scripts definidos vamos a añadir la regla de coincidencia a la sección de políticas.
/usr/local/omk/conf/EventActions.nmis
'policy' => {
'10' => {
IF => 'event.any',
THEN => {
'10' => {
IF => 'event.node eq "bnelab-rr1" and event.element eq "Ethernet1/2" and event.event eq "Proactive Interface Error Input Packets"',
THEN => 'script.bnelab_rr1_e1_2_route_not() y script.bnelab_p2_fa0_0_route_not()',
BREAK => 'false'
},
opConfig
El siguiente paso es definir los conjuntos de configuración. Los conjuntos de configuración son conversaciones de opConfig para los comandos de configuración que te gustaría que se ejecutaran en el router. Debido a que este paso es complicado, pero muy repetible, he proporcionado este script: writeConfigSet.sh. Ejecuta el script y te pedirá los comandos que quieres que se ejecuten en el router e instalará el config set en opConfig. Para verificar los conjuntos de configuración utilice la GUI de opConfig, desde la barra de menú superior seleccione vistas, luego Visión General del Conjunto de Configuración.
Este es el aspecto de nuestro conjunto de configuración de ejemplo.
{
"name": "bnelab-rr1_e1-2_route_not",
"comandos": [
"int e1/2",
"ip ospf cost 9999",
"salida"
],
"post-comandos": ["escribir mem"]
}
Pruebas y verificación
Generar errores de entrada
Hay varios tipos de errores de entrada, pero el más fácil de crear en un entorno de laboratorio son los gigantes. Esto se hace teniendo MTUs desiguales en ambos lados del mismo circuito; entonces se envían paquetes que son demasiado grandes desde el lado con la MTU más grande.
bnelab-p2#ping 10.248.2.6 size 1530 repeat 1000 timeout 0
En benlab-rr1 veremos que los contadores de error se incrementan.
bnelab-rr1#show int e1/2 | inc error|giants
0 runts, 4073 giants, 0 throttles
4073 errores de entrada, 0 CRC, 0 trama, 0 rebasamiento, 0 ignorado
0 errores de salida, 0 colisiones, 1 reinicio de interfaz
Observar el evento de error de entrada en NMIS
Tras el siguiente ciclo de recogida de NMIS para bnelab-rr1 deberíamos ver un evento similar al siguiente:
18-May-2018 13:30:20 bnelab-rr1 Proactive Interface Error Input Packets Fatal Ethernet1/2 p2 Bandwidth=10 Mbps: Value=12.37689 Threshold=0.5
Observar el evento de error de entrada en opEvents
A continuación, busque el evento de error de entrada en opEvents.
Fíjese en las secciones de acciones realizadas y scripts. En base a esto sabemos que el script tuvo éxito y a qué hora se ha programado el cambio de configuración.
Confirmar el empuje de la configuración con éxito en opConfig
Desde la interfaz gráfica de opConfig, navegue hasta la barra de menú superior y seleccione Vistas, Historial de cambios de configuración. Busque y seleccione el push de configuración que se relaciona con nuestro evento de prueba.
