BIBLIOTECAS DEL TECNOLÓGICO DE MONTERREY
PUBLICACIÓN DE TRABAJOS DE GRADO
Las Bibliotecas del Sistema Tecnológico de Monterrey son depositarias de los trabajos recepcionales y de
grado que generan sus egresados. De esta manera, con el objeto de preservarlos y salvaguardarlos como
parte del acervo bibliográfico del Tecnológico de Monterrey se ha generado una copia de las tesis en
versión electrónica del tradicional formato impreso, con base en la Ley Federal del Derecho de Autor
(LFDA).
Es importante señalar que las tesis no se divulgan ni están a disposición pública con fines de
comercialización o lucro y que su control y organización únicamente se realiza en los Campus de origen.
Cabe mencionar, que la Colección de
Documentos Tec,
donde se encuentran las tesis, tesinas y
disertaciones doctorales, únicamente pueden ser consultables en pantalla por la comunidad del
Tecnológico de Monterrey a través de Biblioteca Digital, cuyo acceso requiere cuenta y clave de acceso,
para asegurar el uso restringido de dicha comunidad.
El Tecnológico de Monterrey informa a través de este medio a todos los egresados que tengan alguna
inconformidad o comentario por la publicación de su trabajo de grado en la sección Colección de
Documentos Tec
del Tecnológico de Monterrey deberán notificarlo por escrito a
Sistema de Monitoreo y Alarmas Basado en SNMP-Edición
Única
Title
Sistema de Monitoreo y Alarmas Basado en
SNMP-Edición Única
Authors
Javier Alberto Giese Ruiz
Affiliation
Tecnológico de Monterrey, Campus Monterrey
Issue Date
1994-09-01
Item type
Tesis
Rights
Open Access
Downloaded
18-Jan-2017 14:33:29
B A S A D O EN S N M P
T E S I S
MAESTRÍA EN CIENCIAS
ESPECIALIDAD EN INGENIERÍA DE SISTEMAS
COMPUTA CIONALES
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS
SUPERIORES DE MONTERREY
POR
JAVIER ALBERTO GIESE RUIZ
SISTEMA DE MONITOREO Y ALARMAS BASADO EN SNMP
TESIS
MAESTRIA EN CIENCIAS
ESPECIALIDAD EN INGENIERIA DE SISTEMAS COMPUTACIONALES
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES
DE MONTERREY
POR
JAVIER ALBERTO GIESE RUIZ
POR
JAVIER ALBERTO GIESE RUIZ
TESIS
Presentada a la División de Graduados e Investigación
Este Trabajo es Requisito Parcial
para Obtener el Título de
Maestro en Ciencias
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES
DE MONTERREY
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY
DIVISIÓN DE GRADUADOS E INVESTIGACIÓN
PROGRAMA DE GRADUADOS EN INFORMATICA
Los miembros del comité de tesis recomendamos que la presente tesis del
Ing. Javier Alberto Giese Ruiz sea aceptada como requisito parcial para obtener
el grado académico de Maestro en Ciencias especialidad en:
INGENIERIA DE SISTEMAS COMPUTACIONALES
RECONOCIMIENTOS
Deseo agradecer de la manera más sincera la confianza que depositó en mí
el Ing. Eduardo Salcedo Delgado, mi asesor principal, para diseñar e implementar
este ambicioso proyecto. Su tiempo y su apoyo como asesor y guía fueron tan
importantes para mí como su amistad y entusiasmo, como compañero y amigo.
Esto muestra un ejemplo a seguir para cualquier asesor de Tesis.
También quiero agradecer a todos aquellos que, directa o indirectamente,
intervinieron en la realización de este trabajo, en especial: a mis asesores
secundarios, el Dr. Jorge Olvera y el Ing. Mario de la Fuente, por su confianza
incomparable en mí; a mis compañeros de trabajo, por su preocupación y palabras
de aliento; al Ing. Ciro Velázquez, por su indiscutible apoyo técnico; y sin olvidar a
aquellos grandes amigos que, por su motivación y empuje me animaron siempre a
avanzar y ayudaron a levantarme cada vez que llegué a tropezar.
Javier Alberto Giese Ruiz
Septiembre, 1994
Esta tesis se forma del diseño e implementación de un sistema de monitoreo
para la administración de sistemas conformados de redes heterogéneas. Se
seleccionó, para su elaboración, el empleo de la estación de trabajo NeXT, por las
facilidades que ésta ofrece, para el desarrollo de aplicaciones y las características
propias de este tipo de equipo.
En el presente documento se explican los siguientes aspectos: descripción
breve del protocolo SNMP y definición de su terminología básica; la justificación
del desarrollo de un sistema de monitoreo para la administración de redes
heterogéneas; se describen las características y funciones desarrolladas del
sistema monitor y la forma en que éstas fueron implementadas, y finaliza
comentando las pruebas realizadas y los resultados obtenidos.
TABLA DE CONTENIDO
Página
Reconocimientos v
[image:11.612.99.520.96.643.2]Resumen vi
Tabla de contenido vil
Usta de figuras ix
Lista de tablas x
CAPÍTULO 1. Protocolo SNMP 1
1.1 Antecedentes 1
1.2 Ambiente de SNMP 5
1.2.1 Conveniencia 6
1.2.2 Estaciones administradoras 6
1.2.3 Conceptos de SNMP 7
CAPÍTULO 2. Justificación 11
2.1 Características de sistemas de monitoreo y
administración de redes 11
2.2 Situación actual, el problema y la justificación del trabajo
desarrollado 12
3.1 Características del sistema monitor desarrollado 17
3.2 Descripción de las funciones implementadas en el
sistema monitor 18.
CAPÍTULO 4. Implementación del sistema monitor 20
4.1 Implementación de las funciones de monitoreo 20
4.2 Implementación de las funciones de administración.... 25
CAPÍTULO 5. Pruebas 28
5.1 Pruebas realizadas 28
CAPÍTULO 6. Conclusiones 30
APÉNDICE A. Terminología 39
APÉNDICE B. Rutinas 44
APÉNDICE C. Ejemplos de archivos de registro 82
Bibliografía 92
VITA. 94
LISTA DE FIGURAS
Página
Figura 1.1. Capas de SNMP 5
Figura 1.2. Relación entre el Administrador, SNMP y objetos administrados.. 8
Figura 2.1. Protocolos de administración incompatibles de diferentes firmas. 13
[image:13.612.89.529.74.576.2]Figura 2.2. Protocolos de administración compatibles de diferentes firmas.... 16
Figura 4.1. Aplicación desarrollada para monitoreo bajo SNMP 20
Figura 4.2. Ejemplo del menú principal seleccionando la opción Alarmas 21
Figura 4.3. Ejemplo de funciones seleccionadas disponibles a monitorear.... 22
Figura 4.4. Botón para activación de proceso de monitoreo 22
Figura 4.5. Botón para inicializar área de funciones para monitorear 23
Figura 4.6. Botón de Alarma que indica alguna anomalía en el monitoreo 23
Figura 4.7. Ejemplo del panel de fallas ante un problema 24
Figura 4.8. Panel principal 24
Figura 4.9. Opciones de activación de alarma 25
Figura 4.10. Funciones disponibles para monitoreo y control de la red 25
Figura 4.11. Ejemplo de la selección de un parámetro 26
Figura 4.12. Panel de parámetros y descripción de la función 26
Figura 4.12. Ejemplo de un Get 27.
Página
Tabla 1.1 Evolución de los protocolos de monitoreo 3
CAPITULO 1
Protocolo SNMP
Conforme pasan los anos, más compańías que se dedican al desarrollo de
sistemas de cómputo y cornunicaciones, producen nuevas estaciones de trabajo y
servidores de terminales e impresión, nuevos sistemas de compuertas de
comunicación y dispositivos como puentes, concentradores y multicanaJizadores, y
los introducen al mercado, complicando más la tarea de administración de redes.
El problema se visualiza cuando se desea interconectar y comunicar todos
estos dispositivos al unísono. Debido a la heterogeneidad del equipo en casi
cualquier red actual, es imperativo el manejo de un protocolo común para facilitar
su administración.
En 1990, SNMP (Simple Network Management ProtocoJ) se establece como
protocolo estándar con estatus de "recomendado" por IAB (Internet Activities
Board), el cuerpo encargado en el desarrollo técnico de protocolos para la red
Internet
1.1 ANTECEDENTES.
Axioma Fundamental:
"El impacto de agregar administración de la red a nodos administrados debe ser
mínima, reflejando un mínimo común denominador." [Ros,91]
Debido a un rápido crecimiento de redes conectadas a Internet la
responsabilidad de administrar partes de la red a un nivel de columna principal y el
uso de equipo de diferentes firmas, fue necesario crear un modelo de
administración de redes que cubriera estas necesidades.
En la tabla 1.1 se muestra el desarrollo de protocolos de administración,
desde que se tenía únicamente un monitoreo de nodos hasta que aparece SNMP
como protocolo estándar.
La investigación preliminar se encaminó a los protocolos de transferencia de
ciatos, sin prever el impacto que la administración tendría cuando estos protocolos
se difundieran considerablemente. Las primeras redes utilizando estos protocolos
se conectaron a través de compuertas de comunicación del mismo distribuidor. En
los 80's, las redes incrementaron su tamańo a más del doble, y se conformaron
por distintos distribuidores. De esta forma, la administración de la red se llevaba a
cabo por diversas organizaciones, cada una encargada de un nivel diferente de la
3
1987 SGMP Simple Gateway Monltorlng Protocol
HEMS Hlghlevel Entity Management System
OSI networfc management protocol and framework
CMOT
CMIP Common Management Information Protocol
TCP Transmlsslon Control Protocol
1988 IAB Internet A c t l v l t f e s Board
SGMP
CMOT
SNMP
1989 SNMP se eleva a status recomendable
[image:17.612.99.526.84.345.2]1990 SNMP.SMI V MIBI se elevan a protocolos Estándar
Tabla 1.1 Evolución de protocolos de monitoreo.
En 1987, un pequeńo grupo de gurús en redes, tanto investigadores como de
la industria, decidieron llevar algo a cabo para resolver este problema. Un primer
esfuerzo se presentó produciendo un protocolo de monitoreo simple de
compuertas de comunicación (SGMP), que en poco tiempo tuvo una creciente
aceptación en el exterior. Un segundo esfuerzo fue un proyecto de investigación,
llamado Sistema de Administración de alto nivel de Entidades (HEMS), que
aunque tuvo novedosos conceptos, nunca vio la luz. El tercer esfuerzo lo llevó a
cabo gente de la comunidad de Internet, proponiendo utilizar el protocolo de
administración de red de la OSI, basado en tos protocolos de Internet. Esto se
Tiempo después, en 1988, el Consejo de Actividades de Internet (IAB) reunió
un comité para resolver la controversia entre las tres opciones. Se analizaron
estas propuestas y de ellas se vio que HEMS sufría la desventaja de no tener la
aceptación de SGMP, ni el respaldo de la OSI con que contaba CMOT. De aquí
emergieron dos posibilidades:
1. SGMP fuera utilizado como protocolo de administración de redes en la
comunidad Internet, pero como solución a corto plazo.
2. La propuesta basada en OSI tuviera mayor apoyo en investigación y
experimentación, para eventualmente convertirse en la solución a largo plazo.
De estas dos nuevas propuestas, se desarrolló un protocolo que siguiera los
lineamientos tanto de SGMP como de CMOP, apareciendo el protocolo llamado
Protocolo Simple de Administración de Redes (Simple Network Management
Protocol, SNMP).
Este nuevo protocolo se eleva en 1989 a un estatus de "recomendado", y se
convierte en el estándar operacional de tacto para la administración de redes
basadas en TCP/IP. Rápidamente se percibió la aceptación de SNMP al incluir
diversos distribuidores, una mínima implementación de este protocolo en sus
productos.
Un ańo después, en 1990, la Estructura de Administración de Información
(SMI), la Base de datos de Administración de Información (MIBI) y SNMP se
5
1.2 AMBIENTE DE SNMP.
SNMP fue inventado a fines de los 80's para ayudar a administrar Internet la
red académica y de investigación basada en TCP/IP, y desde entonces el
protocolo se volvió un estándar Me tacto" para la administración de redes. En
teoría, SNMP permite a cualquier estación de administración que use el protocolo
SNMP monitorear y controlar cualquier dispositivo de la red o computadora que
entienda SNMP. En la práctica, esto es un poco más complicado, puesto que
[image:19.612.137.473.316.508.2]involucra atravesar varias capas de protocolos, tal y como lo muestra la figura 1.1.
Figura 1.1. Capas de SNMP.
SNMP necesita de tres tipos de software: uno para el administrador (software
para administración de redes), y dos para cada dispositivo que se quiera
A diferencia del software de administración de redes propietario, el software
de administración de SNMP no proviene de una sola fuente. Una compańía que
construye ruteadores escribirá su propio agente SNMP y su propio MIB, pero la
estación de administración puede venir de cualquier otro lado. No obstante, la
estación administradora y el software de los dispositivos no trabajarán entre sí a
menos que ambos utilicen el mismo protocolo de transporte.
1.2.1 CONVENIENCIA.
SNMP puede ahorrar tiempo y frustraciones, pero sólo si se está
administrando una gran red. SNMP requiere de una inversión significativa de
tiempo por parte del administrador, para aprender el software, para configurarlo a
su medio de trabajo, para afinarlo, y para hacer uso de la información que se
recolecte.
En otras palabras, si la red consiste de cinco PCs y una impresora Láser,
SNMP no es k) indicado. Pero si tiene una red en crecimiento, expansión o
multiprotocolo, lo más seguro es que se necesite de SNMP.
1.2.2 ESTACIONES ADMINISTRADORAS.
La mayoría de las estaciones de administración tienen dos funciones
primordiales: monitoreo y configuración. Una estación monitorea una red al
efectuar sondeo periódicamente a cada dispositivo y tomando la acción
correspondiente en caso de problemas. Algunas estaciones, únicamente prueban
7
activo y corriendo?) Otras, se encargan de actividades más sofisticadas, como
solicitudes, verificación de razones de error, razón de desempeńo, y otros
importantes indicadores de la "salud" de la red.
Cuando hay un problema, la estación administradora puede llevar a cabo
distintas acciones: puede escribir un archivo de log, hacer sonar una alarma
audible(como un "beep" o algún sonido pregrabado), enviar un mensaje de correo
electrónico, o enviar un mensaje ai Radio Beep del administrador de la red con las
malas nuevas.
La otra tarea de la administración es la configuración. Conforme se van
agregando nuevos dispositivos a la red, y el estatus de la misma cambia, también
deben modificarse los valores de omisión que vienen de fábrica. No hay que
perder de vista que las estaciones de administración sólo pueden controlar
dispositivos en la red hasta el extremo que sus agentes y sus MIBs lo permitan.
1.2.3 CONCEPTOS DE SNMP.
El modelo de SNMP para la administración de redes se basa en tres tipos
básicos de software: agentes, MIBs y estaciones de administración.
Los agentes son software que corre en cada dispositivo de la red. Ellos
tienen información almacenada en una base de datos llamada MIB, que reside en
el dispositivo. En la figura 1.2 se muestran las operaciones básicas a través de los
cuales se mantienen en contacto el sistema administrador con tos agentes, ya sea
[image:22.612.82.474.46.336.2]
(23)Frontera para el peso de PDUe
Figura 1.2. Relación entre el Administrador, SNMP y objetos administrados.
Las estaciones de administración permiten recuperar y mostrar información
recolectada del agente de un dispositivo y de un MIB. Ocasionalmente, las
estaciones administradoras pueden incluso controlar (a través de un SET, en
términos de SNMP) estos dispositivos.
Cada registro en un MIB es conocido como una variable de esa MIB. Por
ejemplo, una variable común de MIB para una computadora Macintosh es
sysDescr, la cual describe el hardware y software del sistema. Si se utiliza una
estación administradora para recuperar (a través de un GET, en términos de
SNMP) la variable sysDescr de una Macintosh, se obtendrá una respuesta como
9
Dependiendo de qué tan sofisticada sea la estación administradora de la red,
se podrá conseguir cada parte de la información de distintos dispositivos
separadamente, o se podrá conseguir por completo de una sola vez. Igualmente,
la forma en que la información se desplegará e interpretará dependerá del
software de la estación administradora.
También puede almacenarse información que un agente de SNMP no puede
recolectar desde una computadora con una variable del MIB. Por ejemplo, puede
asignarse (SET) la variable sysLocation de una computadora en particular que sea
Edificio Administrativo, oficina 102. Un administrador que luego solicite esta
variable podrá conocer dónde se encuentra localizado este equipo.
Además de las operaciones básicas de Get y Sel SNMP también cuenta con
Traps, esto es, avisos de eventos enviados por el agente de un dispositivo de la
red a la estación administradora. Esta operación ayuda a los administradores a
observar la red sin tener que estar preguntando constantemente a cada dispositivo
su información de estado. Por ejemplo, un Trap es CoIdStart, el cual envía el
agente de un ruteador cada vez que este se reinicializa. Igualmente, lo que lleva a
cabo una estación administradora cuando recibe un Trap, varía. Puede solamente
escribir la información en un archivo, o enviarla al administrador por correo
electrónico (email) o a su "beeper", o podría iniciar alguna otra acción, como bajar
la información de la configuración del dispositivo.
Hay muchos tipos de MIBs definidos para SNMP. El MIB básico, llamado MIB
II (el cual reemplazó al MIB I) incluye un conjunto básico de variables para
MIB estándar, pero muchas otras definen MIB privados que trabajan únicamente
con sus equipos. Este tipo de MIBs comúnmente incluyen opciones estadísticas
especiales o de configuración que no están definidas en MIB I o II. Muchos
dispositivos de redes soportan más de un MIB, y de esta forma, una estación
administradora puede tener además del MIB básico, uno privado. Así, por ejemplo,
un ruteador puede tener un MIB privado que sólo es útil para él, y que no tiene
significado alguno para un concentrador, aún y cuando ambos utilicen además el
CAPITULO 2
Justificación
2.1 CARACTERÍSTICAS DE SISTEMAS DE MONITOREO Y ADMINISTRACIÓN
DE REDES.
żPor qué es importante un buen sistema de monitoreo y de administración de
redes? Porque actualmente las redes están en continuo crecimiento y cada vez
más se van formando de diversos dispositivos de distintos distribuidores. Tanta
heterogeneidad en el equipo puede hacer difícil la labor de administración y
monitoreo de una red, especialmente si ésta de por sí ya es grande.
Por ejemplo, en caso de falla de un ruteador, un sistema debe ser capaz de
accesar la información y mensajes de error de la última hora a la computadora del
administrador, luego sonar una alarma y marcar un "beeper". Cuando el
administrador se dé de alta, toda la información que necesite la tendrá ahí.
Un administrador de una red puede utilizar un protocolo de administración si
quiere extraer información de un dispositivo indistintamente de su configuración y
estatus, así como información del tráfico entrante y saliente.
Para tener un dispositivo bajo un estándar de administración, un distribuidor
debe instalar una cierta cantidad de software "agente" en él. Un agente maneja
todas las solicitudes entrantes de un "administrador", el cual puede preguntar al
agente a leer o actualizar la base de datos de información de administración (MIB).
No obstante, un agente no siempre tiene que esperar a que se le pregunte por la
información: cuando aparece un problema serio, el agente puede notificar a uno o
más administradores.
El problema de administrar una red puede verse como cinco subprobiemas:
* Administración de la configuración, la cual es la responsable de detectar y
controlar el estado de la red (tanto la configuración lógica como la física).
* Administración del desempeńo, la cual es la responsable de controlar y analizar
características de desempeńo y la razón de errores en la red (incluyendo
información histórica).
* Administración de fallas, la cual es la responsable de detectar, aislar y controlar
el funcionamiento anormal de la red, como excesivos cortes de electricidad.
* Administración de contabilidad, la cual es la responsable de reunir y procesar
información relacionada al consumo de los recursos en la red.
* Administración de la red, la cual es la responsable de controlar el acceso a los
recursos de la red a través del uso de técnicas de autentificaáón y políticas de
autorización.
2.2 SITUACIÓN ACTUAL, EL PROBLEMA Y LA JUSTIFICACIÓN DEL TRABAJO
DESARROLLADO.
El ITESM Campus Monterrey cuenta con una red heterogénea, formada por
arquitecturas tales como Token Ring, Ethernet y AppleTaJk. Dentro del equipo
existente, se cuenta con máquinas IBM, Apple, Digital, SUN y HP. Luego
13
(Ver figura 2.1).
[image:27.612.159.405.93.374.2]żCuál fabricante? żFormato del mensaje? żSignificado de los campos?
Figura 2.1. Protocolos de administración incompatibles de diferentes firmas.
La red del Campus tiene un anillo principal de fibra óptica que comunica a
todos tos edificios a 10 Mbps. A este anillo se conectan el rastro de las redes
existentes, que son otros anillos (a 4 Mbps), Ethernet (a 10 Mbps) y AppleTaik (a
256 Kbps).
Los tipos de enlaces siendo utilizados actualmente son:
* Microondas, para la comunicación con la escuela de medicina.
* Satélite, únicamente para comunicarse con la UNAM.
* RDI, hacia EU, a tos Campus Eugenio Garza Sada y Eugenio Garza Lagüera. y
Los servicios y aplicaciones que se ofrecen a través de la red son muy
diversos. Por ejemplo:
* Correo electrónico.
* Emulación de terminal.
* Transferencia de archivos.
* Compartición de recursos y aplicaciones.
La administración de la red es llevada a cabo en el centro de cómputo,
utilizando paquetes tales como Sniffer y LANManager. Sniffer provee la facilidad
de "capturar" y analizar tos paquetes que circulan por la red Ethernet mientras
que LANManager provee funciones de administración sólo sobre Token Ring.
Debido al tipo de aplicaciones y servicios soportados en las distintas redes
del Instituto, la carga de trabajo en cada una de ellas es muy distinta. Mientras que
en ciertas fechas existe una gran demanda de las redes académicas por el uso de
aplicaciones estadísticas, aplicaciones que permiten grupos de discusión y
herramientas computacionales de diseńo, las redes administrativas se mantienen
relativamente a un mismo nivel de demanda, empleando comunicación entre
usuarios, la compartición de recursos y aplicaciones y la transferencia de archivos.
Cuando aparece un problema en la red, LANManager emite un sonido de
alarma una sola vez, y si alguien cercano a éste lo escucha, entonces podrá saber
de la falla. En caso contrario, esta aplicación da por hecho el servicio de alarma, y
15
máquina dedicada con este paquete para poder tener conocimiento de las fallas
en la red, ya sea por el sonido de la alarma, o por buscar en alguna parte de la
pantalla si nace mención a alguna falla específica. Lo que se hace actualmente es
que la gente encargada de la red tiene asignada la obligación de verificar, cada
vez que pase cerca del LANManager, si existe o no alguna falla en la red del
Campus.
Sin embargo, la mejor aJarma para detectar fallas en la red siguen siendo los
usuarios. Una vez que éstos tratan de accesar los servicios de la red y no pueden
hacerlo, simplemente se comunican con las personas encargadas de su
mantenimiento y reportan la falla.
El uso de la administración dentro de la red permite reducir los promedios de
fallas al monitorear aquellas situaciones que pueden provocar problemas, y así
lograr que la red trabaje más eficientemente y mantener a los usuarios felices.
Minimizar el número de usuarios afectados por una falla es una importante
regla en la administración de la red. Esto tiene mucho que ver tanto con la
productividad personal como con la integridad de la red. Es más fácil tratar con 12
usuarios enojados que con 120.
En una red bien administrada, una falla debe ser identificada y corregida
fácilmente. Para esto, un adecuado protocolo de administración como SNMP y su
estandarización en todos los dispositivos que se desean administrar en la red,
[image:30.627.185.417.68.332.2]
(31)CAPITULO 3
Descripción del sistema monitor desarrollado
3.1 Características del sistema monitor desarrollado
Un servicio de administración de red se orienta, de manera general, a
básicamente tres usos:
* Monitoreo, en donde se reúne la información de administración.
* Control, en donde los dispositivos son manipulados.
* Reporte, en donde los dispositivos reportan eventos fuera de lo normal.
Para el área de monitoreo, se implementaron funciones para recabar
información de dispositivos siendo administrados. Estas funciones incluyen:
* preguntar directamente sobre información específica a algún dispositivo
* generar un archivo o Tog" de monitoreo en donde se escriben todas las
actividades que se llevan a cabo en esta área. Este archivo tiene un nombre por
omisión y ofrece la posibilidad de modificarlo por otro nuevo.
Para el área de control, se puede solicitar la modificación de variables de
dispositivos bajo SNMP, a través de una función SET. Cualquier actividad de
control se registra automáticamente en el mismo archivo de monitoreo.
Los reportes de eventos anormales que aparezcan durante la ejecución de
este aplicación, aparecerán directamente en pantalla en una sección asignada
para ello. Además, estos reportes serán almacenados en un archivo de eventos
extraordinarios cuyo nombre está asignado por omisión, con la posibilidad de
cambiado por otro distinto.
3.2 Descripción de las funciones implementadas en el sistema monitor.
El protocolo de SNMP utiliza relativamente operaciones simples y un número
limitado de unidades de datos del protocolo (PDUs) para llevar a cabo sus
funciones. Estas funciones accesan información del MIB, el cual presenta la
información en una estructura de datos de tipo árbol. Se han definido cinco PDUs
en el estándar, y son los siguientes:
* Get Request Este PDU es utilizado para accesar al agente y obtener valores de
una lista. Ésta lista contiene kientificadores que el agente distingue de entre
múltiples posibles solicitudes de acuerdo a los parámetros dentro de un PDU, así
como valores para ofrecer información sobre el estado del dispositivo en la red.
* GetNext Request: Este PDU es similar al del Get Request, excepto en que éste
permite regresar el siguiente ˇdentificador lógico en un árbol MIB. Es decir,
mientras que el Get Request busca cierto valor dentro de la estructura del árbol,
GetNext busca el siguiente valor al especificado en el PDU, según su recorrido
19
* Get Responso: Este PDU responde a las unidades de datos Get Request, Get
Next Request y Set Request Contiene un identificador que lo asocia con el
anterior POU (de tipo Request). También contiene identificadores para ofrecer
información sobre el estado de la respuesta (códigos de error, estatus de error, y
una lista de información adicional).
* Set Request Este es utilizado para describir una acción a ser ejecutada sobre un
elemento. Típicamente es utilizado para cambiar tos valores de una variable en
una lista, dentro de la estructura de árbol del MIB.
* Trap: Este PDU permite al móduio de administración de la red reportar un evento
Implementación del sistema monitor
[image:34.612.93.515.161.589.2]4.1 Implementación de las funciones de Administración.
Figura 4.1. Aplicación desarrollada para monitoreo bajo SNMP.
21
Como se muestra en la figura 4.1, la aplicación desarrollada prácticamente se
divide en dos grandes partes:
1. En la primer parte pueden realizarse funciones de recolección de información y
de modificación de datos en ios dispositivos siendo administrados bajo el protocolo
de SNMP. Esta sección se explicará más a detalle en el siguiente punto del
capítulo.
2. En la segunda parte se muestra la sección de reporte de fallas. Dicha sección
consta a su vez de dos secciones: una de selección y activación de funciones a
[image:35.612.143.455.349.566.2]monitorear y otra de reporte de fallas y errores..
Figura 4.2 Ejemplo del menú principal seleccionando la opción Alarmas.
* La sección de selección de funciones presenta cuatro campos en donde se
mostrarán las posibles funciones a monitorear. Utilizando la opción de Alarmas del
parámetro,
ta cual duplica el contenido del campo Parámetro en la primer localidad
de las cuatro que se encuentre libre, incluyendo el nombre de la función que se
[image:36.612.96.496.164.273.2]encuentre seleccionada en ese momento.
Figura 4.3 Ejemplo de funciones seleccionadas disponibles a monitorear.
Es posible tener tos cuatro campos de funciones ocupados, pero sin tenerlas
activadas, como lo muestra la figura 4.3. Para llevar esto a cabo, es necesario
presionar el botón que se encuentra a un lado de la función que se desee
empezar a monitorear. Pueden activarse todas o sólo aquellas con las que en ese
momento se quiera empezar a trabajar. Una vez activadas las funciones, debe
presionarse el botón
Activar Monitoreo
para que éste se lleve a cabo. (Rg. 4.4)
Figura 4.4 Botón para activación de proceso de monitoreo.
Para detener el monitoreo, debe presionarse el botón Detener Monitoreo.
Cuando este proceso esté detenido, es cuando se pueden seleccionar otras
funciones, o activar o desactivar otras. Esto es, presionando el botón a un lado de
[image:36.612.230.358.502.563.2]23
[image:37.612.230.367.106.165.2]presionar el botón
zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBAInicializar
mostrado en la figura 4.5.
Figura 4.5 Botón para inicializar área de funciones para monitorear.
* El botón de alarma (Fig. 4.6) se encenderá cada vez que ocurra algún evento
fuera de lo normal en cualquiera de los dispositivos siendo administrados. Seguirá
encendido hasta que el administrador de la estación lo presione, apagándolo. En
este momento, la pantalla se limpiará y volverá a aparecer la leyenda: Todo está
funcionando correctamente."
Figura 4.6 Botón de Alarma que indica alguna anomalía en el monitoreo.
* El área de reporte de eventos extraordinarios mostrará las razones por las
cuales se activó el botón de fallas, o bien, algún mensaje relacionado con la
selección y activación de funciones de monitoreo. Observando las razones de falla
o de error en el panel, el administrador puede decidir cuál es la siguiente acción a
[image:37.612.104.362.369.512.2]
[image:38.612.68.534.72.233.2]
(39)Figura 4.7 Ejemplo del panel de fallas ante un problema.
Mientras no se presione el botón de
zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBAalarma,
los mensajes de error por
alarmas seguirán en el panel de aviso, y se irán acumulando con los nuevos que
se lleguen a presentar. En todo momento, estos mensajes estarán siendo
grabados al archivo por omisión ERRORES.TXT, o bien, al archivo asignado por el
administrador mediante la opción Log fallas. (Ver figura 4.8)
Figura 4.8 Panel principal.
[image:38.612.230.350.439.683.2]25
Una alarma sonará en el momento de que lleguen tos mensajes de error, y se
tendrá la opción de que suene únicamente en ese caso, o bien, que suene cada
cierto intervalo hasta que la falla sea atendida, según se haya seleccionado en los
[image:39.612.208.387.190.290.2]botones de la figura 4.9..
Figura 4.9 Opciones de activación de alarma.
4.2 IMPLEMENTACION DE LAS FUNCIONES DE MONITOREO.
Como ya se mencionó anteriormente, las funciones de monitoreo y control se
llevan a cabo a partir de tres funciones de SNMP donde el administrador tiene ei
control. Estas son: Get Request, GetNext Request y Set Request, como lo
muestra la figura 4.10, proveniente de la pantalla del sistema monitor.
[image:39.612.212.404.548.651.2]De acuerdo a la función seleccionada, en el campo lateral a las operaciones
disponibles, se mostrarán los parámetros seleccionados por medio de cualquier
submenú de la opción Parámetros del menú principal (ver figura 4.11),
[image:40.612.145.472.171.386.2]correspondientes a la función.
Figura 4.11 Ejemplo de la selección de un parámetro.
En el panel inmediato inferior, se desplegará un pequeńo texto explicando la
[image:40.612.78.480.519.642.2]utilidad de la función seleccionada. (Ver figura 4.12)
27
Conforme ai valor del parámetro, en el panel de respuesta a la operación
aparecerán precisamente aquellos valores que fueron solicitados, o en su caso, un
mensaje de respuesta por la activación de un Set.
A continuación se presenta en la figura 4.13 un ejemplo de un Get,
solicitando la información de la dirección del siguiente salto de un ruteador
(ipRouteNextHop) cuya dirección de ip es 128.11.4.1; parámetro cuya dirección
completa se vería como:
iso.org.dCKJ.intemet.mgmt.mib.ip.ipRoutingTable.ipRouteEntry.inRoutNextHop.128.
[image:41.612.80.476.374.614.2]11.4.1.
Pruebas
5.1 PRUEBAS REALIZADAS.
Con la aplicación se llevaron a cabo varias pruebas, a lo largo de su
implementación. Esto es, como fue evolucionando la aplicación debido a cambios
necesarios por modificación de su diseńo, sugeridos por el asesor y por el tesista,
y por limitación de las funciones de SNMP empleadas.
Para la fase de monitoreo, la función que más se utilizó fue la de Status. Esto
fue debido a su facilidad de empleo, al no necesitar de muchos parámetros y
principalmente porque no presentó ningún problema al momento de su
implementación en la aplicación. Con esta función se estuvieron monˇtoreando
manualmente todas las máquinas Academ (académicas) del campus, así como la
máquina Campus, y varios ruteadores y multiplexores entre las máquinas siendo
monitoreadas y la computadora que ejecutó la aplicación a prueba.
Del uso de la función Status, se obtuvieron archivos de registro con toda la
información de monitoreo desde que se empezó a utilizar la función hasta que ésta
fue depurada. En estos archivos se aprecian los cambios que se llevaron a cabo
con la implementación de esta función. Un ejemplo de estos archivos se presenta
en el apéndice C.
29
Las funciones GetNext y Get no fueron tan utilizadas como la función Status,
debido a que las dos primeras rutinas fueron diseńadas principalmente para
ejecutarse a nivel Shell. Este tipo de diseńo permite declarar variables e
iniciaiizarlas al mismo tiempo, facilitando su implementación, pero adecuado sólo
para una sola ejecución. En el caso específico de la aplicación siendo
desarrollada, se necesitó poder ejecutar cada función más de una vez. Se tuvieron
que hacer modificaciones a las rutinas para adecuarlas a la aplicación, pero fueron
tantas las diferencias en el diseńo, que fue necesario contactar al grupo de
personas que diseńaron las rutinas para resolver el problema.
En la sección de alarmas, la función que más se utilizó durante la fase de
pruebas fue Status, por el problema anteriormente mencionado. Para verificar el
buen funcionamiento del sistema de alarmas, se utilizó el monitoreo automático a
las máquinas académicas, principalmente. En un principio fue difícil saber si esta
característica funcionaba correctamente, debido a que nunca fallaron estas
máquinas durante su monitoreo. Si al empezar a monitorear estos equipos, alguno
no estaba funcionando, la aplicación lo seńalaba sin ningún problema. Pero
durante el monitoreo, no se percibió ningún cambio en estas máquinas. Fue
entonces cuando se empezaron a utilizar dispositivos más pequeńos para su
monitoreo automático (computadoras personales ejecutando software agente de
SNMP) y poder simular su mal funcionamiento para verlo reflejado en la aplicación
Conclusiones
La aplicación desarrollada puede utilizarse como una buena herramienta para
la administración de redes heterogéneas. Debido a que el departamento de Redes
de este campus no cuenta con una aplicación que permite monitorear dispositivos
de tantas compańías distintas, el resultado de esta tesis puede, sin sustituir
aquellas aplicaciones similares con las que cuenta ese departamento,
complementar la tarea de administración y monitoreo de tos dispositivos de redes.
De acuerdo a tos resultados obtenidos, se puede observar que esta
aplicación todavía tiene un camino para desarrollo potencial. Aún y cuando tiene
desarrollada toda una interíase de monitoreo y alarmas para dispositivos
heterogénos, aspecto muy importante en la administración de redes en la
actualidad, podría mejorarse incluyendo fases como ambientes gráficos y
posibilidad de control de dispositivos. El mantenimiento de esta aplicación es
simple gracias a la clara identificación de sus componentes, lo cual ofrece a su
vez, una gran posibilidad para el desarrollo de tos nuevos aspectos antes
mencionados.
El gran problema en el desarrollo e implementación de esta tesis fue el
depender de las rutinas básicas de las funciones de SNMP, implementadas en la
universidad de Carnegie Mellon. Sus diseńos de las funciones fueron pensados
para ser ejecutados una sola vez, lo cual limitaba enormemente la functonaiidad
de una posible aplicación empleando estas funciones. Una de las funciones se
31
logró adaptar sin ningún problema, pero las otras dos que se incluyeron en esta
tesis no se adaptaron sino hasta después de muchos problemas. Fue necesaria la
asesoría de la gente de Camegie Mellon para resolver el problema de
incompatibilidad. Si en un principio se hubieran previsto estos problemas, tal vez
hubiera sido mejor redefinir la tesis, para diseńar desde cero estas funciones, y no
. depender de las rutinas de otra gente.
Debido a la posibilidad de empleo de esta tesis en el departamento de redes
de este campus, así como en cursos académicos de esta área, una mejora de
esta aplicación sería deseable. Esta mejora podría observarse como dos posibles
tesis que lleven precisamente ésta a cabo. La primera podría encaminarse a
implementar la función Set, con la cual se podría controlar y configurar cualquier
dispositivo que se encuentre ejecutando bajo el protocolo de SNMP, y también,
agregar el aspecto de acciones de respuesta a la función Trap. Así mismo, se
podría incluir la facilidad de construir "macros" o conjunto de instrucciones y
funciones para aumentar la facilidad de administración de redes. La segunda tesis
podría encaminarse al desarrollo de un ambiente gráfico de la aplicación, y a la
generación de gráficas en base a los archivos que ya genera la aplicación y en
base a las funciones ya implementadas en la misma.
El diseńo, implementación y desarrollo de esta aplicación cumplió con las
expectativas de la gente que en ella intervino, pero no será sino hasta que se
emplee con fines administrativos y académicos cuando se cumpla su verdadera
finalidad: su uso como una herramienta para la administración de redes, que
permita monitorear dispositivos bajo un mismo protocolo, sin importar de qué
fabricante sea, y prevenir y detectar en lo posible, fallas en los dispositivos en red
39
Apéndice A
Conceptos
COMPONENTES
Un sistema administrados de redes contiene tres componentes:
* Diversos nodos administrados, cada uno conteniendo un agente.
Host System (Estación de trabajo, servidor de terminales)
Gateway System (Compuertas de comunicación)
Media device (Puentes, concentradores, multícanalizadores)
* Cuando menos una Estación de Administración de la Red (NMS).
Protocolo de Administración de la Red.
Aplicaciones de Administración de la Red.
* Un protocolo de administración de la Red.
Cada nodo administrado puede verse como si tuviera algunas "variables".
Leyendo estas varíalbes, el nodo es monitoreado.
Modificando esas varíalbes, el nodo es controlado.
Otras operaciones:
• Traversal: Permite a la estación administradora conocer las variables que
soporta un nodo administrado.
Trap: Permite a un nodo siendo administrado reportar eventos extraordinarios a
REPRESENTACION DE LOS DATOS
ASN1 (Abstract Syntax Notation One)
BER (Basic Encoding Rules)
Colección de descripciones de ASN1: Módulo.
Un módulo puede importar o exportar definiciones a otro módulo.
Se definen tres tipos de objetos:
tipos (define nuevas estructuras de datos)
valores (instancias o variables de un tipo)
macros (para modificar la gramática de ANS1)
ASN1 utiliza cuatro tipos:
simples (enteros, stringoctetos, identificador de objetos y nuil)
estructurados (estructuras y arrays)
etiquetados
subtipos
FUNCIONES BASICAS
Cuatro operaciones básicas se definen en este protocolo:
* get (utilizada para obtener información de administración)
* getnext (utilizada para obtener, por recorrido del MIB, información
° set (utilizada para manipular información administrativa)
* trap (utilizada para reportar eventos extraordinarios)
Comunidad: relación entre un agente SNMP y uno o más administradores SNMP.
PROTOCOLO
Apéndice B
Rutinas
r
Generated by Interface Builder ALARMA.HV
#ˇmport <objc/Objecth>
© interface CopiaAlarrna:Object
{
}
activa3Method:sender;
activa2Method:sender;
• activa1Method:sender;
sonido1Method:senden
copiarMetnod.sender;
activa4Method:sender;
sonˇdo2Metbod:sender;
inicializarMethod:sender;
detenerMethod.sender;
45
r Generated by Interface Buiider ALARMA.MV
#ˇmport *CopiaAlarma.h' iimport "appWt/Form.h" «knport •appktt/Vtew.h" «knport 'appkit/Button.h' «inciude •string.h" «inciude •sya/time.h" «inciude 'stdto.h" //«inciude 'snmpstatus.c'
int detenido = 1;
extem char parametro{80]; extern char funcion[20]; int botón 1 = 0;
int boton2 = 0; int boton3 = 0; int botorvt = 0; int libre 1 = 1; int Hbre2= 1; int Iibre3= 1; int libre* =1;
char hostalarmal [20],r»stalarma2[20],hc«talarma3(20],hostalarma4[20];
Oimptementaüon CopiaAiarma
activa3Method:sender {
FILE 'archivo; //vari able para nombrar el archivo
char respakJo{500];
//variables para manipulación de strings
struct timeval tiempo 1; //estr uctura para leer tiempo
struct timezone tiempo2; time_tc;
char'tiempo;
extem char elhost(20]; //vari able ya definida con el nombre del host
gettimeofday(&tiempo1 ,&tiempo2); c = tiempo1.tv_sec;
tiempo s ctime(&c);
If (detenido = 1) {
H (boton3 » 0) {
[reporteOutJet setStiing Valué: 'Alarma 3 activada.U)*]; boton3= 1;
strcat(respaklo,'Alarma 3 activada:"):
strcat(respaldo,(char *) [aiarmaSOutlet stringValue]); strcat(respakJo,"\n\n");
archivctefopen('alarrnas.log","a+"); ^>uts{respaido^rchivo); fcJose(archivo);
8trcpy(hostalarma3,elhost); 8trcat(hostalarma3,aV0*); }
else {
[alarma30utlet setStringVakje:"^*]; boton3 = 0;
Iitxe3 = 1;
[reporteOutJet setStringVaJue:"Alarma 3 desactivada. \0"]; strcat(respaldo,"AJarma 3 desactivada:");
strcat(respaldo,(char *) [alarma30utlet stringValue]); strcat(respaldo,'\n\n');
archrvo=fopen("alarmas.log,,,a+");
fputs(respakJo,arcriivo); fdose(archívo);
}
} etee {[activa30uttet setStaterO];}
return self; }
actrva2Method:sender {
FILE 'archivo; //vari abte para nombrar el archivo
char respaldo[500];
//variables para manipulación de stríngs
struct timeval tiempo 1; //estr uctura para leer tiempo
struct timezone tíempo2; time_tc;
char'tiempo;
47
able ya definida con el nombre del host
gettimeofday(&tiempo1 ,&tiempo2); c = tiempo 1 .tv_sec;
tiempo = ctime{&c);
strcpy(respaldo,tiempo);
if (detenido ==1) {
if (boton2 = 0) í
[reporteOutiet setString Valué: 'Alarma 2 actívadaAO"]; boton2 = 1;
strcat(respaido/Alarma 2 activada:");
strcat(respaldo,(char *) [alarma20utlet stringValue]); strcat(respakío,"\n\n");
archivo=fopen("aJarrras.kxjYa+'); fputs(respakJo .archivo); fclose(archivo);
strcpy(hostalarma2,elhost); strcat(hostalarma2,a\0");
}
else í
[alarma20utlet setStringValue: V)"]; boton2 = 0;
Iibre21;
[reporteOutiet setStringValue.'Alarma 2 desactivada. V0"]; strcat(respaldo,"Alarma 2 desactivada:");
strcat(respaldo,(char *) [alarma20utlet stringValue]); strcatírespaldo.'vivV);
ar{^rvc=fopen("alarrnas.tog","a+"); fputs(respaldo,archivo);
fclose(archrvo);
}
} else {[activa20utiet setState:0];}
return self;
}
activa 1 Method:sender í
abie para nombrar el archivo char respaldo{500];
//variables para manipulación de siringa
struct tímeval tiempo 1; //estr ucture para leer tiempo
struct timezone tiempo2; timejc;
char 'tiempo;
extern char eJhost{20); //vari abte ya definida con el nombre del host
gettimeofday(&tiempo1 ,&tiempo2); c = tiempo 1 .tv_sec;
tiempo = ctime(&c);
strcpy(respaldo,tiernpo);
H (detenido = 1) {
if (botón 1 = 0) {
//if (!strcmp((cnar *)[alarma10uttet stringValue], V)"))
//{[reporteOutiet setStringValue.'No hay instrucción a monitorear.VO"];
ID
//else //{
[reporteOutiet setStringValue:"AJarma 1 activadaAO"]; botonl = 1;
strcat(respaldo, 'Alarma 1 activada:");
strcat(respakJo,(char *) [alarmalOutlet stringValue]); strcat(respaldo,a\n\n');
arcMvosfopen("alarrnas.logYa+"); fputs(respaldo^irchjvo); fclose(archrvo);
strcpy(hostalarma 1 .elhost); strcat(hostalarma1 ,"V0"); //Ubrel = 0;
ID
)
else { [alarmalOutlet setStringValue:"\0"]; botonl «0;Hbrel = 1;
49
strcaUrespakJo/Alarma 1 desactivada:");
strcat( respaldo, (char") [alarma lOutlet stringValue]); strcat(respaido,<\n\n');
archivo=fopen(*alarmas.log","a+"); fputs(respaldo,archivo);
fclose<archivo);
}
} else {[activalOutiet setState:0];}
retum setf;
1
sontdo1Method:sender { retum setf; } copiarMethod:sender { char funcparam[80];extem char parametro{80];
strcpy(funcparam,funcion); strcat(funcparam,' ");
strcat(funcparam parámetro);
if (librel = 1) [
[alar malOutlet setStringValuerfuncparam]; librel =0; } else {
if (Iibre2 = 1) {
[alar ma20utlet setStringValue:funcparam];
Iibre2 0; }
else {
ˇf(lˇtxe3 = 1) {
[alar ma30utlet setStringValueiuncparam];
Iibre3 = 0; }
else í
ma40utíet setStringValuerfuncparam];
Iibre4 = 0; }
else {
[reporteOutiet setStríngValue:"Ya existen cuatro alarmas activas. No se puede copiar otraAO"];
} } } } return seK; } activa4Method:sender { FILE 'archivo;
abie para nombrar el archivo char respaldo[500];
//variables para manipulación de strings struct tfmeval tiempo 1;
uctura para leer tiempo struct timezone tíempo2; tˇme_t c;
char'tiempo;
extern char elhost[20];
abie ya definida con el nombre del host
gettimeofday(&tiempo1 ,&ttempo2); c = tiempo1.tv_sec;
tiempo a ctkne(&c);
strcpy(respeJdo,tiempo);
ˇf (detenido = 1) {
H (boton4 = 0) {
[reporteOutiet setStringValue:'Alarma 4 activadaAO"]; boton4 = 1;
strcat(respakJo, "Alarma 4 activada:");
strcat(respalclop(char *) [alarma40utiet stringValue]);
strcat(respaJdo,'\n\n,,);
anrf»lvo=fopen('aiamia8.log,,"a+");
tputs(re8paido,archlvo);
[alar
//vari
//estr
51
fcJose(archtvo);
8trcpy(hC5taJairna4,eihost);
strcat(hO8talarma4,<\0");
}
else
{
[aJarma40utlet setString Valué: ^0"]; boton4 = 0;
libre* = 1;
[reporteOutiet setStringValue:"Alarma 4 desactivada. V0"]; strcat(respaldo,"Alarma 4 desactivada:");
strcat(respaJcio,(char *) [alarma40utíet stringValue]); strcat{respakk),'\n\n");
archivoefoperKaalarrnas.log","ai");
fputs(respaldo,archivo); fck>se<archivo);
}
} else {Jactiva40uttet setState:0];}
return seif;
)
sonkk>2Methodsender { retum seif; } intóalizarMethod:sender {if (detenido = 1) {
[alarma lOutlet setStringValue:',VO"];
[alarma20utlet setStringValue:,%0"];
[alarma30utiet setStringValue:"VO"]; [alarma40utlet setStringValue:"VO"];
[reporteOutiet setStrˇngValue:"AJarmas desactivadas e inícializadas. V0"]; Hbrel = 1;
Hbre2 = 1; Hbre3 = 1; Bbre4 = 1;
botorúsO; boton3 * O; botoo4 = 0;
}
retum self; }
det8nen\4ethod:sender
{
FILE 'archivo; //vari abie para nombrar el archivo
char respaJdo{500];
//variables para manipulación de strings
struct timevaJ tiempol; //estr uctura para leer tiempo
struct timezone tíempo2; timejc;
char 'tiempo; char mensaje{400]; int nohay;
char *argv[4]; //vari abie para snmpgetnext
extern char funcion[20]; //vari abie que contiene nombre de función
int ciciarstatus; int acumulador,
extern int errorenstatua;
getlirneofday(&tiempo1 ,&tiempo2); c = tiempol .tv_sec;
tiempo = ctime(&c);
strcpy(respaldo,tiernpo);
strcpy(mensaje,aProceso de monitoreo activado. \n");
strcat(respakx),'Proceso de monitoreo activado. Vi"); if (botonl = 1) {strcat(rnensaJe,"AJarma 1 activada:\n");
strcat( respaldo, "Alarma 1 activada: *);
strcat(respaldo,(cnar *) [alarmalOutlet stringValue]);
strcat(respaldo,^n");}
if (boton2 = 1) {strcat(mensaie,"Alarma 2 activada.Nn");
53
strcat(respaldo,(char *) [alarrna20utlet stringValue]);
strcatfrespeJdo,^");}
if (botona =1) {strcat(mensaie,*Alarma 3 actrvadaAn');
strcat(respaldo,"Alarrna 3 activada:");
strcat(respaldo,(char ') [alarma30utiet stringValueD;
strcaKrespakJo.'Nn");}
if (boton4 = 1) {strcatfmerisaje/Alarrna 4 actjvadaAn");
strcat(respaldo,a Alarma 4
activada:');
strcat(respaldo,(cnar *) [alarma40utiet StringValueD;
strcat(reapaido.a\na);}
if ((boton1=0) && (boton2=0) && (boton3=0) && (boton4=0)) {strcpy(mensaje,aNo hay funciones activas para monttorear.");
nohay» 1;
[detenerOutfet setState:0];
1
else {nohay = 0;} strcat(rnensaje,"VO^;
If (detenido=1) í
[reporteOutiet setStringValue:mensaje]; if (nohay = 0)
{
detenido a 0;
[detenerOutiet sefTitie:aDetener MonitoreoVO'];
strcat(respaldo,a\na);
archrvo=fopen("alarma8.log","a+"); fputs(respaldo,archivo); fctose(archivo);
acumulador=0; ciclarstatus = 1;
while (ciclarstatus — 1) {
K(boton1 = 1){
argv[0]=funcion;
argv[1}=hostalarma1;
Este mensaje se intercala en los documentos
digitales donde el documento original en papel no
contenía esta página por algún error de edición del
documento.
Al momento los creadores de este documento no
han localizado esta página.
Preguntas frecuentes:
¿Qué puedo hacer?
Ten por seguro que hemos informado al creador original del documento y estamos intentando reemplazar esta página.
¿Quién convierte estos documentos a formato digital?
Esta tarea se realiza por un grupo de personas que laboran en el proyecto de Biblioteca Digital. Nos esforzamos por convertir documentos originales a una versión digital fidedigna y comunicar a los creadores del documento original de estos problemas para solucionarlos. Puedes contactarnos visitando nuestra página principal en:
fputs(r68paJdolarchivo);
fck>ae(archivo); ciciaretatus = 0;
}
retum seif;
}
Oend
r Generatod by Interface BuHder EJECUTAFUNCION.HV
fimport <obíc/ObiecLh>
ip21 _06Method:sonder, ip21_07Method:sender, ip21 _08Method:sender, ip21_09Method:sender. ip21_10Method:senden ip21_11Method:senden
