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.

  1. 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
  1. 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:

  1. 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 [email protected] 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.

  1. 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:

  1. 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 [email protected] -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").

  2. 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í:

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

  1. Definimos el comando:

     define command{
         command_name    check-host-byipsla
         command_line    $USER1$/check_snmp -H $HOSTADDRESS$ -C [email protected] -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á

  2. 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
     }
    
  3. Definimos un nuevo hostgroup para este tipo de hosts (opcional):

     define hostgroup{
         hostgroup_name  ipslahosts
         alias           ipslahosts
     }
    
  4. 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:

**

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