Smtp 2950

Administración de redes de computadores.

ADMINISTRACIÓN Y CONFIGURACIÓN
DE UN SWITCH CISCO A TRAVÉS DE
SNMP.

Alejandro Gascón González


INDICE DE CONTENIDOS:

1. Resumen..........................................................................................................Pag 3.

2. Problema a resolver........................................................................................Pag 3

3. Introducción al dispositivo cisco catalyst serie 2950. ................................Pag 4

1. Resumen de las características más importantes del dispositivo para nuestra
labor..............................................................................................................Pag 4.

4. Herramientas disponibles para el desarrollo de nuestro problema...........Pag 6.

1. Opción ios...............................................................................................Pag 7.

2. Opción snmp............................................................................................Pag 8.

5. SNMP................................................................................................................Pa g 8

6. Resumen de las mibs disponibles en el cisco..............................................Pag 9

7. RMON................................................................................................................Pag 16

8. Areas de la administración de la iso y nuestro problema............................Pag 22

9. Primeras configuraciones...............................................................................Pag 27

10. Ejemplo de alarma...........................................................................................Pag 29

11. Scripts.............................................................................................................. Pag 30



RESUMEN.

De todos es conocido el auge que está tomando las redes en las empresas. Tras la
necesaria aparición de los computadores en las areas de trabajo. Esas redes representan
la vital comunicación entre computadores y dispositivos como impresoras en una
empresa.

Cuando la red crece de forma exponencial y además necesitas que se encuentre
disponible en todo momento y para cualquier ordenador o dispositivo, crece la necesidad
de una correcta administración de los recursos de esa red y un control de la misma que
evite colapsos que puedan incomunicar los elementos de la red.

Existen numerosas herramientas que ayudan a la tarea del administrador de la red. Las
hay tanto de libre distribución como de pago y nos ofrecen estadísticas del tráfico,
contabilidad, seguridad, ... Donde cada herramienta estará desarrollada de una manera u
otra, realizará una serie de tareas, tendrá un aspecto visual,...

En este documento partiré del protocolo estrella para la gestión de redes: SNMP. No voy
a profundizar en él, ya que existe gran cantidad de documentación respecto a este tema.
Para ello se puede recurrir a páginas como www.snmplink.org o www.net-snmp.org.

Más especificamente usaremos SNMP como forma de configurar RMON en el switch
Cisco. Aunque la información aquí prestada será facilmente transladada a otros
dispositivos intermedios que nos posibiliten el uso de SNMP y de RMON. Incluso se
puede portar esta idea a un host.

PROBLEMA A RESOLVER.

El problema es el siguiente:

DESEAMOS ADMINISTRAR UN DISPOSITIVO INTERMEDIO EN UNA RED.

Supongamos que somos administradores de una red, con una topología concreta, más o
menos compleja. Como paso previo deberíamos conocerla y diseñar una estrategia para
la correcta administración y posteriormente documentarla. La documentación de esa red y
de las decisiones que tomemos deberían ser documentadas para los posteriores
encargados.



Tras el conocimiento de nuestra red, deberemos tomar decisiones para la correcta
administración y la toma de deciones para mejorala, en el caso que fuera necesario, o
para subsanar los fallos a los que nos podemos enfrentar o plantear estrategias frente a
posibles problemas de seguridad a los que nos podemos enfrentar.

Tomaré el switch Cisco como centro de mi red, como decisición respecto a mí red. Para
ello deberé conocer que posibilidades me ofrece, cuales son las herramientas que me
ofrece para realizar mi tarea. Ya que un conocimiento exhaustivo del mismo podría ser de
gran utilidad para desarrollar mi pretendida estrategía.

Como primera tarea consultaré como es mi dispositivo, que me ofrece, de que consta, ...

INTRODUCCIÓN AL DISPOSITIVO CISCO CATALYST SERIE 2950.

Como primera opción será documentarme a través de la página que ofrece Cisco systems, donde
además tenemos un catálogo extenso de otros dispositivos disponibles. Evidentemente lo más
sencillo es tomar el manual del dispositivo, pero en mi caso no dispongo de él.

http://www.cisco.com/en/US/products/hw/switches/ps628/products_data_sheet09186a00801cfb71.html

http://www.cisco.com/en/US/products/hw/switches/ps628/products_data_sheet09186a00801cfb64.html

Ambas páginas ofrecen información muy detallada de nuestro dispositivo en concreto. Y para dudas
concretas sobre la disponibilidad o no de algún servicio recomiendo la consulta a las mismas.

RESUMEN DE LAS CARACTERÍSTICAS MÁS IMPORTANTES DEL
DISPOSITIVO PARA NUESTRA LABOR.

Para comenzar, destacar y subrayar que este tipo de dispositivo de gama alta, su hardware es
similar a la arquitectura que podriamos ver en un computador.



Posee los siguientes elementos principales:

• RAM: Contendrá código, tablas de encaminamiento, buffers,
cache ARP, etc.
• NVRAM (no volátil): fichero de configuración “startup-config”.
• Flash (no volátil): Contiene la imagen del IOS
• ROM (no volátil): parte de imagen IOS, código bootstrap.
• CPU.

Las interfaces, en nuestro caso son 24 para la conexión a dispositivos de red y una 25
para la conexión al Cisco para labores de configuración. Aunque en otro plano, destacar
que existe una interfaz virtual, la 26. Esa interfaz es puramente software y como veremos
más adelante, nos va a ser muy útil.

Para la correcta y eficiente utilización de este hardware, además de ayudar a las tareas
típicas de un switch o de un routes. Cisco nos provee de un sistema operativo propio, el
IOS (Internetworking operating system). Ese sistema operativo está almacenado en la
memoria flsh y está compuesto de un fichero que comprende el código de todas las
funciones disponibles.

Cada dispositivo dispone de dos ficheros de configuración, uno de ellos está compuesto
por el estado actual de la configuración y se llama RUNNING-CONFIG. El otro fichero
incluye la información utilizada en el arranque, se trata del STARTUP-CONFIG. Otro
punto que ofrece el Cisco es una serie de comandos englobados en el intérpretes de
comandos o CLI (command line interface).

Hay numerosas maneras para la comunicación con el Cisco, para conocerlas voy a hacer
un pequeño resumen de todas:

1. Tenemos la opción de comunicarnos físicamente a través de la interfaz 25 o
CONSOLE, del Cisco. Normalmente en el Cisco, fisicamente es una RJ45 y ese
cable en el extremo host es un cable serie. Con esta opción podemos, tras
autentificarnos usar los comandos disponibles del CLI y configurar a nuestro



gusto el dispositivo. Para ello disponemos en Windows del Hyperterminal y en
Linux de Minicom.

2. A través de Telnet. Conectándonos al puerto lógico 23 del dispositivo. De esta
manera podremos de igual manera mandar comandos al Cisco. (Por supuesto
tras la correcta autentificación).

3. A través de una interfaz web que nos ofrece. (mediante nuestro navegador
favorito, con el único requisito de tener instalado la máquina virtual de Java).

IMPORTANTE: Para los que no se han percatado aún de un problema que puede surgir,
estamos hablando de un dispositivo a nivel de enlace (consulta la pila de protocolos de
TCP/IP). Por tanto como es posible tener una dirección IP que es de un nivel superior.
Bueno, sencillo, cuando el dispositivo está sin configurar, la única manera de poder
acceder al switch es a través del puerto CONSOLE. De esta manera podremos configurar
una IP al dispositivo. Aunque seguimos en las mismas, ¿cómo podemos dar una IP en
nivel de enlace?. Bueno, recordar que he hablado que la interfaz 26 es software, y en esa
interfaz si está implementada la pila de protocolos. Por lo tanto, si queremos que nuestro
switch no sea transparente y asignarle una IP, la asiginaremos a través del puerto 26.

Otro punto del que he hablado es la autentificación. ¿Qué nos proporciona IOS? Bueno
decir que en el IOS existen 15 niveles de autentificación. Cada uno de esos niveles tiene
una serie de comando que puede ejecutar. Por tanto, de esta manera, si nos
autentificamos con una clave de nivel 15 tendremos acceso al repertorio de comandos.
(Aunque no es tan sencillo).

Como punto a destacar es que ese CLI tiene un repertorio similar a UNIX (aunque, por
supuesto, más reducido) Por tanto, si estás familiarizado con UNIX o derivados, quizás te
sea más fácil interactuar con IOS a través de CLI:

HERRAMIENTAS DISPONIBLES PARA EL DESARROLLO DE NUESTRO
PROBLEMA.

Para esta tarea, el dispositivo nos provee de dos herramientas:

• IOS.

• SNMP.



OPCION IOS.

La opción IOS, trata de usar los comandos que nos proporciona CLI para la creación de tablas de
RMON. De esta manera y gracias a RMON, crearemos tablas que nos proporcionarán
información como estadísticas de nuestra red. O podremos generar informes o traps o ambos
para indicar que determinada alarma ha sucedido. Para ello CLI nos ofrece comandos como:

rmon statistics, rmon history, rmon alarm, rmon event,...

Como ejemplo usaré el comando rmon alarm, el cual que crea una alarma. Este comando
tiene la siguiente sintáxis:

rmon alarm number variable interval {abs|delta}

rising-threshold value [event-number]

falling-thresold value [event-number]

owner [owner string]

Donde:

NUMBER: Especifica el número único que identifica la alarma. Como estamos hablando
de tablas, con ese número nos referimos al índice de esa tabla. (En este caso de la tabla
Alarm).

VARIABLE: Indica la variable, la cual, va a ser monitorizada. Respresentada por su OID.

INTERVAL: Indica cada cuanto tiempo se toman muestras de esa variable para ver si se
supera un umbral y ver si se salta la alarma.

ABS|DELTA: Indica el tipo de muestreo. Si es ABS, se tomará en cada INTERVAL el
valor de la variable y se comparará con el umbral. Si es DELTA se toma un valor
incremental. En este caso se procede de la siguiente manera: Se toma un valor al inicio y
pasado INTERVAL se toma la diferencia desde el anterior hasta el momento actual y ese
valor se mide con el umbral. De esta manera vemos cuanto ha cambiado la variable
durante el tiempo INTERVAL.

RISING-THRESOLD: Indica el umbral de subida, Si dicho umbral se supera saltará la
alarma.

FALLING-THRESOLD: Indica el umbral de bajada, si el valor de la variable baja de ese
umbral se disparará la alarma.

OJO: En realidad, no se dispara una alarma, sino que se ejecuta la acción definida en el
evento que asociaremos a la alarma. Mediante EVENT-NUMBER.



Un ejemplo posible sería:

rmon alarm 10 ifEntry.20.1 20 delta

rising-threshold 15 1

falling-threshold 0

owner 192.200.2.120

En este caso se ejecutará la acción definida en la tabla de eventos, índice 1. ¿Cuándo?
Cuando el valor del objeto cuyo OID= ifEntry.20.1 (paquetes de salida con error) . En un
intervalo de 20 SEGUNDOS, haya subido de 15 paquetes. Indicando que en 20 segundos
han sucedido 20 errores en paquetes lo cual podría o no ser problemático.

OPCIÓN SNMP.

Esta es la opción que define este documento. Para ello introduciré los datos necesarios.
Como que objetos de la información de gestión nos porporciona el dispositivo, que es
RMON, la gestión con RMON, programación de alarmas, etc.

SNMP.

SNMP es un protocolo de nivel de aplicación para consulta a los diferentes elementos
que forma una red, (routers, switches, hubs, hosts, modems, impresoras, etc). Cada
equipo conectado a la red ejecuta unos procesos (agentes), para que se pueda realizar
una administración tanto remota como local de la red. Dichos procesos van actualizando
variables que nos ofrece la SMI (Structure of Management information) en una base de
datos, que máquinas remotas pueden consultar.

La Arquitectura de Administración de Red se compone de cuatro componentes
principales:

• Estación de administración

• Agente de administración del dispositivo administrado

• Base de información de administración,

• Protocolo de administración.



SNMP facilita la comunicación entre la estación administradora y el agente de un
dispositivo de red (o nodo administrado), permitiendo que los agentes transmitan datos
estadísticos (variables) a través de la red a la estación de administración.

SNMP es independiente del protocolo (IPX de SPX/IPX de Novell, IP con UDP) SNMP se
puede implementar usando comunicaciones UDP o TCP, pero por norma general, se
suelen usar comunicaciones UDP en la mayoría de los casos. Con UDP, el protocolo
SNMP se implementa utilizando los puertos 161 y 162.

Puerto 161 se utiliza para las transmisiones normales de comando SNMP

Puerto 162 se utiliza para los mensajes de tipo “trap” o interrupción.

RESUMEN DE LAS MIBS DISPONIBLES EN EL CISCO.

Cuando pensemos en monitorizar nuestro dispositivo lo primero que deberíamos pensar
es en conocer que nos ofrece nuestra máquina. Una vez conocido elegiríamos los objetos
que nos parecierán más notorios para nuestro trabajo. En mi caso he analizado la
información que me ofrece el Cisco, como veremos ofrece una gran cantidad de datos,
veremos también información redundante,...

.iso.member-body.us.802dot3.snmpmibs.lagMib



En este subárbol podemos encontrar dos tablas:

dot3adAggTable:

Una tabla que contiene información de los"aggregator", que son elementos del BGP
(Border Gateway Protocol). .

dot3adAggPortListTable

Esta tabla es similar a la primera, pero esta da información de cada uno de los
aggregator.

.iso.org.dod.internet.mgmt.mib-2.dot1dBridge

Esta tabla contiene como veremos información sobre la caracterítica de puente del
dispositivo. Información referente a los protocolos de árbol de expansión o el de puente
transparente.
Contiene tres escalares y tres tablas:

dot1dBaseBridgeAddress

Escalar que nos indica la dirección MAC del puente

dot1dBaseNumPorts

El número de puertos controlados por dicho puente.

dot1dBaseType

Indica el tipo de puente de entre estas cuatro posibilidades:

• unknown(1)
• transparent-only(2)
• sourceroute-only(3)
• srt(4)

dot1dBasePortTable

Contiene esta tabla, información sobre cada puerto asociado al puente. Información
como:

dot1dBasePort: El número de puerto del puerto cuya entrada contiene información para
la administración del puente.



Dot1dBasePortIfIndex: El valor de la instancia del objeto ifIndex definido en la MIB-II
para la interfaz correspondiente a ese puerto.

Dot1dBasePortCircuit: Para puertos que tienen otro puerto en el puente, además del
definido en dot1dBasePortIfIndex, este objeto nos da una identificación única.

Dot1dBasePortDelayExceededDiscards: El número de marcos descartados por este
puerto debido a excesivo tránsito retrasado en el puente.

dot1dBasePortMtuExceededDiscards: El número de marcos descartados por este
puerto debido al excesivo tamaño de los mismos.

.iso.org.dod.internet.mgmt.mib-2.dot1dStp

Esta tabla contiene información acerca del protocolo de árbol de expansión. (Spanning
tree). Contiene catorce escalares y una tabla:

dot1dStpProtocolSpecification: Versión del protocolo que el puente está usando.

Dot1dStpPriority: Valor de los primeros dos octetos reescribibles del ID del dispositivo.

Dot1dStpTimeSinceTopologyChange: Tiempo desde el último cambio de topología.

Dot1dStpTopChanges: El número total de cambios de topología desde que el último
reset del dispositivo.

Dot1dStpDesignatedRoot: La identificación de la raiz del árbol.

Dot1dStpRootCost: Coste de la ruta desde éste dispositivo a la raiz.

Dot1dStpRootPort: Número del puerto con el menor coste desde el a la raiz.

Dot1dStpMaxAge: Tiempo máximo que se mantiene la información aprendida.

Dot1dStpHelloTime: Tiempo desde que se configuro el puerto en la topología.

Dot1dStpHoldTime: El valor del intervalo de tiempo durante el cual no más de dos PDU
´s para la configuración del puente han sido transmitidas por dicho nodo.

Dot1dStpForwardDelay: Se especifica en esta variable el tiempo en centésimas de
segundo que necesita para hacer un cambio de estado.

Dot1dStpBridgeMaxAge: MaxAge de la raiz.

Dot1dStpBridgeHelloTime: HelloTime de la raiz.

Dot1dStpBridgeForwardDelay: Valor de Forward delay de la raiz.



.iso.org.dod.internet.mgmt.mib-2.dot1dTp

dot1dTpLearnedEntryDiscards: Entradas que deberían haber sido aprendidas pero no
ha podido, pero no ha podio ser ya que no teneía espacio libre.

Dot1dTpAgingTime: El tiempo que se mantienen las entradas.

Dot1dTpFdbTable

Esta tabla contiene información acerca de entradas a las cuales mantiene un filtrado o
información de enrutado.

dot1dTpFdbAddress: Dirección MAC.

Dot1dTpFdbPort : Puerto de los paquetes cuya MAC es la inficada por
dot1dTpFdbAddress.

Dot1dTpFdbStatus: Estado de la fila:

• other(1)

• invalid(2)

• learned(3)

• self(4)

• mgmt(5)

dot1dTpPortTable

Contiene información por puerto del protocolo de puente transparente.

Dot1dTpPort: Puerto que contiene información de gestión del protocolo.



Dot1dTpPortMaxInfo: Tamaño máximo del campo INFO (no MAC) que un puerto puede
transmitir o recibir.

Dot1dTpPortInFrames: Paquetes de entrada por el puerto.

Dot1dTpPortOutFrames: Paquetes de salida por el puerto.

Dot1dTpPortInDiscards: Número de paquete correctos de entrada pero descartados
(por ejemplo, han sido filtrados).

.iso.org.dod.internet.mgmt.mib-2.mib-2.ifMIB.

IfXEntry

ifName (1): Nombre textual de la interfaz.

IfLinkUpDownTrapEnable (14): Indica si esta interfaz generará traps en caso de que la
interfaz pase de estado UP a DOWN.

IfHighSpeed (15): Estimación del ancho de banda de la interfaz.

IfPromiscuousMode (16): Indica si la interfaz está o no en modo promiscuo.

IfConnectorPresent (17): Indica si la interfaz tiene un conector físico.

IfAlias (18): En él se especifica un nombre alias para esa interfaz.

IfCounterDiscontinuityTime (19): Valor sel sysUpTime cuando uno o varios contadores
de la interfaz sufrierón alguna discontinuidad.

IfStackTable (2)

Está tabla contiene información acerca de las relaciones entre capas. Esta funciona de
manera similar a RMON ya que tiene un objeto columnar STATUS. Aunque es para
indicar el estado de la fila. El objeto STATUS es de sólo lectura.

IfRcvAddressTable

ifRcvAddressAddress: Indica la dirección de los paquetes que el sistema aceptará

ifRcvAddressStatus: Indica el estado de la fila.



IfRcvAddressType: Indica el tipo de entrada, es decir, si es volátil o no volátil.

.iso.org.dod.internet.mgmt.mib-2.entPhysicalTable

entPhysicalTable (1)

entPhysicalDescr: Descripción textual de la interfaz física.

EntPhysicalVendorType: Indica el OID del tipo de hardware del fabricante. En este caso
da SNMPv2-SMI::enterprises.9.12.3.1.10.134. Si vemos el enterprises.9 es Cisco.

EntPhysicalContainedIn: El valor del indice de entPhysicalDescr en el cual está
contenido la interfaz. En nuestro caso es 1, si vemos el calor del índice 1 y vemos la
descripción vemos que es Cisco Catalyst c2950 switch with 24 10/100 BaseTX ports.

EntPhysicalClass: Indica el tipo de hardware.

EntPhysicalParentRelPos.

EntPhysicalName: Indica el nombre textual de cada interfaz.

EntPhysicalHardwareRev: Versión del hardware.

EntPhysicalFirmwareRev: Versión del firmware, de aqui podemos obtener la versión del
IOS.

EntPhysicalSoftwareRev: Versión del software.

EntPhysicalSerialNum: Número de serie.

EntPhysicalMfgName: El nombre del manufacturador del interfaz. (En este caso Cisco).

EntPhysicalAlias: Alias del interfaz.

EntPhysicalAssetID.

EntPhysicalIsFRU: Indica si es una unidad reemplazable.



iso.org.dod.internet.private.enterprises.cisco

En este caso resumiré el contenido de la rama ya que es muy extensa, son 74 escalares
que indican, para empezar tiene 74 escalares que indican:

• Información del planificador de la CPU (porcentaje de uso en los 5 últimos segundos,
en ultimo minuto y en los últimos 5 minutos).

• Clasifica los buffers en:

• Pequeños.

• Grandes.

• Medianos.

• Muy grandes.

• Gigantes.

Y para cada tipo indica la cantidad de buffers, los que están libres, los que están
ocupados, su tamaño, los aciertos, los fallos.

• Indica datos como el nombre del host, el id de la ROM, dirección del host que provee
del fichero host-config, el nombre de la imagen de arranque y del protocolo que provee
de la imagen.

Luego tiene una tabla con 114 elementos columnares, que indican, por interfaz,
información de colisiones, de estado operativo, tipo de hardware, tiempos desde que se
envió el último paquete, desde que se recibió, desde que no se pudo enviar. La cantidad
de bits por segundo movidos en los últimos 5 minutos, desglosados en entrada y en
salida, además de bits, también nos indica los paquetes, ...

También nos dá información acerca de la memoria flash. Desde la identificación, el
tamaño, el tamaño disponible, el ocupado, ... Hasta el nombre asociado a la entrada en
memoria flash donde podemos ver programas y páginas web.



.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt

Esta rama tampoco se queda corta en tamaño. Sólo nuestro dispositivo implementa 20
ramas. Donde podemos encontrar información del dispositivo.

Volvemos a encontrar información de la memoria flash, un log del sistema, información de
monitorización del RTT de los dispositivos, información de la memoria disponible en el
Cisco, el estado del monitor, información de la VLAN, información del protocolo de árbol
de expansión, información del protocolo PAgP (Port Aggregation Protocol), información
de los procesos que corren en el sistema, información acerca del filtro IGMP Filter
configuration MIB, información acerca de la seguridad que aporta Cisco en torno a las
MAC, ...

Ya que SNMP es un estandart, toda la parte de SNMP y RMON no cambiará en otras
marcas. Claro está que en cada dispositivo cambiarán los grupos del árbol de la mib que
este implemente. Si hablamos de un dispositivo D-Link implementará una serie de grupos
específicos de D-Link, pero como común denominador dispondremos de los grupos
standart de la mib (del RFC 1213).

En este documento comentaré los grupos del switch, tanto de snmp como de rmon.
Aunque prestando gran importancia a:

✔ System.

✔ Interfaces.

✔ IP

✔ TCP.

✔ UDP.

✔ ICMP.

✔ SNMP

RMON.

Se trata, RMON, de una extensión de la MIB-II, ya que no se modifica el protocolo SNMP.
Se usa para la monitorización de una red como un todo. Ofreciendo una manera eficiente
para monitorizar el comportamiento de una red reduciendo la carga en la misma.

Si queremos hacer una monitorización y control de una red mediante SNMP, primero
estudiamos la información de la que disponemos a través de los objetos del árbol. Una
vez conocida, elegimos de estos los que creamos necesarios para crear unas estadísticas



de la red, hacer un sondeo periódico de objetos que indiquen algún suceso
significativo, ...

Para ello, debemos hacer peticiones desde la estación gestora a los agentes instalados
en cada host y dispositivos. Un host determinado de la red, cada cierto tiempo, toma
datos de toda la red, pero para ello hace peticiones a todos los host.

En RMON la idea es algo distinta. Un monitor o sonda RMON va observando el tráfico
que atraviesa el dispositivo (normalmente un dispositivo intermedio como un switch o un
router). Analiza ese tráfico que le atraviesa y rellena unas tablas de datos, que ahora el
gestor snmp puede consultar. Por tanto eliminamos bastantes peticiones en la red. Ahora
la sonda monitoriza todo un segmento de una red y no nos centramos en un host
concreto.

Los grupos de RMON son una seríe de tablas, normalmente dos, una de datos y otra de
control. Aunque en eso es flexible. Ya que hay grupos que constan de una sola tabla, de
datos o de control.

La manera común de trabajar es escribir las entradas necesarias de la tabla de control y
una vez terminado el proceso, el propio monitor rellenará la tabla de datos asociada a la
de control. Es necesario destacar tres objetos en las tablas, los cuales, una vez
comprendidos, se podrá trabajar con RMON completamente.

• STATUS: Cada fila que queramos crear será como una pequeña máquina de estados
con los siguientes estados:

valid (1), create request (2), under creation (3), invalid (4).

De forma que pueden suceder los siguientes casos:

• Que no existe la fila: Por tanto deberemos hacer una petición de creación,
escribiendo el valor 2 en el objeto status de la tabla que deseemos en la fila que
hallamos elegido. Por ejemplo:

• snmpset -v2c -c comunity 192.168.35.2 mib-2.16.1.1.1.21.1 i 2.

En este caso elegimos la fila 1, y pedimos la creación. Justo en ese momento
pasa a under creation y no podrá ser pasar al estado de create request.

• Que la fila está creada: En este caso tenemos la opción de borrarla pasándola a
invalid, o modificarla pasándola a under creation.

• INDEX: Las tablas por defecto vienen vacias, pendientes de ser configuradas, aunque
en otras máquinas puede el propio monitor tener alguna tabla configurada.
Supongamos que todas las tablas están vacias.



Si recordamos la manera de acceder a tablas a través de snmp era expecificando el OID
acabado por columna.indice, pero, ¿Sí no existen índices?, muy fácil, cuando quiera
añadir entradas, basta con que elijas un índice, y lo escribes

Por ejemplo:

snmpset -v2c -c comunity 192.168.35.2 mib-2.16.1.1.1.21.1 i 2

En este caso elegimos el índice 1 para configurar una entrada nueva en la tabla de
STATISTICS (mib-2.16.1), le pasamos el OID de la tabla de estadísticas, acabado por el
índice que deseemos.

• OWNER: (1...127 B) es un dato que define el propietario del índice de una
determinada tabla, según el estandart debe contener al menor uno de los siguientes
campos:

Dirección IP,nombre stación de administración, nombre del administrador del sistema,
localización, o teléfono. Tan sólo es un modelo de información, por lo que podrás poner lo
que desees. En algunos casos el agente es el propietario de la fila, estos casos se indica
el propietario como monitor.

La primera tarea a realizar es conocer de que información disponemos en nuestro
dispositivo. Una vez conocidos estos ejemplos nos podemos disponer a crear filas a
nuestro antojo. Pero antes introduciré los grupos de RMON implementados en el CISCO.
Estos serán los grupos clásicos en cualquier dispositivo que nos provea de RMON.
Aunque no son los únicos, recuerda que son nueve grupos.

Grupo Statistics:(mib-2.16.1)

En este caso disponemos de una tabla,se trata de etherStatsTable (mib-16.1.1). Esta
tabla contiene una serie de estadísticas, referidas a paquetes, octetos, colisiones,... Para
configurar esta tabla basta con configurar el origen de los datos. Para ello se usa el objeto
etherStatsDataSource indicándole la interfaz desde la cual va a obtener los datos, desde

ese momento los objetos comienzan a tomar valores. Esa interfaz es la entrada ifInIndex
de la tabla interfaces de mib-2.

EtherStatsTable (mib-2.16.1):

etherStatsIndex (1) [RO i]: Indice de la fila en la tabla.



etherStatsDataSource (2)[RW o]: Origen de los datos. Referido a la entrada de ifIndex
de la tabla ifTable del grupo interfaces.

etherStatsDropEvents (3)[RO i]: Eventos en los cuales se descartan paquetes a causa
de falta de recursos.

etherStatsOctets (4) [RO i]: Número de octetos recibidos por la interfaz.

etherStatsPkts (5) [RO i]: Número de paquetes recibidos por la interfaz. (incluidos
incorrectos, broadcast o multicast).

etherStatsBroadcastPkts (6) [RO i]: Número de paquetes Broadcast recibidos por la
interfaz.

etherStatsMulticastPkts (7) [RO i]: Número de paquetes multicast recibidos por la
interfaz.

etherStatsCRCAlignErrors (8) [RO i]: Número de paquetes con tamaño correcto pero
con errores en el CRC o en el alineamiento.

etherStatsUndersizePkts (9) [RO i]: Número de paquetes buenos con tamaño menor a
64B.

etherStatsOversizePkts (10) [RO i]: Número de paquetes buenos con tamaño mayor a
1518.

etherStatsFragments (11) [RO i]: Número de paquetes erroneos menores de 64B.

etherStatsJabbers (12) [RO i]: Número de paquetes erroneos mayores de 1518.

etherStatsCollisions (13) [RO i]: Número de colisiones estimado.

etherStatsPkts64Octets (14) [RO i]: Paquetes de 64 octetos.

etherStatsPkts65to127Octets (15) [RO i]: Paquetes de 64 a 128.




etherStatsPkts1024to1518Octets (19) [RO i]: Paquetes de1024 a 1518.

etherStatsOwner (20) [RW s]: Propietario.

etherStatsStatus (21) [RW i]: Estado de la fila.



Grupo History: (mib-2.16.2.1)

Este grupo contiene dos tablas, una control y otra de datos. Para la configuración se
define la fuente de los datos a partir de la OID del objeto ifIndex de interfaces y configuras
los parámetros de la captura, automáticamente la sonda RMON irá rellenando la tabla de
datos del grupo (mib-2.16.2.2). Los parámetros son el número de muestras deseadas y el
intervalo de muestreo.

HistoryControlTable (mib-2.16.2.1) :

historyControlDataSource (2) [RW o]: el OID de un ifIndex.

HistoryControlBucketsRequested (3) [RW i]: nº muestras solicitadas

historyControlBucketsGranted (4) [RO i]: nº muestras concedidas.

HistoryControlInterval (5) [RW i]: intervalo en segundos de 1 a 3600

historyControlOwner (6) [RW s]: Cadena del propietario.

historyControlStatus (7) [RW i]: Estado de la fila.

Se puede ver que los objetos de la tabla etherHistoryTable son iguales que en los de la
tabla de estadísticas, salvo que tenemos dos índices en lugar de uno. Uno de ellos es el
índice de la tabla de control y el otro es un contador de la muestra. Indican el número de
muestreo.

Grupo Alarm (3): (mib-2.16.3).

Contiene una tabla de control para programar alarmas. A partir de una variable se define
unos intervalos a partir de los cuales si se que cruzan se genera una alarma. Por ejemplo,
si desearamos controlar si una interfaz se para (pasa su estado administrativo a down (2))
, debemos controlar el objeto, de la tabla de interfaces iftable, ifOperStatus. Si éste objeto
da como valor down (2), indica que la interfaz no está operativa. Por tanto, basta con
programar una alarma indicando como fuente de datos el OID del objeto ifOperStatus.
Además de configurar el resto de parámetros necesarios de la siguiente tabla.

AlarmTable (mib-2.16.3.1):



alarmIndex(1) [RO i]: índice de la tabla.

alarmInterval(2) [RW i]: intervalo de muestreo (segundos).

alarmVariable(3) [RW o]: OID de la variable de RMON MIB que se monitoriza, puede ser
(INTEGER, counter, gauge o TimeTicks).

alarmSampleType(4) [RW i]: el método de cálculo del valor que se compara con el
umbral, puede ser absoluto absoluteValue (1) o diferencial deltaValue(2).

alarmValue(5) [RO i]:valor de la variable en el último periodo de muestreo. A partir de
este valor se compara para saber si se ha cruzado el umbral.

alarmStartupAlarm (6) [RW i]: si se dispara por subida (1), bajada (2) o ambos(3).

alarmRisingThreshold (7) [RW i]: umbral para disparo de alarma por subida.

alarmFallingThreshold(8) [RW i]: umbral para disparo de alarma por bajada.

alarmRisingEventIndex(9)[RW i]/AlarmFallingEventIndex (10)[RW i] índice del evento
llamado cuando se cruza el umbral.

alarmOwner (11) [RW s].

alarmStatus (12). [RW i].

Grupo Event: (mib-2.16.9).

En esta ocasión tenemos dos tablas una de control y otra de datos. En la de control se
definen eventos. Como hemos visto en alarm se asociaban las alarmas con los eventos.
Cuando una alarma se dispara, si está asociada a un eventos se “lanzará” ese evento de
forma que generará un trap, escribirá la tabla log o ambas. También cabe la opción de no
realizar acción.

EventTable (mib-2.16.9.1):

eventIndex (1) [RO i]: índice.

EventDescription (2) [RW s]: descripción textual.

EventType(3) [RW i]: none (1), log (2), snmp-trap (3),log and trap (4).

eventCommunity (4) [RW s]: comunidad para la trap.



eventLastTimeSent (5)[RO i]: valor de SysUpTime cuando se generó el último evento.

eventOwner (6)[RW s].

eventStatus (7)[RW i].

logTable (mib-2.18.9.2):

logEventIndex (1) [RO i]: evento que generó esta anotación.

LogIndex (2) [RO i]: número de esta anotación (de entre todas las anotaciones del mismo
evento).

LogTime (3) [RO i]: valor de SysUpTime cuando se realizó la anotación.

LogDescription (4) [RO s]: descripción de la anotación (dependiente de la
implementación).

AREAS DE LA ADMINISTRACIÓN DE LA ISO Y NUESTRO PROBLEMA.

Desde este momento ya podríamos utilizar este conocimiento para tomar estadísticas de
las interfaces del switch, podríamos programar alarmas asociados a eventos. De esta
manera podemos tener un control de nuestra red.

Estas son las areas de gestión definidas por la ISO, por las que voy a definir una serie de
alarmas, por supuesto se podrán configurar más.

Fallos:

Contabilidad.

Gestión de configuración.

Gestión de prestaciones.

Gestión de seguridad.



FALLOS:

Esta es la que considero más importante dentro de las areas de gestión, en relación a mi
documento. Es decir, si deseo programar alarmas por ciertos eventos para mantener el
estado correcto de mi red, controlar que estos valores se mantengan en valores dentro de
un umbral de seguridad me permite que la propia red me avise que pueden suceder fallos
o que han sucedido y necesita de mi ayuda. Estos son objetos de la MIB succeptibles de
ayudarme en mi labor.

IfAdminStstus

Valores posibles:

up(1). Estado administrativo activo.

Down(2), Estado administrativo inactivo.

Testing(3). Testeando.

Estos valores nos sirven como umbrales. Indicando si el estado operacional sube de 2
indica que no esta operacional si baja de 1 indica que se ha subido la interfaz.

IfOperStatus.

De igual manera , este objeto nos indica el estado operativo de la interfaz, este objeto es
el más intuitivo a la hora de realizar una alarma. Podemos ver que este objeto nos indica
si esa interfaz esta operativa o no lo está. Si una tarjeto de red falla, se desconecta o en
resumen, le sucede algo, entonces el estado operativo pasará a down.

ifInDiscards:

Paquetes descartados por la interfaz, si el número de paquetes descartados comienza a
subir mucho es una muestra de error. Si la alarma asociada a esta variable se activa,
como administradores deberíamos investigar el origen. Podríamos hacerlo a través de la
consulta de valores de ciertas variables de la MIB. Pero lo importante es que hemos sido
avisados de la incidencia.

IfInErrors:



Paquetes con error. De igual manera que antes.

IfOutQLen:

Según el RFC 1213 esta como mandatory aunque en RFC´s posteriores pasa a
deprecated. Indica la longitud de la cola de paquetes, si el tamaño aumenta puede indicar
problemas en la interfaz o sobrecarga.

ipInHdrErrors:

Paquetes descartados debidos a errores en la cabecera(TTL excedido, error de version,
error de checksum, etc) Un aumento de estos podría indicar problemas en el cableado
como puede ser una fuente de interferencias.

ipInAddrErrors:

Paquetes descartados debido a que la direccion IP no es correcta para la interfaz
(Direcciones incorrectas como 0.0.0.0, direcciones de clase E, ... Para dispositivos que no
son pasarelas se incluyen los paquetes descartados cuya direccion no es local.

IpInDiscards:

Paquetes descartados, pero de los cuales no se conocen errores. Por ejemplo, debido a
que se ha llenado el buffer.

IpReasmFails:

Número errores encontrados por el algoritmo de reensamblado. (time out, errores, ...)

ipFragFails:

Número de paquetes descartados por que tenían que haber sido fragmentados pero no lo
han sido por que el flag de no fragmentar estaba activo.

IpRoutingDiscards:

Número de entradas de enrutamiento que han sido eliminadas, aunque eran correctas.
Una posible razón es ahorrar recursos liberando el buffer para nuevas rutas.

IcmpInErrrors:

Número de paquetes ICMP recibidos con error.

icmpInTimeExcds:

icmpInParmProbs:



Número de paquetes ICMP del tipo Parameter Problem.

IcmpInSrcQuenchs:

Son mensajes ICMP que nos pueden indicar que una entidad tiene congestión.

tcpInErrors:

El numero total de segmentos recibidos con error.

udpInErrors:

Numero de datagramas udp que no han podido ser enviados

etherStatsCRCAlignErrors:

Numero de paquetes con tamaño correcto pero con errores de CRC o de alineamiento.

EtherStatsFragments :

Número de paquetes erroneos menores de 64B.

etherStatsJabbers :

Número de paquetes erroneos mayores de 1518.

etherStatsCollisions:

Número de colisiones estimado.

CONTABILIDAD:

A la hora de crear alarmas en esta rama de la gestión se plantean dudas de su estricta
necesidad, para que vamos a querer crearlas a no ser que queramos crear unos límites o
un cliente nos establezca unos limites. Por ejemplo, nuestro cliente se conecta a traves
del Cisco y no dice que no quiere gastar más de cierta cantidad de euros o que sea
avisado de esta situacion, si le tarificamos por octetos o paquetes, o similar podemos
establecer una alarma que avise cuando se pase de una cantidad. Al ser un cliente en
concreto deberemos programar una alarma para un determinado interfaz por tanto nos
tenemos que olvidar de la red virtual y centrarnos en interfaces o estatistics aunque la
precisión no será muy alta al no contar los paquetes u octetos debidos a la gestion (por
ejemplo).Aunque para hacerle un aviso es suficiente.

GESTIÓN DE LA CONFIGURACION.

Buscamos objetos de configuración que sean de los permitidos por alarm. (Integer,



Counter, Gauge, TimeTicks).

Para este tipo de gestión parece más acertada la consulta selectiva a través de snmp, a
la hora de mantener el sistema al comprobar el log de event o al capturar traps debidos
ambos a alarmas debidos un número de errores en aumento o a fallos se comprobara los
parametros de configuración. Aunque se pueden mantener alarmas que adviertan del
cambio de algún parametro de configuración que pueda alterar el correcto funcionamiento
del sistema.

ifAdminStastus

tiempo desde que la interfaz pasó a operacional).

IfLastChange

IfInUnknownProtos:

Debido a que han llegado paquetes de protocolos no soportados.

IpInUnknownProtos :

Se han recibido correctamente pero se descartan por que son protocolos no soportados.

IpDefaultTTL.

IpOutNoRoutes:

El numero de paquetes que se han descartado al no encontrarse ruta para transmitirse.
Por ejemplo si su pasarelas está 201C;apagada201D;.

IcmpInDestUnreachs:

Paquetes icmp con el flag de destino inalcanzable.

tcpMaxConn:

Número total de conexiones tcp que puede la entidad soportar.

TcpRtoAlgorithm:

Algoritmos de enrutamiento:

• constant(2), a constant rto

• rsre(3), MIL-STD-1778, Appendix B

• vanj(4) algoritmo de Van Jacobson's



tcpRtoMin:

El tiempo minimo valor permitido para que se pida una retransmision.

TcpRtoMax:

SEGURIDAD:

En cambio, en la seguridad si son más necesarios controles que adviertan de peligros
potenciales. Para hacerse una idea:

por ejemplo, cuando se quiere atacar una red lo primero es conocerla correctamente,
para ello se puede empezar usando un traceroute (por supuesto solo para empezar).
Luego se realizara un scaner de puertos, hay varias técnicas como puede ser la conexión
a los puertos e ir comprobando si están abiertos o no. O mandando fragmentos de
paquetes (ya que así nos podríamos saltar la protección del firewall). Como vemos
maneras de comprobar si el sistema no está siendo investigado es controlar el trafico
ICMP, comprobando los mensajes de echo o las conexiones a la maquina.Aunque
cuando son semiabiertas no sé si quedará constancia del intento.

Una vez que el ataque es una realidad, si por ejemplo se usan ciertos tipos de DOS se
pueden detectar mediante una alarma en el número de mensajes ICMP de eco (de
entrada basta) (casos como el SMURF y el FRAGGLE) que usan ping con ip fuente falsa
y destino broadcast generando un trafico que crece cada vez mas y mas.

También podemos usar alarmas que nos indiquen que se esta rastreando el agente
SNMP. Para ello intentaran usar comunidades, lo normal es que empiecen con las típicas
public y private ya que en muchos dispositivos es la que viene por defecto y hay
administradores que no las cambian. Ese rastreo se puede detectar con alarmas en
snmpBadCommunityNames o con snmpBadCommuninityUses en este caso estan
usando una comunidad de lectura pa intentar escribir.

PRIMERAS CONFIGURACIONES:

Para ello usaremos SNMP, en concreto SNMPSET. Se puede usar el sistema operativo
del Cisco, el IOS.

Como primer ejemplo configuraremos el grupo estadísticas, de forma que lo definiremos
para la interfaz 1 del switch. Pero primero veremos el esqueleto básico del comando.
Conocido bien el resto será practicamente igual:

snmpset -v2c -c comunidad dirección IP mib-2.16.1.1.1.Objeto.Indice tipo valor



La comunidad se debe configurar antes de cualquier operación. Se configura a través
del IOS, conectándos al switch fisicamente a el puerto habilitado a este fin.
Posteriormente mediante una terminal y usando los comando del IOS configuramos una
comunidad de lectura y escritura para RMON.

La dirección IP del switch.

El objeto que queramos escribir.

El índice, de este ya hemos hablado antes, indica el índice de la fila que queramos crear
y podrá ser el que queramos mientras no esté creado o en proceso de creación, en este
caso no ,pasamos a creación (created request ) sino directamente a under Creation.

Tipo, Con esto especificamos de que tipo es el valor que vamos a escribir coincidiendo
con el tipo de la variable.

Valor, el valor de la variable.

snmpset -v1 -c com 192.200.2.2 mib-2.16.1.1.1.21.1 i 2

Hemos elegido la fila uno para configurar las estadísticas del host o subred conectado al
interfaz 1 del switch. No tenemos por que escoger el índice 1 para el interfaz 1 hay
libertad. Para ello empezamos por el objeto STATUS, pidiendo la creación de la fila.
Llegados a este punto ya tenemo la fila en UNDER CREATION.

snmpset -v1 -c com 192.200.2.2 mib-2.16.1.1.1.20.1 s “lc2”

Ahora definimos el propietario de la fila, si recordamos, el propietario es una cadena de 1
a 127 bytes en la cual ponemos lo que deseemos, pero se prefiere por el estandart que
se especifique al menos uno de los siguientes datos:

Dirección IP,nombre stación de administración, nombre del administrador del sistema,
localización, o teléfono. En nuestro ejemplo escribimos la localización del switch en el
Laboratorio de computación 2.

snmpset -v1 -c com 192.200.2.2 mib-2.16.1.1.1.2.1 o mib-2.2.2.1.1.1

Ahora hemos definido el origen de datos, para ello debemos especificar un ifNIndex de la
tabla de interfaces, mediante el OID. Llegados a este punto, tan sólo nos queda validar la
fila:


Una vez validada la tabla la sonda RMON comenzará a rellenar la tablas. Como hemos
visto, tomamos estadísticas de cada una de las interfaces del switch, sean lo que sean.
Ya que a ese puerto puede haber un host conectado directamente o una subred. Un



puerto, digamos, especial del Cisco Catalist 2950 es el 26. En este puerto hay una VLAN.
Es decir tenemos una red virtual.

Si tenemos 24 host conectados al switch y queremos tomar estadísticas de la red no
podríamos, pero si tomamos las estadísticas del puerto 26 la cosa cambia. Es más, el
Cisco sólo dispone hasta el nivel de enlace de datos, PERO en la VLAN, como es una
emulación software de red, en este caso disponemos de todos los grupos de la MIB-II.
Esto lo tomaremos en cuenta a la hora de definir alarmas.

EJEMPLO DE ALARMA.

La forma de proceder es similar, la idea de status, owner, índice, IP, todo, se mantiene
igual. La manera de proceder será ver qué objetos son de escritura, ver que significan y
escribir los valores necesarios. Claro está, primero deberemos pensar en una alarma.
Prodremos pensar por ejemplo, en que los paquetes descartados, de salida, por la
interfaz en los últimos 5 minutos no sea mayor de 10. Es tán sólo un ejemplo, lo normal
es que no se descarten, pero deberemos ver como se comporta la red, cuantos se
descartan en 5 minutos, y ver si 10 es un umbral, digamos, peligroso. Vamos a suponer
que lo es.

Como sabemos, cuando un umbral es sobrepasado salta la alarma, pero para que genere
una acción debemos asignarla mediante la tabla Event, en Event especificaremos que
sucede cuando una alarma asociado a una entrada event salta. Por lo que primero
defino el evento:


Pasamos a creación el índice 1 de la tabla eventTable que será el evento asociado a la
alarma que he comentado antes.

snmpset -v1 -c com 192.200.2.2 mib-2.16.1.1.1.6.1 s alejandro

Le asocio un propietario al índice.

snmpset -v1 -c com 192.200.2.2 mib-2.16.1.1.1.2.1 s “paquetes descartados mayores
de 10”

Le damos una descripción textual.


Esta evento generará un log, lo que equivale a que se generará una fila en la tabla
logTable cuando la alarma salté.


Valido la fila.



Una vez creado el evento crearé la alarma y la asociaré a este evento.


Paso la fila a creación.

snmpset -v1 -c com 192.200.2.2 mib-2.16.3.1.1.11.1 s Alejandro

establezco el propietario.


Especifico que tome muestras cada 5 minutos.

snmpset -v1 -c com 192.200.2.2 mib-2.16.3.1.1.3.1 o mib-2.2.2.1.13.1

Le asocio a ifInDiscards mediante el OID.


Indico que es por valor incremental, de esta manera veo como cambia en el tiempo.


Le digo que es de subida.


Establezco el umbral a 10.


LA ASOCIO AL INDICE DE LA TABLA DE EVENTOS, QUE ES EL EVENTO QUE HE
CREADO PREVIAMENTE.


Valido la fila.

Como vemos es sencillo, es más, diría que es mecanico. La creación de alarmas será
siempre igual, cambiando umbrales, tiempo de muestreo, tipo de muestreo y el evento al
que la asocio. Digamos que la configuración es cortar y pegar.

SCRIPTS.

Como he dicho la programación es muy mecanica, lo que sugiere que un script será



nuestra herramienta idonea y además de muy fácil programación, con pocos
conociemientos y pocas lineas tendremos scripts que nos harán la tarea
automáticamente. He usado Bash de UNIX para la realización. Este ejemplo es muy
básico. Conforme avanza va pidiendo los datos necesarios para crear el comando y lo
envía. Este ejemplo crea un evento en el índice que le digas.

#!/bin/bash
echo PRIMERO CREAREMOS EL EVENTO
echo Introduce el indice
read INDICE
snmpset -v2c -c arc01 192.200.2.2 mib-2.16.9.1.1.7.$INDICE i 2
echo Introduce el propietario
read OWNER
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.9.1.1.6.$INDICE s "$OWNER"
echo Introduce una descripcion textual
read DESC
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.9.1.1.2.$INDICE s $DESC
echo Introduce el tipo de evento que generara 1 NONE,2 log,3 trap,4 log y trap
read TIPO
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.9.1.1.3.$INDICE i $TIPO
echo Introduce la comunidad de la trap si es necesaria
read COM
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.9.1.1.4.$INDICE s $COM
echo CERRANDO FILA....
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.9.1.1.7.$INDICE i 1

Este otro crea una alarma con los parámetros que le especifiques:

NOTA: la opción -m RMON-MIB carga la MIB de RMON de forma que podrás introducir
los nombres textuales. Para un get o un walk la opción es muy visual, pero para un set y
especificar un OID recomiento el OID numérico ya que el OID textual será muy largo.

#!/bin/bash
echo Introduce el indice de la tabla
read INDICE
echo Introduce el propietario
read PROP
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.3.1.1.11.$INDICE s "$PROP"
echo Introduce el intervalo de tiempo en que se muestrea
read TIME
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.3.1.1.2.$INDICE i $TIME
echo Introduce la variable a controlar
read VAR
snmpset -m RMON-MIB -v1 -c arc01 192.200.2.2 mib-2.16.3.1.1.3.$INDICE o $VAR
echo Introduce la forma de muestreo 1 absoluto 2 incremental
read TYPE
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.3.1.1.4.$INDICE i $TYPE



echo Introduce cuando salta la alarma
read START
case $START in
1) snmpset -v1 -c arc01 192.200.2.2 mib-2.16.3.1.1.6.$INDICE i $START
echo Introduce el umbral de subida
read UMBRAL
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.3.1.1.7.$INDICE i $UMBRAL
echo Introduce el indice del evento
read IND
snmpset -v2c -c arc01 192.200.2.2 mib-2.16.3.1.1.9.$INDICE i $IND;;
echo Introduce el umbral de bajada
read UMBRALBAJ

snmpset -v1 -c arc01 192.200.2.2 mib-2.16.3.1.1.8.$INDICE i $UMBRALBAJ
read INDB
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.3.1.1.10.$INDICE i $INDB;;
echo Introduce el umbral de subida
read UMBRAL
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.3.1.1.7.$INDICE i $UMBRAL
echo Introduce el umbral de bajada
read UMBRALBAJ
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.3.1.1.8.$INDICE i $UMBRALBAJ
read IND
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.3.1.1.9.$INDICE i $IND
read INDB
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.3.1.1.10.$INDICE i $INDB;;

esac
echo Grabando fila....

Este otro Script es para la creación de filas en la tabla de estadísticas:

#!/bin/bash
echo Introduce el indice
read INDICE
echo Introduce el propietario de la fila
read PRO
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.1.1.1.20.$INDICE s $PRO
echo Introduce el interfaz de origen de datos
read ORI
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.1.1.1.2.$INDICE o $ORI




Y éste otro para la creación de entradas en la tabla de History:

#!/bin/bash
echo Introduce el INDICE
read INDICE
snmpset -v2c -c arc01 192.200.2.2 mib-2.16.2.1.1.7.$INDICE i 2
echo Introduce el OWNER
read OWNER
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.2.1.1.6.$INDICE s "$OWNER"
echo Introduce el origen de datos
read ORIGEN
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.2.1.1.2.$INDICE o $ORIGEN
echo introduce el numero de muestras
read MUESTRAS
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.2.1.1.3.$INDICE i $MUESTRAS
echo Introduce el intervalo de tiempo.
read TIEMPO
snmpset -v1 -c arc01 192.200.2.2 mib-2.16.2.1.1.5.$INDICE i $TIEMPO

Este otro es un ejemplo, ya NO de RMON, en el cual usamos las variables de

iso.org.dod.internet.private.enterprises .cisco

En este obtenemos el estado del Cisco, su CPU, memoria, Buffers y una pequeña
descripción del dispositivo. Este es interesante, podemos arrancarlo y ver como responde
cuando se le comienza a realizar acciones que aumente el tráfico de la red. Se trata de
un bucle infinito que realiza peticiones a las variables necesarias:

#!/bin/bash
i=0
for ((i=0;i<1;i++))
do

clear
echo Dispositivo: `snmpwalk -Ov -v1 -c public 192.200.2.2 .1.3.6.1.4.1.9.2.1.3.0 | cut -d " "
-f 2`
echo info rom id: `snmpwalk -Ov -v1 -c public 192.200.2.2 .1.3.6.1.4.1.9.2.1.1.0 | cut -d " "
-f 2`
echo info Config name: `snmpwalk -Ov -v1 -c public 192.200.2.2 .1.3.6.1.4.1.9.2.1.49.0 |
cut -d " " -f 2`
echo info Config address: `snmpwalk -Ov -v1 -c public 192.200.2.2 .1.3.6.1.4.1.9.2.1.48.0
| cut -d " " -f 2`
echo info nombre de la imagen: `snmpwalk -Ov -v1 -c public 192.200.2.2 .
1.3.6.1.4.1.9.2.1.73.0 | cut -d " " -f 2`



echo info Contact: `snmpwalk -Ov -v1 -c public 192.200.2.2 .1.3.6.1.4.1.9.2.1.61.0 | cut -d
" " -f 2`
echo Numero general de buffers LIBRES: `snmpwalk -Ov -v1 -c public 192.200.2.2 .
1.3.6.1.4.1.9.2.1.9.0 | cut -d " " -f 2`
echo Numero general de buffers MX: `snmpwalk -Ov -v1 -c public 192.200.2.2 .
1.3.6.1.4.1.9.2.1.10.0 | cut -d " " -f 2`
echo Numero general de buffers hit: `snmpwalk -Ov -v1 -c public 192.200.2.2 .
1.3.6.1.4.1.9.2.1.11.0 | cut -d " " -f 2`
echo Numero general de buffers miss: `snmpwalk -Ov -v1 -c public 192.200.2.2 .
1.3.6.1.4.1.9.2.1.12.0 | cut -d " " -f 2`
echo Numero general de buffers Creados: `snmpwalk -Ov -v1 -c public 192.200.2.2 .
1.3.6.1.4.1.9.2.1.13.0 | cut -d " " -f 2`
echo Porcenteje uso de CPU 5s %: `snmpwalk -Ov -v1 -c public 192.200.2.2 .
1.3.6.1.4.1.9.2.1.56.0 | cut -d " " -f 2`
echo Porcenteje uso de CPU 1m %: `snmpwalk -Ov -v1 -c public 192.200.2.2 .
1.3.6.1.4.1.9.2.1.57.0 | cut -d " " -f 2`
echo Porcenteje uso de CPU 5m %: `snmpwalk -Ov -v1 -c public 192.200.2.2 .
1.3.6.1.4.1.9.2.1.58.0 | cut -d " " -f 2`

SMALL=`snmpwalk -Ov -v1 -c public 192.200.2.2 .1.3.6.1.4.1.9.2.1.14.0 | cut -d " " -f 2`
total=`snmpwalk -Ov -v1 -c public 192.200.2.2 .1.3.6.1.4.1.9.2.1.15.0 | cut -d " " -f 2`
Libres=`snmpwalk -Ov -v1 -c public 192.200.2.2 .1.3.6.1.4.1.9.2.1.16.0 | cut -d " " -f 2`
Maximos=`snmpwalk -Ov -v1 -c public 192.200.2.2 .1.3.6.1.4.1.9.2.1.17.0 | cut -d " " -f 2`
hits=`snmpwalk -Ov -v1 -c public 192.200.2.2 .1.3.6.1.4.1.9.2.1.18.0 | cut -d " " -f 2`
miss=`snmpwalk -Ov -v1 -c public 192.200.2.2 .1.3.6.1.4.1.9.2.1.19.0 | cut -d " " -f 2`
create=`snmpwalk -Ov -v1 -c public 192.200.2.2 .1.3.6.1.4.1.9.2.1.21.0 | cut -d " " -f 2`
echo SMALL Tamaño $SMALL Total $total Libres $Libres Max numero $Maximos Hits
$hits Miss $miss Creados $create

echo Medio Tamaño $SMALL Total $total Libres $Libres Max numero $Maximos Hits

echo BIG: Tamaño $SMALL Total $total Libres $Libres Max numero $Maximos Hits $hits
Miss $miss Creados $create




echo Largo Tamaño $SMALL Total $total Libres $Libres Max numero $Maximos Hits $hits
Miss $miss Creados $create

echo Huge: Tamaño $SMALL Total $total Libres $Libres Max numero $Maximos Hits
echo Name `snmpwalk -v2c -c arc02 192.200.2.2 SNMPv2-SMI::enterprises.9.9.48.1.1.1.2
| cut -d "=" -f 2 |cut -d : -f 2`
echo Pool alternate `snmpwalk -v2c -c arc02 192.200.2.2 SNMPv2-
SMI::enterprises.9.9.48.1.1.1.3| cut -d "=" -f 2|cut -d : -f 2`
echo Pool valid `snmpwalk -v2c -c arc02 192.200.2.2 SNMPv2-
SMI::enterprises.9.9.48.1.1.1.4| cut -d "=" -f 2|
cut -d : -f 2`
echo Pool used `snmpwalk -v2c -c arc02 192.200.2.2 SNMPv2-
echo Pool free `snmpwalk -v2c -c arc02 192.200.2.2 SNMPv2-
echo Pool Lar free `snmpwalk -v2c -c arc02 192.200.2.2 SNMPv2
sleep 60
#Duerme un minuto.
done


Smtp 2950

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (6)

Similar a Smtp 2950

Similar a Smtp 2950 (20)

Más de 1 2d

Más de 1 2d (20)

Último

Último (20)

Smtp 2950