Monitorización Switches fibra Brocade

Me ha tocado montar la monitorización de los switches de fibra que tenemos, dos Brocade 48000. Como en los dispositivos de red, lo mas sencillo para monitorizarlos es utilizando SNMP. De la documentación de referencia he conseguido extraer información de los puertos.

Los que he utilizado para crear una tabla dinámica con información de cada puerto son los siguientes:

  • Ancho de banda:

Words received: 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.12.X
Words transmited: 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.11.X

Hay que tener en cuenta que se trata de un contador de “words” con lo que si se quiere tener un dato mas común (Mbps por ejemplo) deberíamos hacer la conversión y tener en cuenta el tiempo entre muestras.

Si nuestra herramienta utilizase python por ejemplo bastaría con hacer la siguiente conversión:

txMBps = (abs(tx)*4)/60/1048576

Donde:

tx contiene la diferencia entre dos muestras consecutivas. Al ser una variable de tipo contador de 32 bits es posible que haya que hacer algún tipo de control al reiniciarse el contador.
Multiplico por 4 para convertir de “words” a bytes (ver página 618 de la documentación)
Divido por 60 porque la monitorización toma muestras de la variable cada minuto
Divido por 1024*1024 para convertir de bytes a MBytes.

  • Estadísticas puertos:

EIF: devuelve el número de errores de codificación o disparidad dentro de las tramas recibidas

swFCPortRxEncInFrs 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.21.X

CRC: errores de CRC detectados en las tramas recibidas

swFCPortRxCrcs 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.22.X

Trcs: Tramas truncadas que el puerto ha recibido

swFCPortRxTruncs 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.23.X

TL: Número de tramas recibidas que son demasiado largas

swFCPortRxTooLongs 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.24.X

BEOF: Cuenta el número de tramas que tienen malos delimitadores EOF

swFCPortRxBadEofs 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.25.X

EOF: devuelve el número de errores de codificación o disparidad fuera de las tramas recibidas

swFCPortRxEncOutFrs 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.26

BO: cuenta el número de tramas desordenadas recibidas

swFCPortRxBadOs 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.27

Cualquier incremento en estos contadores puede suponer un problema en la fibra o en los puertos.

  • Estado de los puertos:

swFCPortPhyState 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.3

Este OID devuelve un número que se corresponde con los siguientes estados:

  1. noCard: No hay una tarjeta presentada en este slot del switch
  2. noTransceiver: No hay un GBIC o SFP en el puerto
  3. laserFault: El módulo esta avisando de un fallo en el láser, por lo tanto el GBIC esta defectuoso
  4. noLight: El modulo no está recibiendo luz
  5. noSync: El módulo esta recibiendo luz pero sin sincronismo
  6. inSync: El modulo está recibiendo luz y esta en sincronismo
  7. portFault: El puerto está marcado como en fallo
  8. diagFault: El puerto ha fallado en los diagnósticos
  9. lockRef: Puerto está bloqueado

Con estos OIDs se puede tener una visión bastante exacta del estado de nuestro switch, sus errores y su uso.
Así es como ha quedado en la herramienta de monitorización que utilizo, en caso de producirse algún cambio de estado respecto al día anterior de un vistazo lo detecto:

Estado de los puertos en varios slots de brocade 48k

Estado de los puertos en un slot de brocade 48k

 Tengo otra tabla con las estadísticas que he comentado antes para cada puerto:

 Estadisticas puertos brocade

 Existe un bug en la versión de firmware que tiene el brocade que hace que los slots con Gbics a 8Gbps muestren errores de sincronismo.

Anuncios

SNMP y Trabajo con MIBs

Muchas veces debemos monitorizar elementos que disponen del protocolo SNMP. Normalmente es fácil encontrar el fichero de MIB del dispositivo que queremos monitorizar, ya sea en a través del fabricante o a través de webs de terceros como oidview. Una vez tenemos el fichero de la MIB, ¿que hacemos?¿Como podemos obtener el OID de un nodo en particular?

Como para todo, existirán múltiples formas de trabajar con este fichero, pero para los usuarios de Linux tenemos disponible el paquete “snmp” con un grupo de herramientas que nos servirán para nuestro propósito. Lo primero que deberemos hacer es instalar dicho paquete, si no lo hemos hecho ya antes, con un simple “sudo apt-get install snmp“. Una vez instalado tendremos disponibles comandos como snmpwalk, snmpget o snmptranslate.
En el siguiente ejemplo veremos como obtener el valor de algunas variables que nos pueden interesar para monitorizar un SAI con un adaptador CS121. Con dicho módulo venia su correspondiente CD de utilidades donde podíamos encontrar la MIB del producto, en concreto la RFC1628cs121.MIB. 
Nos podríamos ver tentados por visualizar dicho fichero, pero la sintaxis que utiliza (ASN1) no es la mas amigable para su lectura. 
La herramienta snmptranslate nos sirve para interpretar dicho fichero MIB. A primera vista podríamos analizar el arbol de la mib para evaluar que variables nos pueden interesar en la monitorización, para ello ejecutaremos el siguiente comando, especificando que carge el fichero de MIB del módulo:

julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -Tp 
+–iso(1)
   |
   +–org(3)
      |
      +–dod(6)
         |
         +–internet(1)
            |
            +–mgmt(2)
               |
               +–mib-2(1)
                  |
                  +–upsMIB(33)
                     |
                     +–upsObjects(1)
                     |  |
                     |  +–upsIdent(1)
                     |  |  |
                     |  |  +–upsIdentManufacturer(1)
                     |  |  |
                     |  |  +–upsIdentModel(2)
                     |  |  |
                     |  |  +–upsIdentUPSSoftwareVersion(3)
                     |  |  |
                     |  |  +–upsIdentAgentSoftwareVersion(4)
                     |  |  |
                     |  |  +–upsIdentName(5)
                     |  |  |
                     |  |  +–upsIdentAttachedDevices(6)
                     |  |
                     |  +–upsBattery(2)
                     |  |  |
                     |  |  +– -R– EnumVal   upsBatteryStatus(1)
                     |  |  |        Values: unknown(1), batteryNormal(2), batteryLow(3), batteryDepleted(4)
Si en la herramienta de monitorización podemos cargar el fichero de MIB, con interrogar al dispositivo con el nombre del nodo que nos interesa será suficiente (mas adelante explicaré algún ejemplo). En cambio, muchas herramientas de monitorización no permiten la carga del fichero de MIB y le debemos especificar el OID que queremos interrogar. El árbol de OIDs de la MIB lo podemos ver de la siguiente forma:
julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -To
.1.3
.1.3.6
.1.3.6.1
.1.3.6.1.2
.1.3.6.1.2.1
.1.3.6.1.2.1.33
.1.3.6.1.2.1.33.1
.1.3.6.1.2.1.33.1.1
.1.3.6.1.2.1.33.1.1.1
.1.3.6.1.2.1.33.1.1.2
.1.3.6.1.2.1.33.1.1.3
.1.3.6.1.2.1.33.1.1.4
.1.3.6.1.2.1.33.1.1.5
.1.3.6.1.2.1.33.1.1.6
.1.3.6.1.2.1.33.1.2
.1.3.6.1.2.1.33.1.2.1
.1.3.6.1.2.1.33.1.2.2
.1.3.6.1.2.1.33.1.2.3
.1.3.6.1.2.1.33.1.2.4
.1.3.6.1.2.1.33.1.2.5
.1.3.6.1.2.1.33.1.2.6
.1.3.6.1.2.1.33.1.2.7
.1.3.6.1.2.1.33.1.3
.1.3.6.1.2.1.33.1.3.1
.1.3.6.1.2.1.33.1.3.2
.1.3.6.1.2.1.33.1.3.3
.1.3.6.1.2.1.33.1.3.3.1
.1.3.6.1.2.1.33.1.3.3.1.1
.1.3.6.1.2.1.33.1.3.3.1.2
.1.3.6.1.2.1.33.1.3.3.1.3
.1.3.6.1.2.1.33.1.3.3.1.4
.1.3.6.1.2.1.33.1.3.3.1.5
El problema ahora es que no sabemos cual es la correspondencia entre el OID y el nodo que evaluamos. Esto se soluciona pasando como parámetro en el snmptranslate la opción -Tz, que nos devolverá la forma numérica y etiqueta de todos los objetos:
julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -Tz
“org” “1.3”
“dod” “1.3.6”
“internet” “1.3.6.1”
“mgmt” “1.3.6.1.2”
“mib-2” “1.3.6.1.2.1”
“upsMIB” “1.3.6.1.2.1.33”
“upsObjects” “1.3.6.1.2.1.33.1”
“upsIdent” “1.3.6.1.2.1.33.1.1”
“upsIdentManufacturer” “1.3.6.1.2.1.33.1.1.1”
“upsIdentModel” “1.3.6.1.2.1.33.1.1.2”
“upsIdentUPSSoftwareVersion” “1.3.6.1.2.1.33.1.1.3”
“upsIdentAgentSoftwareVersion” “1.3.6.1.2.1.33.1.1.4”
“upsIdentName” “1.3.6.1.2.1.33.1.1.5”
“upsIdentAttachedDevices” “1.3.6.1.2.1.33.1.1.6”
“upsBattery” “1.3.6.1.2.1.33.1.2”
“upsBatteryStatus” “1.3.6.1.2.1.33.1.2.1”
“upsSecondsOnBattery” “1.3.6.1.2.1.33.1.2.2”
“upsEstimatedMinutesRemaining” “1.3.6.1.2.1.33.1.2.3”
“upsEstimatedChargeRemaining” “1.3.6.1.2.1.33.1.2.4”
“upsBatteryVoltage” “1.3.6.1.2.1.33.1.2.5”
“upsBatteryCurrent” “1.3.6.1.2.1.33.1.2.6”
“upsBatteryTemperature” “1.3.6.1.2.1.33.1.2.7”
“upsInput” “1.3.6.1.2.1.33.1.3”
“upsInputLineBads” “1.3.6.1.2.1.33.1.3.1”
“upsInputNumLines” “1.3.6.1.2.1.33.1.3.2”
“upsInputTable” “1.3.6.1.2.1.33.1.3.3”
“upsInputEntry” “1.3.6.1.2.1.33.1.3.3.1”
“upsInputLineIndex” “1.3.6.1.2.1.33.1.3.3.1.1”
“upsInputFrequency” “1.3.6.1.2.1.33.1.3.3.1.2”
“upsInputVoltage” “1.3.6.1.2.1.33.1.3.3.1.3”
“upsInputCurrent” “1.3.6.1.2.1.33.1.3.3.1.4”
“upsInputTruePower” “1.3.6.1.2.1.33.1.3.3.1.5”

Para obtener mas información de un nodo en concreto primero deberíamos obtener la forma mas completa:

julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -Onf -IR upsInputTruePower
.iso.org.dod.internet.mgmt.mib-2.upsMIB.upsObjects.upsInput.upsInputTable.upsInputEntry.upsInputTruePower

Ya ejecutando el snmptranslate con el OID completo obtendremos mas información del nodo, con una descripción de la variable, las unidades, la  sintaxis, etc.

julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -Td -OS .iso.org.dod.internet.mgmt.mib-2.upsMIB.upsObjects.upsInput.upsInputTable.upsInputEntry.upsInputTruePower
UPS-MIB::upsInputTruePower
upsInputTruePower OBJECT-TYPE
  — FROM UPS-MIB
  — TEXTUAL CONVENTION NonNegativeInteger
  SYNTAX INTEGER (0..2147483647) 
  DISPLAY-HINT “d”
  UNITS “Watts”
  MAX-ACCESS read-only
  STATUS current
  DESCRIPTION “The magnitude of the present input true power.”
::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) upsMIB(33) upsObjects(1) upsInput(3) upsInputTable(3) upsInputEntry(1) 5 }

Para obtener el OID numérico que utilizaremos en la herramienta de monitorización para este nodo ejecutaremos la siguiente consulta:

julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -On UPS-MIB::upsInputTruePower
.1.3.6.1.2.1.33.1.3.3.1.5
Con estos datos ya podemos montar nuestro sistema de monitorización, evaluando únicamente las variables que nos interesen. 
También tendremos dos utilizades que nos permitirán obtener los valores directamente desde el módulo. El snmpwalk hará un recorrido por las ramas del árbol desde el nodo que le especifiquemos mientras que el snmpget nos devolverá el valor específico de un nodo. En ambos métodos podemos especificar el fichero de MIB que queremos utilizar o especificar el OID en formato numérico. Veamos varios ejemplos:
julian@ubuntu:$ snmpget -Os -c comunidad -m “./RFC1628cs121.MIB” -v 1 DireccionIP upsOutputPower.1
upsOutputPower.1 = INTEGER: 700 Watts

julian@ubuntu:$ snmpget -Os -c comunidad -v 1 DireccionIP 1.3.6.1.2.1.33.1.4.4.1.4.1
mib-2.33.1.4.4.1.4.1 = INTEGER: 700

julian@ubuntu:$  snmpwalk -Os -c comunidad -m “./RFC1628cs121.MIB” -v 1 DireccionIP upsInputEntry
upsInputLineIndex.1 = INTEGER: 1
upsInputFrequency.1 = INTEGER: 500 0.1 Hertz
upsInputVoltage.1 = INTEGER: 230 RMS Volts
upsInputCurrent.1 = INTEGER: 0 0.1 RMS Amp
upsInputTruePower.1 = INTEGER: 0 Watts

julian@ubuntu:$ snmptranslate -m “./RFC1628cs121.MIB” -On UPS-MIB::upsInputEntry
.1.3.6.1.2.1.33.1.3.3.1
julian@ubuntu:$  snmpwalk -Os -c comunidad -v 1 DireccionIP .1.3.6.1.2.1.33.1.3.3.1
mib-2.33.1.3.3.1.1.1 = INTEGER: 1
mib-2.33.1.3.3.1.2.1 = INTEGER: 500
mib-2.33.1.3.3.1.3.1 = INTEGER: 230
mib-2.33.1.3.3.1.4.1 = INTEGER: 0
mib-2.33.1.3.3.1.5.1 = INTEGER: 0
Se puede encontrar mas información en los siguientes enlaces: