Tutorial: Monitoreo de Red Utilizando IP SLA y Nagios
El siguiente es un Tutorial para realizar monitoreo de redes remotas (a las que no tenemos acceso por ruteo) con Nagios, utilizando funcionalidades IP SLA.
Además, vamos a utilizar para hacerlo, algunas funciones no tan conocidas de Nagios como: Variables Custom, notes, templates con check_commands nuevos, parents y una forma de registrar en Nagios Services como Hosts.
El siguiente esquema es en el que trabajaremos como ejemplo:
Nagios únicamente tiene visibilidad a nivel de red con R1, R2 y R3 y no puede alcanzar a los Ra, Rb y Rc. Sin embargo, R2, si puede alcanzarlos.
Utilizaremos las funcionalidades de IP SLA, combinadas con algunos trucos en la configuración de Nagios, para poder ver los 6 routers del esquema presentado, como hosts en Nagios.
Mediante IP SLA, podemos configurar los routers para que midan diferentes variables y luego consultar ese resultado en el mismo por SNMP o en el mismo Router.
- Configuración de IP SLA en R2
El primer paso será configurar a R2 para que chequee mediante IP SLA e ICMP los routers Ra, Rb, y Rc.
ip sla 1
icmp-echo 10.0.0.1 source-interface GigabitEthernet0/1
tag Ra
frequency 30
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 10.0.1.1 source-interface GigabitEthernet0/1
tag Rb
frequency 30
ip sla schedule 2 life forever start-time now
ip sla 3
icmp-echo 10.0.2.1 source-interface GigabitEthernet0/1
tag Rc
frequency 30
ip sla schedule 2 life forever start-time now
Para verificar podemos usar el comando show ip sla summary:
ID Type Destination Stats Return Last
(ms) Code Run
-----------------------------------------------------------------------
*1 icmp-echo 10.0.0.1 RTT=36 OK 42 seconds ago
*2 icmp-echo 10.0.1.1 RTT=36 OK 42 seconds ago
*3 icmp-echo 10.0.2.1 RTT=40 OK 42 seconds ago
- Configuración de Routers R1, R2 y R3
En Segundo lugar se configurará en Nagios los Hosts R1, R2 y R3, esto lo hacemos con el template que más nos parezca según nuestra configuración (podría ser el generic-host, o alguno específico para routers o network elements que hayan creado), a modo de ejemplo vamos a definir acá un template nuevo para routers basado en generic-host:
define host{
name router-template
use generic-host
check_period 24x7
check_interval 5
retry_interval 1
max_check_attempts 10
check_command check-host-alive
notification_period workhours
notification_interval 120
notification_options d,u,r
contact_groups admins
register 0
hostgroups routers
icon_image router40.png
}
Creamos el hostgroup routers:
define hostgroup{
hostgroup_name routers
alias Routers
}
Ahora crearemos los 3 routers como hosts:
define host{
use router-template
host_name R1
alias R1
address 192.168.0.1
}
define host{
use router-template
host_name R2
alias R2
address 192.168.1.1
}
define host{
use router-template
host_name R3
alias R3
address 192.168.2.1
}
Hasta acá obtendremos en el Nagios el monitoreo de R1, R2 y R3:
- Chequeo de IP SLA del Router R2 Mediante SNMP
Para chequear el estado los IP SLA de un router, se debe hacer la consulta mediante SNMP al equipo, preguntando por cada uno en particular identificados por el id con el que los definimos (en nuestro caso 1, 2 y 3).
Para routers Cisco, el OID que vamos a utilizar es 1.3.6.1.4.1.9.9.42.1.2.10.1.2
Haciendo una consulta al mismo por SNMP, deberíamos obtener una entrada por cada IP SLA configurado con su correspondinete ID:
snmpwalk -v 2c -c P@ssw0rd 192.168.1.1 .1.3.6.1.4.1.9.9.42.1.2.10.1.2
SNMPv2-SMI::enterprises.9.9.42.1.2.10.1.2.1 = INTEGER: 1
SNMPv2-SMI::enterprises.9.9.42.1.2.10.1.2.2 = INTEGER: 1
SNMPv2-SMI::enterprises.9.9.42.1.2.10.1.2.3 = INTEGER: 1
El último dígito que se agrega al final del OID, es el ID del IP SLA (que habíamos definido como 1, 2 y 3, pero podrían ser cualquier otro números).
Por lo tanto, para consultar un IP SLA específico, vamos a hacerlo armando el OID así:
.1.3.6.1.4.1.9.9.42.1.2.10.1.2.[ID IP SLA]
El resultado de la consulta es un valor INTEGER que significa, por ejemplo:
| 0 | Unknown |
| 1 | OK |
| 4 | Timeout |
Nuestros Routers entonces estarán UP, cuando recibamos un 1 como valor.
- Definiendo Ra, Rb y Rc como services de R2 (Opción 1):
La forma natural y más sencilla de cargar los routers Ra, Rb y Rc es que sean services de R2. Sin embargo, tendremos ciertas limitaciones con esta configuración.
A continuación está la configuración si igualmente quisiéramos hacerlo de esta forma:
-
Definimos el comando poniendo como variable el último dígito del OID (ARG1) para poder reutilizarlo en los services. Además le especificamos que le especificamos que esperamos como resultado "1" de un INTEGER.
define command{ command_name check_snmp_ipsla command_line $USER1$/check_snmp -H $HOSTADDRESS$ -C P@ssw0rd -o .1.3.6.1.4.1.9.9.42.1.2.10.1.2.$ARG1$ -s 1 }(Pueden agregar el parámetro "-l < TEXTO >" si quieren modificar el texto de "Status Information").
-
Luego definimos los servicios basados en ese comando para el R2. Lo único que tenemos que pasarle como argumento es el ID del IP SLA:
define service { use generic-service host_name R2 service_description IP SLA 1 - Router: Ra check_command check_snmp_ipsla!1 } define service { use generic-service host_name R2 service_description IP SLA 2 - Router: Rb check_command check_snmp_ipsla!2 } define service { use generic-service host_name R2 service_description IP SLA 3 - Router: Rc check_command check_snmp_ipsla!3 }
Obtendríamos algo así:
- Definiendo Ra, Rb y Rc como Hosts (Opción 2):
Como segunda opción, vamos a definir Ra, Rb y Rc como Hosts en Nagios. Esto nos va a a permitir trabajar de manera transparente con los equipos como si Nagios llegase a cada directamente; permitiendonos verlos correctamente a nivel visual y en caso de ser necesario aplicar servicios por hostgroups.
Para hacerlo, vamos crear un nuevo template para hosts que utilice como check_command un nuevo comando que vamos a definir. El comando va a realizar el chequeo del OID de IP SLA (en vez de hacer el típico ping de los hosts default). Ese comando va a utilizar una variable Custom que llamaremos "IPSLA_ID" que va a ser el equivalente al ARG1 que utilizamos en el punto 3 (ya que en los check_command no podemos pasar argumentos como en los servicios). El Address del host será la IP de R2.
-
Definimos el comando:
define command{ command_name check-host-byipsla command_line $USER1$/check_snmp -H $HOSTADDRESS$ -C P@ssw0rd -o .1.3.6.1.4.1.9.9.42.1.2.10.1.2.$_HOSTIPSLA_ID$ -s 1 }La variable IPSLA_ID la vamos a definir por hosts, por lo tanto para invocarla desde el command debemos llamar así: $_HOSTIPSLA_ID$
Pueden leer más sobre variables custom acá -
Definimos el template con el nuevo check_command:
define host{ name ipslahost-template use generic-host check_period 24x7 check_interval 5 retry_interval 1 max_check_attempts 10 check_command check-host-byipsla notification_period workhours notification_interval 120 notification_options d,u,r contact_groups admins register 0 hostgroups routers,ipslahosts icon_image router40.png } -
Definimos un nuevo hostgroup para este tipo de hosts (opcional):
define hostgroup{ hostgroup_name ipslahosts alias ipslahosts } -
Por último definimos los hosts, a los que le agregamos la nueva variable IPSLA_ID que definirá como realizar el check_command:
define host{ use ipslahost-template host_name Ra alias Ra address 192.168.1.1 _IPSLA_ID 1 } define host{ use ipslahost-template host_name Rb alias Rb address 192.168.1.1 _IPSLA_ID 2 } define host{ use ipslahost-template host_name Rc alias Rc address 192.168.1.1 _IPSLA_ID 3 }
Ahora podemos ver todos los Routers como hosts:
- Definiendo Parentezco de los Hosts Ra, Rb y Rc (Opcional):
Cómo últimos detalles para mejorar la configuración podemos agregar una variable adicional a la definición de cada host, por ejemplo IPSLA_PARENT_NAME, para poner el nombre del Router del que depende el chequeo y mostrarlo en la página a nivel HTML, en el detalle del Host. Y además podemos agregar la variable parents con el mismo valor, para que en caso de perder conectividad con el router R2, los routers Ra, Rb y Rc figuren como UNREACHABLE, y no como DOWN. O sea, generamos una dependencia de conectividad. Importante aclarar que para que esta condición se active, debe fallar el chequeo contra R2 y contra los Ra, Rb o Rc. Si falla el chequeo de R2, por cualquier otra razón (por ejemplo un bloqueo de ICMP), pero se sigue pudiendo ver Ra, Rb y Rc a través de este, se seguirán viendo UP.
Quedaría así:
define host{
name ipslahost-template
use generic-host
check_period 24x7
check_interval 5
retry_interval 1
max_check_attempts 10
check_command check-host-byipsla
notification_period workhours
notification_interval 120
notification_options d,u,r
contact_groups admins
register 0
hostgroups routers,ipslahosts
icon_image router40.png
notes <font face="verdana" color="blue" size="4"><p> ROUTER IP SLA: $HOST_PARENTS$ </p></font>
}
define host{
use ipslahost-template
host_name Ra
alias Ra
address 10.1.0.1
_IPSLA_ID 1
_IPSLA_PARENT_NAME R2
parents R2
}
Ahora al entrar a los Host veremos:
Y al haber definido los parents, en caso de haber pérdida de conexión con R2, veremos el resto como UNREACHABLE:
Por otro lado, también podremos aprovechar la funcionalidad de Maps, que grafica teniendo en cuenta el parentezco definido:
Espero les haya sido útil,
Gabriel Soltz