TESIS

PONTIFICIA UNIVERSIDAD CATOLICA DE VALPARAISO CHILE
ESCUELA DE INGENIERIA ELECTRICA
ESTUDIO E IMPLEMENTACION DE ADMINISTRACION

DE REDES DE AREA LOCAL BAJO EL
PROTOCOLO SNMPv3
SERGIO JAVIER MONTIEL ESPINOSA
INFORME FINAL DEL PROYECTO

PRESENTADO EN CUMPLIMIENTO
DE LOS REQUISITOS PARA OPTAR
AL TITULO PROFESIONAL DE
INGENIERO CIVIL ELECTRONICO
Julio 2009
ESTUDIO E IMPLEMENTACION DE ADMINISTRACION

DE REDES DE AREA LOCAL BAJO EL
PROTOCOLO SNMPv3
INFORME FINAL
Presentado en cumplimiento de los requisitos

para optar al ttulo profesional de
Ingeniero Civil Electrnico
otorgado por la
Escuela de Ingeniera Elctrica
de la
Pontificia Universidad Catlica de Valparaso
Sergio Javier Montiel Espinosa
Profesor Gua
Profesor Correferente
Sr. Francisco Alonso

Sr. David Velasco
Julio 2009
ACTA DE APROBACION
La Comisin Calificadora designada por la Escuela de Ingeniera Elctrica
ha aprobado el texto del Informe Final del Proyecto de Titulacin,
desarrollado entre el ......... semestre de ...... y el ...... semestre de ........, y
denominado
ESTUDIO E IMPLEMENTACION DE ADMINISTRACION DE
REDES DE AREA LOCAL BAJO EL
PROTOCOLO SNMPv3
Presentado por el Seor

Francisco Alonso
Profesor Gua
Segundo Revisor
Secretario Acadmico
Valparaiso, Julio 2009
Agradesco a toda mi familia,

novia, y profesores el haber
estado
en
durante
mi
todo
paso
momento
por
la
Universidad.
Especial agradecimiento a mi
Abuela que desde los cielos
mira
meta.
este
cumplimiento
de
ESTUDIO E IMPLEMENTACION DE ADMINISTRACION DE

REDES DE AREA LOCAL BAJO EL
PROTOCOLO SNMPv3

Profesor Gua Sr. Francisco Alonso
RESUMEN
La esencia de este Proyecto de Titulo est en la Administracin de Redes
de Area Local, al igual que en las grandes empresas del mundo, las redes de
datos tienen que ser administradas para poder tener un control y supervision del
comportamiento de estas cuando ocurre cierto evento que se escape del normal
funcionamiento, como extremados consumos de ancho de banda, equipos
comportandose de forma no deseada, entre muchas cosas ms.
Para poder tener un sistema de administracion de red, es necesario contar
con varias areas funcionales trabajando en armonia, una de esas areas
funcionales es la de Gestion de Fallas, que recoge e informa lo que ocurre en
una red de datos, todo evento producido es analizado y tratado por la Gestion de
Fallas.
Para poder implementar la Gestion de Fallas, es necesario utilizar un
protocolo de administracion de red, que sea estandar, eficiente y que permita
recoger toda la informacion posible de la red. Este protocolo es el estandar ms
utilizado en la actualidad para la administracion, SNMP (Protocolo simple de
administracion de red). En este proyecto se utilizara especificamente la ultima
version estandarizada del protocolo, la version SNMPv3.
Un buen sistema de administracion de red, y por ende un buen sistema de
Gestion de Fallas, es fundamental en las empresas de telecomunicaciones para
poder optar a certicifaciones ISO de calidad.
INDICE
Pag.
INTRODUCCION
CAPITULO 1
OBJETIVOS DEL PROYECTO
1.1
OBJETIVOS
1.1.2
Objetivos generales
1.1.3
Objetivos Particulares
1.1.4
Relevancia del Proyecto Titulo.
CAPITULO 2
PROTOCOLOS DE ADMINISTRACION DE REDES
2.1
PROTOCOLOS DE ADMINISTRACION DE RED
2.1.1
Protocolo de Administracion de Red SNMP
2.1.2
Que puede hacer SNMP? REDES WIFI.ATM..MPLS.ETC
2.1.3
Estructura de funcionamiento de SNMP
2.1.4
Bases de Informacion y Objetos Identificadores
2.1.5
Principales ventajas SNMP
CAPITULO 3
SNMPv3, ADMINISTRACION Y PROTECCION
3.1
SNMPv3, LA VERSION PARA ADMINISTRACIN
3.1.1
Capacidad en seguridad que cubre SNMPv3
3.2
ARQUITECTURA ENTIDADES SNMPv3
3.2.1
Modularidad
3.2.1.1
Modulo Motor SNMPv3
3.2.1.2
Modulo Aplicacin SNMPv3
3.3
ESTRUCTURA MENSAJE SNMPv3
3.3.1
Seccion msgGlobalData
3.3.2
Seccion msgSecurityParameters
3.3.3
Seccion PDU header y PDU SNMPv2
3.4
ARQUITECTURA ENTIDAD GESTOR
3.5
ARQUITECTURA ENTIDAD AGENTE
CAPITULO 4
PROCESO DE GESTION DE FALLAS
4.1
PROCESO Y PROCEDIMIENTOS DE ALARMAS
4.2
CLASIFICACION DE ALARMAS
4.2.1
Clasificacion por tipo de Alarma
4.2.2
Clasificacion por severidad de la Alarma
4.3
PROCESO DE LOCALIZACION DE FALLAS
4.4
PROCESO DE PRUEBAS DE DIAGNOSTICO
4.5
PROCESO DE CORRECCIN DE FALLAS
4.6
PROCESO DE ADMINISTRACION DE REPORTES
4.7
MANTENIBILIDAD Y DISPONIBILIDAD
CAPITULO 5
IMPLEMENTACION: IDENTIFICACION DE VARIABLES
5.1
VARIABLES DE FALLAS
5.2
INDICADORES
5.2.1
Fase de Medicion.
CAPITULO 6
IMPLEMENTACION: SOFTWARE Y HARDWARE UTILIZADO
6.1
SOFTWARE
6.1.1
Catastro de Software
6.2
HARDWARE
6.2.1
Catastro de Hardware
CAPITULO 7
PRIMERAS PRUEBAS: FUNCIONAMIENTO SNMPv1, v2
7.1
ESCENARIO DE RED
7.1.1
Red Ethernet con enlaces Serial (WAN)
7.1.2
Enrutamiento Dinmico
7.1.3
Determinacin de Direcciones IP
7.2
CONFIGURACION SNMPv1 Y v2c
7.3
PRUEBAS DE FUNCIONAMIENTO
7.3.1
Descubriemiento de Topologias de Red
7.3.2
Visor de Objetos Consultados
CAPITULO 8
SEGUNDAS PRUEBAS: FUNCIONAMIENTO SNMPv3
8.1
CONFIGURACION SNMPv3
8.2
COMANDOS Y SCRIPT CREADOS PARA SNMPv3
8.2.1
Script Pruebas de Nivel de Seguridad
8.2.2
Script Pruebas de Privacidad
8.2.3
Script de Analisis Preventivo
8.2.4
Script de Testeo de un Equipos
8.2.5
Comando de Escritura en MIB
8.3
RESULTADOS DE PRUEBAS SNMPv3
8.3.1
Scripts Generados
8.3.1.1 Script Prueba de Nivel de Seguridad

8.3.1.2 Script Prueba de Privacidad
8.3.1.3 Script Anlisis Preventivo
8.3.1.4 Script Testeo de un Equipo
8.3.1.5 Comando de Escritura en MIB
CONCLUSIONES
REFERENCIAS BIBLIOGRAFICAS
BIBLIOGRAFA.
APENDICE A
Configuracion equipos Cisco
APENDICE B
Instalacion y Configuracion Zenoss-Core.
APENDICE C
Fotografias Centro de Operaciones de Red montado en el Laboratorio
GLOSARIO DE TERMINOS
ITIL
:Librera de Infractustura de Tecnologia de la Informacion
ITU
: Union internacional de Telecomunicaciones
ISO
: Estandar Organizacional Internacional
SLA
: Acuerdos de Nivel de Servicio
OLA
: Acuerdode Nivel de servicio entre departamentos de una Empresa
UDP
: Protocolo de transporte basado en datagramas
PDU
: Unidad de datos de Protocolo
Script
: Pequeo programa ejecutado desde linea de comandos
SNMP
: Protocolo simple de administracion de redes
MIB
: Base de infirmacion para la administracion
SMI
: Estructura en forma de ramificacion
NOC
: Centro de Operaciones de Red
NMS
: Sistema de administracion de redes (software)
EMS
: Sistema de administracion de Eventos, normalmente incluido en el

NMS.
TRAP
: Mensaje de alerta enviado desde el agente cuando alguna

medicion no respeta los valores predefinidos por el fabricante.
INFORM : Mensaje de alerta al igual que el Trap, pero este necesita de ser
respondido por parte del administrador.
RFC
: Solicitud de comentarios por parte de la comunidad a publicaciones

de la IETF
LISTADO DE FIGURAS
Figuras
Figura 1.- Entes participes en SNMP
Figura 2.- Estructura de un OID
Figura 3.- MIB-II y sus grupos de varibles.
Figura 4.- Juego de peticin y respuestas entre agentes y gestor
Figura 5.- Mecanismo de Proteccion SNMPv3
Figura 6.- Arquitectura Entidad Gestor
Figura 7.- Arquitectura Entidad Agente
Figura 8.- Vista General Estructura Mensaje SNMPv3
Figura 9.- Flags de seguridad
Figura 10.- Topologia de Red de Pruebas SNMPv3
Figura 11.- Topologia de Red Descubierta
Figura 12.- Pantalla principal del Administrador
Figura 13.- Trfico por las Interfaces de un dispositivo de Red
Figura 14.- Historiales de Procesos, Memoria y CPU
Figura 15.- Eventos y Reportes generados en una red Administrada
Figura 16.- Comandos de Administracion creados
Figura 17.- Resultado de un cambio de informacion por comando SET.
Figura 18. Respuesta en consola del Router ante una modificacion. Se
indica Configuracion from 192.168.1.2 (administrador) by snmp
Figura 19.- Valor de la Temperatura de la CPU en grados Celcius
Figura 20.- Valor de la Temperatura Umbral de operacin de la CPU.
Figura B-1.- Instalacion de zenpack
Figura B-2.- Gestor de Instalacion
Figura B-3.- Gestor de Instalcion completa
Figura C-1.- Centro de Operaciones de Red montado
Figura C-2.- Consola de Topologia de Red
Figura C-3.- Consola de Gestion de Eventos
Figura C-4.- Consola de Depuracion de Router y Reportes del Sistema
de Gestion
Figura C-5.- Consola de Pruebas de Script SNMPv3
Pag.
INTRODUCCION
Este Proyecto prentende cubrir una de las areas menos atendida en la

actualidad de las redes en Chile, la Administracion de Redes.
Contar con un sistema de administracion de redes, en la actualidad es de
vital importancia en las empresas de telecomunicaciones, ya que estas, deben
cumplir con su mision de mantener 24 horas al dia, 7 dias a la semana y 365
dias al ao, los servicios que ofrece a sus clientes, para las empresas que no
sean del rubro de las telecomunicaciones, igualmente deben tener un sistemas
de administracion para poder cumplir con las metas corporativas, ya sea en
cumplimientos de procesos en empresas manufactureras o en un sistema
confiable por donde transmitir informacion de importante valor como las
empresas de contabilidad y auditorias.
La administracion de red es un area extensa, en este proyecto se
mencionan las FCAPS que son las areas funcionales y estandares de la
administracion, tambien se menciona el enfoque ITIL como las buenas practicas
a seguir por una empresa de telecomunicaciones para poder lograr alguna
certificacion ISO de calidad como por ejemplo ISO/IEC 20000.
Como resultado, se tiene que estableciendo una buen proceso de Gestion
de Fallas mediante SNMPv3, da la oportunidad a empresas del rubro de las
telecomunicaciones a brindar un buen servicio y poder garantizar as sus SLA
con los clientes. En cuanto a las empresas que no tengan relacion con las
telecomunicaciones un buen sistema de Gestion de Fallas, permitiria el cumplir
con parte de los OLA entre las areas de la empresa.
La utilizacion de SNMPv3, que es la ultima version estanderizada de
snmp, es por la razon de poner a prueba sus nuevas caracteristicas, que es la
seguridad y su modularidad para poder interoperar con las versiones anteriores.
Para tal efecto se montar en el laboratorio de redes de la Pontificia

Universidad Catolica de Valparaido, una red de pruebas, en donde se montara
en un sector de esta red , un Centro de Operaciones de Red (NOC) [01], el cual
tendra sera parte fundamental de la mision de hacer las pruebas de
comprobacion de seguridad, de niveles de privacidad, de escritura en las MIB[02]
remotas, y de script de mantencion y testeo de equipos de red.
Para poder montar un Centro de Operaciones de Red, fue necesario
decidir si este seria centralizado o distribuido, debido a que en la empresa de
telecomunicaciones la gran parte de los centros de operaciones es distribuido, se
escoge esta forma.
Para completar el Centro de Operaciones de Red, es necesario montar el
sistema computacional que permita tener un sistema distribuido y que a la vez
sea totalmente editable para poder realizar las pruebas de SNMPv3
mencionadas en el parrafo anterior, dicho sistema es Zenoss-Core, un sistema
open-source el cual es montado en una plataforma GNU/Linux especificamente
Debian Lenny 5.0 (version estable).
CAPITULO 1
OBJETIVOS DEL PROYECTO
1.1
OBJETIVOS GENERALES
El objetivo general es investigar, estudiar, entender, comprender y aplicar
el protocolo SNMPv3 a la administracion de red en una red de pruebas, pasando

por el estudio de protocolos hasta el estudio de las buenas practicas y
recomendaciones para un optimo proceso de gestion de fallas.
1.2
OBJETIVOS PARTICULARES
Estudio de la ultima version de el protocolo de administracion de red,
especificamente SNMPv3.
Estudio de las buenas practicas y recomendaciones para un sistema de
Administracion de red, con un enfoque a las gestion de fallas.
Implementacion de SNMPv3 en una red de pruebas, utilizando equipos de
red como router, switch, servidores, sistema de administracion distribuida.
RELEVANCIA DEL PROYECTO

La relevancia de este proyecto es dado por la necesidad actual de tener
poder de administracion sobre las redes de datos, dicha necedidad, se encuentra

en que los problemas producidos en una red pueden llegar a generar resultados
catastroficos en una empresa que hace uso de la red, asi perdiendo informacion,
clientes y netamente comunicacin entre los usuarios.
Como fue mencionado en los objetivos, la herramienta para lograr esta
administracion es la ultima version de snmp, SNMPv3, la cual produce un
impacto en el modo de administrar, ya que ahora la administracion es segura y
confidencial.
CAPITULO 1
1.1

Para la administracin de redes existen varios protocolos utilizados en la
industria de la telecomunicaciones, entre ellos se puede mencionar
CMOT
(CMIP1 sobre TCP/IP), y SNMP (Simple Network Management Protocol) [03].

a)
CMOT
Es un protocolo enfocado a las redes TCP/IP basado en su versin
anterior, orientada solo a las redes de telecomunicaciones, dicha base de CMOT

es el protocolo CMIP, el cual posee una estructura de configuracin demasiada
compleja y un alto uso de recursos de red para su correcto funcionamiento,
motivo de estos defectos, su masiva utilizacin se ha visto aplazada.
b)
SNMP
Uno de los protocolos ms utilizados en la administracion de redes IP en
la actualidad es SNMP (Simple Network Management Protocol), como su

nombre lo indica, es un protocolo simple, por lo cul la gran ventaja de este, es
su alta relacin en la facilidad de implementacin
versus informacin util
conseguida.
Debido al uso masivo de SNMP en la administracion de redes, segn
Network Computing un 68% de la totalidad usa SNMP, este proyecto se enfoca
plenamente en este protocolo.
CMIP, Protocolo Comn de Administracin de la Informacin, protocolo desarrollado pensando en

cubrir las debilidades de seguridad y fallas de SNMP.
1.1.1 Protocolo de Administracin de Red SNMP

El protocolo simple de administracn de red es un protocolo de la capa de
aplicacin del modelo OSI, este protocolo facilita el intercambio de informacion
entre dispositivos de red, lo que permite al administrador poder supervisar el
desempeo de la red, buscar y solucionar problemas, ademas de poder obtener
informacion de gran utilidad para una planificacin de crecimiento
1.1.2 Qu se puede hacer con SNMP?
En la actualidad, la principal funcin de SNMP es monitorear el estado de
los dispositivos pertenientes a una red IP. Al monitorear con SNMP los
dispositivos de una red, se puede obtener variables y parametros utiles, para asi
tener vigilancia del estado de una red.
Como parte de la gama de acciones que se podrian realizar utilizando
SNMP en una red IP, se pueden mencionar las siguientes:
Monitorear el estado de un enlace punto a punto para detectar cuando

est congestionado y tomar as medidas oportunas,
Configurar una impresora para que alerte al administrador cuando se ha

quedado sin papel,
Configurar un servidor para que enve una alerta cuando la carga de su

sistema incrementa significativamente,
Detectar la utilizacin del ancho de banda por parte de un usuario.
Identificar los cuellos de botella en una red IP.
Modificacar en forma remota la configuracin de dispositivos, como

cambiar direcciones IP de un ordenador a travs de su agente SNMP.
1.1.3 Estructura necesaria para el funcionamiento de SNMP

Este
protocolo
para
su
correcto
funcionamiento
necesita
de
componentes fundamentes, un Manager o Gestor[04] , un Agente[05] o

Informante y una MIB que es una base de datos que maneja el agente y que es
solicitada por el Gestor .(vease Figura 1)
Figura 1.- Entes participes en SNMP

1.1.4 Bases de Informacion y Objetos Identificadores.
Conocido como OID [06] es un identificador de objetos que se usa para
poder tener la localizacin de las variables, se usara los objetos identificadores
que son administrados por la ISO.(vease Figura 2)
Figura 2.- Estructura de un OID.
En la base de informacion MIB-II[07] (RFC-1213), se agregaron ms

variables de gestin, se pas de 114 a 171 variables publicas[08], variables
publicas quiere decir que no son propiedad de ningn equipo o producto en
particular.
En este proyecto se har uso de la MIB-II (vease Figura 3) con soporte
para variables de sistema interfaces, protocolos TCP, RMON y
que son
administradas por ISO (Organizacin Internacional de Estandarizacin).
Figura 3.- MIB-II y sus grupos de varibles.

1.1.5 Principales Ventajas SNMP
Algunas ventajas de este protocolo son las siguientes:
Diseo simple, peticin-respuesta-accin.
Protocolo Orientado a data-grama, por lo que ocupa UDP como

mecanismo de transporte, lo que no necesita una conexin antes de la
operacin del protocolo.
Puede implementarse en cualquier dispositivo que tenga una direccin IP,

Impresoras, PDA, Notebook, etc.
No consume grandes recursos de red.
Se desenvuelve exitosamente ante condiciones adversas de la red.
Es fcil de comprender e implementar por los Programadores.
Es el ms utilizado en el mundo.
1.1.4 Estructura de funcionamiento SNMP.

Este protocolo usa un mtodo de interrogacin para hacer un barrido de
informacin de la red, solicita informacin a todos los agentes de la red (vease
Figura 4), pidindole los datos que este quiera y necesite para alguna accin en
particular.
Figura 4.- Juego de peticin y respuestas entre agentes y gestor
CAPITULO 3
SNMPv3, ADMINISTRACION Y PROTECCION
A cargo de IETF, Internet Engineering Task Force, ingenieros que velan

por que las arquitecturas y protocolos de red funcionen correctamente. Es este
grupo de ingenieros quien publica las RFC 2271-2275 ( Request For Comment)
que son notas tcnicas lanzadas al mundo con informacin especifica del
protocolo SNMP y las cuales estan sujetas a comentarios para futuras
revisiones.
La versin 3 de SNMP es el protocolo de administracin de redes del
futuro proximo, debido a la seguridad que este le d a la gestion de redes. Aun
no es masivamente ocupado debido a su relacion costo-beneficio, costosa
migracion a equipos que soporten esta versin, es por esto mismo que la
industria implementara esta versin a medida que este protocolo sea soportado
en los nuevos dispositivos de red como que en la industria como tal vayan
cambiando sus dispositivos ms viejos por estos nuevos con soporte SNMPv3.
3.1
SNMPv3, LA VERSION PARA LA ADMINISTRACION

Esta versin es presentada en 1998, buscando dar seguridad al protocolo
SNMP, luego de un flujo de realimentacion por parte de la comunidad mundial

dando recomendaciones en el 2002 esta versin es incluida como un estndar
ISO, constituyendo una importante mejora a sus dos versiones predecesoras y
no necesariamente un reemplazo de las mismas. Motivo por el cual esta nueva
versin queda bien determinada a partir de la expresin
SNMPv3 =SNMPv2 + Seguridad y Modularidad (3-1)
Por lo anterior, SNMPv3 no modifica las PDU's (Unidad de datos de
Protolos) de la versin SNMPv2c, es ms, esta versin
define una alta
operabilidad y compatibilidad con sus antiguas versiones (RFC 3416).
La alta operatividad y compatibilidad de SNMPv3 con sus versiones

anteriores es gracias a la modularidad de su arquitectura tanto en el Agente
como en el Gestor (administrador SNMP).
3.1.1 Capacidad de Seguridad que cubre SNMPv3
Segn el RFC 2571[10], que detalla la informacion del funcionamiento de
SNMPv3, el alcance de seguridad que puede cubrir esta ultima versin son las
siguientes:
a) Integridad del mensaje
b) Enmascaramiento
c) Modificacin en el flujo de mensajes
d) Revelacin
a)
Integridad del Mensaje: Asegura que el mensaje no ha sido violado
durante su trayectoria desde origen a destino, en ambas direcciones.

b)
Enmascaramiento: Determina si el mensaje proviene de una fuente valida
o no, brindando de esta manera una proteccin contra entidades no autorizadas

que asumen identidades de entes SNMP autorizadas para uso malicioso.
c)
Modificacin
flujo
Mensajes:
Protege
contra
repeticin,
retardos,
duplicacin, desorden de los mensajes lo que podra dar privilegios de

administracin a entidades no autorizadas.
d)
Revelacin: Una entidad puede observar los intercambios entre el Gestor
y el Agente y as aprender de estos mensajes, trap e informes (traps son

mensajes de alertas que enva un Agente cuando algun estado cambia o cuando
se supera algun umbral predefinido por el fabricante). Mediante encriptacin el
mensaje que pueda ser observado estar inentendible y altamente complejo de
traducir desincriptando.
Estas capacidades de seguridad le dan a esta versin la ventaja y la
oportunidad de activar sus comandos de instruccin Set (instruccin que
permite escribir en la MIB de equipos remotos), que es usada para re-configurar
dispositivos en la red, en las versiones anteriores esta instruccin era
desabilitada debido a la poca seguridad y por ende al temor de que alguna

persona
mal-intencionada
diera
ordenes
no
deseadas
perturbando
el
funcionamiento de la red e incluso robando informacin privilegiada.

El mecanismo de proteccion (vease Figura 5) esta demostrado en el
diguiente diagrama de flujos.
Figura 5.- Mecanismo de Proteccion SNMPv3
3.2
ARQUITECTURA ENTIDADES SNMPv3

Uno de los grandes cambios de esta version, en relacion a las anteriores,
es la estructura de funcionamiento, la cual es definida de forma modular.

3.2.1 Modularidad de SNMPv3
Se define una nueva estructura de funcionamiento de este protocolo, la
modularidad, esta estructura de funcionamiento tiene como fin lograr una mayor
eficiencia, flexibilidad y interoperatividad del protocolo para ambas entidades,
gestor y agente.
La modularidad esta definida con la diferenciacin de tareas dentro del
proceso de analisis de paquetes SNMP, tanto de entrada como de salida desde
un agente o un gestor, lo dos modulos principales dentro de cada agente y
gestor son el Motor SNMP y la Aplicacin SNMPv3.
3.2.1.1 Modulo Motor SNMPv3
Esta compuesto de 5 sub-sistemas, el PDU Dispatcher, Message
Dispatcher,
Message
Processing,
Security
SubSystem,
Access
Control
SubSystem, los cuales interaccionan entre s analizando el paquete SNMP

recepcionado o en proceso de envio. A continuacin un detalle de estos:
a)
PDU Dispatcher
Es el responsable de recibir las PDU desde el modulo aplicaciones y
prepararlas para su envio a la red, y viceversa. Envia las PDU provenientes

desde el modulo aplicaciones hacia el modulo Message Processing para que
sean preparados para su envo, recibir las PDU provenientes de la red y pasarlos
al modulo Message Processing para extraer su mensaje
a)
Message Processing
Es el sub-sistema encargado de preparar y extraer los datos de los
mensajes dependiendo de la versin en cuestin, ya sean paquetes de

SNMPv1,v2 o v3, este sub-sistema invoca al sub-sistema de seguridad USM[11]
(Modelo de Seguridad basado en Usuarios) para poder corroborar seguridad en

mensajes entrantes y para agregar cabeceras de seguridad a los mensajes que
saldrn a la red.
b)
Security SubSystem
Es el modulo encargado de velar por el cumplimientode los modelos de
seguridad, brindando los servicios de autentificacin y privacidad de los

mensajes, tanto para recepcion como para el emision de estos.
c)
Access Control SubSystem

Proporciona un conjunto de servicios de autorizacin para el chequeo de
acceso de los mensajes, generando vistas que pueden ser accedidas y

determinando quienes pueden acceder a estas.
3.2.1.2 Modulo Aplicacin SNMPv3
Este mdulo contiene los sub-sistemas necesarios para llevar a cabo el
papel de la administracin de las red, estos sub-sistemas son el Command
Generator, Notification Receiver, Command Responder, Notification Originator,
Proxy Forwarder los que se detallaran a continuacin.
a)
Command Generator
Modulo encargado de recibir las PDU SNMP Get, GetNext, GetBulk o
SetRequest y procesar una respuesta a la solicitud que ha sido generada

escarbando la informacin en las MIB`s correspondientes.
b)
Command Responder
Modulo encargado de recibir las PDU SNMP Get, GetNext, GetBulk o
SetRequest dirigidas al motor local, y una vez que son atendidas genera las
correspondientes respuestas.
c)
Notification Originator
Modulo encargado de monitorizar un sistema determinado, el cual tiene
definido un parmetro de condicin o evento en particular que genera un

mensaje Trap o Inform basado en estas condiciones o parmetros predefinidos
por el fabricante, este Originador de Notificaciones tiene un mecanismo para
saber a quien mandar este mensaje que versin ocupar y que seguridad dar.
d)
Receptor Notification
Este sub-sistema recibe los mensajes de notificacin del modulo anterior y
genera respuestas a los del tipo Inform y solo recepcion de los tipo Trap[12].
e)
Proxy Forwarder
Este es quien reenva mensajes SNMP, al momento que un equipo tiene
un protocolo interno de monitoreo SNMP, este proxy genera el lazo entre

protocolos distintos al estandar SNMP.
A continuacin se ilustraran estos mdulos, submdulos, subsistemas en
Agentes y Gestores correspondientemente, vease Figura 3.
3.2.2 Arquitectura Entidad Gestor
Un Gestor SNMP convencional esta conformado de un Despachador, un
Subsistema de Procesamiento de Mensajes, un Subsistema de Seguridad, y las
aplicaciones Generadoras de Comandos, de Notificaciones, y Receptora de
Notificaciones (vease Figura 6).
Figura 6.- Arquitectura Entidad Gestor
3.2.3 Arquitectura Entidad Agente

Un Agente SNMP convencional esta conformado de un Despachador, un
Subsistema de Procesamiento de Mensajes, un Subsistema de Seguridad, un
Subsistema de Control de Acceso y las aplicaciones Generadoras de
Notificaciones, Receptora de Comandos y Reenviador Proxy(vease Figura 7).
Figura 7.- Arquitectura Agente.
3.3
ESTRUCTURA MENSAJES SNMPv3

Para poder utilzar las nuevas caracteristas de modularidad, la estructura
del mensaje SNMPv3 sufre unas modificaciones en relacion a las versiones

anteriores, en esta ultima version en el mensaje se incluyen nuevos campos y
secciones importantes para la seguridad. Vista general de la nueva estructura
del mensaje SNMPv3 en Figura 8.
Figura 8.- Vista General Estructura Mensaje SNMPv3.

3.3.1 Seccion msgGlobalData
Los primeros cinco campos son los correspondientes a la seccin
msgGlobalData , esto son la cabecera del mensaje SNMPv3 los cuales son
introducidos por el modulo Message Processing del motor SNMPv3. En detalle la
Seccin msgGlobalData consiste de los campos:
a)
msgVersion: Ajuste para saber la versin del mensaje en cuestin,
SNMPv3 en este caso.

b)
msgID: Identificador nico entre dos entidades SNMP para si poder
coordinar los mensajes de solicitud y respuesta, el rango de ID va desde 0 a

2311 .
c)
msgMaxSize: Expresa el mximo tamao de un mensaje en octetos que
puede recibir una entidad de otras entidades el rango de este es de 484 a 2311
d)
msgFlag: Es el nivel de seguridad que contiene tres Flags en sus tres bit
menos significativos, estos Flags son: reportableFlag, privFlag y authFlag.

(vease Figura 9)
Figura 9.- Flags de seguridad.

Los siguientes niveles de seguridad son los permitidos por la combinacion
de estos ltimos tres bits (vase Tabla 3-1):
Tabla 3-1.- Nivel de Seguridad

e)
msgSecurityModel: Identificador que indica el modelo de seguridad que
fue usado por el remitente para preparar el mensaje y por ende el modelo de
seguridad a usar por el receptor del mensaje para procesar el mensaje, a
continuacin valores permitidos para este campo (vase Tabla 3-2).
Tabla 3-2.- Valores de Modelo de Seguridad Utilizado.
3.3.2 Seccin msgSecurityParameters

Los siguientes 6 campos del mensaje SNMPv3 corresponden a los
parmetros usados por el USM (Modelo de Seguridad basado en Usuarios).
Cuando un mensaje saliente es pasado desde el modulo de proceso de mensaje
al modulo USM, este llena los campos de los parmetros de seguridad, y
viceversa cuando es un mensaje entrante el mensaje es pasado al modulo USM
para que este lea los valores contenidos en los campos de parmetros de
seguridad, los parmetros relacionados con la seguridad son los siguientes:
a)
msgAuthenticationEngineID: Este valor permite hacer referencia de el
origen de los mensajes Trap, Response, Reporte y de el destino de los mensajes

Get, Getnext, Getbulk, Set e Inform[13].
b)
msgAuthenticationEngineBoots: Este valor es un entero de entre 0 a
2311 que representa numricamente el tiempo que un motor SNMP ha iniciado

o reiniciado desde su configuracin inicial.
c)
msgAuthenticationEngineTime: Es el valor numrico entero entre 0 y
2311 expresado en segundos en que se lleva el conteo de el tiempo de cada

entidad desde el ultimo incremento de el msgAuthenticationEngineBoots.
d)
msgUserName: Identificador del usuario en cuyo nombre se realizara el
intercambio de mensajes.
e)
msgAuthenticationParameters: es un parmetro de autentificacin, el cual
es un cdigo de mensaje de autentificacin en HMAC[14].

f)
msgAuthenticationPrivacy: es un parmetro de privacidad, el cual es un
cdigo de mensaje de privacidad en algoritmo DES-CBC[15].

3.3.3 Seccin PDU header y PDU SNMPv2
Las siguientes secciones a la de Parmetros de Seguridad, son las de el
encabezamiento de las PDU y las PDU en s, la cuales no varan a la de las
versiones anteriores de SNMP.
CAPITULO 4
PROCESO DE GESTION DE FALLAS
4.1
PROCESO Y PROCEDIMIENTOS DE ALARMAS

Las alarmas son un elemento de gran importancia para la deteccin de
problemas en la red. Es por eso que se debe contar con un sistema de alarmas,
el cual es una herramienta con la que el administrador se auxilia para conocer
que existe un problema en la red. Tambin conocido como sistema de monitoreo,
se trata de un mecanismo que permite notificar que ha ocurrido un problema en
la red. Esta propuesta se basa en la utilizacin de herramientas basadas en el
protocolo estndar de monitoreo, SNMP, en este caso SNMPv3.
Cuando una alarma ha sido generada, sta debe ser detectada casi en el
instante de haber sido emitida para poder atender el problema de una forma
inmediata, incluso antes de que el usuario del servicio pueda percibirla.
Las alarmas pueden ser clasificada desde de puntos de relevancia como
lo es, el tipo de alarma y la severidad de la alarma.
4.2
CLASIFICACION DE LAS ALARMAS
4.2.1 Clasificacion por tipo de alarma

Alarmas en las comunicaciones. Son las asociadas con el transporte de la
informacin, como las prdidas de seal.
Alarmas de procesos. Son las asociadas con las fallas en el software o los
procesos, como cuando el procesador de un equipo excede su porcentaje
normal.
Alarmas de equipos. Como su nombre lo indica, son las asociadas con los
equipos. Una falla de una fuente de poder, un puerto, son algunos ejemplos.
Alarmas ambientales. Son las asociadas con las condiciones ambientales en
las que un equipo opera. Por ejemplo, alarmas de altas temperaturas.
Alarmas en el servicio. Relacionadas con la degradacin del servicio en cuanto
a lmites predeterminados, como excesos en la utilizacin del ancho de banda,

peticiones abundantes de icmp.
4.2.2 Clasificacion por Severidad de la alarma
a) Crtica. Indican que un evento severo ha ocurrido, el cual requiere de atencin
inmediata. Se les relaciona con fallas que afectan el funcionamiento global de la
red. Por ejemplo, cuando un enlace importante est fuera de servicio, su
inmediato restablecimiento es requerido.
b) Mayor. Indica que un servicio ha sido afectado y se requiere su inmediato
restablecimiento. No es tan severo como el crtico, ya que el servicio se sigue
ofreciendo aunque su calidad no sea la ptima.
c) Menor. Indica la existencia de una condicin que no afecta el servicio pero
que deben ser tomadas las acciones pertinentes para prevenir una situacin
mayor. Por ejemplo, cuando se alcanza cierto lmite en la utilizacin del enlace,
no indica que el servicio sea afectado, pero lo ser si se permite que siga
avanzando.
d) Indefinida. Cuando el nivel de severidad no ha sido determinado por alguna
razn.
4.3
PROCEDIMIENTO DE LOCALIZACION DE FALLAS.

Este segundo elemento de la administracin de fallas es importante para
identificar las causas que han originado una falla. La alarma indica el lugar del
problema, pero las pruebas de diagnstico adicionales son las que ayudan a
determinar el origen de la misma. Una vez identificado el origen, se tienen que
tomar las acciones suficientes para reparar el dao.
4.4
PROCEDIMIENTO DE PRUEBAS DE DIAGNOSTICO

Las pruebas de diagnstico son medios importantes para determinar el
origen de una falla. Algunas de estas pruebas de diagnstico que se pueden

realizar son:
a) Pruebas de conectividad fsica. Son pruebas que se realizan para verificar

que los medios de transmisin se encuentran en servicio, si se detecta lo
contrario, tal vez el problema es el mismo medio.
b) Pruebas de conectividad lgica. Son pruebas que ofrecen una gran
variedad, ya que pueden ser punto a punto, o salto por salto. Las pruebas punto
a punto se realizan entre entidades finales, y las salto por salto se realizan entre
la entidad origen y cada elemento intermedio en la comunicacin. Los comandos
usualmente utilizados son ping y traceroute.
c) Pruebas de medicin. Esta prueba va de la mano con la anterior, donde,
adems de revisar la conectividad, se prueban los tiempos de respuesta en
ambos sentidos de la comunicacin, la prdida de paquetes, la ruta que sigue la
informacin.
4.5
PROCEDIMIENTO DE CORRECION DE FALLAS

Es la etapa donde se recuperan las fallas, las cuales pueden depender de
la tecnologa de red. En esta propuesta solo se mencionan las prcticas

referentes a las fallas al nivel de la red.
Entre los mecanismos ms recurridos, y que en una red basada en
interruptores son aplicables, se encuentran los siguientes.
a) Reemplazo de recursos daados. Hay equipos de red que permiten cambiar
mdulos en lugar de cambiarlo totalmente.
b) Aislamiento del problema. Aislar el recurso que se encuentra daado y que,
adems, afecta a otros recursos es factible cuando se puede asegurar que el
resto de los elementos de la red pueden seguir funcionando.
c) Redundancia. Si se cuenta con un recurso redundante, el servicio se cambia
hacia este elemento.
d) Recarga del sistema. Muchos sistemas se estabilizan si son reiniciados.
e) Instalacin de software. Una nueva versin de sistema operativo, una
actualizacin, un parche (service pack) que solucione un problema , etc.
f) Cambios en la configuracin. Tambin es algo muy usual cambiar algn

parmetro en la configuracin del elemento de la red.
4.6
PROCESO DE ADMINISTRACION DE REPORTES

Es la etapa de documentacin de las fallas. Cuando un problema es
detectado o reportado, se le debe asignar un nmero de reporte para su debido

seguimiento, desde ese momento un reporte queda abierto hasta que es
corregido. Este es un medio para que los usuarios del servicio puedan conocer el
estado actual de la falla que reportaron.
El ciclo de vida de la administracin de reportes se divide en cuatro reas,
de acuerdo a la recomendacin X.790 de la ITU-T.
a)
Creacion de Reportes
Un reporte es creado despues de haber recibido una notificacion sobre la
existencia de un problema en la red, ya sra por una alarma, una llamada

telefonica, por correo electronico o por otros medios. Cuando se crea un reporte
debe contener al la informacion de el nombre de la persona que reporto el
problema, el nombre de la persona que atendio el problema, informacion
tecnicapara ubicar el area del problema, comentarios y observaciones de la
problemtica, fecha y hora de la creacion.
b)
Seguimiento a reportes
La administracin de reportes debe permitir al administrador dar
seguimiento de cada accin tomada para solucionar el problema, y conocer el

estado histrico y actual del reporte. Para cada reporte debe mantenerse un
registro de toda la informacin relacionada al mismo: pruebas de diagnstico,
como fue solucionado el problema, tiempo que llev la solucin, etc, y esta debe
poder ser consultada en cualquier momento por el administrador.
c)
Manejo de reportes
El administrador debe ser capaz de tomar ciertas acciones cuando un
reporte est en curso, como escalar[16] el reporte, solicitar que sea cancelado
un reporte que no ha sido cerrado an, poder hacer cambios en los atributos del
reporte, como lo es el telfono de algn contacto, poder solicitar hora y fecha de
la creacin o finalizacin de un reporte, etc.
d)
Finalizacin de reportes
Una vez que el problema reportado ha sido solucionado, el administrador
o la gente responsable del sistema de reportes, debe dar por cerrado el reporte.
Una prctica importante, es que antes de cerrar un reporte el
administrador debe asegurarse que efectivamente el problema reportado ha sido
debidamente corregido.
4.7
MANTENIBILIDAD Y DISPONIBILIDAD
La mantenibilidad de un sistema es la probabilidad de que un equipo que
haya fallado sea restaurado completamente a su nivel operacional dentro de un

perodo de tiempo dado, ese tiempo es considerado cuando la accin de
reparacin se efecta de acuerdo con procedimientos preestablecidos, teniendo
dentro de un porfalios de trabajo, trabajos preventivos, predictivos y correctivos.
Desde el punto de vista de la confiabilidad y disponibilidad, el
mantenimiento permite aumentar la probabilidad de que el sistema
continue trabajando de modo eficiente. [17].
a)
El mantenimiento preventivo consiste en inspeccionar peridicamente el
aparato o dispositivo para repararlo o sustituirlo, incluso aunque no muestre

signos de mal funcionamiento.
b)
El mantenimiento correctivo cuyo enfoque es en reparar un componente
slo cuando falla por completo (falla catastrfica) o cuando su costo de servicio
es extremadamente alto.
c)
El mantenimiento predictivo consiste en estimar la posible falla de un
componente en base a su historia y a indicios (ej. errores de lectura en un disco

duro, parpadeo del monitor).
CAPITULO 4
IMPLEMENTACION
4. VARIABLES DE FALLAS
Son los objetos de la MIB utilizados para programar alarmas para ciertos
eventos con el fin de mantener el estado correcto y el buen funcionamiento de
una red.
Controlar que estos valores se mantengan en valores dentro de un umbral
de seguridad permiten que la propia red avise las instancias en la cual podran
suceder fallos o que estos ya han sucedido y necesitan del auxilio del
administrador.
4.1
Nodo Interfaces MIB-II

Una de las secciones de la MIB-II ms tiles para anlisis de fallas es la
que contiene OID de las interfaces, mostrada en la siguiente figura (Ver figura 1).
interfaces (mib-2 2)
ifEntry (1)
ifIndex (1)
ifDescr (2)
ifType (3)
ifMtu (4)
ifSpeed (5)
ifOutUcastPkts (17)
ifOutNUcastPkts (18)
ifOutDiscards (19)
ifOutErrors (20)
ifOutQLen (21)
ifSpecific (22)...........
Figura 9.- OID de Nodo Interfaces pertenecientes a MIB-II
A continuacin se describen algunos de los objetos tiles para la

administracin de fallas.
IfAdminStstus: Variable objeto que entrega el estado de una interfaz o del
estado del equipo administrado.
Valores posibles de esta variable:
up(1). Estado administrativo activo.
Down(2), Estado administrativo inactivo.
Testing(3). Testeando estado administrativo.
Estos valores se utilizan 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 indica el estado operativo de la
interfaz, este objeto es el ms intuitivo a la hora de realizar una alarma. Se
puede ver que este objeto indica si esa interfaz esta operativa o no lo est. Si
una tarjeta de red falla, se desconecta o en resumen, le sucede algo, entonces el
estado operativo pasar a down (desactivo).
IfInDiscards: Objeto que indica los paquetes descartados por la interfaz, si el
nmero de paquetes descartados comienza a aumentar en forma considerable
es una muestra de error, lo que podra lanzar una alarma de advertencia. Si la
alarma asociada a esta variable se activa, el administrador debera investigar el
origen. Dicha investigacin se podra hacer a travs de la consulta de valores de
ciertas variables (objetos) de la MIB adicionales a esta.
Lo mas importante es que ha sido avisado de la incidencia[17] ocurrida.
IfInErrors: Paquetes con error que ingresaron a la interfaz. De manera similar al
objeto anterior.
IfOutQLen: Segn el RFC 1213 esta como mandatory aunque en RFC s
posteriores pasa a deprecated. Indica la longitud de la cola de paquetes, si el
tamao aumenta de manera considerable o sobre cierto umbral puede indicar

problemas en la interfaz o sobrecarga de la misma.
IpInHdrErrors: Paquetes descartados debidos a errores en la cabecera(TTL
excedido, error de versin, error en composicin del checksum). Un aumento de
estos paquetes podra indicar problemas en el cableado como puede ser una
fuente de interferencias cercana a este.
IpInAddrErrors: Paquetes descartados debido a que la direccin 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 direccin 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: Nmero errores encontrados por el algoritmo de re-ensamblado.
(time out, errores, otros)
ipFragFails: Nmero de paquetes descartados por que tenan que haber sido
fragmentados pero no lo han sido por que el flag de no fragmentar estaba activo.
IpRoutingDiscards: Nmero de entradas de enrutamiento que han sido
eliminadas, aunque eran correctas. Una posible razn de esta eliminacin es
ahorrar recursos liberando el buffer para nuevas rutas.
IcmpInErrrors: Nmero de paquetes ICMP recibidos con error.
IcmpInTimeExcds, icmpInParmProbs: Nmero de paquetes ICMP del tipo
Parameter Problem.
IcmpInSrcQuenchs: Son mensajes ICMP que nos pueden indicar que una
entidad tiene congestin.
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 tamao correcto pero con
errores de CRC o de alineamiento.

EtherStatsFragments: Nmero de paquetes errneos menores de 64Bytes.
EtherStatsJabbers: Nmero de paquetes errneos mayores de 1518 Bytes.
EtherStatsCollisions: Nmero de colisiones estimado.
System.sysUpTime: Indica el tiempo en centsimas de segundo el tiempo en
que se activo la porcin del sistema responsable de la gestin de red.
ifLastChange:El valor del parmetro sysUpTime en el momento que la interfaz
entro en su actual estado operacional
ifInOctets: El nmero total de octetos recibido en la interfaz, incluyendo los
caracteres de cabecera.
IfInUcastPkts: El nmero de paquetes unicast entrantes a la interfaz.
IfInNUcastPkts: El nmero de paquetes nounicast entrantes a la interfaz
(paquetes multicast o broadcast).
IfInDiscards: Nmero de paquetes entrantes descartados por el router
ifInErrors: Nmero de paquetes entrantes que contenan errores y fueron
descartados
ifInUnknownProtos: Nmero de paquetes recibidos en la interfaz y descartados
de reenvo.
IfOutOctets: El nmero total de octetos de salida en la interfaz, incluyendo los
caracteres de cabecera.
IfOutUcastPkts: El nmero de paquetes unicast salientes de la interfaz.
IfOutNUcastPkts: El nmero de paquetes nounicast salientes a la interfaz
ifOutDiscards: Nmero de paquetes salientes descartados por el router.
IfOutErrors: Nmero de paquetes salientes que contenan errores y fueron
descartados
ifOutUnknownProtos: Nmero de paquetes transmitidos por la interfaz y

descartados de reenvo.
4.1 Nodo Enterprise Cisco
Este nodo dentro de la estructura MIB, corresponde a la parte privada de
Objetos Identificadores, los cuales son pertenecientes a cada empresa que
elabore un producto con soporte SNMP, asi existen, entre otras, OID privados
para Cisco, HP, D-link, Dell, IBM, Unix, Novell , y asi un largo listado, que en
estos momentos alcanza una cantidad de 33443 empresas con su respectiva
estructura SMI y su OID privados.( Ver Link en http://www.iana.org/assignments/
enterprise numbers).
En el caso especifico de Cisco cuenta con un gran listado privado de
Objetos Identificadores, los cuales se pueden utilizar para tener una buena
gestion de dicho equipo Cisco, dentro de esos OID se analizan los
correspondientes a la temperatura de la CPU (OID 1.3.6.1.4.1.9.9.13.1.3.1.). de
dicho Objeto se desprenden instancias, como el estado de la CPU en relacion a
la temperatura (Critico, Peligroso, Normal), otra instancia es la cantidad de
grados en que se encuentra la temperatura de la CPU (en grados Celsius).
5. INDICADORES DE VARIABLES A MEDIR

5.1 Medicin de la tasa de prdidas de datagramas
La frmula de medicin en cada muestra ser la siguiente:
Porcentaje de prdida =No.total de paquetes perdidos en el intervalo de 5' (5-1)
No.total de paquetes enviados en el intervalo de 5'
La cantidad total de muestras tomadas ser, por lo tanto, el producto del
nmero de intervalos de 5 minutos en el lapso de un da. El porcentaje de
prdidas ser el promedio de tasa de prdidas de las 300 muestras tomadas en
1 das.
El umbral para la tasa de paquetes perdidos es de 20%, para cada enlace
de la red de pruebas, la superacin de este indicador, entregara una alerta de
que existe algn problema dentro de la red, y habra que realizar un prueba de
diagnostico de las mismas perdidas por cada red y poder escalar hasta
determinar el origen del supuesto problema.
5.2 Medicin de la disponibilidad de la red
La disponibilidad de una red, es un indicador que resume en s mismo
todos los objetos en cuestin ya que necesita toda o gran parte de esa
informacin tanto directa como indirectamente, para elaborar la medicin.
Las condiciones de medicin para considerar que la red est o no
disponible, no son uniformes y no existe una exigencia para ello entre aquellos
pases en los que se ejerce alguna regulacin al respecto y del mismo modo
dentro de la industria de la gestin y monitoreo de redes, lo que si existen son
recomendaciones para tener una red saludable y eficiente.
Del estudio de esos casos encontrados, se determina que estas
condiciones son seleccionadas en funcin a la facilidad con la que se pueden
realizar las mediciones y la precisin deseada de las mismas. En resumen se
adopta uno de los siguientes criterios:
a) Una red est disponible si su enlace de interconexin est en el estatus

operativo, rescatando el objeto IfOperStatus por SNMP.
b) Una red est disponible si los valores de latencia y tasa de prdida de
paquetes estn dentro de rangos previamente establecidos. (medicin un poco
mas complicada pero en efecto es mas informativa que a) ).
Para efecto de pruebas en este estudio se definen 2 mediciones distintas
de disponibilidad a ser consideradas:
Disponibilidad en el enlace de Usuario (router - host)
Disponibilidad en el enlace WAN. (router - router)
La disponibilidad en cada caso se tomar como un promedio diario, de las
mediciones efectuadas en intervalos de 5 minutos (valor estndar recomendado
y usualmente aceptado), que cumplan con las condiciones de prdida de
paquetes y latencia establecidas.
La frmula que describe esta disponibilidad es la siguiente:
Disponibilidad(%)=
No. de muestras vlidas
(5-2)
No.total de muestras tomadas

El valor objetivo de disponibilidad propuesto es mayor o igual a 99%. Estas
mediciones se realizan va mensajes SNMP (para determinar la operatividad del
enlace).
5.2.1 Fase de medicin

Este proceso se realizar en forma automtica de acuerdo a lo siguiente:
Registro de las direcciones IP consultadas
Muestreo peridico de los indicadores medidos y almacenamiento
Condiciones generales de la medicin como el uso de las variables MIB
mostradas y los indicadores propuestos se relacionan de la siguiente
manera:
Disponibilidad=
n con ifOperStatus.ifIndex=ON
(5-3)
N de Muestras Realizadas
Las muestras recogidas son vlidas si el estatus del objeto MIB

ifOperStatus tiene status ON.
El porcentaje de prdidas de paquetes se calcula (enlace de entrada) de
la siguiente manera:
Paquetes Perdidos(%) =
Paq. Perdidos(K) Paq. Perdidos(K-1)
(5-4)
Paq. entrantes(K) Paq. entrantes(K-1)

Donde:
paquetes
perdidos
Interfaces.ifTable.ifEntry.ifInDiscards.ifIndex
Interfaces.ifTable.IfEntry. ifInErrors.ifIndex
Interfaces.ifTable.ifEntry.ifInUnknownProtos.ifIndex
paquetes
entrantes
Interfaces.ifTable.ifEntry.ifInUcastPkts.ifIndex
Interfaces.ifTable. ifEntry.ifInNUcastPkts.ifIndex
k= es el instante de muestreo.
Igual calculo se debe realizar con los paquetes salientes en cada interfaz
correspondiente a las mediciones WAN y enlaces a Usuarios.
CAPITULO 6
IMPLEMENTACION: SOFTWARE Y HARDWARE UTILIZADO.
6.1
SOFTWARE
Para poder iniciar la etapa de monitoreo y gestin es necesario tener el
computador, donde se hospedara el software de administracin, en las

condiciones necesarias para los requerimientos de Zenoss-Core 2.4
Las condiciones necesarias, en cuanto a software, son las demandadas
por la aplicacin Zenoss.
Condiciones:
1.- Dependencias del lenguaje Python necesarias para el ptimo de la aplicacin.
2.- Agente SNMP activo, para este caso el agente es la suite NET-SNMP.
3.- Contar con un servidor de aplicaciones Zope y un servidor de base de datos
MySQL.
4.- Aplicacin MRTG instalada y funcionando bajo tcnicas RDDtool.
5. Sistema Operativo base GNU/Linux Debian Lenny 5.0 Stable.
6.1.1 Catastro de Software
a)
NET-SNMP
Utilidad (Suite) para recoleccin de informacin desde las MIB usando el
protocolo SNMP, incluyendo configuracin para SNMPv3, esta suite incluye un

agente y una biblioteca SNMP para comandos de gestin, entre otros
cualidades.
b)
ZENOSS-CORE 2.4
Es una herramienta y un sistema de monitoreo y gestin de redes
multiplataforma, que soporta diferentes tipos de dispositivos para administracin
remota, como equipos host, servidores y dispositivos de red (Switch, Router,

Firewall) usando protocolo SNMP y otros para apoyo de este protocolo como
Telnet y SSH.
Este sistema utiliza tecnologas open-source basadas en el lenguaje
Python, como el servidor de aplicaciones Zope, servidor de base de datos
MySQL, herramientas grficas RRDtool y MRTG.
Entre sus principales funciones de puede mencionar la vista de topologas
de red, la supervisin de actividades, la gestin de eventos, la gestin de
alarmas, automatizacin de adquisicin de informacin.
Zenoss a partir de su versin Zenoss 2.0 cuenta con una nueva utilidad
llamada ZenPack, la cual consiste en un grupo empaquetado de funciones y
modelos de plantillas para tipos especficos de dispositivos para optimizar la
supervisin de cada dispositivo.
c)
ZOPE
Servidor de aplicaciones web de codigo abierto escrito en lenguaje
Python, el cual esta conformado por Objetos en vez de archivos como el comn
de los servidores web. Zope posee un sistema de almacenamiento (Base de
Datos) basado en objetos llamado ZODB (Zope Object DataBase).
d)
MYSQL
Sistema de gestin de base de datos, MySQL es de cdigo abierto,
ampliamente utilizado para aplicaciones web, como en este caso que ser
utilizado para el montaje y funcionamiento de Zenoss-Core 2.4.
e)
PYTHON
Proyecto
de
cdigo
abierto,
es
un
lenguaje
de
Programacin
Multiparadigma, el programador puede tomar la opcin de estilo de

programacin Orientada a Objetos, Estructurada y Funcional entre otras, Python
tambin es un lenguaje de programacin interpretado por lo cual no necesita de
compilacin ahorrando tiempo al programador.
f)
RRDtool
Round Robin Database tool, es una herramienta que ocupa una tcnica
de Round Robin para manejo de datos, esta tcnica trata la base de datos como
si fuese un crculo, sobrescribiendo los datos almacenados con anterioridad una
vez alcanzada la capacidad mxima de la misma. Esta capacidad mxima
depender de la cantidad de informacin que se quiera conservar como historial.
Su finalidad principal es el tratamiento de datos temporales y datos
seriales como temperaturas, transferencias en redes, cargas del procesador, etc.
g)
MRTG
Multi Router Traffic Grapher, es una herramienta escrita en C, utilizada
para el monitoreo de trfico en interfaces de red, el cual genera un informe en

formato HTML de los datos recibidos, dicha recoleccin de informacin es
realizada va protocolo SNMP.
h)
DEBIAN LENNY 5.0

Sistema operativo GNU/Linux, en su version estable, se encuentra en la
web para libre descarga bajo la licencia GPL, sobre esta plataforma se instalan
todas las aplicaciones antes mencionadas.
6.2
HARDWARE
Para la implementacion de la red de pruebas, se montaron equipos de red
Switch y Router Cisco, lo cuales debian tener la caracterista de tener un imagen

de sistema operativo compatible con SNMPv3, lo cual implica una version igual
o superior a IOS 12.4 de Cisco, otros equipos montados son los utilizados para
el monitoreo y otro como servidor de la aplicacin de administracion.
6.2.1 Catastro de Hardware.
a) Router Cisco 2811
IOS 12.4
Capa OSI: Red
Plataforma tecnolgica: IP, IPSec, MPLS, VPN.
Tasa de Transferencia de Datos: 400 Mbps.
Protocolos: IPSec VPN, SSH v2, SNMP v3.
Encriptacin basada en hardware: DES, 3DES, AES 128, AES 192, AES 256.
Dimensiones Fsicas: 4.45 cm x 43.82 cm x 41.66 cm (1 Unidad de Rack).
Peso: 6.4 Kg.
Rango de Temperatura de Operacin: 0 C a 40 C (ptima 25 C).
Humedad Relativa: 5% a 95% sin condensacin.
Consumo de Corriente: 4 Amp. (-48 VCD).
Potencia: 180 W.
Disipacin de Calor: 614 BTU/hr.
b) Switch Catalyst 2950
24 Interfaces a dispositivos de red y 1 interfaz a Configuracin
Dimensiones: 1.72 x 17.5 x 9.52 in. (4.36 x 44.45 x 24.18 cm)
Peso: 6.5 lb (3.0 kg)
Protocolos: SNMP 1, SNMP 2, RMON 1, RMON 2, RMON 3, RMON 9, Telnet,
SNMP 3, HTTP
Potencia: 30W
Disipacion de calor :102 BTU/hr
Rango de Temperatura de Operacion: 32 a 113F (0 to 45C) optima 25C
Humedad Relativa: 10% a 85% sin condensacin
Voltaje AC : 100 to 127, 200 to 240 VAC (auto-ranging)
Consumo de Corriente: 4.5 Amp.
Frecuencia AC : 47 a 63 Hz
c) Equipo Servidor
Notebook Dell Inspiron 6400
CPU:
Intel Core Duo T2250 @ 1.73 GhzMemoria RAM:
1 GB
Disco Duro: 80 GB
Sistema Operativo: Debian Lenny 5.0 GNU/Linux
d) Equipo para Monitoreo
PC de Escritorio Dell Vostro, ubicados en el laboratorio de digitales B, ahora
laboratorio de redes.
e) Catastro de Conectores
UTP 5 Para conexin de red Ethernet
Serial 242 Para conexin de simulacion de wan
CAPITULO 7
PRIMERAS PRUEBAS SIMULACION Y FUNCIONAMIENTO SNMP
7.1
ESCENARIO DE RED
7.1.1 Red Ethernet con enlaces Serial (WAN)

La red de pruebas sera la mostrada en la Figura 10. La tecnologa
Ethernet utiliza, para controlar las colisiones, el protocolo CSMA/CD (acceso
mltiple con deteccin de portadora (carrier) y deteccin de colisiones).
En la prctica, esto significa que varios dispositivos pueden tener acceso
al medio y que, para que un dispositivo pueda acceder al medio, deber detectar
la portadora (codificacin Manchester)
para asegurarse que ningn otro
dispositivo est utilizando el mismo medio. Si el medio se encuentra en uso, el

dispositivo proceder a mantener en suspenso el envo de datos. En caso de
que haya dos dispositivos que no detectan ningn otro trfico, ambos tratarn de
transmitir al mismo tiempo, dando como resultado una colisin. A partir de esta
colisin se genera un algoritmo de espera con el que las estaciones
retransmitirn aleatoriamente.
7.1.2 Enrutamiento Dinmico
Actualizacin ante cambios, sin recurrir a reconfiguraciones del router, as
un protocolo de enrutamiento determina sus rutas dinmicamente y anexamente una actualizacin constante de las tablas, dentro de estos protocolos.
Dentro de estos protocolos de enrutamiento estn: RIP, IGRP, EIGRP, OSPF. En
este escenario de configura enrutamiento RIP versin 2.
7.1.3 Determinacin de Direcciones IP
Para este escenario de pruebas, se utilizara RIP v2, dando la direccin IP
a los dispositivos de red en forma manual y aleatoria.
Figura 10.- Topologia de Red de Pruebas SNMPv3

7.2
CONFIGURACION SNMPv1 y v2c.

Por defecto el router viene con grupos creados en versin SNMPv1 y v2c,
por lo que resta es configurar la suite Net-SNMP del PC-Administrador

agregando la red a la cual pertenece y a cuales redes gestionar y monitorizar.
Dentro de esta configuracin del PC-Administrador se debe agregar la
comunidad a cual pertenece, tipo de versin de SNMP que soporta y si tiene
permisos de escritura o lectura.
Para realizar las pruebas SNMPv1 y v2c, se configur la suite Net-SNMP
(en el PC-administrador) con una comunidad usada para pruebas llamada
public , dando privilegios de escritura y lectura rw, agregado tambin la red
a la cual pertenece directamente, y a las redes que eran parte de escenario de
pruebas.
Para el caso del router y switch solo basta con habilitar la funcin snmp
desde la linea de comandos y dar la comunidad a la cual iba a pertenecer, para
mas detalles de esta configuracin ir a apndice A.
7.3
PRUEBAS DE FUNCIONAMIENTO
7.3.1 Descubrimiento de Topologa de Red.

El Administrador Zenoss-Core tiene la funcin de auto-descubrimiento de
la topologa de red, en donde con el comando ZenDisc (Zenoss-Discovery),
realiza una serie de encuestas a los dispositivos de red, utilizando SNMP y
ICMP,
as
detectando
mediante
estos
dos
protocolos
los
elementos
pertenecientes a la red, puede dejarse solamente SNMP o solamente ICMP

funcionando.
El descubrimiento de los equipos de la red es lanzado a traves de un
grfico de topologa (Ver Figura 11) que posee el administrador.
Figura 11.- Topologia de Red Descubierta
Figura 12.- Pantalla principal del administrador
7.3.2 Visor de Objetos consultados

a)
DashBoard. Esta ventana es un visor general (Ver Figura 12) de lo que
cubre en cuanto a administracin Zenoss-Core, as mostrando localizacin de los

dispositivos con plug-in de google map, muestra los dispositivos que estn en
administracin en cualquier momento, distinguiendo cuales estan en mantencion,
supervision y otras opciones, mensajes que haya generado el administrador por
tareas que este realizando en segundo plano, entre otras cosas.
b)
Interfaces. Escalando en las caractersticas, este administrados tiene un
seguimiento completo de las interfaces de comunicacin de los elementos de la

red, tarjetas de red ethernet, tarjetas inalmbricas, puertos seriales, con un
resumen de sus direcciones IP , direcciones MAC, cantidad de paquetes
enviados recibidos, paquetes con error generando grficos diarios mensuales y
anuales de estas variables (ver Figura 13).
Figuras 13.- Trafico por las interfaces de un dispositivo de red
c)
Disco Duros y Procesos. Tambin posee un visor de comportamiento de
un dispositivo teniendo en cuenta su capacidad de procesar, as muestra estados

de memoria, de espacios en disco duro, cantidad de procesos que ejecuta en
elemento de la red, cantidad de byte escritos o ledos de un disco duro y otras
variables, las cuales son descubiertas por medio de SNMP y son graficadas (ver
Figura 14) en el tiempo ya sea en horas, diarias, mensuales, anuales.
Figuras 14.- Historiales de Procesos, Memoria, CPU
d)
Eventos producidos y Reportes Generados. Zenoss-Core tiene una
aplicacin que lleva el registro total de los eventos generados en toda su red de
administracin (ver Figura 15) almacenndolos en una bitcora la cual luego de
un tiempo es almacenada en la base de datos MySQL en una tabla llamada
Events como Historial de Administracin.
Figura 15.- Eventos y Reportes generados en una red administrada.
CAPITULO 8
SEGUNDAS PRUEBAS: FUNCIONAMIENTO SNMPv3
8.1
Para llevar a cabo las pruebas de esta versin del protocolo, se realizan
las siguiente estructura de funcionamiento (comandos en Apendice A):

1.- Se crean 4 usuarios en el router (userone, usertwo, userthree, userfour), los
cuales tendrn niveles de seguridad: sin seguridad, autenticacin y privacidad.
2.- Se crean 4 grupos de usuarios en el router (groupone, grouptwo, groupthree,
groupfour), los cuales tendrn niveles de seguridad al igual que los usuarios.
3.- Estos cuatro usuarios pertenecern a cada uno de los 4 grupos creados.
4.- Se crean vistas de MIB para probar niveles de seguridad efectivos.
8.2
COMANDOS Y SCRIPT CREADOS PARA SNMPv3

Se crearon cuatro scripts para encuestar a los equipos de la red, y un
comando simple, ver Figura 16, para comprar la escritura en forma remota de un
objeto de la MIB II.
8.2.1 Script Prueba de Nivel de Seguridad
Para poder demostrar el sistema de seguridad implementado en la nueva
version de SNMPv3, se crea un script que realiza las mismas consultas que en el
script de Anlisis Preventivo, pero con la salvedad que en esta ocacion se
incluyen datos erroneos en la identificacion y en la clave de ingreso a la MIB del
equipo remoto a escuestar.
8.2.2 Script Prueba de Privacidad
En este pequeo script se realiza la prueba de privacidad en el envio de
mensajes, en donde con encriptacion DES, se encripta el mensaje snmp
enviado, asi probando que el nivel de Privacidad, incluye por defecto al nivel de
Autenticacin.
8.2.3 Script Anlisis Preventivo

Para la serie de pruebas SNMPv3, se crea un script que realiza una
encuesta a un equipo de la red, solicitando datos de su estado fisico, entre estos
datos se encuentran el valor de su temperatura instantanea, su valor de
temperatura umbral segn especificaciones del fabricante, ver Figura 19 y Figura
20, la cantidad y el estado de los ventiladores del equipo, y la energia que
alimenta a dicho equipo en donde se solicita el estado de la alimentacion y que
tipo de alimentacion es la presente.
8.2.4 Script Testeo de un Equipo
En este script, se crea un escaneo basico de puertos de un equipo de la
red de pruebas, con el fin de tener una rapida informacion del estado de
funcionamiento de dicho equipo en la red.
8.2.5 Comando de Escritura en MIB
Este comando es utilizado para probar la escritura de una MIB en un
equipo remoto, utilizando la version SNMPv3, el fin de probar en esta version la
escritura es que en las anteriores versiones este tipo de comandos se
encuentran desabilitados por motivos de seguridad, problema que en esta
version ya no se encuentran, para resultado de prueba ver Figuras 17-18.
8.3
RESULTADO DE PRUEBAS SNMPv3

Pruebas realizadas configurando el administrador Zenoss-Core
Figura 16. Comandos de administracin creados.
Figura 17. Resultado de un cambio de nombre por comando snmpset
Figura 18. Respuesta en consola del Router ante una modificacion. Se indica
Configuracion from 192.168.1.2 (administrador) by snmp
Figura 19.- Valor de la Temperatura de la CPU en Grados Celcius.
Figura 20.- Valor de Temperatura Umbral de Operacion de la CPU

8.3.1 Script generados.
8.3.1.1 Script Prueba de Nivel de Seguridad
El siguiente es el script generado en Zenoss-Core para verificacion de la
seguridad, en donde se intenta acceder con nombre de usuario erroneo.
TEMPERATURA.
snmpwalk -v 3 -u U3 -l authNoPriv -a MD5 -A password3 172.10.10.2
enterprises.9.9.13.1.3.1.3
VENTILACION
ENERGIA
8.3.1.2 Script Prueba de Privacidad
El siguiente script es el generado para pruebas de encriptacion para
consultar informacion a un equipo de red.
PRIVACIDAD
Description: COMPROBACION UTILIZANDO ENCRIPTACION "DES"
snmpwalk -v 3 -u U4 -l authPriv -a MD5 -A password4 -x DES -X password4
172.10.10.2 enterprises.9.9.13.1.4.1.2
8.3.1.3 Script Anlisis Preventivo
Las siguientes lineas son parte del script creado para realizar una
analisis preventivo a un equipo de red.
TEMPERATURA
VENTILACION
ENERGIA
TEMPERATURA
a) Temperatura Actual
b) Temperatura Fabricante
VENTILACION
c) Numero de Ventiladores = #FAN
d) Funcionamiento de Cada Ventilador
INTEGER = 1 -> Normal
INTEGER = 2 -> Warning
INTEGER = 3 -> Critical
INTEGER = 4 -> Shutdown
INTEGER = 5 -> No Presente
INTEGER = 6 -> No Funcionando
ENERGIA
e) Estado de la energia que alimenta el dispositivo
INTEGER = 1 -> Normal
INTEGER = 2 -> Warning
INTEGER = 3 -> Critical
INTEGER = 4 -> Shutdown
INTEGER = 5 -> No Presente
INTEGER = 6 -> No Funcionando
f) Tipo de Energia que Alimenta al Equipo
INTEGER = 1 -> Se Desconoce
INTEGER = 2 -> AC
INTEGER = 3 -> DC
INTEGER = 4 -> External Suply
INTEGER = 5 -> Interna Redundante Output
8.3.1.4 Script Testeo de un Equipo

El script de Testeo es para poder determinar en forma rapida y basica el
estado de funcionamiento de las puertas de un equipo de red.
ESTADO DE INTERFACES
snmpwalk -v 1 -cpublic 172.10.30.2 ifadminStatus snmpwalk -v 1 -cpublic
172.10.30.2 ifDescr
snmpwalk -v 1 -cpublic 172.10.30.2 ifIndex
snmpwalk -v 1 -cpublic 172.10.30.2 ifspeed snmpwalk -v 1 -cpublic 172.10.30.2
ifType
snmpwalk -v 1 -cpublic 172.10.30.2 udpInErrors
8.3.1.5 Comando de Escritura en MIB
En el caso de solo ejecutar un comando, como es en la forma SET, se
utiliza la version 3 para prueba, se escribe en la MIB remota de un equipo cisco.
ESCRITURA EN MIB REMOTA
snmpset -v 3 -n "" -u U3 -l authNoPriv -a MD5 -A password3 172.10.10.2
system.sysContact.0 s "sjme@ingenieros.com" .
Al momento de realizar Script, para un correcto monitoreo y analisis
preventivos, la realizacion dependera de las habilidades del administrador y de
las necesidades que se desean cubrir, asi como los objetivos predefinidos en los
procesos de gestion del Centro de Operaciones Correspondiente.
CONCLUSIONES
Al momento de dar por finalizado este Proyecto de Titulo, se generan
conclusiones relacionadas con los dos topicos mas relevantes de este. Los
principales topicos son el de el Protocolo de Administracion de Red SNMPv3 y el
de la Gestion de Fallas.
La administracion de red al ser un campo muy amplio, es complejo
identificar las prioridades, todo tipo de proceso y decisiones realizadas en la
administracion se basaran en las buenas praticas que se hayan implementado y
en el enfoque de la empresa donde este implementado.
En relacion a SNMPv3, las conclusiones desprendidas luego realizar el
estudio e implementacion son las siguientes.
1)
La estructura modular de esta ultima version, produce un alto grado de
interoperatividad entre las versiones existentes de SNMP.

2)
La estructura modular de esta ultima version, es favorable para el
entendimiento del proceso de los mensajes SNMP, tanto en el agente como en el

Administrador.
3)
Los niveles de seguridad, son de gran utilidad al momento de filtrar
quienes pueden rescatar datos desde un equipo de red, asi mediante el subsistema de la entidad del Gestor, puede definirse que vistas de objetos pueden
ser incresadas y que permisos necesita esta para ser accedida.
4)
Al momento de iniciar la configuracion de SNMPv3, se debe de configurar
los equipos Cisco en forma remota via telnet o de forma local conectandose
directamente a su puerta de consola.
5)
La Administracion de Red es una tarea compleja, es por esta complejidad
que tener un Centro de Operaciones de Red solo con el protocolo SNMP

funcionando no es la mejor opcion, para el apoyo en la administracion existe la
opcion de utilizar telnet, ping, entre otros, lo cual ayuda significativamente la
labor de SNMP.
En relacion a la Gestion de Fallas, las conclusiones desprendidas luego

de realzar su estudio son las siguientes.
1)
Es fundamental tener un proceso bien definido para la gestion de fallas,
ms aun, de acuerdo a las recomendaciones ITIL, se debe tener un buen

proceso de Gestion de Incidencias, lo cual implica tener un amplio espectro de
casos que ocurran en una red, casos que no necesariamiente son fallas deben
ser atendidas de igual manera y realizar los procedimientos correspondientes.
2)
En el proceso de de Gestion de Fallas, tiene un procedimiento de
tratamiento de alarmas, el cual indica como deben tratarse las alarmas

dependiendo de su naturaleza.
3)
Segn el tipo de alarma, se genera un tipo de procedimiento, dicho
procedimiento esta siendo seguido por parte de personal del Centro de

Operaciones de Red, quienes por constingencia, deben dar apertura,
seguimiento y cierre de un caso, hasta que se solucione
4)
En cuanto a las capacidades del Centro de Operaciones de Red, en la
resolucion de problemas, fallas, incidentes, el proceso de Gestion de Fallas,

debe incluir un catalogo de servicios, en donde se pueda definir claramente
cuales son las tareas que puede y no puede realizar el NOC (Centro de
Operaciones de Red).
REFERENCIAS
BIBLIOGRAFICAS
[01]
Peter Fanning, ITILv3 Core Service Operation, OGC, 2007.
[02]
Publicacion: M. Fedor, J Case, M. Schoffstall, Request for Comments

1157 , IETF, Mayo 1990.
[03]
Publicacion: M. Fedor, J Case, M. Schoffstall, Request for Comment

1157 , IETF, Mayo 1990.
[04]

1157 , IETF, Mayo 1990.
[05]

1157 , IETF, Mayo 1990.]
[06]

1157 , IETF, Mayo 1990.]
[07]
Publicacion: K. McCloghrite, M. Rose, Request for Comment 1213. IETF,

Marzo 1991.
[08]

Marzo 1991.
[09]

Marzo 1991.
[10]
Publicacion: D. Harrington, R Presuhn, B. Wijnen, Resquest for Comments

2571, Abril 1999.
[11]

2571, Abril 1999.
[12]

1157 , IETF, Mayo 1990.
[13]

1157 , IETF, Mayo 1990.
[14]

2571, Abril 1999.
[15]

2571, Abril 1999.
[16]
[17]
BIBLIOGRAFIA
1.-
Douglas Mauro, Kevin Schmidt, Essential SNMP , O`Reilly Media Inc, 11

Julio 2001
2.-
David Zeltserman, A Practical Guide to Snmpv3 and Network

Management,Prentice Hall, 1999.
3.-
Gustavo Fonseca, Red Hat Linux, Herramientas para la administracin de

Redes, Steve Maxwell, traducido por Gustavo Fonseca.
4.-
William Stallings, Network Security Essentials, Applications and

Standards, Second Edition, Prentice Hall, 2003.
5.-
"Revisin: Tecnologa de Agentes de Software". Tolosa, G y Bordignon, F.

Ciencia da Informacao, vol 28, n. 3, pp 300-307. 1999
6.-
william Stallings, SNMP,SNMPv2,SNMPv3, and RMON 1 and 2, Tercera

Edicion, Prentice Hall,
7.-

1157 , IETF, Mayo 1990.
8.-

2571, Abril 1999.
9.-
10.-

Marzo 1991.
ANEXOS
APENDICE A
APENDICE A
En los equipos de red Cisco existen por defecto dos vistas creadas y dos
grupos relacionadas con estas vistas. Las vistas predefinidas son dos:
everything, que abarca toda la MIB, y restricted, que incluye slo los grupos
system, snmpStats y snmpParties. En versiones SNMPv1 y v2c con solo permiso
de lectura.
Para poder dar una configuracin SNMPv3 se seguir las siguientes
lineas de comando tato para switch como para router Cisco.
CONFIGURACION SWITCH CISCO

switch(config)# snmp-server community public ro
switch(config)# snmp-server group secure v3 priv
switch(config)# snmp-server group secure v3 priv read secure-ro write securewr
switch(config)#snmp-server group secure v3 priv
switch(config)#snmp-server group secure v3 priv read secure-ro write secure-wr
switch(config)#snmp-server view secure-ro internet included
switch(config)#snmp-server view secure-wr mgmt included
switch(config)#snmp-server user snmpuser secure v3 auth md5 cisco123 priv
des56 cisco123
CONFIGURACION ROUTER CISCO

ROUTER 1
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
interface Serial0/0
ip address 172.10.10.1 255.255.255.0
router rip
version 2
network 172.10.0.0
network 192.168.0.0
network 192.168.1.0
snmp-server community public RW
snmp-server enable traps snmp authentication linkdown linkup coldstart
warmstart
snmp-server enable traps
ROUTER 2
en
conf t
interface Serial0/0/0
ip address 172.10.10.2 255.255.255.0
clock rate 64000
snmp trap link-status
no shutdown
exit
interface Serial1/2
ip address 172.10.20.1 255.255.255.0
clock rate 64000
no shutdown
exit
interface Serial1/3
ip address 172.10.30.1 255.255.255.0
clock rate 64000
no shutdown
exit
router rip
version 2
network 172.10.0.0
network 192.168.0.0
exit
snmp-server user userone groupone v3
snmp-server user usertwo grouptwo v3
snmp-server user userthree groupthree v3 auth md5 user3pass
snmp-server user userfour groupfour v3 auth md5 user4pass priv des56
user4priv
snmp-server group TRAP v3 priv
snmp-server group groupone v3 noauth
snmp-server group grouptwo v3 noauth read myview
snmp-server group groupthree v3 auth
snmp-server group groupfour v3 priv
snmp-server view myview mib-2 included (da acceso)
snmp-server view myview 1.3.6.1.4.1.9.9.13.1.3.1.6 included
snmp-server view myview 1.3.6.1.4.1.9.9.13.1.3.1.3 included
snmp-server view NORMAL iso included
snmp-server view RESTRICTED ifEntry.*.3 included
snmp-server host 192.168.1.2 traps
snmp-server host 192.168.1.2 traps version 3 priv TRAP
snmp-server host 192.168.1.2 traps version 3 auth public
ROUTER 3
En
Config t
interface Ethernet0/0
ip address 192.168.2.1 255.255.255.0
no shutdown
exit
interface Serial0/0
ip address 172.10.20.2 255.255.255.0
no shutdown
interface Serial0/1
ip address 172.10.40.1 255.255.255.0
clockrate 64000
no shutdown
exit
router rip
version 2
network 172.10.0.0
network 192.168.0.0
network 192.168.2.0
exit
snmp-server community public RW (esto no poner para snmp v1 o v2)
snmp-server trap
ROUTER 4
En
Conf t
interface FastEthernet0/0
ip address 192.168.2.1 255.255.255.0
no shutdown
exit
interface Serial0/0
ip address 172.10.30.2 255.255.255.0
no shutdown
exit
interface Serial0/1
ip address 172.10.40.2 255.255.255.0
no shutdown
exit
router rip
version 2
network 172.10.0.0
network 192.168.1.0
network 192.168.2.0
exit
snmp-server enable traps snmp authentication linkdown linkup coldstart
warmstart
snmp-server host 192.168.1.2 version 3 auth public
APENDICE B
INSTALACION Y CONFIGURACION ZENOSS-CORE
APENDICE B
INSTALACION Y CONFIGURACION ZENOSS-CORE
Primero que todo se necesitan varias dependencias para poder instalar

Zenoss-Core:
1-python-dev
2-libmysqlclient15-dev
3-mysql-server
4-build-essential
5-binutils
6-make
7-swig
8-autoconf
Proceder a agregar el siguiente repositorio editando el siguiente archivo
de configuracin:
sjme@debian# nano /etc/apt/sources.list
Agregar el repositorio:
deb http://http.us.debian.org/debian lenny main contrib non-free
Este repositorio nos permite descargar paquetes desde un servidor web en
estados unidos para nuestra versin de debian lenny.
sjme@debian# apt-get update
Proceder a instalar las dependencias con el siguiente comando:
sjme@debian# apt-get install python-dev libmysqlclient15-dev mysql-server
build-essential binutils make swig autoconf
Mysql-server:
Mysql-server lee opciones de las secciones [mysql.server] y [mysqld] de los
icheros de opciones. (Para compatibilidad con versiones anteriores).
Al instalar la dependencias el sistema pide una confirmacin y entonces colocar
la letras S indicando que se desea seguir con la instalacin.
Creacin de Usuario:
Crear un usuario especial dentro de debian para la administracion de
Zenoss.
sjme@debian# adduser zenoss

Al crear un usuario, se pide que copiemos el password (contrasea) son la
que va iniciar sesin el usuario zenoss, y ms adelante pide unos datos
personales los cuales se pueden dejar por defecto presionando enter.
Proceder a logueo por consola con el usuario zenoss para ms adelante
poder realizar varios cambios en las variables de el usuario, dar el siguiente
comando:
sjme@debian# su zenoss
Zenos@debian#
Proceder a modificar el archivo de las variables para el interprete de
comandos de dicho usuario, para ello ubicarse en el home del usuario, y escribir
el siguiente comando.
Zenos@debian# cd /home/zenoss/
Despus damos el comando:
Zenos@debian# nano .bashrc
Al final del archivo agregar las siguientes lneas:
export ZENHOME=/usr/local/zenoss
export PYTHONPATH=$ZENHOME/lib/python
export PATH=$ZENHOME/bin:$PATH
Breve detalle de las lineas agregadas
export ZENHOME=/usr/local/zenoss -->ruta donde se instalara Zenoss-Core,
ser la raz como tal para el funcionamiento del Zenoss
export PYTHONPATH=$ZENHOME/lib/python-->ruta de la librera de python
export PATH=$ZENHOME/bin=$PATH-->ruta de los binarios ejecutados por
zenoss.
La variable ZENHOME apunta a un directorio inexistente por lo tanto crear
uno desde el usuario root.
sjme@debian# su
password
Y crear el directorio:
sjme@debian# mkdir /usr/local/zenoss
Cambiar el propietario del directorio
sjme@debian# chown zenoss /usr/local/zenoss
Antes de que instalar cerciorar de que el server mysql este corriendo.
sjme@debian# /etc/init.d/mysql status

Luego descargar el paquete zenoss en la siguiente ruta:
(http://downloads.sourceforge.net/zenoss/zenoss-2.4.tar.gz),
el paquete
queda en el escritorio, entonces se traslada del escritorio a la siguiente ruta
sjme@debian# /usr/local/zenoss
de la siguiente forma.
sjme@debian# cp /home/sena/Desktop /usr/local/zenoss
Y cuando el paquete este en /usr/local/zenoss, realizar la instalacion
su zenoss
cd /usr/local/zenoss
tar -zxvf zenoss-2.2.4.tar.gz cd zenoss-2.2.4
./install.sh
Proceso de Instalacion Zenoss-Core.
Preguntara passwords para acceder va web al entorno grafico del
zenoss, usuario para acceder a la base de datos del mysql y dems, estos datos
se brindaran dependiendo de la respectiva configuracin que exista en el equipo;
la instalacin del paquete se demora un poco, mientras crea base de datos y
finaliza otros procesos.
Luego entrar como usuario root.
sjme@debian# su
password
Y ejecutar los siguientes comandos:
chown root:zenoss /usr/local/zenoss/bin/zensocket
chmod 04750 /usr/local/zenoss/bin/zensocket
Antes de iniciar el zenoss se debe de instalar los agentes por defecto en
el servidor, y tambin el scli para poder ver los dems agentes en nuestra red. El
snmpd es el demonio de snmp y ah es donde se configura el agente.
Ahora se debe modificar algunas lneas al archivo de configuracin del
demonio snmpd en la siguiente ruta: /etc/default/snmpd:
sjme@debian# ano /etc/default/snmpd
Buscar la siguiente lnea:
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp I -smux -p /var/run/snmpd.pid
127.0.0.1' , y proceder a borrar la direccion del localhost
Despus de haber hecho esto modificar el siguiente archivo:

sjme@debian# nano /etc/snmp/snmpd.conf
y agregar las siguientes lneas (ingresando las redes correspondientes)
com2sec mynetwork 192.168.101.0/24 public
Y luego estas:
group MyRWGroup v1 mynetwork
group MyRWGroup v2c mynetwork
group MyRWGroup usm mynetwork
rocommunity public
Guardar cambios y reiniciar el demonio del snmpd:
sjme@debian# /etc/init.d/snmpd restart
Ahora el zenoss esta listo para iniciarse
Zenos@debian# su zenoss
Password
Y al estar como usuario zenoss, iniciar con:
Zenos@debian# zenoss start
Luego entrar por va Web a la interfaz administrativa con la siguiente url:
http://localhost:8080/zport/dmd
Recuerdar la contrasea dada al usuario admin en la instalacin del ZenossCore.
Instalacin Plug-In Flash Player
apt-cache search flashplugin-nonfree
apt-get install flashplugin-nonfree
Deb
http://apt.debianchile.org/debian-multimedia/
stable
main
http://apt.debianchile.org/debian-multimedia/ stable main

# apt-get update
# wget http://debian-multimedia.org/gpgkey.pub -O - | apt-key add
# apt-get install flashplayer-mozilla
deb http://www.backports.org/debian etch-backports main contrib
deb-src
#apt-get update
#wget -O - http://backports.org/debian/archive.key | apt-key add #gpg --keyserver hkp://subkeys.pgp.net --recv-keys 16BA136C
#gpg --export | apt-key add -
resultado debe ser ok
#apt-get update
apt-get install flashplugin-nonfree
reiniciar equipo
INSTALACION DE ZENPACK
Vamos a la pagina oficial de zenoss, (http://www.zenoss.com), buscamos
la pestaa comunity, zenpack.
Se busca el zenpack que se quiere descargar e instalar en zenoss,
algunos serian , router, switch, cisco, ibm, http, ftp, dns, dhcp...
Se le da clic en el paquete que es compatible con nuestro sistema

operativo enel que se esta trabajando, en este solo aparece este paquete. Se
van al paquete y se le da clic derecho, se guardar el link como, y se ubica
dndole la ruta donde se quiere guardar.
Al descargar todos los zenpack que se necesitan, cuando este guardado,

se entra a la web. En setting, zenpack, install a zenpacks:
Figura B-1 Instalacion de zenpack

Pide la ruta donde quedo guardado el link del zenpack.
Figura B-2.- Gestor de Instalacion

En este caso escritorio y elegimos el zenpack a instalar: abrir. OK.
Figura B-3.- Gestor de Instalacion completa

Asi sucesivamente van agregandose los zenpack.
APENDICE C
FOTOGRAFIAS CENTRO DE OPERACIONES DE RED
MONTADO EN EL LABORATORIO
APENDICE C
FOTOGRAFIAS CENTRO DE OPERACIONES DE RED
MONTADO EN EL LABORSTORIO
Figura C-1 Centro de Operaciones de Red montado
Figura C-2.- Consola de Topologia de Red
Figura C-3.- Consola de Gestion de Eventos
Figura C-4 Consola de Depuracion de Router y Reportes

del Sistema de Gestion
Figura C-5.- Consola de Pruebas de Script SNMPv3

TESIS

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TESIS

Cargado por

Copyright:

Formatos disponibles

PONTIFICIA UNIVERSIDAD CATOLICA DE VALPARAISO CHILE

ESCUELA DE INGENIERIA ELECTRICA

ESTUDIO E IMPLEMENTACION DE ADMINISTRACION

SERGIO JAVIER MONTIEL ESPINOSA

INFORME FINAL DEL PROYECTO

ESTUDIO E IMPLEMENTACION DE ADMINISTRACION

Presentado en cumplimiento de los requisitos

Sergio Javier Montiel Espinosa

Sr. Francisco Alonso

Presentado por el Seor

Valparaiso, Julio 2009

Agradesco a toda mi familia,

ESTUDIO E IMPLEMENTACION DE ADMINISTRACION DE

Sergio Javier Montiel Espinosa

Relevancia del Proyecto Titulo.

PROTOCOLOS DE ADMINISTRACION DE RED

Protocolo de Administracion de Red SNMP

Que puede hacer SNMP? REDES WIFI.ATM..MPLS.ETC

Estructura de funcionamiento de SNMP

Bases de Informacion y Objetos Identificadores

Principales ventajas SNMP

SNMPv3, LA VERSION PARA ADMINISTRACIN

Capacidad en seguridad que cubre SNMPv3

ARQUITECTURA ENTIDADES SNMPv3

Modulo Motor SNMPv3

Modulo Aplicacin SNMPv3

ESTRUCTURA MENSAJE SNMPv3

Seccion PDU header y PDU SNMPv2

ARQUITECTURA ENTIDAD GESTOR

ARQUITECTURA ENTIDAD AGENTE

PROCESO Y PROCEDIMIENTOS DE ALARMAS

Clasificacion por tipo de Alarma

Clasificacion por severidad de la Alarma

PROCESO DE LOCALIZACION DE FALLAS

PROCESO DE PRUEBAS DE DIAGNOSTICO

PROCESO DE CORRECCIN DE FALLAS

PROCESO DE ADMINISTRACION DE REPORTES

Red Ethernet con enlaces Serial (WAN)

CONFIGURACION SNMPv1 Y v2c

Descubriemiento de Topologias de Red

Visor de Objetos Consultados

COMANDOS Y SCRIPT CREADOS PARA SNMPv3

Script Pruebas de Nivel de Seguridad

Script Pruebas de Privacidad

Script de Analisis Preventivo

Script de Testeo de un Equipos

Comando de Escritura en MIB

RESULTADOS DE PRUEBAS SNMPv3

8.3.1.1 Script Prueba de Nivel de Seguridad

:Librera de Infractustura de Tecnologia de la Informacion

: Union internacional de Telecomunicaciones

: Estandar Organizacional Internacional

: Acuerdos de Nivel de Servicio

: Acuerdode Nivel de servicio entre departamentos de una Empresa

: Protocolo de transporte basado en datagramas

: Unidad de datos de Protocolo

: Pequeo programa ejecutado desde linea de comandos

: Protocolo simple de administracion de redes

: Base de infirmacion para la administracion

: Estructura en forma de ramificacion

: Centro de Operaciones de Red

: Sistema de administracion de redes (software)

: Sistema de administracion de Eventos, normalmente incluido en el

: Mensaje de alerta enviado desde el agente cuando alguna