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.