Obtener uso de CPU y memoria, temperatura y estado de interfaces de dispositivos Cisco, utilizando SNMP

Continuando con la labor de monitorear el estado de dispositivos conectados a la red, decidí profundizar en el control de equipamiento Cisco. Para ello, recurrí al viejo pero muy vigente y útil protocolo SNMP. Los dispositivos Cisco, como la gran mayoría de los dispositivos de red, proveen información detallada a través de SNMP. El problema es que entre tanta información provista, uno se puede marear y perder lo que le interesa conocer.

Dado que no encontré mucha información que detalle cómo monitorear e interpretar la información de los recursos más importantes (si encontré pedazos de información por separado), decidí investigar y armar documentación propia. Distintas páginas de Cisco proveen información, pero dan por asumido que conocemos relativamente bien la información provista. Lo único que me resultó realmente útil es el navegador de objetos SNMP (http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en). En base a este último pude recopilar y armar las consultas que yo requería.

Yendo al grano, con la información provista en este artículo podrán no sólo saber cómo obtener por SNMP información del estado de los recursos del dispositivo, sino también entender los valores obtenidos.

Me centraré en obtener la información listada a continuación, la cual abarca todo lo necesario para conocer el estado de un dispositivo:

- Estado de las interfaces de red del dispositivo.
- Uso de CPU.
- Temperatura del chasis, y/u otra información provista por los sensores que el equipo posea.
- Uso de memoria.

En el artículo me centraré en describir los OIDs necesarios para obtener la información listada. Los ejemplos los haré utilizando snmpwalk como herramienta de consulta. Esta misma información se puede obtener con distintos clientes snmp, snmpwalk es sólo uno de ellos, muy versátil y completo. Una vez que se conocen los OIDs y la información provista, es muy fácil automatizar el monitoreo con herramientas como Nagios, o scripts propios. Dejaré la integración con Nagios para otro artículo :D

Si les interesa el monitoreo de redes, pueden encontrar más información al respecto en mis anteriores artículos:

- Nagios: monitoreo remoto de dispositivos + agentes Linux + agentes Windows
- Monitoreo de ancho de banda en routers/switches/etc usando MRTG
- Armar servidor de logging con rsyslog y configurar dispositivos para logging remoto
- Instalar Zabbix en Debian GNU/Linux

Estado de Interfaces

Hay ciertas interfaces que son muy interesantes para monitorear, dado que ello nos permitirá saber si un equipo importante perdió la conexión. Interfaces de este tipo pueden ser uplinks entre edificios, conexiones a servidores, enlaces a la WAN, etc.

El OID utilizado para ver el estado de las interfaces es el 1.3.6.1.2.1.2.2.1.8 (objeto ifOperStatus), descripto como "The current operational state of the interface". Este OID contiene una entrada por cada interfaz presente en el switch.
Por ejemplo, al realizar un walk en un 2950, obtenemos la siguiente información:

$ snmpwalk -v2c -c public 192.168.1.100 -On  1.3.6.1.2.1.2.2.1.8
.1.3.6.1.2.1.2.2.1.8.1 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.2 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.3 = INTEGER: down(2)
...
...

Ok, esto nos da el estado de las interfaces... pero cómo sabemos cuál interfaz es cada una? Para esto existe el OID 1.3.6.1.2.1.2.2.1.2 (objeto ifDescr), que contiene información de la interfaz. En el ejemplo anterior, la consulta de este OID nos dará lo siguiente:

$ snmpwalk -v2c -c public 192.168.1.100 -On  1.3.6.1.2.1.2.2.1.2
.1.3.6.1.2.1.2.2.1.2.1 = STRING: FastEthernet0/1
.1.3.6.1.2.1.2.2.1.2.2 = STRING: FastEthernet0/2
.1.3.6.1.2.1.2.2.1.2.3 = STRING: FastEthernet0/3
...

Ahora si, ya sabemos que el OID 1.3.6.1.2.1.2.2.1.8.1 representa el estado de la interfaz FastEthernet0/1, el 1.3.6.1.2.1.2.2.1.2.3 la Fa0/3, etc. Para cada interfaz que se desee monitorear, deberá consultarse primero la descripción de la misma, así sabemos con cuál OID se relaciona.


Uso de CPU

Cisco almacena distintos valores para el uso de CPU, utilizando distintos períodos de tiempo. Los OIDs son:

• 1.3.6.1.4.1.9.9.109.1.1.1.1.10 (cpmCPUTotalMonIntervalValue): uso de CPU en el intervalo especificado por 1.3.6.1.4.1.9.9.109.1.1.1.1.9 (cpmCPUMonInterval). El intervalo suele ser 5 segundos, y este OID es el que debe utilizarse en lugar de cpmCPUTotal5sec y cpmCPUTotal5secRev, ya en desuso.
• 1.3.6.1.4.1.9.9.109.1.1.1.1.7 (cpmCPUTotal1minRev): uso en el último minuto. Anteriormente se utilizaba cpmCPUTotal1min.
• 1.3.6.1.4.1.9.9.109.1.1.1.1.8 (cpmCPUTotal5minRev): uso en los últimos cinco minutos. Debe utilizarse en lugar de cpmCPUTotal5min.

La empresa recomienda utilizar cpmCPUTotal5minRev, dado que representa la mejor estimación de uso.
Todos estos valores representan porcentaje de uso y van de 0 a 100.

Ejemplo de consulta del valor de carga de CPU en los últimos 5 minutos es el siguiente:

$ snmpwalk -v2c -c public 192.168.1.100 -On  1.3.6.1.4.1.9.9.109.1.1.1.1.8
.1.3.6.1.4.1.9.9.109.1.1.1.1.8.1 = Gauge32: 6

es decir, la carga es de 6%.

En la página How to Collect CPU Utilization on Cisco IOS Devices Using SNMP se explica bien como obtener información del uso de CPU.


Sensores (midiendo temperatura y estado de fans)

Existen varios sensores en los dispositivos que permiten medir diferentes valores, como la temperatura del chasis y el funcionamiento de los fans. Los valores de los sensores se almacenan en el objeto 1.3.6.1.4.1.9.9.91.1.1.1.1.4 (entSensorValue).
Por ejemplo, accediendo los valores de los sensores en un 4500 obtendremos algo así:

$ snmpwalk -v2c -c public 192.168.1.200 -On 1.3.6.1.4.1.9.9.91.1.1.1.1.4
.1.3.6.1.4.1.9.9.91.1.1.1.1.4.9 = INTEGER: 35
.1.3.6.1.4.1.9.9.91.1.1.1.1.4.15 = INTEGER: 1
.1.3.6.1.4.1.9.9.91.1.1.1.1.4.18 = INTEGER: 2

Este objeto contiene entradas indexadas según el índice físico de cada entidad (en este caso, el sensor es la entidad). Para saber a qué entidad refiere cada índice, se puede consultar el objeto 1.3.6.1.2.1.47.1.1.1.1.2 (entPhysicalDescr), el cual describe cada entidad física.
En el ejemplo anterior, podemos ver lo siguiente al consultar este objeto:

$ snmpwalk -v2c -c public 192.168.1.200 -On 1.3.6.1.2.1.47.1.1.1.1.2
...
.1.3.6.1.2.1.47.1.1.1.1.2.9 = STRING: "Chassis Temperature Sensor"
...
.1.3.6.1.2.1.47.1.1.1.1.2.15 = STRING: "Power Supply Fan Sensor"
...
.1.3.6.1.2.1.47.1.1.1.1.2.18 = STRING: "Power Supply Fan Sensor"

Es decir, los valores obtenidos anteriormente son la temperatura del chasis y el estado de los fans de las fuentes.
Ahora, qué significan esos valores? en qué unidades están representados? Bueno, para esto necesitamos consultar ooootro objeto, el 1.3.6.1.4.1.9.9.91.1.1.1.1.1 (entSensorType), que nos indica de qué tipo es cada sensor:

.1.3.6.1.4.1.9.9.91.1.1.1.1.1.9 = INTEGER: 8
.1.3.6.1.4.1.9.9.91.1.1.1.1.1.15 = INTEGER: 12
.1.3.6.1.4.1.9.9.91.1.1.1.1.1.18 = INTEGER: 12

Cisco tiene predefinidos estos valores en una tabla, la cual se puede encontrar en su página. La tabla indica lo siguiente:

1:other
2:unknown
3:voltsAC
4:voltsDC
5:amperes
6:watts
7:hertz
8:celsius
9:percentRH
10:rpm
11:cmm
12:truthvalue
13:specialEnum
14:dBm

Con esto sabemos que el primer sensor mide grados celsius (valor 8), y los otros dos otorgan un valor booleano (12). Pero qué significan los valores 1 y 2? cuál es verdadero y cuál es falso? Consultando la página de Cisco, encontramos lo siguiente:

other(1): a measure other than those listed below
unknown(2): unknown measurement, or
arbitrary, relative numbers
voltsAC(3): electric potential
voltsDC(4): electric potential
amperes(5): electric current
watts(6): power
hertz(7): frequency
celsius(8): temperature
percentRH(9): percent relative humidity
rpm(10): shaft revolutions per minute
cmm(11),: cubic meters per minute (airflow)
truthvalue(12): value takes { true(1), false(2) }
specialEnum(13): value takes user defined enumerated values
dBm(14): dB relative to 1mW of power

Gracias a esta última información, ahora sabemos que 1 es verdadero, y 2 es falso. Es decir, el Fan 1 funciona bien, mientras que el 2 no.

Juntando todo este meollo de consultas, ahora sabemos lo siguiente:

• El switch posee 3 sensores.
• El primero mide la temperatura del chasis, la cual en este momento es de 35º
• Los otros dos sensores chequean el estado de los fans de las fuentes, estando el primer fan funcionando bien y el segundo no.

 
Uso de Memoria

Es posible ver el uso de memoria de los dispositivos, así como la cantidad de memoria libre, accediendo al objeto 1.3.6.1.4.1.9.9.48 (ciscoMemoryPoolMIB). Cisco divide la memoria en pools, según su uso. Los tipos de pools predefinidos son:

1:  processor memory
2:  i/o memory
3:  pci memory
4:  fast memory
5:  multibus memory

Además, los pools pueden ser categorizados en dinámicos o predefinidos. De los listados anteriormente, sólo el tipo processor debe ser soportado por todos los dispositivos.
Ejemplo de valores obtenidos en un 2950:

$ snmpwalk -v2c -c public 192.168.1.100 -On 1.3.6.1.4.1.9.9.48
.1.3.6.1.4.1.9.9.48.1.1.1.2.1 = STRING: "Processor"
.1.3.6.1.4.1.9.9.48.1.1.1.2.2 = STRING: "I/O"
.1.3.6.1.4.1.9.9.48.1.1.1.3.1 = INTEGER: 2
.1.3.6.1.4.1.9.9.48.1.1.1.3.2 = INTEGER: 0
.1.3.6.1.4.1.9.9.48.1.1.1.4.1 = INTEGER: 1
.1.3.6.1.4.1.9.9.48.1.1.1.4.2 = INTEGER: 1
.1.3.6.1.4.1.9.9.48.1.1.1.5.1 = Gauge32: 2417476
.1.3.6.1.4.1.9.9.48.1.1.1.5.2 = Gauge32: 687872
.1.3.6.1.4.1.9.9.48.1.1.1.6.1 = Gauge32: 1467696
.1.3.6.1.4.1.9.9.48.1.1.1.6.2 = Gauge32: 1492064
.1.3.6.1.4.1.9.9.48.1.1.1.7.1 = Gauge32: 1274620
.1.3.6.1.4.1.9.9.48.1.1.1.7.2 = Gauge32: 1492060

De los valores obtenidos, tenemos que:

• 1.3.6.1.4.1.9.9.48.1.1.1.2 (ciscoMemoryPoolName) define el nombre del pool. En el ejemplo hay dos pools, Processor e I/O.
• 1.3.6.1.4.1.9.9.48.1.1.1.5 (ciscoMemoryPoolUsed) muestra el uso de memoria actual de cada pool, expresado en bytes.
• 1.3.6.1.4.1.9.9.48.1.1.1.6 (ciscoMemoryPoolFree) representa la memoria libre en cada pool, también en bytes.

La memoria total del equipo se puede obtener sumando los bytes libres con los utilizados.