UNIVERSIDAD NACIONAL DE INGENIERIAcybertesis.uni.edu.pe/bitstream/uni/10168/1/marcelo_fl.pdf ·...
Transcript of UNIVERSIDAD NACIONAL DE INGENIERIAcybertesis.uni.edu.pe/bitstream/uni/10168/1/marcelo_fl.pdf ·...
UNIVERSIDAD NACIONAL DE INGENIERIA
,.
FACULTAD DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA
SISTEMA DE SUPERVISIÓN DE FALLAS Y SERVICIOS PARA OPERADORAS EN TELECOMUNICACIONES USANDO
CIC (CISCO INFO CENTER)
INFORME DE SUFICIENCIA
PARA OPTAR EL TÍTULO PROFESIONAL DE:
INGENIERO ELECTRONICO
PRESENTADO POR: LUIS MIGUEL MARCELO FERNANDEZ
PROMOCIÓN 2003 - 1
LIMA-PERÚ 2007
SISTEMA DE SUPERVISIÓN DE FALLAS Y SERVICIOS PARA OPERADORAS EN TELECOMUNICACIONES USANDO CIC
(CISCO INFO CENTER)
Dedico este trabajo a:
Mis padres, quienes siempre apoyaron toda
iniciativa de progreso con ejemplo de valor y
contante esfuerzo
SUMARIO
El presente trabajo describe la implementación de un sistema de gestión y supervisión de
fallas y servicios para operadoras, esta implementación pretende encajar dentro del
marco del mapa de procesos TOM (Telecom Operations Map) que es ampliamente
adoptado por las operadoras alrededor del mundo.
El sistema implementado se basa principalmente en almacenar en un repositorio
centralizado los eventos y/o notificaciones que alertan de un cambio en el estado,
configuración o incumplimiento en el nivel de servicio SLA en la red de la operadora a
nivel de equipos de red y servidores.
El almacenamiento de eventos en un repositorio nos permite centralizar todos los eventos
independiente de la tecnología o plataforma del equipo o servidor sobre la cual podemos
realizar todo tipo de análisis (correlación de eventos, análisis de causa raíz,
enriquecimiento de eventos, etc.) para posteriormente normalizar y clasificar los eventos,
este trabajo se realiza en forma conjunta desarrolladores y personas implicadas en la
operadora.
La plataforma usada para tal fin es Cisco lnfo Center este nos permite una rápida y
eficiente recolección, consolidación y correlación de eventos en la red. Es también
comúnmente conocido como el "gestor de gestores" porque tiene la capacidad de
comunicarse con los sistemas de gestión de las diferentes plataformas instaladas en la
red, o a punto de serlo, para lograr la consolidación de información que facilite y mejore la
operación de la red. La herramienta permite eficiencia de operación, continuidad del
negocio, reducción de costos de infraestructura IT e incrementa la disponibilidad de los
servicios ofrecidos.
PROLOGO
CAPITULO 1
INDICE
1
CONSIDERACIONES GENERALES Y DESCRIPCION DEL PROYECTO 2
1.1 Introducción
1.2 Alcance del Proyecto
1. 3 Normatividad aplicable
1.3.1 Funcionalidades
CAPITULO 11
IDENTIFICACIÓN DE LA INFRAESTRUCTURA DE RED EN LA OPERADORA
2.1 Tecnologías involucradas
2.2 Elementos de Red
2.2.1 Red de acceso ADSL
2.2.2 Red ATM
2.2.3 Red de Agregación
2.2.4 RedlP
2.3 Topología actual de la operadora
CAPITULO 111
2
2
4
6
9
9
10
10
11
11
12
12
IDENTIFICACIÓN DE LOS SERVICIOS INTERNET EN LA OPERADORA. 15
3.1
3.2
3.3
3.3.1
3.3.2
3.4
3.5
3.6
Descripción de los servicios Internet en la operadora
Servicio DNS
Servicio Radius
Servidores Radius para servicio dial-up
Servidores Radius para servicio ADSL
Servicio LDAP
Gestor de Cuenta
Softswitch
15
15
17
17
19
19
20
21
CAPITULO IV
MÉTODOS DE RECOLECCIÓN DE EVENTOS EN LA RED. 23
4.1 Descripción de los métodos de Recolección 23
4.2 Recolección de eventos en la red de Acceso 23
4.2.1 Recolección mediante AWS (ADSL WorkStation) 24
4.2.2 Recolección mediante NMS iManager N2000-Huawei 25
4.3 Recolección de eventos en la red de ATM usando CWM(Cisco Wananager)
4.3.1 Interfaz de administración de averías
4.3.2 Traps
4.4 Recolección de eventos en la red de Agregación y la red IP
4.4.1 Proceso ovtrapd
4.5 Recolección de eventos para los servicios IP
4.5.1 Listado de pruebas DNS
4.5.2 Listado de pruebas LDAP
4.5.3 Listado de pruebas RADIUS
4.6 Solución basado Cisco lnfo Center
4.6.1 Probes o Sondas
4.6.1.1 Funcionamiento básico de las sondas
4.6.1.2 Fichero de propiedades
4.6.1.3 Fichero de reglas
4.6.1.4 Parada y arranque de las Sondas
4.6.2 INTERNET SERVICE MONITOR (ISM)
4.6.2.1 Arquitectura Netcool/lSMs
CAPITULO V
ANÁLISIS Y PROCESAMIENTO DE EVENTOS EN LA RED.
5.1 Normalización de Eventos
5. 1. 1 Repositorio Centralizado
5.1.2 Proceso de Normalización
5.2 Correlación de Eventos
5.2.1 Detección de duplicaciones de eventos
5.2.2 Enriquecimiento de eventos
5.2.3 Correlación de evento de falla con su evento de Clear (on/off)
5.2.4 Automatizaciones para eliminación de eventos
28
28
28
30
31
32
32
34
36
39
39
41
42
43
44
45
45
47
47
47
48
51
51
52
53
53
5.2.5 Intermitencia de eventos
5.3 Análisis de Causa Raíz en los eventos
5.4 Solución basado Cisco lnfo Center
CAPITULO VI
MECANISMO DE PRESENTACIÓN Y GENERACIÓN DE REPORTES DE LOS
EVENTOS.
6.1
6.2
6.3
Web de supervisión
Web para la monitorización de servicios de Internet
Solución basado Cisco lnfo Center
6.3.1 CIC/Webtop
6.3.2 CIC/Reporter
CONCLUSIONES
BIBLIOGRAFÍA
54
54
56
61
61
64
64
64
65
67
68
PROLOGO
Este trabajo pretende buscar un consolidado para la gestión de fallos sobre la situación
del hardware, los servicios y las aplicaciones a lo largo de toda la red para cualquier
operadora, constituyendo una única interfaz de gestión para los equipos de operaciones
de red y TI. Esto facilitara a los citados equipos la identificación y gestión de los
problemas de infraestructura, en tiempo real.
La suite CIC (Cisco lnfo Center) es el agente para gestión de fallos en la red
perteneciente a un Soporte de Funcionamiento de Red (OSS) de última generación Estas
soluciones de vanguardia trabajan conjuntamente para recopilar y consolidar información
sobre redes, detectar eventos asociados que puedan generar disfunciones en el
funcionamiento de la red y mejore así la eficiencia de las redes simplificando la
administración de grandes redes mediante la automatización de los procesos, la
integración de los procesos de servicios y la habilitación del personal para que pongan el
foco en actividades de mayor nivel.
CAPITULO 1
CONSIDERACIONES GENERALES Y DESCRIPCION DEL PROYECTO
1.1 Introducción
La importancia de un sistema integrado de gestión de red y servicios radica
principalmente la amplísima gama de arquitecturas de sistema para garantía de servicio y
gestión de alarmas, que se pueden ir ampliando para alcanzar múltiples niveles de
rendimiento, tanto en consolas como en gestión de eventos. Las empresas proveedoras
de servicios y las grandes redes corporativas evolucionan para dar soporte a mayores
anchos de banda y a nuevos servicios. Por tal motivo la solución que se plantea permite
que puedan configurarse y realizar la transición entre redes con toda facilidad, ideal para
infraestructuras que tienden a expandirse con rapidez.
Este documento pone de relieve las numerosas ventajas que conlleva la implementación
de un sistema Integrado de gestión de eventos en grandes arquitecturas distribuidas,
como:
• Contención de gastos de explotación (reducción de los costes de operación de los
centros de gestión de red o NOC).
• Reducción de los gastos de capital (al disminuir las consolas de gestión).
• Mayor facilidad para ampliación de los sistemas de hardware/software mediante la
minimización de la carga en consolas.
• Mejora del Mean Time to Resolve (tiempo medio de reparación o MTTR), gracias
a una mayor capacidad resolutiva de la intervención humana.
• Evitar penalizaciones por el incumplimiento de los contratos de nivel de servicio
(SLA).
1.2 Alcance del Proyecto
El sistema SIGRES - Sistema Integrado de Gestión de Redes y Servicios - es un
proyecto global y sinérgico concebido por T-LATAM (Telefónica Latin America) para
actuar sobre las redes ADSL e IP de sus operadoras latinoamericanas, así como en los
servicios suministrados por estas redes.
Por ser una herramienta involucrada con las capas de gestión de red y servicios, SIGRES
3
podrá atender a los complejos procesos de negocios de Cumplimiento de Servicios
(Service Fulfillment), Garantía de Servicios (Service Assurance) y demás procesos
asociados, posibilitando su actuación en diversos niveles de gestión.
Según la recomendación M.3010 del ITU-T y la Figura 1-1: Sistema Integrado de Gestión
de Red y Servicios, SIGRES contendrá las siguientes funcionalidades:
1. Gestión de Provisión y Activación: permite la optimización de recursos de red
mediante la provisión dinámica y flexible de servicios, incluso de forma masiva.
2. Gestión de Inventario de Red: hace la gestión en línea de los recursos (equipos y
enlaces) y servicios existentes en las redes cubiertas, posibilitando la disposición
de datos confiables para las demás operaciones de la operadora (Área de
Negocios, Planificación, Operación y Mantenimiento, etc.).
3. Gestión de Alarmas: provee la supervisión y gestión centralizada de fallos en la
red. Su integración con los módulos de Inventario y Desempeño permite el
enriquecimiento de alarmas, la detección de causa-raíz, la definición de clientes y
servicios afectados, así como la toma de acciones pro-activas mediante la
detección de umbrales de desempeño excedidos.
4. Gestión de Desempeño: monitoriza el desempeño de la red y servicios
registrados, permitiendo ejecutar medidas, observar la degradación de la calidad
del servicio y soportar acciones pro-activas para resolución de problemas. Los
datos de prestaciones también podrán soportar eventuales acuerdos de niveles de
servicios con los clientes internos y externos de la operadora.
Entre las actividades soportadas por el SIGRES están:
• Aprovisionamiento de Redes y Configuración de Servicios.
• Gerencia y Administración de Inventario.
• Supervisión y Medición.
• Operación y Mantenimiento de la red.
' ' ' ' ' '
-··,
SIGRES
' .... ,.. · .. !.- .. ------- ... ----- ... -------------------.. -----------
;tt�1Jitf���º-\'·'. .-.. _: __ �:. - · - -
Figura 1.1 Sistema Integrado de Gestión de Red y Servicios.
4
Las referidas actividades serán ejecutadas directamente sobre los sistemas de gerencia
de red (NMS) y de elemento (EMS), así como sobre los propios elementos de red (NE)
que estarán bajo el ámbito de gestión del SIGRES. De manera análoga, el SIGRES se
comunicará con las capas superiores de gestión para el debido intercambio de datos con
los diversos sistemas de soporte al negocio (BSS).
El ámbito del presente documento solo se ocupara de la funcionalidad de Gestión de
alarmas utilizando para ello la suite de productos de Cisco lnfo Center, para cumplir los
objetivos antes mencionados.
1.3 Normatividad aplicable
La Figura 2.3.a: Mapa de Operaciones en Telecomunicación (TOM) representa el TOM -
Telecom Operations Map-idealizado y modelado por el TeleManagement Forum (TMF).
Este mapa de procesos es ampliamente adoptado por las operadoras alrededor del
mundo y sirven para la identificación de los dominios funcionales de los sistemas de
soporte a la operación (OSS) y al negocio (BSS) que pueden existir en un proveedor de
servicios de telecomunicaciones.
El TOM fue concebido por el TMF como un modelo de referencia de procesos, siendo
organizado bajo la forma de tres grandes grupos de procesos fin-a-fin:
• Cumplimiento de Servicios (Fulfillment).
• Garantía de Servicios (Assurance).
• Facturación de Servicios (Billing).
5
El concepto del framework (o marco de procesos) de TOM es que todos los procesos de
negocios referentes a la operación de una proveedora de telecomunicaciones puedan ser
mapeados o descritos dentro de estos tres grandes grupos, asegurando que los mismos
puedan así ser soportados por los sistemas OSS y BSS que ejecutan los sub-procesos
de referencia asociados al modelo.
El framework de procesos TOM está compuesto por 15 sub-procesos básicos, sin tener
en cuenta la interfaz del cliente, siendo 5 sub-procesos por capa TOM, los cuales
involucran actividades generales de gerencia, fuerza de trabajo y planeamiento.
Estos 15 sub-procesos se relacionan entre sí bajo la forma de entradas y salidas,
constituyendo un completo conjunto de procesos operacionales capaces de soportar
cualquier proceso de negocios en Telecomunicaciones.
Figura 1.3.a Mapa de Operaciones en Telecomunicación (TOM).
A partir de esta introducción al TOM se torna posible la identificación del encaje funcional
del SIGRES en términos de funcionalidades que deberán ser soportadas por la
6
plataforma para cada uno de los sub-procesos del modelo de referencia, conforme a la
Figura 1.3.b: Encaje Funcional de SIGRES:
Figura 1.3.b Encaje Funcional de SIGRES
1.3.1 Funcionalidades
A continuación se presentan las principales funcionalidades previstas para el SIGRES,
siendo su encaje funcional con el TOM del TMF:
7
Sub-proceso del TOM Funciones soportadas por SIGRES
Configuración de Diseñar solución - Design
Servicios Designar capacidad - Assign
Configurar elementos de red
Actualizar registro de configuración del cliente
Activar/Desactivar servicios
Reportar servicio completado
Gestión de Problemas de Aislar y resolver problemas de servicios
Servicios Identificar fallas crónicas
Determinar el impacto en el desempeño de los
servicios
Proveer Datos de Desempeño de Red y Calidad de
Servicios de Red.
Gestión de Calidad de Monitorizar la calidad general de una clase de
Servicios Servicio
Analizar la calidad del servicio
Informar las restricciones
Provisión de Red Configurar instalación inicial de la red
Administrar la red lógica y prepararla para el
aprovisionamiento de servicios
Gerenciar conexiones
Gestión de Inventario de Administración de la red física.
Red Realizar trabajo en la red.
Gerenciar números (Direcciones IP, etc.)
Alinear el Inventario con la Red, a través del
Upload
8
Mantenimiento y Analizar problemas
Reestablecimiento de Red Mantener datos históricos de desempeño y
problemas de la red.
Planificación de Servicios Datos para el planeamiento de la capacidad de red
y de Red requerida.
Gestión de Datos de Red Colectar, correlacionar y formatear eventos
Determinar el desempeño en términos de
capacidad, utilización y tráfico
Proveer notificaciones de degradación de
desempeño
Iniciar funciones y control del tráfico
CAPITULO 11
IDENTIFICACIÓN DE LA INFRAESTRUCTURA DE RED EN LA OPERADORA
2.1 Tecnologías involucradas
Los procesos de negocios a ser atendidos por el SIGRES y los servicios a ser
administrados por la plataforma están directamente relacionados a la infraestructura
tecnológica que los soportan, una vez que el SIGRES irá a actuar directamente sobre los
elementos de red y sus sistemas de gerencia respectivos para asegurar el cumplimiento
de los procesos de Service Fulfillment y Service Assurance.
Así, con el objetivo de permitir una mejor comprensión de los capítulos subsecuentes y
del ambiente operacional de la operadora, este ítem presenta una breve descripción de la
infraestructura de red y tecnologías asociadas con los servicios a ser considerados.
Los servicios de acceso a banda ancha Speedy son basados en la tecnología ADSL
(Asymmetric Digital Subscriber Une).
UJJuerlo
Operadora de Teht�omunkaclonH t .. . . . . ·, .
. '
.
Yert.
r.lDF
l"br.
, vra. + Dalos '' • �-- . ---- .. -. �:-:. ----:----� ------
Swttch ATM
)
RedlP
INTERNET
'• '
.
--- �? •
�- ·. ····�J---...Agr�gador .• ·· . ·. �::
Servidor de Autentic.1ción
Figura 2.1 Mapa de Operaciones en Telecomunicación (TOM).
10
El ADSL es una tecnología concebida para transmitir datos a alta velocidad (normalmente
entre 128Kbps a tasas superiores a 2Mbps) sobre líneas telefónicas convencionales,
proveyendo conectividad "always-on" al mismo tiempo en que se utiliza la banda de
transmisión de voz. Se dice que el ADSL es asimétrico porque utiliza gran parte de su
canal para enviar datos al usuario, mientras que el resto del espectro es destinado a la
recepción de datos a partir del mismo.
2.2 Elementos de Red
De manera general, la infraestructura de un servicio ADSL esta compuesta por la
interconexión de 4 redes distintas, Red de acceso ADSL, Red A TM, Red de Agregación,
Red IP.
2.2.1 Red de acceso ADSL
Es la red de concentración y multiplexación de los accesos ADSL de los usuarios. Su
principal elemento de red es el DSLAM, multiplexador de accesos digitales sobre par de
cobre, posibilitando el acceso a la red de banda ancha sobre la línea telefónica
convencional, por intermedio de interfaces A TM.
Un DSLAM puede eventualmente concentrar accesos provenientes de otros DSLAMs
subyacentes. En este caso, se dice que estos DSLAMs están subtendidos.
�lllIIl Villa -2
BPX-4
lucas 2.2 íñ
�---STM-11---.....,.¡¡"'l¡
ij
13.2,
'-2.5 "-.... ' 1E3
' '"
Mercedes 4 E1
�mm -----;i_1mm /,"':.� Gl 4 E1
4E1�1lllll
STM-1 4E1� @
""� i� .
�¡ lllIII --illlill loma
4E1-- f¼
�: �llllll �� ::�IIIIll loma-1 �
4E1� il! "-- �llJID Cobamba
1 E1 . '•
STM-1
....._ .......... ,si '- llll]] Cordova-1
";llDJl Conlo,aMllllll laguna L , ..
Figura 2.2.1.a Red de acceso ADSL - DSLAM Alcate1.
Ramon
Ramon-2
Pampa
Pampa-2
11
2.2.2 Red ATM
La red ATM (Asynchronous Transfer Mode) es una tecnología de transporte de datos a
alta velocidad basada en el concepto de conmutación por células. Su elemento esencial
es el conmutador (o switch) ATM, que mapea y direcciona las células a partir de cualquier
puerta de entrada hacia una puerta de salida específica, como su destino.
BPX-3
1 SfM.1 '
.--------.35, '
... ____ __.,
'-. 1 STM-1 Switch ATM
_ ,
ERX-1
ERX-2
Figura 2.2.2 Red ATM
2.2.3 Red de Agregación
BPX-4
Switch ATM
Formada por los NISIP (Nodo lmplementador de Servicios IP) o agregadores, que son los
elementos de agregación ATM que hacen interfaz con la red IP, terminando los circuitos
virtuales y túneles PPP.
ERX-1
BPX--3 BPX-4
AGREGADOR
ERX-2
AGREGADOR
Figura 2.2.3 Red de Agregación.
2.2.4 Red IP
Son los ruteadores que ofrecen las funcionalidades de ruteamiento entre los diferentes
nodos y hosts, así como conectividad a la Internet.
•. 1 So-0/0/0 10.5.0.0/30
So-1/0/0 Lo 200.48.225.51
10.5.0.12/30
So-110/0
.13 Lo 200.48.225.54
.. 10 So-0/0/0 10.5.0.8 30
So-0/0/0 .2
Lo 200.48.225.52
Lo 200.48.225.53
So-0/0/0 .9
Figura 2.2.3 Red IP.
2.3 Topología actual de la operadora
.6
T320
SIS
So-1/0/0
T320
MIR
12
La Figura 2.3: Topología de Red para Servicios Speedy ilustra la topología de red actual
de la operadora:
Elemento
Core Router
Toll-Gate
Agregador
.d._ '•
Trafico !ntemaelonal Internet
• __ ..,,.,-e
.. COl'fUOil.er(J�rT320)_,::.: .:
• ,: Z::t:.»:,.;�r: a Sw.tér,ATM{árno:sp�f ::: .· .. �- , DSLAM(A� !:''·. ::: : ·:: ,:·
: :\raéflqre��ª�f��r:::: :-.. . . ··� . .
13
Figura 2.3 Topología de Red para Servicios Speedy.
Equipo Suministrador Descripción
T320 Juniper 6 ruteadores (2
Washington, 2 San
Isidro, Monterrico y
Miraflores),
localizados en Lima
M40 Juniper: 2 ruteadores
(Trujillo y Arequipa)
ERX1410 Juniper 17 nodos. El ERX
de Trujillo
concentra todo el
tráfico del norte
del Perú; el de
14
Arequipa concentra
el
tráfico del sur.
Switch ATM BPX Cisco 12 nodos
DSLAM 7300 Alcatel DSLAMs pueden
estar subtendidos;
hay casos en que
los DSLAMs
pueden acceder al
ERX directamente
Agregador 11 Shasta Nortel 2 nodos, 1 nodo
conectado con el
BPX de Washington
y el otro
conectado al BPX2
de San Isidro;
utilizados para el
establecimiento de
VPNs del servicio
SpeedyWAN.
Servidor de SMC Alcatel Utiliza servidor
Autenticación LDAP para
gestionar base de
datos de
autenticación
CAPITULO 111
IDENTIFICACIÓN DE LOS SERVICIOS INTERNET- EN LA OPERADORA.
3.1 Descripción de los servicios Internet en la operadora
Adicionalmente a los elementos de red descritos en el capitulo anterior las operadoras
necesitan manejar servidores como son de resolución de nombres de dominio DNS
autenticación Radius LDAP, este capitulo se encarga de describir los distintos servicios
que están implementadas en la operadora.
3.2 Servicio DNS
Los servidores DNS son aquellos que permiten resolver los nombres de dominio en
direcciones IP, ya que la comunicación no se realiza por nombres sino por direcciones de
red. Una herramienta sencilla que determina la dirección IP de un dominio en particular
es el "nslookup", el cual se encuentra en todo Sistema Operativo, incluso en Windows:
C:\>nslookup www.google.com
Servidor: huascaran.tdp.net.pe
Address: 200.48.225.130
Respuesta no autoritativa:
Nombre: www.google.com
Addresses: 64.233.161.99, 64.233.161.104, 64.233.161.147
Aliases: www.google.com
En este caso se resolvió el nombre www.google.com, cuyo resultado son las direcciones:
64.233.161.99, 64.233.161.104 y 64.233.161.147. Del mismo modo, las aplicaciones
WEB usan este mecanismo para acceder a los servicios que ofrece Internet: web, ftp,
correo, etc.
TdP ofrece a sus clientes el servicio DNS que les permita resolver nombres de dominio,
además de alojar nombres de dominio de usuarios que lo requieran. Los servidores DNS
de TdP sólo resolverán los nombres de los dominios de sus clientes (www.t
empresas.com.pe por ejemplo), en el caso que se requiera resolver dominios externos a
la red de TdP se hará la consulta a los servidores de primer nivel llamados ROOT
SERVERS.
Pastoruri 10.3.1.21
Huaytap lana 10. 1.22
Seavidores
DNS FW
Servidores
DNS Soboncay'o 10.3.2.21
16
Content
switch ,r::;;:,, ,, :,·=, :, ;r huascaran.tdp.net.pe
Content
itch . :; ,: F'.c,
;•.-:,, ,:.e-,:,: 200.48.225.130 huondoy. tdp.net.pe tt, .=t< ... �ffitl200.48.225.146
WASHINGTON Balanc e cargas SAN ISIDRO
usuario
Figura 3.2 Servicio DNS.
Los detalles de la consulta son:
• El protocolo de transporte usado es UDP, utilizando el puerto 53 por defecto.
• Cuando se procede a la consulta, se crea un tráfico hacia los servidores DNS que
son balanceados por los equipos llamados Content Switch (poseen las
direcciones I P públicas de los servidores DNS) también llamados balanceadores
de carga. Estos equipos trabajan a partir de la capa de transporte y distribuyen el
tráfico a los servidores.
• Si el conjunto de servidores DNS Primario no puede responder de forma
inmediata a alguna consulta, la aplicación de usuario procede a consultar al DNS
Secundario.
• Los servidores DNS sólo resolverán los dominios que se encuentran en su
memoria o en su configuración; el resto de dominios serán resueltos a partir de
17
consultas a los ROOT SERVERS, que son servidores DNS de mayor nivel y que
se encuentran sobre Internet.
• El proceso que permite ofrecer el servicio es el "named".
• Se cuenta con ficheros log los cuales registran las actividades del servicio. Se
realiza el backup cada cierto tiempo.
3.3 Servicio Radius
Servicio IP, que se basa también en un modelo cliente-servidor, usado principalmente
para la autenticación de usuarios, quienes intentan acceder a un determinado servicio de
manera remota. Cuando un cliente RADIUS intenta acceder al servicio, el servidor
RADIUS le exige autenticarse enviando para ello peticiones de autenticación, a lo que el
cliente responde enviando su nombre de usuario y contraseña, la cual es encriptada
usando el algoritmo RSA-MD5 con una llave compartida (shared secret); esta llave es
compartida entre el cliente y el servidor, utilizada únicamente para encriptar la
contraseña. Si el nombre de usuario es válido y la contraseña fue correctamente
encriptada, el cliente obtiene el acceso al servicio; básicamente esta es la manera de
cómo funciona el servicio RADIUS que ofrece el servicio usando el protocolo de
transporte UDP, en los puertos 1645-1646 y 1812-1813 (puerto de autenticación y conteo
respectivamente)
Cabe mencionar que en la autenticación de los clientes para el acceso a Internet, los
servicios RADIUS y LDAP funcionan de manera conjunta: El servidor RADIUS le pide al
cliente autenticarse, si dicha autenticación resultó exitosa, este servidor se comunica con
el servidor LDAP enviando peticiones de búsqueda bajo un criterio dado (verificación del
cliente), el servidor LDAP realiza la búsqueda en su árbol de directorios si lo encuentra
(search matched), el cliente obtiene el acceso a internet y si no el acceso es denegado.
Para el acceso Dial-Up, TdP cuenta con dos servidores NavisRadius y para el acceso
ADSL, TdP cuenta con un servidor Radius-ADSL.
3.3.1 Servidores Radius para servicio dial-up
TdP cuenta con dos servidores Radius para el servicio dial-up, uno en Washington y otro
en San Isidro, estos servidores trabajan conjuntamente para balancear la carga durante
el proceso de autenticación.
NAVISRADIUS {WASHINGTON)
_,;:.
NAVISRADIUS (SAN ISIDRO)
EQUIPO RAS (REMOTE ACCESS SERVER)
Figura 3.3.1 Servidores Radius para servicio dial-up.
18
LOAPTERRA
SERVIDOR RADIUS TERRA
TdP utiliza autenticación de usuario por medio de la combinación Radius-LDAP. En el
caso del NavisRadius para el servicio dial-up, no se cuenta con servidores LDAP locales
para realizar consultas debido a que los usuarios dial-up son exclusivamente de TERRA,
por lo que el NavisRadius tiene que comunicarse con el Radius de TERRA para realizar
las autenticaciones (El Navias radius autentica el dominio y en los servidores de TERRA
se autentica el usuario y la password).
En cuanto a la información del servicio se tiene lo siguiente:
• El protocolo de transporte es UDP.
• El servicio se da por la interfaz 10.3.1.6 (Washington) y 10.3.2.6 (San Isidro), y el
puerto de servicio es el 1645-1646 para el caso de los equipos MAXTNT y el
1812-1813 para el caso de los equipos HIG.
• Para conectarse al Radius de TERRA se consulta a la dirección 172.20.1.2, por el
puerto 1645-1646.
• El proceso principal del servicio es el "nr_exec".
• Existe un proceso en Peri llamado "monitor.pi" el cual monitoriza el servicio.
• Se tiene ficheros log, los cuales registran la autenticación de los clientes. Se
realiza backup cada cierto tiempo.
19
3.3.2 Servidores Radius para servicio ADSL
El servicio de autenticación para el acceso ADSL está conformado por los servidores
Radius y LDAP. Para el caso de los servidores Radius, estos están conformados por dos
servidores, los cuales comparten un arreglo de discos, formando así un cluster. Estos
servidores reciben peticiones de los routers ERX para autenticar usuarios que quieren
acceder al servicio ADSL.
LDAP WASHINGTON
LDAPSA� ISIDRO
10.3.1.16
RADIUGADGL
ARREGLO DE DISCOS
-,
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Figura 3.3.2 Servidores Radius para servicio ADSL.
Los servidores Radius del SMC ofrecen su servicio por el puerto 1812-1813, y solicitan
verificación de usuario en el LDAP Washington. No existe comunicación directa con el
LDAP San Isidro, esto se debe a que el LDAP de San Isidro es un servidor de back-up,
por lo que si existe un problema con el LDAP de Washington, se configura los Radius
para que consulten al LDAP de San Isidro.
Cada servidor Radius presenta dos aplicaciones que son importantes para brindar el
servicio de autenticación: la aplicación SMC y la base de datos ORACLE. Para ello, los
administradores monitorizan los procesos que pertenecen a las aplicaciones
mencionadas.
3.4 Servicio LDAP
Los servidores LDAP (LightWeight Directory Access Protocol) se encargan de autenticar
usuarios ya que cuenta con una base de datos en directorio. Estos se comunican con los
20
servidores Radius ADSL (SMC) los cuales solicitan las autenticaciones de los clientes
ADSL.
Gestor de Cuentas
10.3.1.14 Port 389
10.3.1.7
LDAP (Washington)
10.3.2.7
LDAP
(San Isidro)
Figura 3.4 Servicio LDAP
SMC
BACKUP
Existen dos servidores LDAP, uno en Washington y otro en San Isidro. Sólo uno se
comunica con el cluster SMC para que se realice la autenticación, este es el LDAP de
Washington. El LDAP de San Isidro se comunica con el cluster SMC cuando el LDAP de
Washington tiene problemas, para ello se realiza la configuración, de forma manual y no
automática, en los servidores Radius para que consulten sólo al LDAP de San Isidro.
Este proceso es sólo para consultas en el directorio del LDAP. Para realizar configuración
de usuario, se tiene el servidor denominado Gestor de Cuentas, el cual a través de un
Portal web realiza la configuración de los usuarios ADSL. Una vez realizado la
configuración en el Gestor de Cuentas, se procede a conectarse con el LDAP de
Washington para proceder a guardar la nueva en configuración. El LDAP de Washington
se comunica con el LDAP de San Isidro para actualizar la configuración que se hizo en el
Gestor de Cuentas.
El LDAP ofrece el servicio por el puerto 389, a través del protocolo de transporte TCP.
3.5 Gestor de Cuenta
Para la configuración de los usuarios ADSL, se tiene el servidor denominado Gestor de
Cuentas, ya antes mencionado. Este servidor ofrece por medio de un Portal Web, la
21
configuración de clientes. Por lo tanto este servidor ejecuta un servicio Web propio del
software SUNONE. Por defecto, este servicio atiende por el puerto 80.
Además, este servidor cuenta con una base de datos ORACLE en donde se guarda todos
los datos de los clientes configurados.
· 3.6 Softswitch
Como se vio anteriormente, los servidores Softswitch se encargan de gestionar las
llamadas que solicitan los clientes para acceder al servicio de Internet por dial-up. TdP
cuenta con un grupo de servidores que realizan esta tarea, y los cuales se redundan
tanto en Washington como en San Isidro. En este caso, solo se monitorizará los
servidores que se encuentran en Washington, aunque el grupo de San Isidro es idéntico
al de Washington.
Estos servidores cuentan con un agente propietario que les permite monitorizar muchos
parámetros del servicio que ofrece, además de los recursos del sistema. Pero según los
administradores de estos servidores, el agente con que cuenta no monitoriza algunos de
los recursos del sistema por razones ajenas. En principio, se ha solicitado monitorizar los
procesos que permiten mantener el servicio activo. El diagrama de funcionamiento de los
servidores Softswitch es el siguiente:
USUARIO
EQUIPOS RAS
OIRECTORY SERVER
Figura 3.6 Softswitch.
. CALL COORDINATOR
DIRECTORY COORDINA TOR 8D
ORACLE
22
• El Directory Server se encarga de gestionar las llamadas utilizando señalización
#7 (SS7), para ello cuenta con enlaces E1 y además comunicación con los
equipos RAS para poder controlarlos.
• El Call Coordinator se encarga de controlar las llamadas y permitir la correcta
comunicación entre los equipos involucrados.
• EL Directory Coordinator se encarga de llevar un registro de las llamadas para su
posterior tarificación, además contiene el agente SNMP que se encarga de
monitorizar el Sistema Softswitch, este agente es el Netmon.
CAPITULO IV
MÉTODOS DE RECOLECCIÓN DE EVENTOS EN LA RED.
4.1 Descripción de los métodos de Recolección
Actualmente en las operadoras no se tienen un único sistema de recolección de eventos
alarmas de la red tanto para equipos como servidores, esto debido a la variedad de
tecnologías existentes en la red y sus distintos métodos de notificación de eventos, por tal
motivo nuestro trabajo es en este apartado será reconocer e integrar los diferentes
sistemas de recolección de eventos de manera que podamos obtener todas las
notificaciones en un solo repositorio centralizado de eventos para su posterior análisis y
procesamiento.
Debido a la variedad de tecnologías existentes, también existen variedad de soluciones
propietarias que deberán integrarse mediante algún protocolo que sirva de interfaz por
ejemplo SNMP, Syslog, TL 1, etc.
Existen cuatro métodos usados para tal propósito:
• Configuración directa en el equipo/servidor a monitorizar por medio de envió de
traps (protocolo snmp)
• Configuración de mensajes syslog en el equipo/servidor.
• Configuración del gestor de los equipos a monitorizar para el envió de traps
(HPOV, iManager200-Huawei).
• Envió comandos TL 1 al AWS (ADSL WorkStattion).
Estos métodos serán usados de acuerdo a los equipos/servidor a monitorizar.
4.2 Recolección de eventos en la red de Acceso
En la red de acceso se tiene dos equipos DSLAM Alcatel y DSLAM Huawei cada uno de
ellos notifican eventos de manera distinta. Para la recolección de eventos de los dslam
alcatel se debe hacer uso de un script que consulta al AWS (ADSL WorkStattion)
mediante comandos TL 1, para el caso de los dslam huawei mediante un gestor
24
propietario de huawei iManager2000 que permite la recolección de eventos mediante el
envió de traps-snmp.
4.2.1 Recolección mediante AWS (ADSL WorkStation)
El Alcatel ADSL Workstation (AWS) es un sistema de administración para solución DSL
(Digital Subscriber Line). El AWS agrupa, filtra y traduce eventos (problemas) y alarmas
(notificaciones) que llegan de varios equipos.
El AWS puede recibir alarmas y eventos de varias capas dentro de las topología ADSL,
las capas de un DSLAM especifico como son subrack, trajetas NT, tarjetas L T.
►
ASA.l\ls
Figura 4.2.1 Recolección de eventos mediante AWS.
El script que colecta los eventos tiene el siguiente algoritmo:
1. Abre la sesión
2. Verifica el tamaño del archivo de log, hacer el debido tratamiento.
3. Comando para recibir el evento.
4. Espera por "TNM1 (data) (hora)<cr><lf> MM<ctag>"COMPLD"
.. -!...i��i;iyc � le�
f.:.-rnl:lt� ?ércnin.éc·
5. Si se verificar respuesta "DENY", se entiende como error de conexión y aguarda la
conexión sea completada.
6. Entra en funcionamiento normal, interpreta línea a línea la respuesta TL 1.
Ejemplo de mensaje TL 1:
�1$�:(}.RQ01· Cl4-11118 18:48:29
11�����!,M��L .:./�.�'AQSb��1�7-4iCL;CAPINSUF,SA, 11-,18, 18-4�29,NEND,: ::-!,:�(<�{t .. } <'.: :,-� .. ':-.-.".:� -�" <,. , �: : .,·· y .:. '. ,
• , ,• '
• • •
0\;:�¿t:iR4if �_city:insuffici�nt .for config\"''; }f1'.;{(:l ::. ·.·. . . . . .
-�·--··· > -~�·· ··· · - � .·,. .. , .. · , ... ,- ' . .
Este mensaje se transforma en la siguiente línea de log
. Sf.l0"'.�QQ11:94� 11-18f18:48:29tAfREPTtADSL-3-1'."'7-4!CLICAPINSUFfSAtNENDlLine - -
4.2.2 Recolección mediante NMS iManager N2000-Huawei
25
El NMS (Network management system) envía todo tipo de requerimientos a los
dispositivos de la red. Este también recibe los paquetes de respuestas y traps de los
dispositivos administrados, y muestra el contenido de los paquetes.
Un Agente es un proceso en un dispositivo administrado. Este recibe y se encarga de los
requerimientos de paquetes del NMS. Luego este obtiene los valores de las variables
administrados de otros protocolos en los dispositivos para formar el paquete de
respuesta, y envía luego el paquete al NMS. En casos de emergencias, el agente notifica
al NMS (enviando un paquete trap), por ejemplo, cuando el estado de una interface ha
cambiado.
El SnmpAgent es un proceso en la capa inferior NMS, y tiene la misma función como un
agente genérico que recibe y se encarga de los requerimientos de la capa superior NMS,
y envía trap. La siguiente figura muestra la relación de la capa superior NMS, capa
inferior, y el dispositivo administrado.
Upper layer NMS
uest Req res ponse
R equest
j�
, '
j SnmpAgent 1 Lower layer NMS
j
re sponse
, '
Managed device
j�
Tr ap
H
Tr ap
Figura 4.2.2.a Recolección de eventos mediante iManager N2000-Huawei.
26
El siguiente diagrama describe el uso SnmpAgent para reportar alarma a una capa
superior NMS. Cuando la capa mas baja NMS recibe una alarma del elemento de red
(NE), el SnmpAgent reporta las alarmas a la capa superior NMS de acuerdo a un archivo
de configuración.
1 1 SnmpAgent 1 1 Upper layer NMS
�----�
Trap �
, __ T_rap_�
Figura 4.2.2.b Proceso de reporte de alarmas.
A continuación se detalla el proceso de configuración SnmpAgent
1. Configure parameters of the upper layer NMS to receive Trap
NBEventReceiverlP1 = 10.70.140.222
NBEventReceiverPort1 = 162
NBEventTrapVersion1 = 1
2. Configure the device type to be filtered
DeviceTypeFilter = 1234
3. Configure the Trap to report alarms
VB1 = NEName
VB2 = NEType
VB3 = Objectlnstance
VB4 = EventType
VBS = EventTime
VB6 = ProbableCause
VB7 = Severity
VB8 = EventDetail
VB9 = Additionallnfo
VB10 = FaultFlag
AdditionalVB1 = DEVICE_LABEL
AdditionalVB2 = RESOURCE_LABEL2
AdditionalVB3 = RESOURCE_LABE3
AdditionalVB4 = RESOURCE_LABEL4
AdditionalVBS = RESOURCE_LABELS
27
AdditionalVB6 = RESOURCE_LABEL6
AdditionalVB7 = RESOURCE_LABEL7
AdditionalVB8 = RESOURCE_LABEL8
28
4. Configure the notifylD to report alarms to the third-party NMS and whether to
use the Specification field to represent alarm levels
UsingDeviceSysOIDForTrap = O
5. Configure a bound IP address
LocalBindlP = 10.70.140.199
LocalBindPort = 9812
6. Subscribe the notification of creating and deleting devices
AdminStatus = 3
ThirdNotify = 32767
7. Save the configurations and restart the SnmpAgent.
4.3 Recolección de eventos en la red de ATM usando CWM(Cisco Wan Manager)
La red ATM de la operadora se basa en equipos Cisco Switch ATM BPX8620, por tal
motivo el método de recolección de eventos se realiza a través de un gestor propietario
CWM (Cisco Wan Manager) de Cisco que es el que se encarga de la gestión los equipos
de la red. A continuación se hará un estudio de la configuración en CWM para la gestión
de averías en la red.
4.3.1 Interfaz de administración de averías
El gestor de averías CWM(Cisco Wan Manager) para un externo OSSs se basa en un
robusto SNMP trap. Este mecanismo de traps, conocido como Robust Trap Mechanism
(RTM), es soportado por el agente del servicio SNMP que corre conjuntamente con un
sistema CWM. A través del agente del servicio, hasta 16 SNMP Managers externos (con
uno reservado para CWM) pueden registrarse para recibir traps de la red y servicios
relacionados.
En CWM algunos recursos de la red utilizan traps SNMP para retransmitir la información
de la avería hasta CWM, mientras que otros utilizan alarmas propietarias robustas y
secuencias de cadenas de eventos. Las alarmas robustas, en términos del Cisco, se
refieren a las representaciones del estado de los recursos de la red en un momento
específico. La secuencia de cadena de eventos se refiere a los acontecimientos
descriptivos accionados por ciertas actividades y se envía hasta el sistema de gerencia.
29
Los dos mecanismos de la gerencia de avería no tienen ninguna correlación. Las
secuencias de eventos se envían solamente al puerto 162 de la estación de trabajo
CWM.
NOTA: Los BPX envían solamente secuencia de eventos (Eventos textuales).
Las acciones que ocurrían en la red, tal como faltas del recurso, pudieron dar lugar a la
generación de eventos textuales así como un cambio en estado de las alarmas.
Otras acciones pudieron dar lugar a ningún estado del alarma; sin embargo, pueden
generan eventos textual. Es mas, el orden en el cual se reciben las alarmas robustas no
pudo reflejar la secuencia cronológica de los eventos de la red; las alarmar robustas
reflejan cambios del estado en el tiempo < x >. Estos casos deben ser considerados por
los encargados que reciben estas averías.
4.3.2 Traps
El interfaz primario para la gerencia de avería es a través de las traps SNMP emitidas por
el agente del servicio SNMP. Este agente proporciona una interfaz uniforme que oculte
parcialmente la gestión de eventos de las interfaces híbridos soportados por los varios
elementos de la red. Los Gestores que se registran para recibir trapas del agente del
servicio del SNMP pueden recibir los cambios del estado de alarmas, estos también
reciben, a través del agente del servicio traps de los elementos de la red soportados por
traps nativos.
Por lo tanto, Una completa interfaz de gestión de averías presentado a los usuarios de
agente del servicio incluye:
• Traps del Cisco MGX 8230, Cisco MGX 8250, Cisco MGX 8830, Cisco MGX 8850
PXM1-based, Cisco MGX 8850 del Cisco MGX 8220 PXM1E-basaron, y Cisco
MGX 8850 PXM45-based.
• Representaciones de traps de alarmas robustas de Cisco IGX, Cisco BPX 8600.
• Representaciones de eventos textuales de Cisco IGX, de Cisco BPX 8600, de
Cisco MGX 8230, de Cisco MGX 8250, de Cisco MGX 8830, de Cisco MGX 8850
PXM1-based, de Cisco MGX 8850 PXM1 E-basado, y de Cisco MGX 8850
PXM45-based.
• Traps de CWM
30
• Los traps que son entregadas por el agente del servicio son traps estándares de
la SNMP-Versión 1. Estas traps se entregan a nombre de los dispositivos de la
red y del CWM.
El agente del servicio entrega traps en modo (RTM). En este modo la perdida de traps
puede ser detectado y ser recuperado por los gestores SNMP.
Para recibir estos traps RTM del agente del servicio, un gestor SNMP debe registrarse
con el agente del servicio.
El agente del servicio entrega las siguientes categorías de traps:
• Traps que son generados en CWM que reflejen el estado de CWM.
• Los Traps que son generados en CWM basados en los mensajes robustos
propietarios recibidos de los dispositivos del Cisco BPX 8600 y del Cisco IGX
8400.
• Traps que se generan en Cisco MGX 8220, Cisco MGX 8230, Cisco MGX 8250,
Plataformas del Cisco MGX 8850 PXM1-based, y del Cisco MGX 8850 PXM45-
based.
4.4 Recolección de eventos en la red de Agregación y la red IP
En la capa de agregación de la red de la operadora en estudio tenemos routers Juniper
ERXs que al igual que los routers M40/T320 de la capa de agregación son gestionados
por el gestor NNM (Network Node Manager) HP-Open View.
NNM (Network Node Manager) proporciona facilidad de uso para gestionar fallas,
configuración para redes multifabricante redes TCP/IP y IPX/SPX. Usted puede usar
NNM para lo siguiente:
• Descubrimiento automático de la red, permitiendo monitorizar el estado de la red
• Obtener el mapa topológico de la red IP o IPX basado en la información del
descubrimiento de la red. Descubrir dispositivos en sus segmentos apropiados.
• Manejar cualquier dispositivo que soporta SNMP.
31
• Incluye nueva enterprise-specific Internet MIBs y NNM's MIB. Al cargar los nuevos
módulos MIB en el estación, usted puede acceder a cualquier objeto MIB definido
en el modulo MIB.
• Definir thresholds events para mibs objetos, por ejemplo, un evento puede ser
generado cuando el uso de disco se ha excedido un limite.
• Diagnostica defectos en la red y problemas de performance. Esto incluye
personalizar y automatizar en repuesta a los eventos de la red.
Un evento es una notificación no solicitada del gestor o agente que indican que una de
las siguientes condiciones ha ocurrido
• Se ha excedido un umbral establecido
• La topología de la red ha cambiado
• Un mensaje de información o de error a ocurrido
• El estado de un objeto ha cambiado
• La configuración de un nodo ha cambiado
• Una alerta de aplicación ha ocurrido
Los informes de trap SNMP y Notificaciones SNMPv2 son recibidos por ovtrapd.
4.4.1 Proceso ovtrapd
Los traps generados por un agente (snmpd en el caso del agente HP OpenView SNMP )
van a ovtrapd (iba UDP port #162), los cuales son forwards al pmd, ovtrapd actúa como
un buffer para los traps que pueden potencialmente ser borrados cuando el pmd esta
ocupado, pmd reenvía estos traps (en forma de un evento) a netmon, ovactiond,
ovtopmd, ipmap, xnmevents y otros potenciales aplicaciones como es el caso de la sonda
nnm5 de CIC (Cinco lnfo Center) que será explicada mas adelante.
c�e�ent� -.,_,. _______ _
.__º_v_a_c_t_i_on_d _ _.�--����s.------,pmd
Events / ,___� _ ___.-,
trapd.log
....---netmo------,n r E;ents ---1�--------:��-:-
ovtrapd. ,�:J;-d. l� -� old
Manager
Agent Traps
C] background process •C_� applicatlon, toreground process t-==-j database
Figura 4.4.1 ovtrapd Interacción con agentes SNMP.
4.5 Recolección de eventos para los servicios IP
32
El método diseñada para monitorizar la confiabilidad, tiempo de respuesta y
funcionamiento de los Servicios de Internet como Aplicaciones web (Comercio
Electrónico), E-mail, DNS, FTP, etc, es el testeo en forma periódica de un determinado
servicio; el resultado de dichas pruebas es utilizado para generar: alarmas y/ eventos de
la información del estado de servicio (rendimiento), facilitando de esta manera la
identificación de áreas con problemas en la red.
4.5.1 Listado de pruebas DNS
La Monitorización del servicio DNS, es llevado a cabo por el monitor DNS, el cual se
configuró para realizar consultas a 4 servidores DNS (2 primarios en Washington y 2
secundarios en San Isidro) y a los 2 content switch (de Washington y San Isidro). Se
configuraron 2 consultas para cada Content Switch y cada Servidor DNS, una con
resolución local y la otra con resolución remota, utilizando para ello los dominios
www.metroperu.com y www.google.com respectivamente. Número Total de Consultas
Configuradas 12. Se muestra la siguiente tabla con los parámetros usados en la
configuración del monitor:
33
Nº Puert Resol u ció Dominio de Intervalo
Test Nodo Equipo Nombre Dirección IP o n búsqueda (seg)
Content huandoy.tdp.net.p 200.48.225.14 metroperu.c
1 Switch e 6 53 Local om 600
Content huandoy.tdp.net.p 200.48.225.14
2 Switch e 6 53 Remota google.com 600
Servidor metroperu.c
3 Washingto DNS Pastoruri 10.3.1.21 53 Local om 600
n Servidor
4 DNS Pastoruri 10.3.1.21 53 Remota google.com 600
Servidor metroperu. e
5 DNS Huaytapallana 10.3.1.22 53 Local om 600
Servidor
6 DNS Huaytapallana 10.3.1.22 53 Remota google.com 600
Content huascaran.tdp.net 200.48.225.13 metroperu.c
7 Switch .pe o 53 Local om 600
Content huascaran.tdp.net 200.48.225.13
8 Switch .pe o 53 Remota google.com 600
Servidor metroperu.c
9 DNS Alpamayo 10.3.2.22 53 Local om 600 San Isidro
Servidor
10 DNS Alpamayo 10.3.2.22 53 Remota google.com 600
Servidor metroperu.c
11 DNS Sabancaya 10.3.2.21 53 Local om 600
Servidor
12 DNS Sabancaya 10.3.2.21 53 Remota google.com 600
Tabla 4.5.1 Testees DNS.
P�storuri 10.3.1.21 c;:¡H·,·
Huayta lana . 10. 1.22
, huascaran.tdp,net.pe '" "' ·'' 200.48.225.130
-� f'
,. �.. :,:i '"'
WASHINGTON
_,,,..--,- --�'"'
· ··. ·------·--:---.
( Internet. : \ � ) ----··--.. · ·
-�.,.
:;i---__.�-r�--- -
�ervidores
ONS
Content
Switch
34
Figura 4.5.1 Pruebas DNS en el lado de Washington - análoga en San Isidro.
4.5.2 Listado de pruebas LDAP
La Monitorización del servicio LDAP, es llevado a cabo por el monitor LDAP, el cual se
configuró para realizar pruebas a los 2 servidores LDAP (uno en Washington y el otro en
San Isidro). Se configuraron 2 consultas para cada Servidor LDAP, una utilizando el
usuario sigres1@speedy, y la otra utilizando el usuario sigres2@speedy. Número Total
de Consultas Configuradas 4, Se muestra la siguiente tabla con los parámetros usados
en la configuración del monitor:
Nº Test Nodo Equipo Nombre Dirección IP Puerto Usuario
WASH- cn=Directory
1 Servidor LDAP LDAP 10.3.1.7 389 Manager
Washingto WASH- cn=Directory
2 n Servidor LDAP LDAP 10.3.1.7 389 Manager
SISI- cn=Directory
3 Servidor LDAP LDAP 10.3.2.7 389- Manager
SISI- cn=Directory
4 San Isidro Servidor LDAP LDAP 10.3.2.7 389 Manager
35
[ Base de Intervalo Autenticaci
Nº Test Password búsqueda Filtro (seg) ón
uid=sigres1@s
peedy,ou=Use userPass
administrat rs,o=speedy,o word=sigr
1 or =telefonica es1 600 Simple
uid=sigres2@s
peedy,ou=Use telephone
administrat rs,o=speedy,o Number-2
2 or =telefonica 105564 600 Simple
uid=sigres 1@s
peedy,ou=Use telephone
administrat rs,o=speedy,o Number-2
3 or =telefonica 105538 600 Simple
uid=sigres2@s
peedy,ou=Use userPass
administrat rs,o=speedy,o word=sigr
4 or =telefonica es2 600 Simple
Tabla 4.5.2 Testeos LDAP.
SISI-WAP
10.3.?:7
Usuario Dial-Up
Pruebas con el usuario Sig.-csl@spocdy
Servidores LDAP
WASHINGTON
FW
Usuario
ADSL
Figura 4.5.2: Pruebas LDAP en el lado de Washington - análogo en San Isidro.
4.5.3 Listado de pruebas RADIUS
36
La Monitorización del servicio RADIUS, es llevado a cabo por el monitor RADIUS, el cual
se configuró para realizar pruebas a los dos servidores NavisRadius (uno en Washington
y el otro en San Isidro) y a los dos servidores que forman el cluster SMC (Servidor
RadiusADSL). Se configuraron 2 consultas para cada servidor NavisRadius, una
utilizando el usuario sigres@terra y la otra utilizando el usuario sigres@terraplana;
ambas consultas con la llave (shared secret) s1gr3s; Y para el servidor RadiusADSL se
configuraron también 2 consultas por cada servidor que integra el cluster SMC (Vira y
Cocha), una utilizando el usuario sigres1@speedy, y la otra utilizando el usuario
sigres2@speedy; ambas consultas con el secret adslauth. Número Total de Consultas
Configuradas 8 (4 para los NavisRadius y 4 para los RadiusADSL), Se muestra la
siguiente tabla con los parámetros usados en la configuración del monitor:
- ��-�-
Nº Test ..
1
2
3
4
5
6
7
8
Nodo Acceso
ADSL
Washi
ngton DIAL-UP
San
Isidro DIAL-UP
Equipo Nombre
Servidor
RADIUS-
ADSL VIRA
Servidor
RADIUS-
ADSL VIRA
Servidor
RADIUS-
ADSL COCHA
Servidor
RADIUS-
ADSL COCHA
Servidor
NAVIS
RADIUS PECORE
Servidor
NAVIS
RADIUS PECORE
Servidor
NAVIS PEUMAUT
RADIUS HSSC
Servidor
NAVIS PELIMAUT
RADIUS HSSC
37
Share
Dirección IP Puerto Secret Usuario
sigres1@s
10.3.1.16 1812 adslauth peedy
sigres2@s
10.3.1.16 1812 adslauth peedy
sigres1@s
10.3.1.17 1812 adslauth peedy
sigres2@s
10.3.1.17 1812 adslauth peedy
sigres@ter
10.3.1.6 1812 s1gr3s ra
sigres@ter
10.3.1.6 1812 s1gr3s raplana
sigres@ter
10.3.2.6 1812 s1gr3s ra
sigres@ter
10.3.2.6 1812 s1gr3s raplana
38
Estación de llamada
Passw autenticació Called Calling Intervalo Puerto
Nº Test ord n Login IP Host Station Station (seg) NAS
sigres
1 1 PAP 192.168.7.4 2105538 600 o
sigres
2 2 PAP 192.168.7.4 2105564 600 o
sigres
3 1 PAP 192.168.7.4 2105538 600 o
sigres
4 2 PAP 192.168.7.4 2105564 600 o
sigres
5 1 PAP 192.168.7.4 **** 600 o
sigres
6 1 PAP 192.168. 7.4 ****
600 o
sigres
7 1 PAP 192.168.7.4 **** 600 o
sigres
8 1 PAP 192.168.7.4 **** 600 o
Tabla 4.5.3: Testeos Radius.
SISI-LDAP . + 10,3,2.7 �- e;_.;.11111111-
PEUMAUTHSSC 10,3.2.6
SAN ISIDRO
Usuario Dial-Up
Servidores LDAP
PECORE 'd 10_3 ,l.6 r\ Se� ore_s
L../ Nav1 sRad1 u s
VIRA
10.3.1.16 r.-J\. Cluster
COCHA ll.:.y SMC 10,3.1.17
WASHINGTON
Pruebas con los usuarios sigresl @speedy slgras2@speedy
�,,,--------.._
Figura 4.5.3 Pruebas RADIUS en el lado de Washington - análoga en San Isidro.
4.6 Solución basado Cisco lnfo Center
39
La solución de Cico lnfo Center para la reelección de eventos para diversas tecnologías
de eventos la utilización de sondas que es la aplicación que es parte de la solución para
la gestión de fallas. Para la monitorización de servicio IP se utiliza INTERNET SERVICE
MONITOR (ISM) que permiten monitorizar servicios IPs configurando para ello consultas
y definiendo LSA (Leve! Service Agreement) para cada servicio monitorizado.
A continuación detallamos el funcionamiento de las sondas y la integración para la
recolección de eventos de la operadora.
4.6.1 Probes o Sondas
Estos componentes son los encargados de capturar los eventos de la red y conducirlos al
Object Server con el formato de alarma normalizada definido. El conjunto de
equipos/redes desde los que se están recibiendo eventos son:
•
o
Red de acceso: DSLAMs Alcatel, MAXTNTs
Transporte A TM: BPXs8620
• Agregadores: ERXs1410, VXRs7200 y BSNs5000 (SHASTAs)
º Core IP: M40s y T320s
40
Para la captura de los diferentes formatos de alarmas recibidos desde los equipos
anteriores se utilizan las siguientes sondas:
• Sonda Mttrapd: recolección de eventos SNMP (BPX y BSN)
o Sonda NNM5: recolección de eventos encaminados hacia el HPOV
(VXR,MAXTNT, ERX, M40, T320)
º Sonda GLF: recolección de eventos procedentes del A WS (DSLAM Alcatel)
• Sonda Ping, realiza un ping a los distintos equipos y genera una alarma si no
responde.
El detalle de la recolección de eventos en cada uno de los entornos es el que se refleja
en la siguiente figura.
sg-al-gw-pe
1 O. 226. 250. 229
Figura 4.6.1 Distribución de las sondas.
41
Sobre cada uno de los equipos contemplados dentro del rango del proyecto se ha
realizado un análisis exhaustivo de tipos de eventos a recibir y el formato de los mismos,
además se ha definido para cada uno de ellos la transformación al formato de alarma
normalizada. Fruto de todo este análisis se generó un entregable conocido con el nombre
de Catálogo de Alarmas Normalizado que puede ser consultado para conocer en detalle
los eventos mapeados por la herramienta.
4.6.1.1 Funcionamiento básico de las sondas
Son los probes !os que permiten obtener información de eventos, transformarla en el
Formato de Evento Común y enviarla al ObjectServer. El sentido de los probes es
recuperar datos de una fuente, transformarlos y enviar la información al ObjectServer.
Cuando el probe recibe una cadena de datos, particiona esa cadena en elementos
individuales (tokens), con los cuales construye el evento. El probe o sonda utiliza un
archivo de reglas donde se define la asignación de estos elementos 'particionados' a los
campos de evento que se volcarán en la tabla alerts.status. En e! fichero de reglas se
puede añadir también información extra al evento y realizar operaciones matemáticas
Dependiendo de! origen de los datos se utiliza un tipo de sonda u otra, en nuestro caso si
la fuente es un fichero de texto se utiliza la sonda GLF (Generic Lag File), o si por el
contrario la fuente son traps SNMP, la sonda utilizada es la MTTRAPD. También
disponemos de una sonda NNMS (Network Nade Manager) que lee eventos del gestor
HP OpenView.
El modo de operación de un probe puede dividirse en cinco etapas:
• lnicialización:EI probe se conecta al ObjectServer, identificando el formato de
la tabla alerts.status. Se leen y analizan los ficheros props y rules del probe y
éste queda preparado para recibir eventos.
º Recuperación de Eventos: El probe recupera los eventos de la fuente de
datos. Esta operación puede realizarse a través de un API, leyendo un
archivo de log o conectándose a un puerto serie.
• Partición: El probe particiona la cadena de datos del evento en elementos
individuales($), los cuales son utilizados en el archivo de reglas.
42
• Archivo de Reglas (Rules File):Una vez que el probe ha particionado la
cadena de datos del evento, el evento es analizado por e! archivo de reglas,
donde se fijan los valores de los campos (@)
� Envío de Evento: El último paso consiste en enviar el Evento al
ObjectServer, asegurándose de que dicho evento es recibido. Si ocurriese
cualquier problema durante e! envío, el probe lo almacenará en un archivo a
la espera de recuperar la conexión con el ObjectServer. A continuación, el
probe recupera el siguiente evento .
•
4.6.1.2 Fichero de propiedades
Todos los probes tienen propiedades estándar, tales como -server, -version. Algunos
probes tienen además propiedades específicas, necesarias para cada tipo de
monitorización:
Estas propiedades se pueden fijar bien con opciones de línea de comandos a! arrancar la
probe o bien en el fichero de propiedades. El fichero de propiedades está localizado en
$OM NI HOME/probes/solaris2.
Las opciones de línea de comando son:
$OMNIHOME/probes/nco_p_probename -help
name: Nombre del probe. Corresponde al nombre utilizado para los ficheros de reglas y
propiedades
rulesfile: Fichero de reglas a utilizar
versión: Muestra información de versión. Es importante para identificar la versión y los
parches aplicados al probe
server : ObjectServer al que se conectará el probe
saf: Almacenamiento y Envío (Store & Forward) de eventos.
Store and Forward
Esta propiedad permite al probe seguir recibiendo eventos aún cuando se haya perdido la
conexión con el ObjectServer. Los eventos se almacenan en un archivo en el directorio
$OMNIHOME/var. Cuando se recupera la conexión con el ObjectServer, el probe envía
todos los eventos almacenados en archivo, y continúa funcionando en modo normal. Por
defecto, esta propiedad (store and forward) está activa.
43
El valor de una propiedad debe escribirse entre comillas simples. Para incluir la opción de
línea de comandos -rulesfile, añada al archivo de propiedades:
RulesFile: '/opt/Omnibus/probes/solaris2/glf.rules'
IMPORTANTE: Los valores de las propiedades que están comentadas son los
valores por defecto. Si queremos modificar e! valor de una propiedad NO
descomentaremos dicha propiedad sino que la añadiremos al final del fichero.
4.6.1.3 Fichero de reglas
El propósito principal del archivo de reglas es definir el campo ldentifier, utilizado en la
deduplicación de eventos.
Tocios los campos de la tabla alerts. status se pueden fijar en el archivo de reglas
Puede añadirse también información adicional en el archivo de reglas
Para que el probe interprete los cambios realizados al archivo de reglas es necesario
enviarle una SIGHUP:
kill-HUP PID
PID: Identificador de proceso del probe.
Cuando el probe recibe una cadena de eventos de la fuente de datos, la particiona en
'tokens'. Estos tokens no son estáticos y dependen del evento recibido.
Los tokens se identifican en el archivo de reglas con el carácter '$', p.e. $Node es un
token que representa el nombre del nodo. Es posible utilizar estos tokens para rellenar
los campos de la tabla alerts.status.
Ejemplo de asignación:
2005 12 January 12:00:00 wombat The interface hme0 is down 3 hme0
$Year = 2005
$Day = 12
$Month = January
$Time = 12:00:00
$Interface = hme0
$Node = WASHBPX
$Summary = The interface hme0 is down
$Severity = 4
En el archivo de reglas, los campos de la tabla alerts.status se representan con el
carácter'@', p.e. @Node es el valor del campo Node. El valor que se le asigna a estos
campos de la tabla alerts.status es el obtenido de los tokens que han sido extraídos de la
cadena de evento recibida.
Asignación Directa
Concatenación
Añadiendo texto
@Node=$Node
@Summary=$Summary + $Group
@Summary=$Node + " has problem " + $Summary
Algunas sentencias de asignación utilizadas en las sondas son:
match(@Node, "Cocha") coinciden exactamente
nmatch(@Node, "Cocha") comienza con Cocha
regmatch(@Node, ""coc[0-9]")
exists($Node)
expresión regular
comprueba si el token existe
4.6.1.4 Parada y arranque de las Sondas
44
Las tres sondas que utilizamos pueden pararse y arrancarse con el PADMIN (utilidad
proporcionada por CIC).
o
•
..
•
SondaGLF
SondaMtttrapd
SondaNNM
SondaPing
También se pueden parar todas a la vez parando el Servicio Sondas con el PADMIN:
Al igual que todos los componentes de CIC, las sondas se pueden parar y arrancar
manualmente desde línea de comandos:
Script de Arranque de las probes
$OM NI HOME/probes/solaris2/nco _p _probename
A continuación se enumeran los ficheros de propiedades, reglas y script de arranque de
las sondas:
• Ficheros de propiedades (en $OMNIHOME/probes/solaris2):
mttrapd.props
nnm5.props
glf.props
• Ficheros de reglas (en $OMNIHOME/probes/solaris2):
45
mttrapd. rules
nnm5.ru!es
glf.rules
� Script de arranque de las sondas (en $OMNIHOME/probes/solaris2):
nco_p_mttrapd
nco_p_nnm5
nco_p_glf
4.6.2 INTERNET SERVICE MONITOR (ISM)
Netcool/lSMs es una aplicación diseñada para monitorizar la confiabilidad, tiempo de
respuesta y funcionamiento de los Servicios de Internet como Aplicaciones web
(Comercio Electrónico), E-mail, DNS, FTP, etc. Cada Netcoo!/ISMs testea en forma
periódica un determinado servicio; el resultado de dichas pruebas es utilizado para
generar: alarmas (Netcool/Omnibus), e información del estado de servicio (rendimiento),
facilitando de esta manera la identificación de áreas con problemas en la red.
4.6.2.1 Arquitectura Netcool/lSMs
Los Componentes del Netcool/lSMs son:
• ISM-Server
Es un programa independiente (stand-alone), que mediante su interfaz web
permite: la configuración de los monitores; la visualización de reportes sobre
la disponibilidad y rendimiento del servicio. Y finalmente ta comparación del
estado del servicio con los objetivos del SLA (Service Level Agreement).
º Databridge
•
Es un programa independiente, que actúa como un puente de
comunicaciones entre los Monitores, el lSM-Server, el ObjectServer y alguna
otra Base de Datos. El Databridge recibe la información (resultado de los
tests) enviada por !os monitores y la distribuye a sus respectivos módulos:
ObjectServer (incluye un fichero de reglas que procesa todos los eventos,
que serán enviados al ObjectServer), XML-Datalog (produce ficheros
datalogs, los cuales se enviarán al ISM-Server) y Database (que implementa
conexiones a bases de datos externas como Oracle, MySQL, etc)
Monitores
46
Son programas independientes configurados para testear, probar la
disponibilidad, rendimiento y tiempo de respuesta de un especifico servicio
de internet y/o protocolo tal como lo hiciera un usuario común. Los monitores
son a su vez responsables del envio de !os resultados de dichas pruebas al
Databridge.
Los Netcool/lSMs pueden monitorizar el estado de más de 20 protocolos de internet y los
servicios proveídos por ellos, a petición de TdP (Telefónica del Perú) sólo se configurará
los monitores para los servicios de: DNS, LDAP y RADIUS .
Eventos
._R_e-su-lt-:dos-es-ts--�-t]::�°i!{ • .
-------- Ficheros Rules
Configuración datos
Configuración datos
Figura 4.6.2.1: Arquitectura del Netcool/lSMs.
yprops
CAPITULO V
ANÁLISIS Y PROCESAMIENTO DE EVENTOS EN LA RED.
5.1 Normalización de Eventos
Las alarmas generadas en la red por los distintos elementos de la red de la operadora
atienden a formatos bien distintos que son procesados y adaptados al formato de alarma
normalizado que es el que reside en el core del Repositorio de Alarmas.
5.1.1 Repositorio Centralizado
El Repositorio de Alarmas Centralizado contiene, a cada instante, el conjunto de eventos
que representan el estado actual de la planta de de la operadora, elimina mediante
correlaciones básicas de activación/cese las ráfagas de eventos esporádicos de la red y
aquellos eventos que bien por su antigüedad o bien por su irrelevancia no son útiles para
la supervisión. De esta forma, ofrece al usuario de supervisión la posibilidad de acceder
vía web a los eventos normalizados generados por los distintos elementos de la red
objetivo del proyecto, agilizando y mejorando los procedimientos de detección de
problemas en la red.
Todos los eventos adquiridos en la capa de recolección son procesados e introducidos en
el core del Repositorio de Alarmas Centralizado, el usuario utilizará una interfaz vía web
para e! acceso a dichos eventos.
Para el seguimiento detallado de la monitorización de servicios el usuario dispondrá,
dentro del Repositorio de Alarmas Centralizado, de acceso a una interfaz web que le
permitirá ver la evolución y el detalle de la configuración de cada una de las pruebas
realizadas.
• Object Server
Este componente es el core del Repositorio de Alarmas Centralizado y consiste en una
base de datos en memoria que contiene la relación de eventos recogidos de la red, la
característica de ser una base de datos en memoria hace que el acceso a la información
de la misma sea más rápida que en una base de datos convencional.
48
Además de contener el detalle de las alarmas acontecidas en la red, el Object Server,
alberga información de gestión de usuarios, conversiones numéricas a texto,
automatismos internos, menús y tooles.
Esta base de datos es parte de la solución para la gestión de fallas de CIC(Cisco lnfo
Center) que es el core de la herramienta.
11:1�,llii l'I - Sondas
��./
Figura 5.1.1 ObjectServer (Repositorio Centralizado).
5.1.2 Proceso de Normalización
En la figura 5.1.2 se muestra el proceso de normalización de eventos que se basa en la
identificación y estudio de los eventos de la red la operadora que permite la identificación
de los eventos por parte del operador.
A continuación se hacer un resumen de proceso de normalización de los eventos.
• Se recoge las alarmas que provienen de todos los equipos de la red, cada uno
con un formato diferente
49
• Se realiza una labor de descarte y filtrado ya que en algunos casos el volumen de
alarmas es enorme e innecesarios para la operadora. Este trabajo se realiza de
forma conjunta con la operadora.
e Se procede a categorizar cada evento independientemente de la tecnología de los
equipos a monitorizar. Por ejemplo a continuación detallamos dos eventos que
pertenecen a distintas tecnologías Alcatel ADSL y Router ERX 141 O.
Evento Alcatel ADSL
LOS (Loss of signa! clock)
Evento Router ERX 1410
juniNtpFirstSystemClockSet {This trap wi!I be generated to report when the
system clock offset error is set for the first time from the good time sample taken,
enabling the time synchronization. This is usually the case after a system reboot. )
Estas son categorizadas dentro de la categoría Clock_Alarm de esta manera
estos eventos se identificaran por esta categoría así pertenezcan a tecnologías
diferentes permitiendo posteriormente hacer alguna clase de análisis y
automatización con estos eventos.
• Tras la laborar de adaptación realizada, los nuevos campos se almacenan en la
8800 del Object Server.
Se recogen las alarmas que provienen de todos los equipos de la red, coda una con un fonnulo diferente
Catálogo de Alarmas
NO normolizodo
··,.._ :.;.:•:-�···· .. •····��
. · - .. -.:.�;l .,o.·'.:�)�¡_.¡v t'� •.,,¡�
'11
-·· ... - . �!;�_--_: ;s.·:. . ... :=�:-�---�-�-�--;���-.
Se realiza una labor de descarte y lilb'Bd.>. ya que en algunos ""'°" el voltm1en ele ahumas es enorme y de adaptación a l()S cumpoo de la alauna noanalizada
j•c,·,.w.,•·,·,.· ... :Il>
Catálogo de Alarmas
NORMALIZADO
•! ::---:".'" ..... ·• · · • •· •��-.. -- __ ..
'fms la labor de adaplación realizada. los mrevoa campos se almacenan en la BBDD del O ·ect Smver
ObjectServer Tabla alttt1.statas dota BBDD del Object Server. En esta tnbla so guardan los campoo de las a lannas.
Figura 5.1.2 Proceso de Normalización.
CAMPO
SATEGORY
ifECHNOLOGY
STDSUMMARY
ALERTGROUP
OBJECTTYPE
NODE
NODEALIAS
NENAME
NEADDRESS
MANAGER
AGENT
ALERTKEY
IDENTIFIER
SEVERITY
DESCRIPCIÓN
Categoría normalizada de la alarma
Red [IP\A TM\ADSL] - Fabricante Equipo
Detalle de la alarma normalizado
Grupo de alarma
Tipo de alarma
Equipo que notifica o envía la alarma
IP del equipo que notificala alarma
Equipo dónde se origina la alarm
IP del equipo dónde se origina la alarma
sonda® hostname
Gestor de red o en su defecto nombre de
equipo
Parte del equipo afectada por la alarma
Es la clave para la correlación de alarmas,
está definido de tal forma que un mismo
tipo de problema localizado en un mismo
equipo, se mapea sobre la misma alarma
Severidad de la alarma
Indica si la alarma en un problema (1) o
¡TYPE una resolución (2)
SUMMARY Detalle por defecto de la alarma
uepartamento/Provincia a la que
AREA pertenece el equipo
Distrito/Local donde está ubicado el
LOCA TION equipo
ADDITIONALINFO Información adicional de la alarma
OWNERUID Usuario propietariode la alarma
DWNERGID Grupo propietario de la alarma
�CKNOWLEDGED Marca de alarma reconocida
íl""iempo de caducidad de la alarma,
EXPIRETIME Severity 1 - 48h, Severity 2 - 72h, Severity
50
�ampos
externos
j3 - 168h
1 ipología de evento: ADSL, A TM, gregadores, CorelP, Servicio,
Desempeño, Polling, RAS
Fecha de última actualización de la alarma
Número de veces que ha llegado la
Identificador único de la alarma, número de serie del evento
Tabla 5.1.2 Definición de alarma normalizada.
51
Para la gestión de las alarmas normalizadas de todos los equipos de la red, además de
las provenientes de la monitorización de los servicios de Internet se elaboró el Catálogo Normalizado de Alarmas., este es un documento Excel en el que se distribuyen por vistas las alarmas normalizadas de todos los equipos tal como se mostrarán en el repositorio Normalizado cuando las visualicemos.
5.2 Correlación de Eventos
Para la gerencia de fallos del proyecto SIGRES, varios tipos de correlaciones fueron implementados. Este apartado describirá tales correlaciones.
• Detección de duplicaciones de eventos
• Enriquecimiento de alarmas
• Correlación de evento de falla con su evento de Clear ( on/off)
• Automatizaciones para eliminación de eventos• Intermitencia de eventos
5.2.1 Detección de duplicaciones de eventos
Para elementos de red que presentan algún fallo, es normal que, en determinadas ocasiones, el evento representando este fallo, sea generado más por un golpe. Esto puede ocurrir debido al propio mecanismo de gerencia de estos elementos o debido al funcionamiento intrínsico de los elementos de red. Aunque este evento esté siendo
52
generado continuamente, del punto de vista de gerencia, sólo un evento es necesario. El
proceso de detectar cuáles eventos son idénticos es llamado de detección "de
duplicaciones de eventos". Para ello el repositorio Centralizado (BBDD en memoria
ObjectServer), utiliza del campo ldentifier para identificar eventos duplicados, o sea,
siempre que él recibe más de un evento con el mismo ldentifier, el ObjectServer
considera que no es un nuevo evento que está siendo recibido, pero sí, está es una
nueva ocurrencia de un evento anterior. La definición del campo ldentifier es realizada en
cada sonda en el proceso de recolección de eventos.
5.2.2 Enriquecimiento de eventos
Al recibir los eventos provenientes de !as sondas, muchos de ellos no poseen la
información de Nombre del Elemento (NEName) o Dirección del Elemento (NEAddress).
Para solucionar este problema de una forma centralizada, fue implementada una política
en el enriquecimiento de eventos, que identifica lo que el evento posee: nombre o
dirección y completa la información que estuviera faltando.
Estas políticas de enriquecimiento son implementadas usando lmpact que forma parte de
la arquitectura de solución de (CIC) Cisco lnfo Center esta herramienta permite
conectarse con Base de datos propietarias para obtener información adicional de los
elementos de red como por ejemplo IP; Nombre, Localidad del equipo,# de Usuarios, etc.
La política de enriquecimiento ejecuta entonces el siguiente algoritmo:
1. Convierte NENAME y NEAddress en mayúsculas.
2. Verifica si NEName es un IP o un nombre.
3. Si NEName es un IP, entonces:
a. NEAddress recibe NEName
b. Se busca por el IP, cual es el nombre del elemento en la tabla
IMPACT _NENAME_IP
c. NEName recibe el nombre encontrado.
4. Se NEName es un IP, entonces:
a. Verifica si NEAddress es un IP
b. Si NEAddress es un IP, entonces:
i. Sebusca por IP, cual es el nombre del elemento en la tabla
IMPACT _NENAME_IP
ii. NEName recibe el nombre encontrado.
c. Si NEAddress no es un IP, entonces:
i. Supone que NEName sea um nombre.
ii. Se busca por nombre, cual es el IP del elemento en la tabla
IMPACT _NENAME_IP.
iii. En el caso de encontrar el nombre, NEAddress recibe el IP
encontrado.
5. Por e! NEName se descubre cuál es la localidad.
6. Location recibe la localidad.
5.2.3 Correlación de evento de falla con su evento de Clear (on/off)
53
En la red, cuando un evento de fa!!o es generado, este evento se quedará activo en e!
ObjectServer del CIC, posibilitando la visualización por el operador de que existe un fallo.
Cuando el elemento deja de presentar fallo, el propio elemento o un controlado de
elementos, genera un evento de clear para este fallo. Este evento de clear es un nuevo
evento que debe ser correlacionado al evento anterior de fallo. Esta cuestión es resuelta
a través de una automatización (triggers en BBDD) denominada GenericClear, la cual
rueda cada 15 segundos. La automatización GenericClear es resuelta en dos etapas:
Trigger y Action. La etapa Trigger selecciona eventos que contiene información relevante
para la etapa de Action, donde efectivamente ocurre la alteración del registro. Así
tenemos la siguiente regla:
Tigger:
select ldentifier, LastOccurrence, NEName, AlertGroup, AlertKey from
alerts.status where Type = 2 and Acknowledged = O and Severity = O;
Action:
update alerts.status set Severity = O, Grade= Grade +1 where Severity > O and
Type = 1 and LastOccurrence <= @LastOccurrence and NEName = '@NEName'
and AlertGroup = '@AlertGroup' and AlertKey = '@AlertKey';
update alerts.status via '@ldentifier' set Severity = O, Acknowledged = 1;
5.2.4 Automatizaciones para eliminación de eventos
El objetivo del de estas automatizaciones es mantener los eventos que actualmente
representan fallo, o sea, sólo los eventos actuales. Para efecto de histórico, los eventos
son enviados a la base de datos Oracle, pero en el ObjectServer debemos mantener sólo
los eventos actuales. Debido a ello algunas automatizaciones fueron creadas para
eliminar eventos que ya no representen un problema. Son ellas:
54
• DeleteClears
= Delete 24hs old
DeleteClears
La regla DeleteC!ears rueda cada 93 segundos y su objetivo es borrar los eventos que
estén en el estado de clear de más de 5 minutos.
Regla: delete from alerts.status where Severity = O and Abertura <> 10 and
StateChange <= (getdate - 300);
Delete 24hs old
La regla De!ete 24hs o!d rueda cada 1577 segundos y su objetivo es remover los eventos
más antiguos que 24 horas.
Reg!a: delete from alerts.status where ( LastOccurrence < getdate - 86400 );
5.2.5 Intermitencia de eventos
Existe en la red la posibilidad de algunos fallos intermitentes, por ejemplo, una puerta de
un router que se cae e inmediatamente enseguida sube nuevamente. Este tipo de evento
es de difícil observación por el operador, principalmente si la puerta pasa más tiempo
activa que inactiva. En conjunto con la operadora se definió por crear en el ambiente de
gerencia de fallos, una variable que fuera capaz de medir la intermitencia de un
determinado evento. Para que midamos este dato, utilizamos el campo Grade del evento
en e! CIC, y hicimos con que cada Clear para un evento el Grade incrementara en 1.
Como, al recibir un clear el evento continúa activo por lo menos 5 minutos, es de
esperarse que un evento intermitente vuelva a representar fallo antes de este periodo,
luego el campo Grade irá incrementando cada ocurrencia.
5.3 Análisis de Causa Raíz en los eventos
Dentro de un ambiente de red controlado, muchas veces existe avalanchas de eventos
que son decurrentes de una única causa. Entendemos como Analice de Causa Raíz la
correlación hecha entre varios eventos diferentes, a fin de identificar cua! evento puede
ser considerado como "causa raíz" de otros eventos, facilitando la identificación por parte
del operador de cuál es el problema real. Un ejemplo típico de este tipo de correlación es
el caso donde varios eventos de Node Down llegan hasta la interfaz del operador, pero
55
efectivamente la causa de estos eventos es la caída de sólo un equipo o una interfaz de
un equipo. Aunque simple de ser imaginado este problema es de compleja resolución
automática por los sistemas utilizados, por esto varias herramientas del CIC, fueron
utilizadas en conjunto para producir el efecto deseado por el cliente. Son ellas:
Automatizaciones, Políticas del lmpact y Políticas del Precisión.
Para el proyecto las siguientes reglas de correlación de causa raíz fueron desarrolladas:
1 Correlación de Causa Raíz entre eventos de un mismo nodo.
Según esta definición, si el sistema recibe varios eventos de shelf, slot y puerta deun
mismo nodo, el sistema deberá correlacionar estos eventos encontrando la causa raíz.
2 Correlación de Causa Raíz entre eventos Node Down y otros eventos del mismo
Nodo.
Según esta definición, si el sistema recibe un evento de Node Down, este
deberá ser considerado con causa raíz de otros eventos ocurridos para el
nodo.
3 Correlación de Causa Raíz entre eventos Node Down.
evento
mismo
Según esta definición, si el sistema recibe un evento Node Down, el sistema deberá
relacionar este evento con otros eventos Node Down de nodos aislados por el fallo del
primer evento.
5.4 Solución basado Cisco lnfo Center
56
En este apartado se describe la distintas herramientas que hacen posible la
implementación de las tareas emprendidas en este capitulo.
Histórico de Eventos
l!f ,iJl.f lJii:¡; 1 \
lmpact
ObjectSen,e
Sondas
# r
Webtop
• •
Figura 5.4 Solución Cisco lnfo Center.
lmpact es la principal herramienta de análisis y correlación de datos para la suite de
productos CIC. Utilizado principalmente para customizar y mejorar el rendimiento del
ObjectServer haciendo posible el enriquecimiento de eventos, notificación de eventos
especiales y la integración con otros sistemas como bases de datos, sistemas de
mensajería, aplicaciones de inventario, etc. lmpact puede enriquecer y actualizar un
determinado evento con información contenida en su 8800 interna o en otras bases de
datos como Oracle .
LJ OBJECTSERVER
IMPAC
Tratamiento
avanzado de
eventos
u Figura 5.4.1 lmpact (Tratamiento avanzaao ae eventos).
Precision /Topoviz
BBDD
interna
57
Precision nos permite obtener la topología de red desde una BBDD cargada mediante un
procedimiento mixto de autodescubrimiento de red y carga por fichero.
La base de datos de topología de red de Precision se actualiza mediante dos procesos
distintos:
Carga automática de datos de red mediante descubrimientos. Precision dispone de
agentes que debidamente configurados realizan el descubrimiento de la red y almacenan
los datos obtenidos en la BBDD de topología.
Carga manual mediante fichero de texto. Los datos que se introducen en la BBDD de
topología mediante carga por fichero son facilitados por TdP. Mediante unos scripts de
Unix, los datos que siguen un determinado formato en el fichero, son leídos y extraídos
para ser almacenados en la base de datos.
�--·· Re&
·�- -- - a, .
- --
Arqt1i'-·o de Carga de.
Totologia
Amos
Precision
Figura 5.4.2a Funcionamiento de Presicion.
1 Las probes recolectan eventos de la red y los encaminan al ObjectServer.
58
2 De tiempos en tiempos el Inventario deberá crear un archivo con toda la información
de topología, la cual será cargada en el precision.
3 Dentro del precision, el componente Model es el responsable por el banco de datos
de Topología.
4 El gateway del prec1s1on mantiene informaciones de eventos, provenientes del
ObjectServer, y de topología, provenientes del Model, relacionándolas.
5 El Componente Amos del Precision es responsable por el análisis de causa raíz
(RCA - Root Cause Analice). Relacionando las informaciones de eventos con la
información de topología él identifica cuáles eventos deben ser considerados Causa
(Root) y cuáles deben ser considerados Síntoma (Symptom).
6 Después del analisis el Gateway actualiza estas informaciones de !os respectivos
eventos en el ObjectServer.
Para que un evento llegue hasta un analice de causa raíz es preciso que él pase por un
filtro de selección, tenga un reconocimiento sobre cual regla de analice él participará, sea
posible encontrar la entidad con fallo en el banco de topología y sea posible encontrar el
elemento de referencia para la designación de la correlacion. Este proceso puede ser
verificado por la siguiente figura:
No
No
No
Discard
ObjectSe-rver
Ewnt En.-k:hment
Updale E�nt
Yes
Figura 5.4.2b Filtro de selección para RCA.
AMOS
OOL lnSE-rt
Statsm�nt
59
Una vez que los eventos llegan estén disponibles para el proceso Amos de tratamiento
de causa raíz, el precision se utiliza de los siguientes conceptos para este tratamiento:
a. lnstance (sólo el elemento con fallo).
b. Connected (elementos conectados)
c. lsolated (elementos aislados)
Poll
Fail
Polling IOC;lti(m
Examole Ne,twork
C<)ntrol = o Onst�ncl!'i
,:ontrol ;e 2 (Connected}
co1)t,o.J = 1 !lsolat�,
concml "" 2 {Connect�d) rndude_ trigger _ entity;., true
Figura 5.4.2c Conceptos de RCA.
60
Según este concepto, en las políticas del precision, a partir de la información del
elemento en fallo y del elemento responsable por e! polling, conseguimos identificar quién
son los elementos conectados al elemento de fallo o quien son los elementos aislados
por él.
En el banco de datos de topología (Model), elementos de red, sus shelfs, slots, puertas,
etc, son organizados según un modelo de containment. Gracias a esta organización,
conseguimos, por ejemplo, instanciar puertas dentro de slots y así correlacionar
eventuales fallos de slots y puertas. La figura abajo muestra este concepto.
1
2a 2b
3a 3b -/
3c
� 4 14 4 � b •. d e t
Figura 5.4.2d Modelo Containment
CAPITULO VI
MECANISMO DE PRESENTACIÓN Y GENERACIÓN DE REPORTES
DE LOS EVENTOS.
6.1 Web de supervisión
Para establecer la interfaz con el usuario final, fue desarrollado un portal web de acceso
al Sistema. Describiremos en este capítulo como fueron hechas las implementaciones del
ambiente de fallos para utilización por el portal
Con cualquier navegador se accederá a Webtop y a los distintos servicios del Sistema,
esta es la herramienta principal que usaran los operadores.
En la web de supervisión se tendrá acceso a:
• Resumen Ejecutivo que es el resumen a golpe de vista del estado de la red.
• Mapas de supervisón distribuidos jerárquicamente por departamento, provincias,
categorías de eventos, Distrito (solo para Lima).
• Lista de Eventos.
• Reportes predefinidos de la BBDD de históricos.
• Mapas topológicos de la red de la operadora.
■·s.i.«i=":.;· i:J fl.T�O$ r;J QF!-•"-<l=!JF'Fr-,mvn
�} o ,,..,-_r,1;;,; •i1DN,W.OIW· iftD.ANCAEJ-1 .•. , .. Q#UA\'W.
. !r•a AAE<JJPA , .. CI A•1•r11rM,)' 1f C1 CAJ.I.M.IJ'iC.I. ., Q CVZ:CQ l•,1:31-fJAJlC'A\lt:UCA !"' c::l 14\JAIIUCO •
,¡
q "' . .. n ·"""� ¡g��:J� " l g �:-ElO ::· ..
<'\ 0 MOOuCGLIA
i:�n ./':=
ig �.wm-1 .. J:�� ,. 01�":l,'Ul'J
. O SOPOPT'f :· 1-W-JrnP�,gon
GJ c:wx.u,.,fffr.-.r,n,-,.
S&RVICfO
1m1:1;,;;�·i �·
•--•""'-'-•' ......
��l .!l!!!l!!!l ..
POI.UIC ,,�:'t':•!•
AGReGADORES
��i-!l!!!l!!l-
Figura 6.1 a Resumen Ejecutivo .
• '-f·l•.•·;· ..I6J.!Jt
___, ·7----I :J , ..... .,_ "(
..... ..,....,,,SIIG<l, . . , , ' . , ,, ' . •
• "'""''1111�10� f YJ IIU � ' • l' • , ' •• ; '1 ,:¡- • •• •• l. .. '
I/) · ,RES - .... � .... r...y,.c.
----�¡ 1 ·1 lwmnt
Figura 6.1 b Mapas de Supervisión.
t.-;U,. _ l�P IOr • .-,. '-t.:-� �
') ' : ó ; ··.\ ;� ;, ✓ ;.....;. • '. :·�- �' í¡?t�,?:1.�<� .f.¡
. , ... ,, •. -6)1.tb'JJI0.91.I. Ul,fl)ll[l.,!\V�11��'Y.J')� .. _,,___..,-...:.,u ,. ...... .
Figura 6.1 e Lista de Eventos.
62
NETCOOl"'/Wl'btop· ''" '" " --=,,.;. M
·,.-,111.i\\�1; ¡ , ' , ,')t.¡;¡.,i.1nkti!,;i�,¡t,ñ:{'•.�••,'o\r.,.¡ -! / �- •1 ', ,. ' , ,· r ,,,-, .', · 1 •--,�,, 1, • ..-: d',J_', 1�l,J,1.,,,r'..'b'1; ,,�--J"'J
·•st1ttt:' 1)-
. '.-Q.Sa�•-=onllg; _ft,·D�lltlL,,,
_ _.t:��111n-
!f_.Qsit;�II. ;::··
: L 19 oat11vn :·
1 el fmd11ij¡,' j-:E>.a♦l'l'abJo • . . ••
-f.� ::=: �:=t torAI:
:,- S Él•ÍMmo iin,rfxi, C IIIPITICIO!Qll �ª"'"*'
_.¡:_..e¡¡ ��mo"uo:1rit�•r,:
-r=--��-� ..;f �·-=-: :1::::�,·.-;�Gl Mio�uce
'.·-�.!�i
Figura 6.1 d Reportes de Históricos.
llltUOS ... - - V:
¡��-·-
.-¡;--· --�filw, .... ...,
- -
177 .ln.1.1 . 172.30.t.1 --
,.i.6.1A.1.9.1..2l7 -----�-
........ Figura 6.1 e Topología de la red.
13
m
!N
143 167
1
1�
00,
-ti.·
Y,
. :.,-;;..,.
63
64
6.2 Web para la monitorización de servicios de Internet
Esta web de supervisión permite al operador monitorizar los diferentes servicios de
Internet como son DNS, LDAP, Radius todo en tiempo real.
..- C:Ni,� e,r '� I,!""'� �
Q=. <i.). � � :, . .,-•� j:,,_..., ,1·; . :¿ .; 11,
Figura 6.2 a Status de los Servicios.
6.3 Solución basado Cisco lnfo Center
En este apartado se describe la distintas herramientas que hacen posible la
implementación de las tareas emprendidas en este capitulo.
6.3.1 CIC/Webtop
El módulo Webtop interactúa con las alarmas de ObjectServer a través de un navegador
web y permite que ciertos usuarios las manipulen, mediante listas de eventos activos
(AEL). Incluye también páginas de administración, que pueden utilizarse para dar
usuarios de alta, crear vistas, filtros. También incluye la capacidad de crear y editar
mapas. El servidor de Webtop publica alarmas sobre el protocolo HTTP, de manera que
puedan consultarse a través de cualquier navegador soportado. De esta forma los
operadores pueden monitorizar alarmas de su red vía web.
,I\C'tiv!!:· [vtont Lls.t
S ub·L "-'<.-nl l Is &
6.3.2 CIC/Reporter
.... •,..�e-•t ... ,,.,.:¡¡) •'•"' ifti�]�t
:,,Jcrts
lntc-r.;>ctivc O.:i.-:� FI co\d Only O�t.:, J',dmini5 huüon
T-,sk�
-- <¡,_._•::-�: .... ··:"t· .... -�. . .... � Administratlon Map Edrtor
-�---�-- ¡u ··e_ 'j==:-3 ,:
�lló!:"'!cit ! Mopl'I"'•
Figura 6.3.1 CIC/Webtop.
65
Netcool/Reporter es una aplicación cliente servidor basada en web que proporciona
funcionalidades de creación, diseño y vista de reportes sobre la base de datos Oracle
(histórico de alarmas). Reporter nos proporciona una capacidad histórica de reportes de
tres meses.
Los eventos son almacenados en una 8800 Oracle provenientes del ObjectServer a
través de un Gateway. El servidor de Reporter genera los reportes bajo demanda previa
consulta a la 8B00, que serán publicados en cualquiera de los formatos, html, excel y
pdf.
�I �
1 1
_j
JRun
W�b'Se.,,,,.,
Middl_.,,A
Figura 6.3.2 CIC/Reporter.
·HTMLP�o
Jaw.lpplffl
66
CONCLUSIONES
1. Dado que la solución es altamente escalable y rápidamente desplegable, las
soluciones CIC brindan una administración de servicios end-to-end, identificación
de problemas y automatización para ayudar a los proveedores de servicios a
operar con una mayor efectividad.
2. Mejorar la flexibilidad y adaptabilidad, acelere el tiempo al mercado para nuevos
servicios y adapte rápidamente para satisfacer los requisitos futuros del mercado.
3. Reducir los gastos operativos, mejora la eficiencia de las redes simplificando la
administración de grandes redes mediante la automatización de los procesos, la
integración de los procesos de servicios y la habilitación del personal para que
pongan el foco en actividades de mayor nivel.
4. Aumentar la satisfacción del cliente, reduzca la agitación del cliente y mejore la
confiabilidad de los servicios críticos, mejorando al mismo tiempo la calidad del
servicio a través de la red.
5. Esta solución tiene como requerimiento para su buen desempeño y fiabilidad
tener el inventario de red actualizado constantemente, esto es si existe alguna tipo
de provisionamiento en los equipos de red, se tendría que tener procesos
automatizados que actualizan los cambios en la red a nivel de topología de la red
y elementos de red.
1.
2.
3.
4.
5.
6.
7.
v.
9.
10.
BIBLIOGRAFÍA
Netcool / Omnibus 3.6, Administration Guide.
Netcool / Webtop 1.3, Administration Gude.
Netcool / Internet Service Monitors, Administration Guide.
Netcool / Internet Service Monitors, Administration Guide.
Alcatel 5523 AWS TL 1 Gateway, lnstallation Guide.
Alcatel 5523 AWS TL 1 Gateway, User Guide.
lnstallation Guide HP OpenView, Edition 1.
Using Ner.vork Node Manager HP OpenView, Edition 1.
iManager N2000(EMF) V200R003SNMP The Third-Party NMS.
Enhanced Te!ecom Operations Map (eTOM), The Business Process Framework, addendum F (GB 921 F), www.tmforum.org, 2004.