ESCUELA POLITÉCNICA NACIONAL

FACULTAD DE INGENIERÍA ELÉCTRICA Y

ELECTRÓNICA

DESARROLLO DE UN SISTEMA DE GESTIÓN DE MONITOREO

PARA LA RED BACKBONE DE ECUANET ORIENTADO A LA
IMPLANTACIÓN DE LA HERRAMIENTA “HP OPEN VIEW
NETWORK NODE MANAGER”

PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN

ELECTRÓNICA Y TELECOMUNICACIONESL

PÉREZ RENGEL MAYRA ROSARIO

[email protected]

PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN

ELECTRÓNICA Y TELECOMUNICACIONES

SEMANATE CAJAS PAOLA ALEXANDRA

[email protected]

DIRECTOR: PhD. LUIS CORRALES

[email protected]

Quito, Octubre 2009

 DECLARACIÓN

Nosotros, Mayra Rosario Pérez Rengel y Paola Alexandra Semanate Cajas,

declaramos que el trabajo aquí descrito es de nuestra autoría; que no ha sido
previamente presentada para ningún grado o calificación profesional; y, que
hemos consultado las referencias bibliográficas que se incluyen en este
documento.

La Escuela Politécnica Nacional, puede hacer uso de los derechos

correspondientes a este trabajo, según lo establecido por la Ley de Propiedad
Intelectual, por su Reglamento y por la normatividad institucional vigente.

_____________________________ ____________________________
Mayra Rosario Pérez Rengel Paola Alexandra Semanate Cajas
 CERTIFICACIÓN

Certifico que el presente trabajo fue desarrollado por Mayra Rosario Pérez
Rengel y Paola Alexandra Semanate Cajas, bajo mi supervisión.

________________________
PhD. Luis Corrales
DIRECTOR DEL PROYECTO
 i

CONTENIDO
CONTENIDO …………………………………………………… I
RESUMEN …………………………………………………… IX
PRESENTACIÓN …………………………………………………… XI

ANÁLISIS DE LOS MODELOS (TMN) Y (TOM) PARA EL

DESARROLLO DE UN SISTEMA DE GESTIÓN DE MONITOREO
(SGM).............................................................................................. 1

1.1 GESTIÓN DE TELECOMUNICACIONES ............................................ 2

1.2 GESTIÓN DE RED ............................................................................... 2
1.3 ELEMENTOS DE LA GESTIÓN DE REDES ........................................ 2

1.3.1 ESTACIÓN DE GESTIÓN O GESTOR (NMS)........................................... 2

1.3.2 AGENTE.................................................................................................... 3

1.3.3 PROTOCOLO DE GESTIÓN DE REDES .................................................. 3

1.3.3.1 Mensajes SNMP ............................................................................................. 5

1.3.3.1.1 Get Request............................................................................................................ 5

1.3.3.1.2 Get Next Request ................................................................................................... 6
1.3.3.1.3 SetRequest ............................................................................................................. 6
1.3.3.1.4 GetResponse .......................................................................................................... 6
1.3.3.1.5 Trap ........................................................................................................................ 6
1.3.3.1.6 GetBulkRequest...................................................................................................... 6
1.3.3.1.7 InformRequest ........................................................................................................ 7
1.3.3.1.8 Modelo de seguridad basado en usuario (USM - User-Based Security Model) ...... 8
1.3.3.1.9 El modelo de control de acceso basado en vistas VCAM ...................................... 8
1.3.3.2 Formato de las Tramas SNMP ....................................................................... 9

1.3.3.2.1 GetRequest, GetNextRequest o SetRequest........................................................ 10

1.3.3.2.2 GetResponse ........................................................................................................ 10
1.3.3.2.3 Trap ...................................................................................................................... 11

1.3.4 BASE DE INFORMACIÓN DE GESTIÓN (MIB) ...................................... 12

1.3.4.1 Ejemplo de codificación de objetos según SMI ............................................ 13

1.3.4.2 MIB-2 ............................................................................................................. 13

1.3.4.2.1 System .................................................................................................................. 14

1.3.4.2.2 Interfaces .............................................................................................................. 14
1.3.4.2.3 AT (Address Translation o traducción de direcciones).......................................... 15
1.3.4.2.4 IP .......................................................................................................................... 15
1.3.4.2.5 ICMP ..................................................................................................................... 16
 ii

1.3.4.2.6 TCP....................................................................................................................... 16
1.3.4.2.7 UDP ...................................................................................................................... 17
1.3.4.2.8 EGP ...................................................................................................................... 17
1.3.4.2.9 Transmission ........................................................................................................ 18
1.3.4.2.10 SNMP ................................................................................................................... 18

1.4 EVOLUCIÓN DE LOS SISTEMAS DE GESTIÓN DE RED ................. 18

1.4.1 MODELO DE GESTIÓN OSI .................................................................. 19

1.4.2 EL MODELO DE GESTIÓN INTERNET. ................................................. 19

1.4.3 MODELO DE GESTIÓN TMN ................................................................ 20

1.4.3.1 Arquitectura física de TMN ........................................................................... 21

1.4.3.1.1 Componentes ....................................................................................................... 21

1.4.3.1.2 Interfaces .............................................................................................................. 23
1.4.3.2 Modelo Organizativo de TMN ....................................................................... 24

1.4.3.2.1 Gestión de Fallos .................................................................................................. 27

1.4.3.2.2 Gestión de Configuración ..................................................................................... 27
1.4.3.2.3 Gestión de Contabilidad........................................................................................ 28
1.4.3.2.4 Gestión de Rendimiento ....................................................................................... 29
1.4.3.2.5 Gestión de Seguridad ........................................................................................... 30
1.4.3.3 Modelo Funcional de TMN ............................................................................ 30

1.4.3.3.1 Bloque Funcional de Sistema de Operación (Operation System Function, OSF) . 31

1.4.3.3.2 Bloque Funcional de Elementos de Red (Network Element Function, NEF) ........ 32
1.4.3.3.3 Bloque Funcional de Estación de Trabajo (Workstation Function, WSF).............. 32
1.4.3.3.4 Bloque Funcional de Adaptador (Q Adaptor Function, QAF) ................................ 33
1.4.3.3.5 Bloque Funcional de Mediación (Mediation Function, MF) ................................... 34
1.4.3.4 Modelo de información de TMN .................................................................... 35

1.5 NGOSS (NEW GENERATION OPERATIONS SYSTEMS AND SOFTWARE -

SISTEMAS Y SOFTWARE DE OPERACIONES DE ÚLTIMA GENERACIÓN) ..................... 38

1.5.1 TOM vs. eTOM ........................................................................................ 40

1.5.1.1 Estrategia, Infraestructura y Producto .......................................................... 41

1.5.1.2 Operaciones .................................................................................................. 42

1.5.1.3 Gestión Empresarial ..................................................................................... 42

1.5.1.4 Áreas funcionales ......................................................................................... 43

1.5.2 MAPA DE OPERACIONES DE TELECOMUNICACIONES (TOM) .......... 44

1.5.2.1 Agrupamiento vertical de TOM ..................................................................... 44

1.5.2.1.1 Aprovisionamiento ................................................................................................ 45

1.5.2.1.2 Aseguramiento ...................................................................................................... 46
1.5.2.1.3 Facturación ........................................................................................................... 48
1.5.2.2 Agrupamiento horizontal de TOM ................................................................. 49
 iii

1.5.2.2.1 Gestión de las Relaciones con el Cliente (CRM) .................................................. 50

1.5.2.2.2 Gestión y Operaciones de Servicios ..................................................................... 50
1.5.2.2.3 Gestión y Operaciones de Recursos .................................................................... 51
1.5.2.2.4 Gestión de las Relaciones con el Proveedor/Aliado: ............................................ 51

1.6 DESARROLLO DE UN SISTEMA DE GESTIÓN DE MONITOREO EN BASE A TMN

Y TOM PARA LA EMPRESA ECUANET S.A. ......................................................... 52

1.6.1 MONTORIZACIÓN .................................................................................. 53

1.6.2 CONTROL ............................................................................................... 53

1.6.3 SISTEMA DE GESTION DE MONITOREO ............................................. 54

1.6.3.1 OBJETIVO .................................................................................................... 54

1.6.3.2 ANTECEDENTES ......................................................................................... 54

1.6.3.3 IMPLEMENTACION DEL SGM .................................................................... 55

1.6.3.3.1 Service Level Management (SLM) ........................................................................ 55

1.6.3.3.2 Service Level Agreement (SLA)............................................................................ 55
1.6.3.3.3 Modelos de Gestión: TMN y TOM ........................................................................ 57
1.6.3.3.4 Recursos humanos: Infraestructura, Instalaciones, NOC. .................................... 57
1.6.3.3.5 Herramientas de apoyo: HP OV NNM AE v7.53 ................................................... 59

CONFIGURACIÓN DE LA HERRAMIENTA NETWORK NODE

MANAGER .................................................................................... 61

2.1 PLATAFORMAS DE GESTIÓN DE MONITOREO ........................................... 62

2.1.1 ZENOSS.................................................................................................. 63

2.1.2 SunNet Manager (SUN)........................................................................... 63

2.1.3 Spectrum ................................................................................................. 63

2.1.4 OPManager ............................................................................................. 64

2.1.5 Integrated System Management (ISM) .................................................... 64

2.1.6 WhatsUp Gold V12 .................................................................................. 65

2.1.7 Real-Time NetFlow Analyzer ................................................................... 66

2.1.8 Multi Router Traffic Grapher (MRTG)....................................................... 66

2.1.9 Net-SNMP ............................................................................................... 66

2.1.10 Nagios ................................................................................................. 67

 iv

2.1.11 JFFNMS .............................................................................................. 67

2.1.12 Nino Is Not Openview (NINO) .............................................................. 68

2.1.13 CiscoView ............................................................................................ 68

2.1.14 HP OPENVIEW ................................................................................... 68

2.2 HP OPENVIEW NETWORK NODE MANAGER ............................................ 70

2.2.1 Productos base de Network Node Manager ............................................ 71

2.3 ANÁLISIS DE LA HERRAMIENTA HP OPENVIEW NETWORK NODE

MANAGER ADVANCE EDITION EN BASE A LOS REQUERIMIENTOS Y
NECESIDADES DE ECUANET S.A. ............................................................. 72

2.3.1 Reducir el TCO (Total Cost of Ownership)............................................... 77

2.3.2 Reducir el tiempo de reparación de problemas en la red ......................... 77

2.4 PLAN DE TRABAJO REFERENTE AL SGM ................................................. 78

2.4.1 actualización de Diagramas de red .......................................................... 78

2.4.2 Levantamiento de información de los nodos principales de la Red

Backbone de Ecuanet a nivel nacional. ............................................................... 78

2.4.3 Archivos MIB de los equipos Cisco, Lucent, Alvarium.............................. 79

2.4.4 Configuracion de la comunidad snmp y habilitación de Traps SNMP en los

elementos de la RBE .......................................................................................... 80

2.4.5 Políticas de Interfaces libres .................................................................... 82

2.4.6 Habilitación de Puertos ............................................................................ 83

2.5 ARQUITECTURA DEL SERVIDOR DE GESTIÓN ........................................... 83

2.6 INSTALACIÓN DE LA HERRAMIENTA NETWORK NODE MANAGER ADVANCE
EDITION V7.53 ................................................................................................ 86

2.6.1 PRERREQUISITOS PARA LA INSTALACIÓN ........................................ 86

2.6.1.1 Servicio TCP/IP ............................................................................................. 86

2.6.1.2 Agente SNMP ............................................................................................... 87

2.6.1.3 Internet Information Service (Web Server) ................................................... 89

2.6.1.4 Microsoft Terminal Services.......................................................................... 90

 v

2.6.1.5 Instalación de un Web Browser .................................................................... 90

2.6.2 Instalación DE HP OpenView Network Node Manager for Windows v7.53

90

2.6.3 Instalación de Patches............................................................................. 98

2.7 CONFIGURACIÓN DE LA HERRAMIENTA NETWORK NODE MANAGER ADVANCE

EDITION V7.53................................................................................................ 98

2.7.1 iniciar los servcios de NNM (Background processes) .............................. 98

2.7.2 Abriendo NNM (Foreground Processes) .................................................. 99

2.7.2.1 Vista Clásica o de Contenedores.................................................................. 99

2.7.2.1.1 Submapa de Internet: ......................................................................................... 101

2.7.2.1.2 Submapa de Red: ............................................................................................... 101
2.7.2.1.3 Submapa de Segmento: ..................................................................................... 101
2.7.2.1.4 Submapa de Nodos: ........................................................................................... 101
2.7.2.2 Vistas Dinámicas ........................................................................................ 101

2.7.3 Autodescubrimiento de la red ................................................................ 102

2.7.3.1 Configuración de la Topología Extendida ................................................... 103

2.7.4 Carga de Archivos MIB .......................................................................... 103

2.7.5 Configuración de las comunidades snmp .............................................. 105

2.7.5.1 Global Default ............................................................................................. 106

2.7.5.2 IP Wildcards ................................................................................................ 106

2.7.5.3 Specific Nodes ............................................................................................ 107

2.7.6 Polling ................................................................................................... 107

2.7.7 indicadores de gestión ........................................................................... 108

2.7.7.1 Métricas ....................................................................................................... 108

2.7.7.2 Eventos ....................................................................................................... 110

2.7.7.3 Notificaciones .............................................................................................. 113

2.7.8 Mapas de red ........................................................................................ 115

2.7.9 Seguridad .............................................................................................. 119

2.7.9.1 Consola Remota ......................................................................................... 119

2.7.9.2 Perfiles y Usuarios ...................................................................................... 119

 vi

2.7.9.3 Acceso vía Web (Vistas dinámicas Home Base)........................................ 120

2.7.9.4 Acceso vía Web (HP OpenView Launcher) ................................................ 121

2.7.10 REPORTES ....................................................................................... 123

2.7.10.1 Report Configuration ................................................................................... 123

2.7.10.2 Report Presenter ......................................................................................... 123

2.8 DATAWAREHOUSE ........................................................................ 124

2.8.1 Base De Datos Embebida ..................................................................... 124

2.8.2 Tipo de bases de datos propietarias de NNM ........................................ 125

2.8.2.1 Base de datos objeto OVW ......................................................................... 125

2.8.2.2 Base de datos de Mapa .............................................................................. 125

2.8.2.3 Base de datos de Topología ....................................................................... 126

2.8.2.4 Base de datos SNMP-Colección o Tendencias .......................................... 126

2.8.2.5 Base de datos de eventos .......................................................................... 126

2.8.3 Open Database Connectivity (Odbc) ..................................................... 127

2.8.4 SQL (Structured Query Language) ........................................................ 127

2.8.5 Capacidades de las base de datos ........................................................ 128

2.8.6 Administración de base de datos ........................................................... 128

2.8.7 Características Datawarehouse ............................................................. 129

2.8.8 Configuración de la base de datos para el funcionamiento del

DaTawarehouse ................................................................................................ 130

2.8.9 Proceso De Creación De Información En El Datawarehouse................. 132

PRUEBAS Y ANÁLISIS DE RESULTADOS ............................... 136

3.1 ALARMAS FALSAS ............................................................................... 136

3.1.1 Incorrecta aplicación de políticas de interfaces libres ............................ 136

3.1.2 Alarmas de equipos Access Server y CPE ............................................ 139

3.1.2.1 Network Access Server ............................................................................... 139

3.1.2.2 Customer Premises Equipment .................................................................. 140

 vii

3.2 PRUEBAS DE RESPUESTA .................................................................... 142

3.3 GRÁFICAS DE CONSUMO ...................................................................... 148
3.4 VISTA DINAMICA A TRAVÉS DEL WEB BROWSER ....................... 149
3.5 NOTIFICACIÓN DE EVENTOS .................................................................. 151

3.6 MAPAS ............................................................................................ 152

3.7 PRUEBAS Y RESULTADOS REALIZADOS CON LA VISUALIZACIÓN
DE ALARMAS. ............................................................................................ 154

3.7.1 Estados administrativos ......................................................................... 154

3.7.1.1 Unmanaged:................................................................................................ 154

3.7.1.2 Testing: ....................................................................................................... 154

3.7.1.3 Restricted: ................................................................................................... 154

3.7.1.4 Disabled: ..................................................................................................... 155

3.7.2 Estados Operacionales.......................................................................... 155

3.7.2.1 Unknown: .................................................................................................... 155

3.7.2.2 Normal:........................................................................................................ 155

3.7.2.3 Warning: ...................................................................................................... 155

3.7.2.4 Minor/Marginal: ........................................................................................... 155

3.7.2.5 Major: .......................................................................................................... 156

3.7.2.6 Critical: ........................................................................................................ 156

3.8 COMPOSICION DEL ESTADO DE ALARMAS ................................ 156

3.9 VERIFICACIÓN DE LAS CAMBIO DE ESTADO O ALARMAS ......... 160
3.10 PRUEBA DEL SGM.......................................................................... 161

ANÁLISIS DE COSTOS .............................................................. 165

4.1 DINAMICA DEL SECTOR DE LAS TELECOMUNICACIONES ........ 165

4.1.1 COMPETENCIA .................................................................................... 166

4.1.2 CLIENTES ............................................................................................. 166

4.1.3 NUEVA ECONÓMICA ........................................................................... 166

4.1.4 TECNOLOGIA Y SERVICIOS ............................................................... 166

 viii

4.2 VIABILIDAD ..................................................................................... 167

4.3 COSTOS DE IMPLEMENTACIÓN ................................................... 169
4.4 FINANCIAMIENTO DEL PROYECTO .............................................. 170
4.5 JUSTIFICACION DE LA INVERSIÓN............................................... 172

CONCLUSIONES Y RECOMENDACIONES .............................. 173

5.1 CONCLUSIONES ............................................................................ 173

5.2 RECOMENDACIONES .................................................................... 176

SIGLAS ....................................................................................... 178

REFERENCIAS BIBLIOGRÁFICAS ........................................... 181

ANEXOS
 ix

RESUMEN

El mercado actual de las telecomunicaciones exige un cumplimiento de altos

niveles de disponibilidad en los servicios ofertados a los clientes, por tanto es
necesario la utilización de Sistemas de Gestión y herramientas que permitan
entregar un servicio de acceso de calidad de acuerdo a los contratos
establecidos con el cliente y las normas de nivel de servicio generadas por el
ente regulador de las telecomunicaciones en el país (SENATEL) así como la
defensoría del consumidor. Por lo indicado se hace imperiosa la necesidad de
tener un Sistema de Gestión de Monitoreo apoyado en una herramienta
integral que permita mantener y asegurar los servicios ofertados, así como el
aprovisionar posibles crecimientos y mejoras en la red.

Ecuanet, al tener opciones limitadas de monitoreo y de obtención de

información, debido al aumento del número de clientes, exigencia de
proactividad y altos niveles de disponibilidad de sus circuitos ha visto la
necesidad de adquirir un Sistema de Gestión de Monitoreo que cumpla con las
demandas actuales de todos los clientes y así poder lograr una ventaja frente a
sus competidores inmediatos. La implementación de este Sistema de Gestion
es el propósito de este trabajo.

Con tal objetivo en el presente proyecto se analizó los modelos de gestión

Telecommunication Management Network (TMN) y Telecommunication
Operation Map (TOM) para determinar las características que debería poseer
un Sistema de Gestión de Monitoreo (SGM). Este se desarrolló orientado a la
implantación de la herramienta HP OV NNM AE v7.53, basado en la situación
actual de la empresa.

El SGM desarrollado posee un Plan de Trabajo para la configuración de NNM,

Instructivos de Monitoreo, Manual de Usuario para el personal que diariamente
operara la herramienta y posibilita determinar el origen de fallos y resolver
proactivamente las incidencias encontradas, detectando comportamientos
anómalos en la Red Backbone.
 x

Sobre la base del SGM desarrollado se configuró la herramienta HP OV NNM

AE v7.53, con el que se da soporte y permite el cumplimiento de los elementos
de gestión de calidad fijados en el modelo de SGM.

Después de realizar las pruebas sobre el funcionamiento de NNM se verificó

que la herramienta está operando correctamente, además que la utilización y
manejo de la información proporcionada por NNM representa un factor
importante para la solución de incidencias, comprobar el comportamiento de la
RBE en tiempo real, lo cual ha permitido mejorar los índices de calidad,
competitividad, obtener rentabilidad.
 xi

PRESENTACIÓN

En el sector de las telecomunicaciones se presenta un desafío importante en

el desarrollo de estrategias de gestión de telecomunicaciones, como resultado
se produce que los operadores deban generar cambios radicales para enfrentar
a la competencia que les deje diferenciarse en el mercado, para lo cual
Ecuanet adoptará un sistema que le permitirá tener una correcta operación e
identificación de problemas en su red.

Con este objetivo, en el presente proyecto se encontrara un análisis para el

desarrollo de un Sistema de Gestión de Monitoreo y la posterior
implementación del mismo utilizando la herramienta HP OpeView Network
Node Manager Advance Edition for Windows v7.53, el cual permitirá mantener
un óptimo rendimiento de la red, con la detección oportuna de las fallas,
dando seguimiento a todos los eventos ocurridos en los dispositivos de la Red
Backbone de Ecuanet (RBE).

Para cumplir con dicho objetivo en el Capítulo 1 se hace un análisis de los

sistemas de gestión de telecomunicaciones orientados al monitoreo de red y a
las necesidades de Ecuanet.

En el segundo capítulo se compararán las plataformas de Gestión de Monitoreo

disponibles en el mercado y se desarrollara un plan de trabajo en el SGM y la
descripción del proceso de instalación y personalización de HP OpeView
Network Node Manager Advance Edition for Windows v7.53.

En el tercer capítulo se describirán las pruebas del sistema implementado y se

analizarán los resultados obtenidos para determinar el correcto funcionamiento
de la herramienta.

En el cuarto capítulo se realizará un análisis de la viabilidad y el financiamiento

del proyecto así como se buscará justificar la inversión para Ecuanet.
 CAPÍTULO 1

ANÁLISIS DE LOS MODELOS (TMN) Y (TOM) PARA EL

DESARROLLO DE UN SISTEMA DE GESTIÓN DE
MONITOREO (SGM)

En el sector de las telecomunicaciones, para las empresas que soportan redes

telemáticas, es muy importante el desarrollo de estrategias de gestión de
telecomunicaciones que ayudaran a enfrentar los desafíos tecnológicos,
controlar una correcta operación en sus redes de telecomunicaciones,
identificar la razón de algún problema que se pueda presentar, con el propósito
de mejorar el grado de satisfacción de los clientes y mantener la rentabilidad
del negocio.

Actualmente en la industria de las telecomunicaciones existen estándares que

pueden aportar soluciones como el modelo de gestión definido por la UIT-T
(International Telecommunications Union–Telecommunications)en la
Recomendación M.3000 que es TMN (Telecommunication Management
Network), por otra parte el TMF (Telecommnication Management Forum) ha
propuesto el modelo NGOSS (New Generation Operations Software and
Systems) que utiliza y eTOM (enhanced Telecommunication Operation Map),
reconocido ya por UIT-T en la M.3050, para organizar la gestión de redes
desde una perspectiva de negocio.

A partir del análisis de las características de los modelos TMN y TOM

precedentes para la gestión de redes en este capítulo se desarrollará un
Sistema de Gestión de Monitoreo de particular importancia para la empresa
Ecuanet S.A.
1.1 GESTIÓN DE TELECOMUNICACIONES

Se puede definir como un conjunto de estrategias, procesos, funciones y

herramientas para facilitar y optimizar la planeación, el aprovisionamiento, la
operación, el mantenimiento y la administración de los servicios y redes de
telecomunicaciones.

1.2 GESTIÓN DE RED

Hace referencia a un conjunto de actividades dedicadas al control y vigilancia

de la red para maximizar la eficiencia, la productividad y la calidad de los
servicios soportados por dicha red.

1.3 ELEMENTOS DE LA GESTIÓN DE REDES

Es muy importante conocer y entender a los elementos de la Gestión de

Redes, debido a que son claves para el desarrollo del SGM, y son los
siguientes:
• Estación de Gestión o Gestor
• Agentes
• Protocolo de Gestión de Redes
• Base de Información de Gestión (MIB)

1.3.1 ESTACIÓN DE GESTIÓN O GESTOR (NMS)

La Estación de Gestión, también conocida como NMS (Network Monitoring

System - Sistema de Monitoreo de Red), sirve como interfaz entre el
Administrador de red y el sistema de gestión de red, y tiene una base de datos
de información de gestión de red extraída de las bases de datos de todas las
entidades gestionadas en la red.
1.3.2 AGENTE

El Agente es el que responde a las solicitudes que son invocadas desde la

estación de gestión y puede de una forma asíncrona, proporcionar a la estación
de gestión información importante.

1.3.3 PROTOCOLO DE GESTIÓN DE REDES

La Estación de Gestión y el Agente están enlazados por el protocolo SNMP

(Simple Network Management Protocol - Protocolo de Gestión de Red Simple)
que se lo va a mencionar brevemente.

El Protocolo Simple de Administración de Red o SNMP es un protocolo de la

capa de aplicación que facilita el intercambio de información de administración
entre dispositivos de red. Es parte de la familia de protocolos TCP/IP. SNMP
permite a los administradores supervisar el desempeño de la red, buscar y
resolver sus problemas, y planear su crecimiento.

Existen tres versiones del protocolo y se denominan SNMPv1, SNMPv2 y

SNMPv3. La mayoría de los componentes de red tienen agentes SNMP
internos, que permiten ser integrados a un sistema de administración.

Las versiones de SNMP más utilizadas son dos: SNMP versión 1 (SNMPv1) y
SNMP versión 2 (SNMPv2). Ambas versiones tienen un número de
características en común, pero SNMPv2 ofrece mejoras, como por ejemplo,
operaciones adicionales.

SNMP en su última versión (SNMPv3) posee cambios significativos con

relación a sus predecesores, sobre todo en aspectos de seguridad; sin
embargo, no ha sido mayoritariamente aceptado en la industria.
SNMPv1 utiliza como único mecanismo de autenticación la “Comunidad” que
puede ser “Read” o “Set”, de forma que si agente y estación administradora lo
conocen, pueden interactuar. Pero esta protección es muy débil ya que el
nombre de la comunidad no está cifrado. Si no se dispone de seguridad
suficiente, con carácter general es aconsejable que la comunidad Read y Set
sean diferentes.

Cabe destacar que SNMPv3 no se trata de un estándar que reemplaza a

SNMPv1 y/o SNMPv2, sino que define una serie de capacidades adicionales
de seguridad y administración a ser utilizadas en conjunto con SNMPv2 o
SNMPv1. Estas mejoras harán que SNMP se constituya en un protocolo de
gestión susceptible de ser utilizado con altas prestaciones en todo tipo de
redes, desplazando a medio plazo a ICMP como estándar de gestión de las
grandes redes de las operadoras de telecomunicación.

El SNMP describe la información exacta de cada tipo de agente que tiene que
administrar la estación administradora y el formato con el que el agente tiene
que proporcionarle los datos. Cada dispositivo mantiene una o más variables
que describen su estado, estas variables se llaman objetos. El conjunto de
todos los objetos posibles de una red se da en la estructura de datos llamada
MIB (Management Information Base, Base de Información de Administración).

La estación administradora interactúa con los agentes usando el protocolo

SNMP. Este protocolo permite a la estación administradora consultar, y
modificar el estado de los objetos locales de un agente.

A veces pueden ocurrir sucesos no planeados, como un congestionamiento o

la caída de una línea. Cada suceso significativo se define en un módulo MIB.
Cuando un agente nota que ha ocurrido un suceso significativo, de inmediato lo
informa a todas las estaciones administradoras de su lista de configuración.
Este informe se llama Trap SNMP. Como la comunicación entre los nodos
administrados y la estación administradora no es confiable, la estación
administradora debe sondear ocasionalmente cada nodo llamado Polling.

1.3.3.1 Mensajes SNMP

Para realizar las operaciones básicas de administración anteriormente

nombradas, el protocolo SNMP utiliza un servicio no orientado a la conexión
(UDP) para enviar un pequeño grupo de mensajes (PDUs) entre los
administradores y agentes.

La utilización de un mecanismo de este tipo asegura que las tareas de

administración de red no afectarán al rendimiento global de la misma, ya que
se evita la utilización de mecanismos de control y recuperación como los de un
servicio orientado a la conexión, por ejemplo TCP.

Los puertos comúnmente utilizados para el envío y recepción de los mensajes

SNMP son los siguientes:

• puerto 161 se utiliza para las transmisiones normales de comando

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

1.3.3.1.1 Get Request

GetRequest es generado por el NMS cuando solicita el valor de un objeto. En

respuesta el agente envía una respuesta indicando el éxito o fracaso de la
petición. Si la petición fue correcta, el mensaje resultante también contendrá el
valor del objeto solicitado.

Este mensaje puede ser usado para recoger un valor de un objeto, o varios
valores de varios objetos, a través del uso de listas.
1.3.3.1.2 Get Next Request

GetNextRequest se utiliza cuando un objeto contiene una lista de valores. Por

ejemplo, una tabla de rutas.
Una vez que se ha usado un mensaje GetRequest para recoger el valor de un
objeto, puede ser utilizado el mensaje GetNextRequest para repetir la
operación con el siguiente objeto de la tabla.

Siempre el resultado de la operación anterior será utilizado para la nueva

consulta. De esta forma un NMS puede recorrer una tabla de longitud variable
hasta que haya extraído toda la información para cada fila existente.

1.3.3.1.3 SetRequest
SetRequest es generado por el NMS para solicitar a un agente modificar
valores de objetos. Para realizar esta operación el NMS envía al agente una
lista de nombres de objetos con sus correspondientes valores.

1.3.3.1.4 GetResponse

GetResponse es generado por el agente para responder un mensaje

GetRequest, GetNextRequest, o SetRequest.

1.3.3.1.5 Trap
Trap es un mensaje no solicitado generado por el agente, sin intervención del
administrador, al detectar una condición predeterminada, como es la
conexión/desconexión de una estación o una alarma.

1.3.3.1.6 GetBulkRequest

GetBulkRequest es usado por un NMS que utiliza la versión 2 del protocolo

SNMP típicamente cuando se requiere una larga transmisión de datos, tal
como la recuperación de largas tablas.
En este sentido es similar al mensaje GetNextRequest usado en la versión 1
del protocolo, sin embargo, GetBulkRequest es un mensaje que implica un
método mucho más rápido y eficiente, ya que a través de un solo mensaje es
posible solicitar la totalidad de la tabla.

1.3.3.1.7 InformRequest
InformRequest es usado por un NMS que utiliza la versión 2 del protocolo
SNMP.

Transmite un mensaje a otro NMS con las mismas características, para

notificar información sobre objetos administrados.

La Figura 1.1 muestra el detalle de los mensajes SNMP

FIGURA 1.1. MENSAJES SNMP

1.3.3.1.8 Modelo de seguridad basado en usuario (USM - User-Based Security Model)

Proporciona los servicios de autentificación y privacidad en SNMPv3. El

mecanismo de autentificación en USM asegura que un mensaje recibido fue
trasmitido por la entidad indicada, que el mensaje no fue alterado durante su
tránsito, que no fue retardado o repetido.

Para conseguir la autentificación, el gestor y el agente que desean

comunicarse deben compartir la misma clave de autentificación secreta
configurada previamente fuera de SNMPv3 (no es almacenada en la MIB y no
es accesible mediante SNMP). La clave secreta, algoritmo de encriptación
utilizado, es el CBC (Cipher Block Chaining) de DES (Data Encryption
Standard), conocido también por DES-56 y posibilita los agentes encriptar
mensajes para prevenir que sean analizados por intrusos.

1.3.3.1.9 El modelo de control de acceso basado en vistas VCAM (Views-Based Access

Control Model)
Proporciona diferentes niveles de acceso a las MIB de los agentes para los
distintos gestores en SNMPv3. Un agente puede, de este modo, restringir el
acceso de ciertos gestores a parte de su MIB o bien limitar las operaciones
susceptibles de realizar por ciertos gestores sobre una parte de su MIB.

La política de control de acceso debe estar configurada previamente;

consistiendo básicamente en una tabla que detalla los privilegios de acceso
para los distintos gestores autorizados.

En la Tabla 1.1 se muestra lo mensajes correspondientes a cada versión

SNMP.
 SNMP ver1 SNMP ver2 SNMP ver3
GET REQUEST √ √ √
GET NEXT REQUEST √ √ √
SET REQUEST √ √ √
SET NEXT REQUEST √ √ √
GET RESPONSE √ √ √
TRAP √ √ √
GET BULK REQUEST √ √
INFORM REQUEST √ √
USER-BASED SECURITY MODEL (USM) √
VIEWS-BASED ACCESS CONTROL √
MODEL (VCAM)

TABLA 1.1 MENSAJES SNMP

1.3.3.2 Formato de las Tramas SNMP

SNMP permite el intercambio de información a través de la red en forma de

mensajes SNMP que tienen el siguiente formato (Figura 1.2):

Versión Comunidad SNMP PDU

FIGURA 1.2. FORMATO DEL MENSAJE SNMP

Versión: Indica la versión del protocolo. (SNMPv1, SNMPv2, SNMPv3)

Comunidad: Nombre o palabra clave que se usa para la autenticación, que
puede ser de lectura (READ) y una comunidad de escritura (SET).
SNMP PDU: Contenido de la unidad de datos del protocolo, el que depende de
la operación que se ejecute, como se muestra a continuación (Figura 1.3,
Figura 1.4, Figura 1.5):
1.3.3.2.1 GetRequest, GetNextRequest o SetRequest

PDU Type Request ID 0 0 Variable Bindings

FIGURA 1.3 SNMP PDU DE GETREQUEST, GETNEXTREQUEST O SETREQUEST

• PDU type: Indica el tipo de PDU.

• Request ID: Se utiliza para diferenciar las distintas peticiones,
agregando un único identificador.
• Variable Bindings: Es una lista de nombres de variables y sus
correspondientes valores. En algunos casos (GetRequest), el valor de
las mismas es NULL. En el caso de los Traps, proporcionan información
adicional relativa a la Trap, dependiendo el significado de este campo de
cada implementación en particular.

1.3.3.2.2 GetResponse

PDU Type Request ID Error-status Error-index Variable Bindings

FIGURA 1.4 SNMP PDU DE GETRESPONSE

• Error-status: Se utiliza para indicar que ha ocurrido una excepción

durante el procesamiento de una petición. Sus valores posibles son:

o 0: No hay error;
o 1: Demasiado grande;
o 2: No existe esa variable;
o 3: Valor incorrecto;
o 4: El valor es de solo lectura;
o 5: Error genérico.
1.3.3.2.3 Trap

PDU Type Enterprise Agent-Addr Generic-Trap Specific-Trap Timestamp Variable

Bindings

FIGURA 1.5 SNMP PDU DE TRAP

• Enterprise: Identifica el subsistema de gestión de red que ha emitido

el Trap.
• Agent-addr. : Dirección IP del agente que generó el Trap.
• Generic-trap: Tipo de Trap genérico predefinido. Puede ser:

o coldStart (0): Típicamente reinicio por caída del sistema.

o warmStart (1): Usualmente es una rutina de tipo restart.
o linkDown (2): Indica el fallo de alguno de los enlaces de
comunicación del Agente. El primer elemento en el campo
Variable-Bindings indicará el interfaz en cuestión.
o linkUp (3): Indica el restablecimiento de uno de los enlaces de
comunicación del Agente. El primer elemento en el campo
Variable-Bindings indicará el interfaz en cuestión.
o authentificationFailure (4): Indica que la entidad emisora del
Trap ha recibido un mensaje en el que ha fallado la
autentificación.
o egpNeighborLoss (5): Indica que un EGP (External Gateway
Protocol) vecino, para el cual la entidad emisora tenía
asociado otro EGP, ha sido desmarcado y la relación entre
ambos EGPs ha finalizado.
o enterpriseSpecific (6): Indica que algún evento específico del
fabricante ha ocurrido. El campo specific-trap indica el tipo de
Trap.
 • Specific-trap: Indica de una forma más específica la naturaleza del
Trap.
• Timestamp: Tiempo transcurrido entre la última reinicialización de la
entidad de red y la generación del trap.

1.3.4 BASE DE INFORMACIÓN DE GESTIÓN (MIB)

Una MIB (Management Information Base- Base de Información de

Administración) es una colección de información que está organizada
jerárquicamente. Las MIBs son accedidas usando un protocolo de
administración de red, como por ejemplo, SNMP.

Los objetos administrados están compuestos por variables que residen en el

nodo administrado. Cada objeto administrado es descrito usando un
identificador de objeto (OID) definido en el SMI.

La jerarquía MIB puede ser representada por la Estructura de Gestión de

Información (SMI) que presenta una estructura en forma de árbol global para la
información de administración, convenciones, sintaxis y las reglas para la
construcción de MIBs.

La estructura ha sido definida por la OSI, donde la raíz no tiene un nombre

específico, pero ilustra las variadas jerarquías asignadas por las diferentes
organizaciones, como se describe a continuación (Figura 1.6):

• iso, de la Internacional Standards Organization,

• itu, de la Internacional Telecommunications Union ,
• iso-itu para los objetos acordados en conjunto,
• dod se refiere al “Department of Defense”.
 FIGURA 1.6 ORGANIZACIÓN JERÁRQUICA DE UNA MIB

1.3.4.1 Ejemplo de codificación de objetos según SMI

Se tiene el siguiente OID 1.3.6.1.4.1.9.3.3.1, ¿Cuál es su equivalente?

De acuerdo a la Figura 1.6 se tiene que el equivalente para el OID especificado
es el siguiente:
iso.identified-organization.dod.internet.private.enterprise.cisco.temporary.AppleTalk.atInput

1.3.4.2 MIB-2

El corazón del árbol MIB se encuentra compuesto de varios grupos de objetos,

los cuales en su conjunto son llamados MIB-2. Los grupos son los siguientes:
• System
• Interfaces
• AT
 • IP
• ICMP
• TCP
• UDP
• EGP
• Transmission
• SNMP

1.3.4.2.1 System

Proporcionan información genérica del sistema gestionado. Por ejemplo, dónde

se encuentra el sistema, quién lo administra.

• sysDescr: Descripción completa del sistema (versión, HW, OS).

• sysObjectID: Identificación que da el distribuidor al objeto.
• sysUpTime: Tiempo desde la última reinicialización.
• sysContact: Nombre de la persona que hace de contacto.
• sysServices: Servicios que ofrece el dispositivo.

1.3.4.2.2 Interfaces

En este grupo está la información de las interfaces de red presentes en el

sistema.
• ifIndex: Número de interfaz.
• ifDescr: Descripción de la interfaz.
• ifType: Tipo de la interfaz.
• ifMtu: Tamaño máximo del datagrama IP.
• ifAdminisStatus : Status de la interfaz.
• ifLastChange: Tiempo que lleva la interfaz en el estado actual.
• ifINErrors: Número de paquetes recibidos que contenían errores.
• ifOutDiscards: Número de paquetes enviados y desechados.
1.3.4.2.3 AT (Address Translation o traducción de direcciones)

Este grupo es obsoleto, pero se mantiene para preservar la

compatibilidad con la MIB-I. En él se almacenan las direcciones de nivel
de enlace correspondientes a una dirección IP.

• atTable: Tabla de traducción de direcciones

• atEntry: Cada entrada que contiene una correspondencia de
dirección de red a dirección física
• atPhysAddress: La dirección física dependiente del medio
• atNetAddress: La dirección de red correspondiente a la dirección
física

1.3.4.2.4 IP

En este grupo se almacena la información relativa a la capa IP, tanto de

configuración como de estadísticas.

• ipForwarding: Indicación de si la entidad es una pasarela IP

• ipInHdrErrors: Número de datagramas de entrada desechados
debido a errores en sus cabeceras IP
• ipInAddrErrors: Número de datagramas de entrada desechados
debido a errores en sus direcciones IP
• ipInUnknownProtos: Número de datagramas de entrada
desechados debido a protocolos desconocidos o no soportados
• ipReasmOKs : Número de datagramas IP reensamblados con éxito
• ipRouteMask : Máscara de subred para el encaminamiento
1.3.4.2.5 ICMP

En este nodo se almacenan contadores de los paquetes ICMP entrantes

y salientes.

• icmpInMsgs: Número de mensajes ICMP recibidos.

• icmpInDestUnreachs: Número de mensajes ICMP "destino
inalcanzable" (destination unreachable) recibidos.
• icmpInTimeExcds: Número de mensajes ICMP "time exceeded"
(tiempo excedido) recibidos.
• icmpInSrcQuenchs: Número de mensajes ICMP "source quench”
(desbordamiento del emisor) recibidos.
• icmpOutErrors: Número de mensajes ICMP no enviados debido a
problemas en ICMP

1.3.4.2.6 TCP

En este grupo está la información relativa a la configuración, estadísticas

y estado actual del protocolo TCP.

• tcpRtoAlgorithm: Algoritmo que determina el timeout para retransmitir

octetos para los que no se ha recibido reconocimiento
• tcpMaxConn: Límite en el número de conexiones TCP que puede
soportar la entidad
• tcpActiveOpens: Número de veces que las conexiones TCP han
efectuado una transición directa del estado SYN-SENT al estado
CLOSED
• tcpInSegs: Número de segmentos recibidos, incluyendo aquellos con
error
• tcpConnRemAddress: La dirección IP remota para esta conexión
TCP
• tcpInErrs: Número de segmentos desechados debido a errores de
formato
• tcpOutRsts: Número de resets generados
1.3.4.2.7 UDP

En este nodo está la información relativa a la configuración, estadísticas del

protocolo UDP.

• udpInDatagrams: Número de datagramas UDP entregados a

usuarios UDP
• udpNoPorts: Número de datagramas UDP recibidos para los
que no existía aplicación en el puerto de destino
• udpInErrors: Número de datagramas UDP recibidos que no
se pudieron entregar por razones otras que la ausencia de la
aplicación en el puerto de destino
• udpOutDatagrams: Número de datagramas UDP enviados
por la entidad

1.3.4.2.8 EGP

Aquí está agrupada la información relativa a la configuración y operación del

protocolo EGP.

• egpInMsgs: Número de mensajes EGP recibidos sin error

• egpInErrors: Número de mensajes EGP con error
• egpOutMsgs: Número de mensajes EGP generados
localmente
• egpNeighAddr: La dirección IP del vecino de esta entrada
EGP
• egpNeighState: El estado EGP del sistema local con respecto
a la entrada EGP vecino
1.3.4.2.9 Transmission

Objetos que proporcionan información sobre el medio de transmisión para cada

interfaz del sistema.

1.3.4.2.10 SNMP

Contiene información relevante sobre la implementación y funcionamiento de

SNMP.

1.4 EVOLUCIÓN DE LOS SISTEMAS DE GESTIÓN DE RED

• Gestión Autónoma: En un inicio las redes de telecomunicaciones tenían

pocos nodos y cada uno tenía su propio administrador por lo que cuando
se presentaba algún problema éste debía solucionarlo.

• Gestión Homogénea: Debido al crecimiento del número de nodos la

Gestión Autónoma ya no es eficaz. Por ello, a principios de los ochenta,
aparecieron aplicaciones que posibilitaban la supervisión remota de los
nodos de las redes. Sin embargo, cada aplicación sólo servía para redes
que estuvieran compuestas por equipos de un mismo fabricante.

• Gestión Heterogénea: Este tipo de Gestión se desarrollo debido a que la

evolución de las redes y la heterogeneidad de los recursos se hizo
mayor.

• Gestión Integrada: Este tipo de Gestión permite la utilización de un único

Centro de Gestión válido para llevar el control de entornos
heterogéneos. Para llegar a estos sistemas era necesaria una
estandarización previa de la gestión de red.
En actualidad existen 4 modelos fundamentales de gestión integrada:

o Gestión de Red OSI

o Gestión Internet
o Modelo TMN
o Modelo NGOSS

1.4.1 MODELO DE GESTIÓN OSI (OPEN SYSTEMS INTERCONNECTION-

INTERCONEXIÓN DE SISTEMAS ABIERTOS)

La Gestión de Sistemas OSI se basa en el uso de protocolos del nivel de

aplicación (CMIP) para el intercambio de información de gestión entre Gestor y
Agente.

La Gestión de Sistemas OSI consta de cuatro modelos, que son:

• Modelo de Comunicación: Mantiene el intercambio de información de gestión

mediante el protocolo de nivel de aplicación CMIP (Common Management
Information Protocol).
• Modelo de Información: Define el conjunto de objetos que se van a gestionar.
Se utiliza la sintaxis GDMO (Guidelines for the Definition of Managed Objects).
• Modelo Funcional: En él se definen las funciones de gestión.
• Modelo de Organización. En él se exponen las posibles subdivisiones de la red
en dominios de gestión.

1.4.2 EL MODELO DE GESTIÓN INTERNET.

Este modelo fue definido por la Internet Society para gestionar el modelo de
referencia TCP/IP, que en su inicio utilizaba el protocolos ICMP, pero cuando
Internet avanzó en complejidad, multiplicando el número de nodos, se empezó
a trabajar con SNMP el cual se convirtió en el estándar de las redes TCP/IP y
de Internet.
1.4.3 MODELO DE GESTIÓN TMN (TELECOMMUNICATIONS
MANAGEMENT NETWORK - RED DE GESTIÓN DE LAS
TELECOMUNICACIONES)

La creciente heterogeneidad en la tecnología para la construcción de redes y

servicios de telecomunicaciones en un entorno de diversos fabricantes es una
de las múltiples razones por las que TMN fue introducida en 1985 por la UIT-T
en la recomendación M.3000 como un modelo de referencia que establece
comunicaciones entre los Sistemas de Operación y Soporte (OSS-Operation
Support System) y los Elementos de Red (NE-Network Elements) de los
proveedores de servicios de telecomunicaciones.

TMN es una estructura de red organizada que interconecta los bloques

funcionales a través de interfaces estándares y provee funciones de gestión
que abarcan OAM&P (Operations, Administration, Maintenance, and
Provisioning) la operación, administración, mantenimiento y aprovisionamiento
para redes y servicios de telecomunicaciones ya que TMN es flexible, fiable,
económico, fácil de mejorar. Permite apropiados niveles de escalabilidad,
optimo desempeño, eficiente comunicación.

El objetivo de TMN es proporcionar un marco de gestión integrada, eficaz y

oportuna de redes y servicios de telecomunicaciones ayudando en la toma de
decisiones en los diferentes niveles de la organización de las empresas de
telecomunicaciones.

El modelo de gestión TMN está orientado hacia la cooperación entre la gestión

de los sistemas individuales para conseguir un efecto coordinado sobre la red.
Para ello, la UIT-T, en las recomendaciones M.3010, define la siguiente
arquitectura y modelos:
 • Arquitectura física
• Modelo organizativo (Arquitectura de capas lógicas)
• Modelo funcional
• Modelo de información

1.4.3.1 Arquitectura física de TMN

La arquitectura física de TMN (Figura 1.7) describe la estructura y entidades de

la red como son los componentes e interfaces que se utiliza para transportar la
información.

1.4.3.1.1 Componentes

Los componentes son los siguientes y se describen en la Tabla 1.2.

• Sistemas de Operaciones (OS)
• Redes de Comunicaciones de Datos (DCN)
• Dispositivos Mediadores (MD)
• Estaciones de Trabajo (WS)
• Elementos de Red (NE)
• Adaptadores Q (QA)

Componentes Descripción

Desempeña funciones como monitoreo y control, también

ofrecen soporte al procesamiento de la información relacionada

OS con (OAM&P) Operaciones, Administración, Mantenimiento y

(Operations Systems aProvisionamiento de las redes de telecomunicaciones.

- Sistemas de
Operaciones) • Operaciones: actividades necesarias para ofrecer
servicios de telecomunicaciones a los usuarios finales o
abonados
 • Administración: funciones que conlleva la provisión de
servicios de manera eficiente a los clientes y
cumpliendo los requisitos de calidad de servicio.
• Mantenimiento: actividades que incluyen la detección,
localización y reparación de fallos (mantenimiento
correctivo y mantenimiento preventivo)
• Aprovisionamiento: actividad de gestión que pone
recursos a disposición de los servicios de
telecomunicación (provisión de servicios y provisión de
recursos)

DCN representa las capas 1 a 3 del modelo OSI, permite el

transporte de los datos entre OS y los NE. Las conexiones

DCN físicas se constituyen a partir de diferentes tipos de

(Data componentes de red, como son:

Communications
Network-Redes de Líneas dedicadas, red pública de conmutación de paquetes,
Comunicaciones de red telefónica pública conmutada, red digital de servicios
Datos) integrados RDSI, sistema de señalización por canal común
(CC7), redes locales que son usadas para el intercambio de la
información de gestión gracias a las capacidades de
encaminamiento y transporte

Ejecuta las funciones de mediación o sea la traducción de

MD información de modelos propietarios a modelo normalizado.
(Mediation Devices- Tienen funciones de pasarela tales como: Implementa
Dispositivos funciones como conversión de protocolos, conversión de
Mediadores) mensajes, traducción de direcciones y encaminamiento.

También pueden realizar funciones de procesamiento de la

información, filtrado de datos, almacenamiento de datos, etc.
WS
(Workstations- Soportan las funciones de Terminal de usuario, para ejecutar
Estaciones de Trabajo) entrada y salida de datos recibidos de los de los MD y OS.
 NE NE es un objeto, grupo de objetos que contiene información
(Network Elements - (MIB) que es monitoreada y controlada por el OS también se
Elementos de Red) los conoce como Agentes,
Los NE deben tener una interfaz TMN estándar, en caso de no
tenerla se los puede manejar mediante un QA.
QA (Q Adapters- Los adaptadores QA permite la Gestión de NE que no tienen
Adaptadores Q) interfaces TMN para convertir los datos de no-TMN a datos que
siguen el modelo de información TMN.
TABLA 1.2. COMPONENTES DE TMN

1.4.3.1.2 Interfaces

Las interfaces son los siguientes y se describen en la Tabla 1.3.

• Interfaz Qx
• Interfaz Q3
• Interfaz X
• Interfaz F

Interfaces Descripción

Q Qx El interfaz Qx transporta información que es compartida entre el MD

y los NEs, la interfaz Qx existe entre el NE y MD; QA y MD; MD y
MD.
Q3 Cualquier componente que este conectada directamente al OS usa
una interfaz Q3, es decir la interfaz Q3 esta entre los NE y OS; MD
y OS; QA y OS; OS y OS.
X Soporta el conjunto de funciones para la interconexión de diferentes
OSs en diferentes dominios TMNs, también existe entre un OS de
una red TMN y otro OS de un Red no TMN. Requiere de las 7
capas de OSI.
F Soporta el conjunto de funciones para la interconexión de
estaciones de trabajo con componentes físicos de la red, esta
interfaz existe entre una WS y OS; WS y MD.
TABLA 1.3. INTERFACES DE TMN
Además, la recomendación M.3010 define dos puntos de referencia adicionales
los cuales están ubicados fuera del área de los elementos estándares de TMN:

• El punto de referencia “g” está ubicado entre el usuario humano y la

WSF.
• El punto de referencia “m” está ubicado entre el QAF y un elemento
que no conforma a las recomendaciones TMN

FIGURA 1.7. ARQUITECTURA FÍSICA DE TMN

1.4.3.2 Modelo Organizativo de TMN

La arquitectura organizativa introduce una relación jerárquica entre los

diferentes gestores que existen en una red TMN de manera que haya gestores
de bajo nivel más orientados a la resolución de problemas técnicos de los
recursos y gestores de más alto nivel, orientados a garantizar calidades de
servicio. TMN se divide en capas lógicas que se muestran en la Figura 1.7 y se
describen en la Tabla 1.3.
 FIGURA 1.7. CAPAS LÓGICAS DE TMN

Nivel Descripción

Relacionada con la gestión táctica y estratégica de

BML empresas, responsable en la toma de decisiones de
(Business inversión y utilización optima del presupuesto,
Management Layer- soporte y demanda de mano de obra.
Nivel de Gestión del
Negocio)
Apoya la toma de decisiones en la alta dirección.
Incluye sistemas que soportan múltiples aplicaciones
de información empresarial.

Responsable de supervisar y controlar los aspectos

contractuales de los servicios suministrados a los
SML clientes.
(Service Management
Layer-Nivel de Soporta la interacción con clientes, otras
Gestión del Servicio)
administraciones y proveedores de servicios,
mantenimiento de los acuerdos de nivel de servicio
(SLA), mantenimiento de datos estadísticos,
interacción entre servicios, la gestión de solicitudes y
reclamos de servicio o facturación.
 La NML gestiona la primera vista de la red, coordina
todas las actividades y soportes que demanda el
cumplimiento del SLA, es decir es responsable por la
supervisión, control y configuración remota de redes.
Soporta análisis y correlación de alarmas
NML provenientes de nivel 4. Interactúa con el nivel 2
(Network para el suministro de datos de estado, desempeño,
Management Layer- utilización y disponibilidad, y para la recepción de
Nivel de gestión de órdenes de servicio.
Red)
Soportada por un sistema de operación de red (OS)
con las siguientes funciones: provisión, finalización o
modificación de las capacidades de la red para el
soporte de servicios a clientes. Control y
coordinación de todos los elementos de la red con
su ámbito y dominio.

Soporta y mantiene un control de los NEs. Abarca

EML funciones de colección y análisis de datos de
(Element desempeño, vigilancia del estado de la red, reportes
Management Layer- de alarmas, control de logs de eventos,
Nivel de Gestión configuración de elementos de red, pruebas,
Elementos de Red colección de datos de tarificación, conversión de
protocolos.

TABLA 1.3 DESCRIPCIÓN DE LA CAPAS LÓGICAS DE TMN.

El modelo organizativo trabaja en conjunto con las áreas de gestión FCAPS
(Fauls, Configuration, Accounting, Performance, Security) las que se describen
a continuación:

1.4.3.2.1 Gestión de Fallos

La Gestión de Fallos tiene como objetivo fundamental la localización y

recuperación de los problemas de la red. Comprende las siguientes tareas:
• Aseguramiento de la calidad: confiabilidad, disponibilidad y
mantenibilidad.
• Vigilancia de alarmas: detección y análisis de eventos de falla, reportes,
registros cronológicos, correlación y filtraje de alarmas.
• Localización de averías: verificación de conectividad, ejecución de
diagnósticos.
• Corrección de averías: proceso de reparación, órdenes de trabajo,
corrección y restauración.
• Pruebas: control de puntos de acceso, pruebas de servicio, reportes
• Administración de problemas: recepción de reportes de problemas,
administración de tiquetes de problema, notificaciones a los clientes.

1.4.3.2.2 Gestión de Configuración

La Gestión de Configuración es el proceso de obtención de datos de la red
y utilización de los mismos para incorporar, mantener y retirar los diferentes
componentes y recursos que la integran, todos estos cambios están
coordinados. Comprende las siguientes tareas:
• Planeación y Negociación del servicio: definición de características,
mercadeo, ventas, relaciones externas, análisis de mercados, definición
y desarrollo de soluciones específicas a clientes
• Planeación e ingeniería de red: análisis de presupuesto, selección de
tecnologías y suministradores, gestión de procesos, diseño de
soluciones.
 • Instalación: negociación de equipos y herramientas, administración de
instalaciones, gestión de materiales, administración de la fuerza de
trabajo, reportes.
• Aprovisionamiento: determinación de rutas de acceso, de circuitos y
direcciones, administración de estado de servicio, selección y asignación
de recursos de red, diseños de facilidades, gestión de inventario de red,
configuración de elementos.
• Situación y control: de servicios, redes, elementos y sistemas.

1.4.3.2.3 Gestión de Contabilidad

La Gestión de Contabilidad tiene como misión la recolección de estadísticas
que permitan generar informes de tarificación que reflejen la utilización de los
recursos por parte de los usuarios. Requiere la realización de las siguientes
tareas:
• Recolección de datos sobre la utilización de los recursos: planeación,
gestión, reportes de utilización de servicio, colección, validación,
correlación, distribución, corrección de errores, pruebas y administración
de datos de utilización.
• Tarificación y fijación de precios: estrategias y administración de tarifas y
precios de productos, análisis de costos por servicio, políticas de
convenios, aplicación de tarifas a las mediciones de uso para generar
facturas, liquidación.
• Recaudación y finanzas: planeación y gestión de facturación, envío de
facturas, recepción de pagos, administración de cuentas, operaciones de
contabilidad general, soporte de nómina, pensiones, tributación,
recursos humanos.
• Control empresarial: manejo de presupuesto, auditoria, análisis de flujo
de caja, gestión de costos e inversiones, análisis de rentabilidad,
reportes financieros, análisis de seguros.
1.4.3.2.4 Gestión de Rendimiento

La Gestión de rendimiento tiene como principal objetivo el mantenimiento del

nivel de servicio de la red y basa sus tareas en la definición de unos
INDICADORES DE FUNCIONAMIENTO. Es decir, es necesario fijar una serie
de criterios que permitan conocer cuál es el grado de utilización de un recurso.

Los indicadores más utilizados se clasifican en dos grandes grupos:

• PARÁMETROS DE FUNCIONAMIENTO ORIENTADOS AL SERVICIO:

miden el grado de satisfacción del usuario al acceder a los recursos. Los
más importantes son la disponibilidad, el tiempo de respuesta y la tasa
de error.
• PARÁMETROS DE FUNCIONAMIENTO ORIENTADOS A LA
EFICIENCIA: miden el grado de utilización de los recursos. Básicamente
son la productividad (throughput) y la utilización.

La gestión de rendimiento consiste en realizar cuatro tareas básicas:

• Aseguramiento de la calidad de funcionamiento: fijación de objetivos de

desempeño de calidad de servicio QoS y acceso al resumen de
mediciones sobre desempeño y disponibilidad de la red y sus elementos
para comparación de metas.
• Supervisión de la calidad de funcionamiento: políticas de supervisión,
correlación de eventos, colección, procesamiento y reportes de datos de
desempeño, estado y calidad de funcionamiento del tráfico
• Control de la calidad de funcionamiento: políticas de gestión de tráfico,
controles, administración de mediciones de datos, umbrales,
bases de datos y cambios de enrutamientos, auditorías.
• Análisis de la calidad de funcionamiento: recomendaciones para
mejoramiento de la QoS, pronósticos de tráfico, sumario de mediciones,
evaluación de desempeño de la red extremo a extremo.
1.4.3.2.5 Gestión de Seguridad

La Gestión de Seguridad es el responsable de la protección de la red de

usuarios no autorizados, físicos y electrónicos de sabotaje, verifica la
autenticación de usuario y autorización. Asimismo, mantiene la confidencialidad
de la información del usuario. Se ocupa de los siguientes puntos:

• Prevención: revisión legal, seguridad de acceso físico, vigilancia de

acceso, análisis de riesgo de personal, validación de seguridad de
clientes.
• Detección: investigación de patrones de ingreso y de utilización,
protección de elementos de soporte, alarmas de seguridad, investigación
de hurtos de servicio, análisis de tráfico interno y de patrones de
seguridad, auditoría de intrusión en el software.
• Salvaguardia y recuperación: protección de datos del negocio, clientes y
configuración, acciones para limitar propagación de violaciones de
seguridad, aprehensión de intrusos, recuperación o restauración de
servicio, administración de listas de revocación de clientes.
• Administración de seguridad: políticas de seguridad, planeación de
recuperaciones, gestión de vigilancia, auditorías, control de accesos.

1.4.3.3 Modelo Funcional de TMN

Se definen cinco tipos de bloques funcionales, los cuales proporcionan la

funcionalidad que permite a la TMN realizar sus funciones de gestión. Dos
bloques funcionales que intercambian información están separados mediante
puntos de referencia.
La recomendación M.3010 define cinco bloques de función que se muestran en
la Figura 1.8.
 • Bloque de función de sistemas de operaciones (Operations Systems
Function: OSF)
• Bloque de función de elemento de red (Network Element Function: NEF)
• Bloque de función de estación de trabajo (Workstation Function: WSF)
• Bloque de función de mediación (Mediation Function: MF)
• Bloque de función de adaptador Q (Q Adaptor Function: QAF)

FIGURA 1.8. BLOQUES FUNCIONALES DE TMN

1.4.3.3.1 Bloque Funcional de Sistema de Operación (Operation System Function,

OSF)

Los OSF procesan la información relativa a la gestión de la red con el objeto

de monitorizar y controlar las funciones de gestión, inicia las operaciones de
gestión y recibe las notificaciones de los agentes.

Se comunica con los NEF sobre el punto de referencia q3, como se muestra en
la Figura 1.9

FIGURA 1.9 COMUNICACIÓN ENTRE OSF Y NEF

Es posible definir múltiples OSF dentro de un dominio TMN a través del punto
de referencia q3 o en diferentes dominios TMN a través del punto de referencia
x, como se muestra en la Figura 1.10.

FIGURA 1.10. COMUNICACIÓN ENTRE DIFERENTES OSF

1.4.3.3.2 Bloque Funcional de Elementos de Red (Network Element Function, NEF)

Este bloque realiza las siguientes funciones:

• Funciones Principales: son el objeto de la gestión y posibilitan la

conmutación de los datos entre los usuarios de la red de
telecomunicación. Estas funciones no están definidas en TMN.
• Funciones de Gestión: permiten al bloque NEF funcionar como agentes
de gestión, susceptible de ser monitorizado y controlado. Estas
funciones sí están definidas en TMN.

1.4.3.3.3 Bloque Funcional de Estación de Trabajo (Workstation Function, WSF)

Este bloque funcional proporciona los mecanismos para que un usuario pueda
interpretar e interactuar con la información de TMN. Incluye soporte a la interfaz
con los usuarios humanos a través del punto de referencia g, el cual no es
parte de TMN por lo que se puede decir que una parte de WSF no es parte de
la TMN como se muestra en la Figura 1.11.
 FIGURA 1.11 INTERACCIÓN DE WSF EN TMN

1.4.3.3.4 Bloque Funcional de Adaptador (Q Adaptor Function, QAF)

Permite que TMN pueda gestionar elementos de red que posean un sistema de
gestión propietario; es decir, se utiliza para conectar a la TMN aquellas
entidades que no soportan los puntos de referencia estandarizados por TMN.
Por ejemplo, es utilizado para conectar un bloque de función similar a NEF (no-
TMN-compatible) con un OSF, ó un bloque de función similar a OSF (no-TMN-
compatible) con un NEF.

Esto significa que la información entre un bloque de función TMN-compatible y

un bloque de función no-TMN-compatible será traducida por el QAF.

Una parte dada de las funciones del QAF están definitivamente fuera de la
TMN como se muestran en la Figura 1.12.

FIGURA 1.12 INTERACCIÓN DE QAF EN TMN

1.4.3.3.5 Bloque Funcional de Mediación (Mediation Function, MF)

Actúa sobre la información que llega de los NEF y de los QAF para adaptarla,
filtrarla y condensarla, adecuándola al formato utilizado por los OSF como se
muestra en la Figura 1.13.

FIGURA 1.13 MF

En la Tabla 1.4 se especifican los puntos de referencia posibles entre los

distintos bloques funcionales.

NEF OSF MF QAFq3 QAFqx WSF No TMN

NEF q3 qx
OSF q3 x, q3 q3 q3 f
MF qx q3 qx qx f
QAFq3 q3 m
QAFqx qx m
WSF f f g
No TMN m m g
TABLA 1.4 PUNTOS DE REFERENCIA
1.4.3.4 Modelo de información de TMN

Las características generales del modelo de información de TMN son

discutidas por las recomendaciones M.3010 y M.3100 de ITU-T. Este se
soporta en gran medida sobre el modelo de gestión de red OSI/CMIP. La
arquitectura de información de TMN está basada sobre un modelo orientado a
objeto y define el formato de la información que se transmite entre los bloques
funcionales.

Un objeto gestionado representa uno de los componentes importantes de un

elemento de red físico ó un recurso lógico. Cada elemento gestionado debe
tener un nombre simple y único; su condición actual es una función del tiempo.

Desde el punto de vista de gestión, un objeto se ve como (Figura 1.14):

• Atributos: propiedades o características del objeto
• Operaciones: que se realizan sobre el objeto
• Comportamiento: que el objeto exhibe en respuesta a operaciones
• Notificaciones: emitidas por el objeto

FIGURA 1.14 OBJETO EN TMN

El gestor y el agente se comunican utilizando protocolos “Q” estándares,

construidos de acuerdo al modelo de comunicación de siete capas de OSI.
 FIGURA 1.15 COMUNICACIÓN ENTRE GESTOR Y AGENTE

Los elementos esenciales de la interfaz de aplicación TMN son altamente

similares a aquellos de la gestión OSI/CMIP

• Elemento de Servicio Común de Información de Gestión (Common

Management Information Service Element, CMISE)

El CMISE es responsable por la generación de requerimientos (requests)

estándares básicos y el procesamiento de mensajes de respuesta según
lo definido por el CMIS. El CMIS puede ser utilizado por un proceso de
aplicación en un ambiente de gestión centralizado ó descentralizado
para intercambiar información y comandos para el propósito de sistemas
de gestión.

• Elemento de Servicio de Operación Remota (Remote Operation Service

Element, ROSE)
• El ROSE controla y supervisa las interacciones entre entidades remotas
de una aplicación distribuida, donde esas interacciones pueden ser
modeladas y soportadas como operaciones remotas.

• Elemento de Servicio de Aplicación de Gestión de Sistemas (Systems

Management Application Service Element, SMASE)
El SMASE provee servicios que dan soporte a funciones de gestión
específicas.

• Elemento de Servicio de Control de Asociación (Association Control

Service Element, ACSE)
El ACSE es responsable de ejecutar la negociación inicial a efectos de
decidir si se puede establecer una conexión de datos y ponerla a
disposición de la comunicación. ACSE incluye dos unidades funcionales
opcionales:

o Una unidad funcional soporta el intercambio de información

soportando autenticación durante el establecimiento de la
asociación.
o La segunda unidad funcional soporta la negociación del contexto
de aplicación durante el establecimiento de la asociación”

• Transferencia de archivo, acceso y gestión (File Transfer, Access and

Management, FTAM)
FTAM organiza y gestiona acceso a archivos para propósitos de
aplicación, de acuerdo a las especificaciones de ANS.1.
1.5 NGOSS (NEW GENERATION OPERATIONS SYSTEMS AND
SOFTWARE - SISTEMAS Y SOFTWARE DE OPERACIONES
DE ÚLTIMA GENERACIÓN)

TeleManagement Forum es una organización global sin ánimo de lucro que

impulsa el desarrollo de sistemas y software de operaciones de última
generación (NGOSS).

La visión original del TMF fue "Acelerar la disponibilidad de productos

interoperables de gestión de red", siendo que para su origen y hasta la fecha
uno de los grandes retos que posee la industria es la capacidad real que
poseen las aplicaciones de soporte al negocio (BSS) y el soporte de
operaciones (OSS).

Un factor decisivo en el desarrollo y evolución de cualquier servicio de

telecomunicaciones, en cualquier momento y lugar, será la eficacia que los
Sistemas de Soporte de Operaciones y los Sistemas de Soporte del Negocio
(OSS/BSS) que los ISPs puedan ofrecer para afrontar la enorme complejidad
tecnológica que requieren los clientes.

NGOSS representa un cambio de paradigma en los OSS de las

Telecomunicaciones. Es una solución orientada a negocio que especifica una
metodología para construir componentes de los OSS a la vez que sirve de guía
para lograr un rápido desarrollo, integración, adquisición y despliegue de
soluciones OSS/BSS flexibles y a bajo costo que satisfagan las necesidades
del negocio.

NGOSS consta de los siguientes elementos:

• El Mapa de Procesos del Negocio NGOSS, definido por el Mapa de

Operaciones de Telecomunicaciones mejorado (eTOM), el cual
constituye el tema de este trabajo.
 • El Modelo de Información NGOSS, definido por el Modelo de Datos e
Información Compartida (SID).
• La Arquitectura Directriz NGOSS, definida por la Arquitectura de
Tecnología Neutral (TNA)
• Las Interfaces de Contrato.
• Los Criterios de Conformidad NGOSS, definidos en las Pruebas de
Conformidad.

En Ecuanet S.A. se maneja el sistema de Gestión TMN el cual se lo ha

fusionado con el Proceso TOM que es la versión anterior a eTOM, por lo que
en el presente documento se hace una descripción de TOM y el lugar que
ocupa dentro del proceso eTOM como se muestra en la Figura 1.16

FIGURA 1.16 TOM DENTRO DE ETOM

1.5.1 TOM VS. ETOM

Telecommunication Operations Map (TOM) fue desarrollado por la organización

Telemanagement Forum TMF entre 1995 y1998. A partir del 2001 se hace una
ampliación y mejora de donde proviene el nombre actual enhanced
Telecommunication Operations (eTOM) que se traduce como Mapa de
Operaciones de Telecomunicación Mejorado.

El marco referencial hoy en día posee información fundamental para el mundo

de telecomunicaciones y pretende, entre otras cosas, estandarizar los
conceptos de los procesos y dar estructura coherente a los procesos de una
empresa de telecomunicaciones, para lo cual eTOM abarca las siguientes
áreas (Figura 1.17):

• SIP por Estrategia, Infraestructura y Productos; y

• OPS por Operaciones
• EM por Enterprise Management,
• Áreas Funcionales

Su uso permite comprender mejor el tipo de empresas, desarrollar de manera

rápida y consistente flujos de extremo a extremo con calidad y sobre todo crear
todo lo necesario para mapear las aplicaciones de dichos procesos.

FIGURA 1.17 ÁREAS DE ETOM

1.5.1.1 Estrategia, Infraestructura y Producto

Cubre la planeación y la gestión de los ciclos de vida. El eTOM agrega esta

área al mapa de procesos, con el propósito de destacar los procesos de
planeación y desarrollo, de los operacionales, que están más relacionados con
el día a día del negocio.

El Área de Procesos de Estrategia, Infraestructura y Producto (Figura 1.18)

incluye los procesos que desarrollan la estrategia, comprometen a la empresa,
construyen la infraestructura, desarrollan y gestionan los productos, y los que
desarrollan y gestionan la Cadena de suministro. En el eTOM, la infraestructura
se refiere a algo más que sólo la infraestructura de tecnología de información y
recursos que soporta los productos y servicios. Incluye la infraestructura
requerida para soportar los procesos funcionales, como la Gestión de las
Relaciones con el Cliente (CRM, por su nombre en inglés). Estos procesos
dirigen y hacen posible los procesos de Operaciones.

FIGURA 1.18 ESTRATEGIA, INFRAESTRUCTURA Y PRODUCTO

1.5.1.2 Operaciones

Cubre el núcleo de la gestión operacional. El eTOM recoge los procesos

operacionales establecidos por el TOM, los cuales constituyen los procesos
end-to-end fundamentales de Aprovisionamiento, Aseguramiento, y
Facturación, agrupándolos en el área de Operaciones del nuevo mapa. Estos
procesos los ha utilizado Ecuanet S.A. para fusionarlos con el modelo TOM,
por lo que este estudio será referente a esta área, como se muestra en la
Figura 1.19

FIGURA 1.19 PROCESOS OPERACIONALES DE ETOM

1.5.1.3 Gestión Empresarial

Cubre la gestión corporativa o de soporte al negocio. En esta área se

concentran los procesos que toda empresa debe tener para su normal
funcionamiento.

El Área de Procesos de Gestión Empresarial incluye los procesos de negocio

básicos requeridos para que cualquier negocio funcione. Estos procesos se
enfocan en los procesos del Nivel de Empresa, metas y objetivos.
Estos procesos tienen interfaces con casi todos los otros procesos en la
empresa, ya sean operacionales, de producto o de infraestructura. Son
considerados algunas veces funciones y/o procesos corporativos, como la
Gestión Financiera, los procesos de Gestión de Recursos Humanos, como se
muestra en la Figura 1.20.

FIGURA 1.20 GESTIÓN EMPRESARIAL DE ETOM

1.5.1.4 Áreas funcionales

El eTOM también ha definido cuatro áreas funcionales que, de alguna manera,

corresponden a diferentes niveles de la Arquitectura Lógica de TMN, y afinan
los grupos de procesos definidos en su antecesor, el TOM. Estas áreas son:

• Los procesos de Mercado, Producto y Cliente, incluyen aquellos

relacionados con la gestión de ventas y canales, gestión de mercadeo, y
gestión de productos y ofertas, así como también la Gestión de las
Relaciones con el Cliente, el manejo de órdenes y problemas, la gestión
de Acuerdos de Niveles de Servicio (SLA) y la facturación.
• Los procesos de Servicio incluyen aquellos relacionados con el
desarrollo y configuración de servicios, gestión de problemas y análisis
de calidad de los servicios, y tarifación.
• Los procesos de Recursos incluyen los que tienen que ver con el
desarrollo y la gestión de la infraestructura de la empresa, ya sea
relacionada con los productos y servicios, o con el soporte de la
empresa en sí.
 • Los procesos del Proveedor/Aliado incluyen los relacionados con la
interacción de la empresa con sus proveedores y aliados. Esto involucra
tanto los procesos que gestionan la Cadena de Suministro que soporta
los productos y la infraestructura, como aquellos que soportan la interfaz
de Operaciones con sus proveedores y aliados.

1.5.2 MAPA DE OPERACIONES DE TELECOMUNICACIONES (TOM)

Se realizará la descripción de TOM agrupando los procesos de manera Vertical

y Horizontal como se muestra en la Figura 1.21.

1.5.2.1 Agrupamiento vertical de TOM

Él área de procesos de Operaciones contiene los agrupamientos verticales de

los procesos directos de operaciones de Aprovisionamiento, Aseguramiento y
Facturación, que algunas veces son referidos como procesos de Operaciones
del Cliente.

FIGURA 1.21 TOM

1.5.2.1.1 Aprovisionamiento

Este proceso es responsable de proveer a los clientes sus productos

requeridos de manera oportuna y correcta. Este proceso informa a los clientes
el estado de su orden de compra, asegura la terminación oportuna, así como
también un cliente satisfecho.

En la Figura 1.22 se muestra el Proceso de Aprovisionamiento del servicio en

Ecuanet.

a. Respuesta de Aprovisionamiento de Mercadeo: son los procesos

encargados de la distribución de los productos de mercadeo colateral,
como por ejemplo cupones, premios, etc.

b. Ventas: son los procesos responsables de la gestión de los clientes y del

ajuste de las expectativas del cliente a los productos y servicios de la
empresa.

c. Manejo de Órdenes: estos procesos responden por la aceptación y el

trámite de las órdenes.

d. Configuración y Activación de Servicios: comprenden la instalación y

configuración del servicio para los clientes, al igual que la reconfiguración
del mismo cuando ya está activado.

e. Compra a Proveedores/Aliados: estos procesos son responsables del

entendimiento de lo que se necesita de los proveedores y aliados para
tomar las decisiones de compra; negocian compras específicas y solicitan
el trámite de las órdenes de compra; estos procesos tienen una interfaz
con los procesos de ventas del proveedor.

f. Gestión de Órdenes de Compra a Proveedores/Aliados: gestionan las

órdenes de compra, con el fin de asegurar la entrega oportuna de los
productos o servicios requeridos por la empresa. Tienen interfaz con los
procesos de Manejo de Órdenes del proveedor.
FIGURA 1.22 PROCESO DE APROVISIONAMIENTO DEL SERVICIO EN ECUANET.

1.5.2.1.2 Aseguramiento

Este proceso (Figura 1.23) es responsable de la ejecución de las actividades

proactivas de monitoreo continuo del estado y del desempeño de los recursos
de la red para detectar posibles fallos, y asegurar que los servicios provistos a
los clientes estén disponibles continuamente, y así mantener los niveles de
desempeño (SLA) y de QoS. Recoge datos de desempeño y los analiza para
identificar problemas potenciales y resolverlos sin impacto al cliente. Recibe los
reportes de problemas desde los clientes, informa a los clientes sobre el estado
del problema y asegura la restauración y reparación, como también la
satisfacción del cliente.

a. Manejo de Problemas: estos procesos son responsables de la

recepción de los reportes de problemas por parte de los clientes, su
resolución y su comunicación al cliente sobre el estado de las
actividades pertinentes. También contactan y apoyan al cliente ante
la detección de cualquier problema que afecte el servicio.
b. Gestión de QoS y SLA: estos procesos encierran el monitoreo, la
gestión y el reporte de la Calidad del Servicio (QoS) entregada vs. la
contractual, como está definida en las descripciones del servicio de la
empresa, los contratos con los clientes, como es el SLA.

c. Gestión de Problemas de Servicio: estos procesos responden

inmediatamente ante problemas o fallas que afecten el servicio para
minimizar sus efectos en los clientes.

d. Análisis, Acción y Reporte de Calidad del Servicio: enmarcan el

monitoreo, el análisis y el control del desempeño del servicio
percibido por los clientes.

e. Recolección, Análisis y Control de Datos de Recursos: estos

procesos se refieren a la recolección de uso, eventos de red y
tecnología informática, incluyendo información de los recursos, para
el reporte de uso del cliente y facturación.

f. Reporte y Gestión de Problemas de Proveedor/Aliado: estos

procesos gestionan los problemas, ya sean éstos identificados dentro
de la empresa o notificados por el proveedor; diligencian reportes o
tiquetes de problemas para las organizaciones de proveedores y
aliados dentro de la cadena de valor, los siguen y aseguran la
oportuna y correcta restauración o reparación.

g. Gestión de Desempeño de Proveedores/Aliados: estos procesos

siguen, miden y reportan el desempeño de proveedores y aliados.
 FIGURA 1.23. PROCESO E ASEGURAMIENTO DEL SERVICIO EN ECUANET.

1.5.2.1.3 Facturación

Este proceso (Figura 1.24) es responsable de la producción oportuna y correcta

de facturas, de la provisión de información pre-facturación de uso, y de la
facturación a los clientes, del procesamiento de sus pagos, y del recaudo de los
mismos.

Adicionalmente, maneja las consultas de los clientes sobre facturación, provee

el estado de dichas consultas y es responsable de resolver los problemas de
facturación para la satisfacción de los clientes de una manera oportuna. Este
proceso también soporta el prepago de servicios.

a. Gestión de Facturación y Recaudo: estos procesos encierran la creación

y el mantenimiento de la contabilidad de la facturación de los clientes, el
envío de las facturas a los mismos, el procesamiento de sus pagos, el
recaudo de éstos, el monitoreo de las cuentas, y el manejo de las
excepciones de facturación y pagos.
 b. Tarifación del Servicio e Instancias Específicas: estos procesos
gestionan los eventos de servicio correlacionándolos y formateándolos
de una manera apropiada. Incluyen la tarifación de los niveles de
servicio con base en la información de uso, así como la investigación de
los problemas con eventos de facturación relacionada con el servicio.

c. Gestión de Convenios y Facturación: estos procesos gestionan todos los

convenios y la facturación para la empresa, incluyendo la validación y
verificación de facturas, y la autorización de los respectivos pagos.

FIGURA 1.24. PROCESO DE FACTURACIÓN DE ECUANET

1.5.2.2 Agrupamiento horizontal de TOM

En el área de procesos Operacionales del eTOM, hay cuatro agrupamientos de

procesos funcionales de Operaciones que soportan los procesos de
Aprovisionamiento, Aseguramiento y Facturación, así como también la gestión
de las operaciones para soportar los clientes, el servicio, los recursos y las
interacciones con el proveedor/aliado.
El TOM original usó los niveles lógicos de Negocios, de Servicios y de Red del
TMN para organizar los procesos del núcleo del negocio. Esto facilitó el mapeo
de las Funciones de Gestión definidas en TMN, hacia los procesos del TOM.
Como el Marco de Referencia de los Procesos de Negocio eTOM es una
evolución del Marco de Referencia TOM y debido a que el enfoque por niveles
de TMN aún es relevante, los Niveles Lógicos de TMN continúan de alguna
manera acoplados a los agrupamientos de procesos funcionales.

1.5.2.2.1 Gestión de las Relaciones con el Cliente (CRM)

Este agrupamiento de procesos comprende el conocimiento fundamental de las

necesidades de los clientes e incluye todas las funcionalidades necesarias para
la adquisición, ampliación y retención de una relación con un cliente. Trata
acerca del servicio y soporte al cliente, ya sea en centros de atención, por
teléfono, web o servicio en campo.

CRM también incluye la recolección de la información de los clientes y su

aplicación para personalizar e integrar la entrega de los servicios al cliente,
como también para identificar oportunidades para incrementar el valor del
cliente para la empresa, es una característica clave del eTOM sobre TOM.

1.5.2.2.2 Gestión y Operaciones de Servicios

Este agrupamiento de procesos se enfoca en el conocimiento de los servicios
(acceso, conectividad, contenido, etc.) e incluye todas las funcionalidades
necesarias para la gestión y las operaciones de comunicaciones y los servicios
de información requeridos por los clientes, o propuestos por ellos.
Algunas de las funciones involucran planeación a corto plazo de las
capacidades del servicio, la aplicación de un diseño del servicio a clientes
específicos o la gestión de iniciativas de mejoramiento del servicio. Estas
funciones están íntimamente conectadas con la experiencia diaria del cliente.
1.5.2.2.3 Gestión y Operaciones de Recursos

Este agrupamiento de procesos mantiene el conocimiento de los recursos y es

responsable de la gestión de todos los recursos utilizados en la entrega y
soporte de los servicios requeridos por los clientes, o propuestos por ellos.
Estos procesos son responsables de asegurar que la infraestructura de red y
de tecnologías de información soporte la entrega diaria de los servicios
requeridos. La misión de estos procesos es asegurar que la infraestructura
funcione sin contratiempos, sea accesible a los servicios y empleados, sea
mantenida y responda a las necesidades, directas o indirectas, de los servicios,
clientes y empleados.

1.5.2.2.4 Gestión de las Relaciones con el Proveedor/Aliado:

Estos procesos se alinean fuertemente con los procesos de Gestión de las
Relaciones con el Cliente del proveedor o del aliado. Su inclusión en eTOM es
una de las formas clave en que el eTOM se diferencia del marco de referencia
de empresa integrada verticalmente que estuvo en el TOM.

La existencia de estos procesos permite la interfaz directa con el ciclo de vida

apropiado, las operaciones end-to-end con el cliente o los procesos funcionales
con los proveedores o aliados. Los procesos incluyen la elaboración de
Requests for Proposals (RFPs) como parte del proceso de compra, la
elaboración de órdenes de compra y su seguimiento para la entrega, manejo
de problemas, validación de la facturación y autorización de pagos, como
también la gestión de calidad de los proveedores y aliados.
1.6 DESARROLLO DE UN SISTEMA DE GESTIÓN DE
MONITOREO EN BASE A TMN Y TOM PARA LA EMPRESA
ECUANET S.A.

El Backbone de la empresa Ecuanet S.A.se encuentra divida en dos regiones

llamadas R1 (Sierra y Oriente) y R2 (Costa e Insular) a nivel nacional, donde la
región R1 comprende 85 nodos y la región R2 80 nodos distribuidos en
ciudades tales como: Quito, Guayaquil, Ibarra, El Coca, Riobamba, Ambato,
Santo Domingo, Loja, Macas, Azogues, Portoviejo, Manta, Salinas, Babahoyo,
Galápagos y Machala.

La empresa tiene opciones limitadas de monitoreo y de obtención de

información, el aumento del número de clientes, soluciones complejas, la
exigencia de proactividad y altos niveles de disponibilidad de sus circuitos
(cumplimiento de Service Level Agreement SLA) ha exigido que la empresa
adquiera un Sistema de Gestión de Monitoreo que cumpla con las demandas
actuales de todos los clientes y así puedan tener una ventaja frente a sus
competidores inmediatos.

Para resolver la problemática descrita se desarrollará un Sistema de Gestión

de Monitoreo orientado a la implantación de la herramienta HP OV NNM AE
v7.53. que permitirá a la empresa conocer el estado de la red en tiempo real en
los puntos de convergencia, envío de notificaciones de alertas vía e-mail,
generación de reportes con las estadísticas necesarias para mantener un
óptimo rendimiento de la red de datos y la detección oportuna de las fallas;
dando seguimiento a todos los eventos ocurridos en los dispositivos de
comunicaciones en la Red Backbone de Ecuanet.
1.6.1 MONTORIZACIÓN

La monitorización es la parte de la gestión de red que se ocupa de la

observación y análisis del estado y el comportamiento de los recursos
gestionados. Abarca cuatro fases:

• DEFINICIÓN DE LA INFORMACIÓN DE GESTIÓN QUE SE VA A

MONITORIZAR.
• ACCESO A LA INFORMACIÓN DE MONITORIZACIÓN. Las
aplicaciones de monitorización utilizan los servicios ofrecidos por un
gestor para acceder a los datos de monitorización mantenidos por un
agente. Las comunicaciones entre gestores y agentes se realizan
gracias a los protocolos de gestión
• DISEÑO DE POLÍTICAS DE MONITORIZACIÓN. Se distinguen dos
tipos de comportamiento:
• Sondeo (Polling): En este caso el gestor pregunta periódicamente a los
agentes por los datos de monitorización.
• Informe de Eventos: Los agentes, por su propia iniciativa, informan a los
gestores para lo cual se configurará en cada NE a monitorearse el envío
de Traps SNMP.
• PROCESADO DE LA INFORMACIÓN DE MONITORIZACIÓN.

1.6.2 CONTROL

La parte de control dentro de la gestión de redes es la encargada de modificar

parámetros e invocar acciones en los recursos gestionados.
1.6.3 SISTEMA DE GESTION DE MONITOREO

1.6.3.1 OBJETIVO

El objetivo del SGM es mantener un óptimo rendimiento de la red de datos al

monitorear de manera constante la disponibilidad, y funcionalidad de los
dispositivos de red de datos, la detección oportuna de las fallas, dando
seguimiento a todos los eventos ocurridos en los dispositivos de la Red
Backbone de Ecuanet (RBE).

1.6.3.2 ANTECEDENTES

Actualmente Ecuanet S.A. posee una amplia e importante cartera de clientes,

los cuales debido a la falta de un SGM no existe un adecuado control sobre el
ingreso y salida de información de la RBE, tampoco poseen políticas ni
procedimientos relacionados con el monitoreo.
El NOC (Network Operation Center) necesita adelantarse a los eventos,
notificar al cliente, prevenir incidencias, actuar proactivamente ante las fallas
encontradas en la RBE y dar una solución eficaz y eficiente, así como
proporcionar información al área comercial sobre eventos de saturación, no
consumos, comportamientos de red, etc.

El desarrollo del SGM se basará en los modelos de gestión TMN y TOM con
los que trabaja Ecuanet S.A. y consistirá en el desempeño de las que se
describen en la siguiente sección de este documento.

El correcto desempeño de esta rutina nos permitirá mantener en estado eficaz

del funcionamiento de la red de comunicaciones de datos.
1.6.3.3 IMPLEMENTACION DEL SGM

El SGM debe ser puesto en práctica mediante la organización de un CENTRO

DE GESTIÓN DE RED, que en el caso de ECUANET es el Network Operation
Center (NOC) que va a disponer de tres clases de recursos: Modelos de
Gestión, Recursos Humanos, Herramientas de Apoyo, que conjuntamente
permitirán que los procesos de Monitoreo, Aprovisionamiento, Aseguramiento y
Facturación provean un diagnostico y respuesta rápida a cada problema
potencial apoyando la mejora de QoS, y así establecer un mejor SLA.

1.6.3.3.1 Service Level Management (SLM)

La Gestión del Nivel de Servicio reside en la capa de Gestión de Servicio de
TMN y es el conjunto de personas y sistemas que hace que la empresa cumpla
con los SLA´s y que los recursos para esto sean proporcionados
eficientemente.

1.6.3.3.2 Service Level Agreement (SLA)

El Acuerdo de Nivel de Servicio, es un documento anexo al Contrato de

Prestación de Servicios. En el SLA se pactan las condiciones y parámetros que
comprometen al proveedor del servicio a cumplir con unos niveles de calidad
de servicio frente al cliente.

A diferencia de los productos tangibles que se pueden ver, tocar o manipular,

los servicios se basan en la “confianza” que deposita el cliente frente al
proveedor por diferentes motivos como el conocimiento o el prestigio sin
embargo el proveedor de servicios para cumplir con estos niveles se apoya en
diferentes modelos de gestión, herramientas, etc.

Es importante que las condiciones implicadas en el servicio se especifiquen en

el documento del SLA, los términos y parámetros sobre los que se adquiere el
compromiso en el servicio, se indique el modo de cálculo de la disponibilidad;
indicando el valor o márgenes de referencia, compensaciones por
incumplimiento y por último las exclusiones o limitaciones en dichos cálculos.

Las partes que componen el SLA [1], referente al servicio, son:

• Definición: Descripción de las características del servicio.

• Provisión: Tiempo transcurrido desde la firma del pedido o contrato hasta
la entrega o puesta en marcha del servicio.
• Disponibilidad: Se trata del aspecto fundamental en el Acuerdo de Nivel
de Servicio y es necesario que contemple la plataforma tecnológica
(sistemas), las comunicaciones y el soporte técnico.
• Atención al cliente: Describe el método a seguir por el cliente frente a
incidencias o consultas sobre el servicio. Es vital un soporte técnico
cualificado y eficiente para asegurar el nivel de servicio adecuado y con
atención 24*7.
• Tiempo de respuesta: Compromiso de tiempo mínimo en cuanto a
resolución de incidencias.
• Mantenimiento: Condiciones sobre el mantenimiento, la reparación de
equipos y las posibles intervenciones que afecten al servicio de forma
programada.
• Penalizaciones: Garantías y compensaciones relativas al incumplimiento
del nivel de servicio comprometido.

Ecuanet posee un SLA que emite a sus clientes a la firma del contrato, éste no
consta en este trabajo debido a políticas de confidencialidad interna de la
empresa.

1 www.acens.com/file_download/.../acens_que_es_el_sla_baja.pdf
1.6.3.3.3 Modelos de Gestión: TMN y TOM

Los modelos de gestión TMN y TOM son la base del Plan de Trabajo a
seguirse para la implantación de la herramienta de monitoreo adquirida por
Ecuanet S.A. con esto se podrá establecer un mejor SLA.

• Actualización de Diagramas de Red.

• Levantamiento de información de los nodos principales de la Red
Backbone de Ecuanet a nivel nacional.
• Adquisición de archivos MIB de los equipos a ser monitoreados.
• Habilitación de Traps SNMP en los nodos de RBE
• Establecimiento de Políticas de Interfaces libres
• Habilitación de Puertos
• Establecimiento de la arquitectura del Servidor de Gestión.
• Instalación de la herramienta de gestión.
• Configuración de la herramienta de gestión.
• Pruebas de aceptación.

1.6.3.3.4 Recursos humanos: Infraestructura, Instalaciones, NOC.

a. Infraestructura
El área Infraestructura se encarga de la ingeniería de los enlaces de backbone
como por ejemplo la interconexión UIO-GYE, también hacen los diagramas de
red de estos enlaces, los suben a la red y los monitorean. Además capacitan al
área del NOC sobre la tecnología aplicada en el nuevo enlace.

Anteriormente esta área tenía su propio monitoreo pero la idea con NNM es
que sirva para todas las áreas por ser una plataforma robusta y completa es así
que se ha creado una consola de monitoreo para esta área con sus respectivas
claves y permisos.
 b. Instalaciones
El área de Instalaciones se encarga de la instalación de los enlaces a clientes,
es decir se encarga de la instalación de la última milla del cliente, hacen los
respectivos diagramas de red y los suben a la red, también utilizan la
herramienta de monitoreo para tener un control en los días de prueba y así
demostrar al cliente que el enlace se ha instalado correctamente y esta
operativo cumpliendo con el servicio ofertado como por ejemplo el apropiado
Ancho de Banda.

Sobre los enlaces cancelados el área de instalaciones los desinstala y el NOC

verifica si se liberaron todos los recursos correctamente.

c. Network Operation Center (NOC)

El área del NOC es responsable por el monitoreo de los enlaces de red de
backbone y clientes, analiza los problemas, previene incidencias, actúa
proactivamente a anomalidades encontradas en la red, da seguimiento a los
problemas a través de un Trouble Ticket que son reportados tanto por clientes
o notificaciones de alarmas del NNM. Además esta área verifica que las
instalaciones sean realizadas correctamente así como en una desinstalación
que los recursos sean liberados de manera adecuada.

Una vez que el NOC verifica que los enlaces nuevos estén bien instalados se
hace cargo de su mantenimiento y soporte, es decir el NOC administra los
enlaces de cada cliente, en los enlaces de Backbone el NOC solo monitorea y
si hay algún problema Infraestructura se encarga de solventarlo.

El administrador del NMS es parte de esta área y este se encarga de revisar

que los diagramas de red estén elaborados correctamente y en la red, también
le notifican mediante mail el nombre de los equipos a monitorearse, la dirección
IP´s, comunidad SNMP, y los Traps que serán habilitados.
Es el responsable de subir los enlaces al monitoreo así como de eliminar los
que han sido desinstalados, revisar que el sistema de monitoreo este
funcionando adecuadamente.

El Administrador del NMS revisa el las notificaciones que llegan al correo

[email protected] y se encarga de levantar un Trouble Ticket y
asignar a la persona adecuada dentro del área de escalamiento para su
revisión y solución.

El personal humano debe trabajar en conjunto para un excelente performance

del SGM así como un correcto funcionamiento de la herramienta NNM para
esto se ha creado los siguientes documentos.

• Instrucciones de Trabajo para el Ingreso de Clientes Corporativos y

VIP.
• Instructivo para el Proceso de Monitoreo;
• Manual de Usuario;

El desarrollo de estos documentos se adjunta en el Anexo 1 y serán

entregados a Ecuanet para su utilización

1.6.3.3.5 Herramientas de apoyo: HP OV NNM AE v7.53

Ecuanet S.A. ha adquirido la herramienta de gestión de HP OpenView Network

Node Manager Advance Edition v7.53 la cual cumple con las expectativas del
SGM que se ha desarrollado.

En el modelo de gestión TMN se puede verificar que es importante la

implantación de una plataforma de gestión, esta debe cumplir con los procesos
FAB de TOM para la obtención de rentabilidad.
En el capítulo II se evaluarán las diferentes plataformas de gestión existentes
en el mercado y se analizará si Ecuanet acertó en la decisión de haber
comprado la herramienta de HP OpenView Network Node Manager v7.53 y si
es la adecuada para sus necesidades.
 CAPÍTULO 2

CONFIGURACIÓN DE LA HERRAMIENTA NETWORK

NODE MANAGER

En este capítulo se compararán las plataformas de Gestión de Monitoreo

disponibles en el mercado, y se analizará si la decisión de Ecuanet al haber
seleccionado el software HP OV NNM AE v7.53 sobre la base del Sistema de
Gestión de Monitoreo desarrollado, ha sido la acertada para las necesidades y
requerimientos de su infraestructura de red.

Además, este documento presenta el desarrollo del plan de trabajo en el SGM

y la descripción del proceso de instalación y personalización de HP OpeView
Network Node Manager Advance Edition for Windows v7.53, con una licencia
para 250 nodos.

Tener una herramienta de monitoreo es esencial en el SGM que utiliza

Ecuanet, este permite saber sobre el desempeño de los equipos y así prevenir
futuros problemas para garantizar la disponibilidad de los servicios y disminuir
los riesgos que puedan haber frente una falla, anticiparse ante ésta, prepararse
para buscar las soluciones y mantener un buen funcionamiento, ofreciendo de
esta manera un buen servicio.

ECUANET requiere una herramienta de monitoreo que permita mejorar los

niveles de disponibilidad de sus servicios de TI basados en los modelos TMN y
TOM y establecer una arquitectura de administración de redes que permita la
habilitación y automatización de los procesos definidos en el SGM.

Para cumplir con estos requerimientos, en base al SGM se aplicará la Solución

de Gestión de Redes HP OpenView Network Node Manager 250 Advanced
Edition v7.53 para Windows.
2.1 PLATAFORMAS DE GESTIÓN DE MONITOREO

Una plataforma de gestión de red es una aplicación software que proporciona

la funcionalidad básica de gestión de red para los diferentes componentes de
una red.

La utilización de modelos de gestión como TMN y TOM obliga a la

implementación de una plataforma de Gestión de Red en Ecuanet.

En el mercado actual existe una variedad de plataformas de gestión que

pueden ser comerciales como no comerciales. Existen tres plataformas
fundamentalmente que se reparten el mercado: OpenView de Hewlett Packard,
SunNet de Sun Microsystems, y NetView de IBM. Otras ofertas del mercado
son: Spectrum Enterprise de Cabletron Systems, Optivity de Bay Networks o
Transcend de 3-Com. OpenView, es el producto más representativo, al
disponer de más de un 40 % de cuota dentro de las grandes empresas.

Todas estas herramientas se encargan de la recepción de información y datos

mediante sondeo automático (Polling) o iniciado por el usuario, a diferentes
dispositivos de la red como: ordenadores, hubs, routers, conmutadores, etc.
La tecnología Web, como forma de acceso fácil, barata, estándar e integrada a
la información de gestión de red, constituye una de las tendencias de futuro
más prometedoras en el mercado de plataformas de gestión de red.

Las funciones principales de un sistema de gestión son:

• Descubrir automáticamente la topología de la red

• Monitorización de la red
• Herramientas de diagnostico
• Gestión de MIBs
• Interfaz gráfica de usuario (GUI)
• Sistema gestor de base de datos (DBMS)
 • Registro de eventos (Event Log)
• Interfaces de programación de aplicaciones (API)
• Seguridad del sistema

Existen numerosas Plataformas de Gestión en el mercado a continuación se

describen algunas de ellas.

2.1.1 ZENOSS

Zenoss es una herramienta de monitoreo de redes y servidores de código

abierto licenciado bajo la GNU GPLv2 que utiliza SNMP, basada en Nagios.
Permite a los administradores tener un control completo sobre la infraestructura
de red. La instalación, la configuración y la administración fueron simplificadas
al máximo para permitir disponer de una poderosa herramienta de monitoreo
con un esfuerzo mínimo. La administración se realiza desde una interfaz Web,
desde la que se puede monitorear la disponibilidad de servicios, inventario de
hardware y software, configuración de sistema, rendimiento, eventos, etc.

2.1.2 SUNNET MANAGER (SUN)

SunNet Manager (Solstice) es una herramienta poderosa de monitoreo y

colección de estadísticas SNMP que está basada en arquitecturas y protocolos
de cálculo distribuido. Actúa sobre redes como: Ethernet, FDDI, Internet y X.25.

2.1.3 SPECTRUM

SPECTRUM es un sistema Open Source de la compañía Cabletron Systems

basado en el sistema operativo UNIX, corre bajo X-WINDOWS. Es descrito
como un sistema experto que controla y administra tanto redes
computacionales como los sistemas conectados a dichas redes.
Es una herramienta para proveer un ambiente poderoso y flexible para
administrar redes de distintos proveedores (multivendor networks). También es
un sistema multi-protocolario, es decir, puede controlar y administrar cualquier
equipo, sin importar qué tan diverso sea.

2.1.4 OPMANAGER

AdventNet ManageEngine OpManager es un sistema de monitorización para

todo tipo de elementos de red: redes de área local (LAN), redes de área amplia
(WAN), servicios de Windows, monitorización de logs, monitorización de URLs,
gestión de servidores y aplicaciones, etc.

Durante el proceso de monitorización, el programa es capaz de enviar alertas y

notificaciones a través del correo electrónico o de un mensaje SMS en caso de
que se registren errores. Genera también completísimos gráficos y estadísticas
para reflejar cualquier dato o información que pudiera escapar de otra manera.

2.1.5 INTEGRATED SYSTEM MANAGEMENT (ISM)

Características principales de la versión 3.5 de la suite Integrated System

Management del grupo Bull, al igual que las versiones anteriores, está
construida en torno a OpenView de Hewlett-Packard y consiste en diversos
módulos que de distribución de software, gestión de alarmas, operaciones
remotas, medición del rendimiento e identificación de problemas, así como
capacidades de back-up y monitor periférico.

ISM está diseñado para ofrecer un sistema de software integrado para

gestionar redes y plataformas basadas en Unix y en arquitectura PC, enlaces
de comunicaciones de área extensa, mainframes propietarios, aplicaciones y
dispositivos de red como routers, bridges y hubs.
2.1.6 WHATSUP GOLD V12

WhatsUp Gold es una herramienta que ofrece monitorización exhaustiva de

aplicaciones y redes y permite a los administradores de TIC convertir datos de
red en información práctica para el negocio. Al monitorizar de modo continuo
todos los servicios y dispositivos críticos, WhatsUp Gold optimiza el tiempo de
disponibilidad de la red ante una eventual caída. A la vez aporta mayor
seguridad al controlar con rapidez dispositivos no autorizados en una red.

La nueva herramienta incorpora una interfaz Web que permite el control de la

infraestructura y las aplicaciones de red, con lo que la empresa puede
concentrarse en la actividad propia de su negocio.
Entre las principales novedades de WhatsUp Gold v12 destacan:

• Datos en tiempo real (SSG): La herramienta SSG proporciona datos

gráficos en tiempo real e informes completos en el área de trabajo, en el
administrador de tareas Web y en el monitor de rendimiento Web. Así
mismo, da acceso instantáneo a datos de rendimiento en tiempo real.
• SNMP: Asistencia para controladores de interfaz de alta capacidad.
Permite explorar objetos SNMP gracias a la herramienta basada en
Internet SNMP MIB Walker y objetos SNMP en archivos MIB definidos.
• Correo electrónico: Mediante el Email Monitor se pueden enviar a
servidores correos electrónicos compatibles con encriptación y
autenticación SMTP.
• SMS: Servicio de mensajes cortos compatibles con SMS Direct.
• Base de datos SQL Server 2005 Express
• Monitores pasivos que requieren credenciales
• Administrador de pantalla del Tablero de Control: Agrega capacidad para
definir listas de selección de información que se muestran en uno o
varios monitores, incluyendo páginas web externas.
• Compatibilidad con Windows Vista
2.1.7 REAL-TIME NETFLOW ANALYZER

Real-time NetFlow Analizer desarrollado por SolarWinds captura y analiza los

datos en tiempo real y muestra exactamente el tipo de tráfico en la red, permite
diagnosticar y resolver problemas referentes al ancho de banda. Este es un
software que se lo puede descargar gratuitamente.

2.1.8 MULTI ROUTER TRAFFIC GRAPHER (MRTG)

MRTG es una herramienta para controlar la carga de tráfico de la red de

enlaces. MRTG genera páginas HTML que contienen imágenes gráficas que
proporcionan una representación visual en tiempo real del tráfico en la red.

MRTG corre en Linux, Windows y otros sistemas operativos que tengan

habilitado PERL. Utiliza SNMP para leer los contadores de tráfico de routers y
un rápido programa en C que registra el tráfico de datos y crea gráficos que
representan el tráfico en la conexión de red.

Puede controlar hasta 200 conexiones y es posible crear representaciones

visuales del tráfico visto durante los últimos siete días, las últimas cinco
semanas y los últimos doce meses.

2.1.9 NET-SNMP

Net-SNMP es un conjunto de aplicaciones utilizados para implementar SNMP

v1, SNMP v2c y SNMP v3 utilizando IPv4 e IPv6. Net-SNMP es un software
gratuito e incluye las siguientes aplicaciones:

• Recuperar información de un dispositivo. Manipular la información de

configuración en un dispositivo con capacidad SNMP (snmpset).
• Mostrar el contenido de la estructura.
 • Un visor gráfico MIB
• Permite la recepción de notificaciones SNMP.

2.1.10 NAGIOS

Sistema de monitoreo Open Source que monitorea los elementos de red y

servicios que se especifiquen, alertando cuando el comportamiento de la red no
es el deseado. Además provee vigilancia de los recursos tales como la carga
del procesador, disco, uso de la memoria, los procesos en ejecución, archivos
de registro, factores ambientales, etc.

Se ha diseñado para ejecutarse bajo el sistema operativo LINUX. Está

licenciando bajo la GNU General Public License versión 2 por la Free Software
Foundation. Está escrito en PHP.

Cuando se detectan problemas, el “demonio” puede enviar notificaciones

administrativas a los contactos en una variedad de diferentes formas (correo
electrónico, mensajes instantáneos, SMS, etc.) información de estado actual,
los registros históricos, y los informes pueden ser accedidos a través de un
navegador Web.

2.1.11 JFFNMS

En un sistema de administración y monitoreo de red open source diseñado

para monitorear redes SNMP. Puede ser usado para monitorear cualquier
dispositivo que cumpla con el estándar SNMP, como servidores, routers y
puertos TCP/IP.

Está escrito en PHP y usa como backend a MySQL.

2.1.12 NINO IS NOT OPENVIEW (NINO)

NINO es una solución que monitorea en tiempo real el estado de los elementos
de red como: routers, conmutadores, servidores y aplicaciones, también envía
notificaciones de eventos por correo electrónico.

NINO es una plataforma independiente diseñada en un inicio para Linux pero

ya hay versiones para Windows. Su instalación requiere la habilitación de
módulos PERL en el servidor y utiliza Java Applets para mostrar gráficos y
mapas de los nodos.

NINO es una solución basada en una interfaz Web para el usuario, utiliza
SNMP para controlar los dispositivos de red.
Las principales funciones de NINO son:

• Vista de estado de los dispositivos de la red

• Monitoreo
• Gestión de eventos
• Presentación de reportes

2.1.13 CISCOVIEW

Aplicación de software para gestión de dispositivos, basada en GUI, que

proporciona estado dinámico, estadísticas, e información de configuración
comprensiva a los dispositivos de Internetworking Cisco

2.1.14 HP OPENVIEW

La plataforma de gestión de red líder del mercado, OpenView de HP, es una

solución completa de gestión de redes y sistemas en entornos heterogéneos.
Está disponible para Windows y varios tipos de sistemas Unix. Es una
herramienta ampliamente utilizada por los administradores de redes para hacer
un seguimiento de sus redes físicas, los servicios de redes virtuales y la
relación entre todos los activos de una red. De manera más específica, NNM
ayuda a los administradores a identificar, diagnosticar y predecir posibles
problemas antes de que afecten al rendimiento de la red y su disponibilidad.

Se trata de un completo conjunto de productos, con tres módulos principales:

• Network Node Manager, es la herramienta de gestión principal, se encarga de

descubrir la topología de la red, maneja las alarmas procedentes de los
distintos dispositivos y conecta cualquier otra herramienta de gestión al mapa
de red.
• Operations Center, constituye la interfaz de usuario, gestionando funciones de
integración de sistemas de gestión, como gestión de impresoras, copias de
seguridad de servidores, etc.
• Admin Center se encarga de la gestión de configuraciones de puestos de
trabajo, servidores, etc.

Algunos de los beneficios de la Solución HP OpenView son los siguientes:

• Una puesta en operación rápida y precisa de los Productos HP OpenView le

garantiza resultados inmediatos en términos de productividad y ahorro en
costos.
• El conjunto de soluciones HP OpenView permite a las empresas de
telecomunicaciones optimizar la experiencia de sus clientes finales y entregar
un servicio lleno de satisfacción.
• HP OpenView, garantiza la administración, disponibilidad, operación y
completa confiabilidad de una estructura IT, en tiempo real.
• Las soluciones de HP OpenView, ofrecen soluciones integradas que duran el
ciclo entero de vida de los servicios, lo cual se traduce en el logro del éxito para
las empresas que lo utilizan.
2.2 HP OPENVIEW NETWORK NODE MANAGER

NNM es un software de gestión destinado a la administración de redes

distribuidas. Permite analizar, mediante visualizaciones en formato gráfico e
intuitivo, los dispositivos y el estado de la red en todo momento. Accesible
desde cualquier punto a través de consola Java, permite la realización de una
gestión proactiva con análisis de tendencias, informes de gestión, etc.

NNM tiene como finalidad realizar el descubrimiento de los equipos de red

definidos en su alcance, monitorear en tiempo real el estado de cada uno de
sus elementos, y administrar a través del protocolo SNMP, las diferentes
métricas y eventos que permiten determinar el comportamiento de la red.

Sus características principales son:

• Autodescubrimiento de la red
• Visualización topológica de la red descubierta
• Interfaz grafico de usuario (GUI)
• Gestión de eventos
• Servicio de correlación de eventos
• Actualización automática de estados en el mapa
• Colecciones de datos SNMP
• Visualización grafica de datos SNMP
• Herramientas de gestión de fallos
• Datawarehouse
• Consolas de gestión
• Interfaz Web de usuario
2.2.1 PRODUCTOS BASE DE NETWORK NODE MANAGER

HP OpenView posee dos Ediciones de NNM las cuales son:

• Network Node Manager Starter Edition para pequeñas redes con

ruteadores y hubs, y
• Network Node Manager Advanced Edition para redes conmutadas
complejas medianas o grandes. Advanced Edition combina Network
Node Manager con recursos de topología extendida y diagnostico de
problemas en un solo producto. En la Tabla 2.1. se muestran sus
diferencias, y en la Figura 2.1 Se muestra algunas soluciones y
productos de HP OV para cada Edición.

CAPACIDADES NNM Starter NNM Advanced

Edition Edition
Descubrimiento, poleo, eventos, SI SI
colección de datos, reportes
Descubrimiento de capa 3 SI SI
Descubrimiento de capa 2 NO SI
OSPF, HSRP, IPv6 NO SI (via Advanced
Routing SPI)
Telefonía IP, Frame Relay NO SI (SPI adicional)
Filtro de eventos SI SI
Correlación de Eventos SI SI (SPI y APA)
Fallos Adyacentes NO SI
Diagnostico inteligente de la red NO SI
Reportes SI SI
Overlapping Address Domains NO SI
Home Base GUI SI SI
Vistas dinámicas SI, capa 3 SI, capa 3 y capa 2
Windows, Solaris, HP-UX, Linux SI SI
TABLA 2.1. DIFERENCIAS ENTRE NNM STARTED EDITION Y NNM ADVANCED EDITION
 FIGURA 2.1. SOLUCIONES Y PRODUCTOS DE HP OPENVIEW

2.3 ANÁLISIS DE LA HERRAMIENTA HP OPENVIEW

NETWORK NODE MANAGER ADVANCE EDITION EN
BASE A LOS REQUERIMIENTOS Y NECESIDADES DE
ECUANET S.A.

La herramienta NNM AE v7.53 fue adquirida por Ecuanet previo al desarrollo

del SGM, lo cual ha sido un limitante debido a la gran variedad de plataformas
de gestión existentes en el mercado.

Es por eso que se hará un análisis entre las plataformas más importantes y se
definirá si Ecuanet acertó en su elección y si esta cumple las expectativas
dentro del SGM desarrollado para los requerimientos de Ecuanet.

En la Tabla 2.2 se muestra la comparación de las siguientes plataformas

What´s Up Gold versión 12, OPManager, NNM, Nagios, Zenoss, Lorito Pro, y
en la Figura 2.2 se muestra los costos de las plataformas de monitoreo.
Al realizar este análisis se comprueba que NNM es una poderosa y robusta
herramienta de monitoreo que supera en gran medida a las plataformas de
gestión que fueron comparadas. También es adecuada para los requerimientos
y necesidades de la empresa Ecuanet. Sin embargo, se encontraron dos
desventajas las cuales son:

• Se necesitan módulos adicionales para cuando se desee manejar

mayor información, tal como un escritorio de reportes, alarmas de
tecnología Frame Relay, MPLS, Telefonía IP. Estos módulos tienen
un costo adicional ya que estos son independientes. Sin embargo, a
Ecuanet le permite manejar el flujo de capital de acuerdo a las
necesidades e ir adquiriendo los módulos adicionales paulatinamente.

• Existe vulnerabilidades que podrían ser explotadas por atacantes

remotos.
Para solucionar las vulnerabilidades de seguridad HP OV posee
parches que se pueden instalar en las diferentes versiones de NNM.
En la Tabla 2.3 se muestran los parches que se requieren en la
versión 7.53 y se los puede descargar del servidor FTP de HP que es:
ftp://hprc.external.hp.com/

SISTEMA PARCHE ARCHIVO

OPERATIVO REQUERIDO
HP-UX (IA) PHSS_39246 SSRT090008.QCCR1B26779.753_IP22_rev1.hotfix.tar
HP-UX (PA) PHSS_39245 SSRT090008.QCCR1B26779.753_IP22_rev1.hotfix.tar
Linux LXOV_00093 SSRT090008.QCCR1B26779.753_IP22_rev1.hotfix.tar
RedHatAS2.1
Linux LXOV_00094 SSRT090008.QCCR1B26779.753_IP22_rev1.hotfix.tar
RedHat4AS-
x86_64
Solaris PSOV_03519 SSRT090008.QCCR1B26779.753_IP22_rev1.hotfix.tar
Windows NNM_01197 SSRT090008.QCCR1B26779.753_IP22_rev1.hotfix.tar

TABLA 2.3. PARCHES PARA VULNERABILIDADES DE NNM V7.53

 COSTOS SOFTWARE DE MONITOREO
$ 399.600,00
$ 450.000,00
$ 400.000,00
$ 350.000,00
$ 300.000,00
$ 250.000,00
$ 200.000,00
Costo Total
$ 150.000,00
$ 45.000,00
$ 100.000,00
$ 10.995,00 $ 9.594,00 $ 27.898,60 $ 0,00
$ 50.000,00
$ 0,00

V IEW
NO D E
NA G IO S
Z ENO S S

G O LD
HP O PEN
MA NA G ER
NETW O R K

W HA TS UP
V ER S IO N 12
LO R IO T P R O

O PMA NA G ER
Después de realizar el análisis se puede concluir que la herramienta Network
Node Manager Advanced Edition cumple con los requerimientos de Ecuanet y
facilitará retos más complicados de la gestión de redes lo que le hace un pilar
clave dentro del SGM desarrollado debido a las siguientes ventajas:

• Sistema de monitoreo proactivo.

• Permite entregar estadísticas a clientes finales.
• Constituye una herramienta robusta para clientes Corporativos y VIP de
la empresa Ecuanet.
• Apoyará la gestión comercial al entregar datos de consumos.
• Reducción de notas de crédito por falta de proactividad.
• Cumplimiento de SLA al permitir una detección más rápida de
problemas.
• Representa una ventaja competitiva al mostrar una herramienta robusta
de monitoreo.
• Proporciona una ponderosa solución de administración de redes que se
ocupa de los problemas antes de que se vuelvan críticos.
• Permite administrar su red mediante la detección y el mapeo
automáticos de redes Ethernet TCP/IP heterogéneas y redes
conmutadas complejas.
• Ayuda a comprender el estado de funcionamiento de los dispositivos de
red y activa vistas dirigidas para una rápida resolución de problemas.
• Permite administrar los problemas antes de que se vuelvan críticos con
el recurso Inteligent Diagnostics for Networks.
• Monitorea proactivamente la salud del dispositivo y mide el flujo de
tráfico.
• Genera rápidamente alarmas con base en actividad predecible y crítica
para la empresa

Además se cumple con los procesos dentro del Modelo TMN y TOM ya que
permite reducir el TCO y el tiempo de reparación de problemas en la red.
2.3.1 REDUCIR EL TCO (TOTAL COST OF OWNERSHIP)

• Fácil de usar
• Asegurar la red
• Realizar la contabilización de nodos y recursos
• Centralizar el reporte y control
• Reducir el TT (Time on Task) para los gestores de red
• Reducción de notas de crédito

2.3.2 REDUCIR EL TIEMPO DE REPARACIÓN DE PROBLEMAS EN LA

RED

• Proporcionando un rendimiento consistente y confiable de la red y

sus servicios
• Reduciendo los tiempos de caída (Downtime)
• Detección rápida, Aislamiento y Corrección de Problemas
• Anticiparse a los problemas y demandas
• Almacenar, de forma inteligente, información para diagnósticos
• Análisis de tendencias

El centro de operaciones de red (NOC) al integrar la herramienta NNM

permitirá comprender la red, sus relaciones y dependencias de los Modelos
TMN y TOM que adapta los servicios de red y empresariales.

Lo que se quiere es una forma de simplificar la administración de esas

relaciones complejas para actuar proactivamente cumpliendo con el servicio
ofertado y obtener un retorno de la inversión.
2.4 PLAN DE TRABAJO REFERENTE AL SGM

2.4.1 ACTUALIZACIÓN DE DIAGRAMAS DE RED

Es necesario que los diagramas de red de los nodos del backbone de Ecuanet
a nivel Nacional estén actualizados, para que al momento de realizar los
mapas en el NNM se lo haga sin errores. Este procedimiento se lo debe hacer
continuamente tanto en los enlaces nuevos, en cambios de enlaces existentes,
y en los enlaces que han sido eliminados; estos cambios se los deben notificar
al administrador del Sistema de Gestión regularmente, para un eficiente
rendimiento del SGM.

Los Diagramas de Red de Backbone y Nodos se encuentran publicados en la

Red Interna de Ecuanet.

2.4.2 LEVANTAMIENTO DE INFORMACIÓN DE LOS NODOS

PRINCIPALES DE LA RED BACKBONE DE ECUANET A NIVEL
NACIONAL.

Siguiendo el Plan de Trabajo desarrollado en el SGM se realizó un

levantamiento de información de los Nodos de la RBE, esta información se
utilizará para la configuración de la herramienta.

La RBE se encuentra divida en dos regiones llamadas R1 y R2. La región R1

comprende las siguientes ciudades: Ibarra, El Coca, Riobamba, Ambato, Santo
Domingo, Loja, Macas y Azogues. La región R2 comprende las siguientes
ciudades: Portoviejo, Manta, Salinas, Babahoyo, Galápagos y Machala.

Se realizó una depuración de los equipos ubicados a nivel nacional de los

cuales se mencionarán el nombre de los nodos pero no las direcciones IP por
privacidad que mantiene Ecuanet.
La información recopilada se la obtuvo ingresando al equipo mediante Telnet.

Para la configuración del NNM se utilizará únicamente la comunidad de lectura

SNMP debido a previsiones de seguridad.
Se revisó el nombre de la comunidad SNMP en cada dispositivo y se encontró
que en algunos de ellos no se había configurado la comunidad SNMP, por lo
que se procedió a configurarla.

A continuación en la Tabla 2.4 se muestra un fragmento del archivo que dio

como resultado el levantamiento de esta información.

NODO EQUIPO NOMBRE COMUNIDAD IP

FUNDACION c2950FE-24P MEGA-FUNUIO-9 megadatos 69.65.135.9
c2950LRE- MEGA-FUNUIO- megadatos 69.65.135.10
24P 10
c2950LRE- MEGA-FUNUIO- megadatos 69.65.135.20
24P 20
c2950LRE- MEGA-FUNUIO- megadatos 157.100.41.37
24P 41.37
CE500 MEGA-WTCUIO- megadatos 157.100.41.35
35
TABLA 2.4. INFORMACIÓN DE LOS NODOS QUE SERÁN MONITOREADOS

2.4.3 ARCHIVOS MIB DE LOS EQUIPOS CISCO, LUCENT, ALVARIUM

Es necesario tener los archivos MIB de los equipos que serán monitoreados
para poder cargarlos en el NNM. Estos archivos se los puede encontrar en el
servidor de gestión en el siguiente path: E:\Program Files\HP
OpenView\snmp_mibs\Vendor, como se muestra en la Figura 2.4.
 FIGURA 2.4.ARCHIVOS MIB DE LOS DIFERENTES DISPOSITIVOS A MONITOREAR

2.4.4 CONFIGURACION DE LA COMUNIDAD SNMP Y HABILITACIÓN DE

TRAPS SNMP EN LOS ELEMENTOS DE LA RBE

Se encontró que en ciertos equipos no se había configurado la comunidad

SNMP y tampoco estaba configurado el envío de traps al servidor de gestión.

A continuación se muestra un ejemplo de cómo configurar la comunidad SNMP

de lectura y la habilitación de Traps SNMP basados en un archivo de Cisco que
se encontrará en el Anexo 2.

Ejemplo de Habilitación de Traps en los Dispositivos de Red a ser

monitoreados.

• Comunidad de lectura: megadatos

• Grupo: backbone
• Usuario: monitoreo
 • Versión: SNMP versión 2c
• NMS: 157.100.40.251
• Equipo: 157.100.40.17

Los tipos de traps a configurarse dependerán de los eventos que se desea

recibir de cada equipo. A continuación se muestran los tipos de traps que
pueden ser habilitados; de estos se debe tomar los que son los mas
importantes y necesarios. Por ejemplo si un equipo maneja Enrutamiento BGP,
pues se habilitará este trap; caso contrario, no es necesario. Se debe tener
cuidado con la habilitación de traps ya que se puede saturar al Servidor de
Gestión. En el Anexo 3 se muestran los tipos de traps que pueden ser
habilitados.
La habilitación de traps se lo hará de acuerdo al tipo de notificaciones que se
deseará recibir. A continuación se muestra, en la Tabla 2.5, algunos Traps
importantes que fueron habilitados en el quipo CORE-NODOAMB-3.
 TABLA 2.5.TRAPS HABILITADOS PARA EL EQUIPO CORE-NODOAMB-3

2.4.5 POLÍTICAS DE INTERFACES LIBRES

NNM en el descubrimiento automático absorbe las interfaces de los equipos

que se están monitoreando; sin embargo cuando encuentra interfaces que no
están conectadas las reporta como alarmadas, por lo que se ha establecido
una Política de Interfaces Libres que se muestra en la Tabla 2.6. Esta política
se aplicará a todos los equipos en la RBE, lo cual ayudará a tener un mejor
control de las interfaces, un mayor desempeño en la herramienta NNM y de
esta manera no tener alarmas falsas.

Configuración Razón
Descripción: LIBRE Se aplicará cuando una interfaz este:
Estado: Shutdown • Sin utilizarse
• Cuando se liberan recursos
Descripción: PRUEBA Se aplicará cuando una interfaz sea:
Estado: Shutdown • Utilizada para pruebas y no se
asignara a clientes.

Descripción: PRUEBA Se aplicará cuando una interfaz que

Estado: No Shutdown sea de pruebas se esté utilizando.

Descripción: Se aplicará cuando una interfaz:

REVISAR/DAÑADA • Presente falencias en su
Estado: Shutdown funcionamiento.
• Este dañada
TABLA 2.6. POLÍTICAS DE INTERFACES LIBRES
2.4.6 HABILITACIÓN DE PUERTOS

Se deberán abrir los puertos o servicios necesarios para poder realizar la

implementación de las herramientas y contar con toda la infraestructura de red
y comunicaciones LAN/WAN. No se abrirá el puerto 161 y 162 en el Firewall de
Ecuanet ya que el NMS no pasará por este.

NNM utiliza los puertos que se describen en la Tabla 2.7, y se los puede
encontrar ejecutando el siguiente comando: netstat –b

7510 ovhpas 7510/tcp HP OpenView Application Server

ovhpas 7510/udp HP OpenView Application Server
2953 ovalarmsrv 2953/tcp OVALARMSRV
ovalarmsrv 2953/udp OVALARMSRV
80 http 80/tcp World Wide Web HTTP
http 80/udp World Wide Web HTTP
www 80/tcp World Wide Web HTTP
www 80/udp World Wide Web HTTP
www-http 80/tcp World Wide Web HTTP
www-http 80/udp World Wide Web HTTP
2954 ovalarmsrv-cmd 2954/tcp OVALARMSRV-CMD
ovalarmsrv-cmd 2954/udp OVALARMSRV-CMD
TABLA 2.7. DESCRIPCIÓN DE PUERTOS PARA NNM

2.5 ARQUITECTURA DEL SERVIDOR DE GESTIÓN

El ambiente donde se instalará NNM debe ser el adecuado y correctamente

dimensionado para la carga de información que se manejará, es por eso que
los requerimientos del sistema tanto de hardware como de software son muy
importantes. Para el SGM que va a manejar Ecuanet adquirió la herramienta de
gestión HP OpenView Network Node Manager Advanced Edition 250 Node
Pack 7.53 Windows;
Los requerimientos mínimos de Hardware para la versión de NNM con una
licencia para 250 Nodos se los puede encontrar en el archivo readme.html que
está en los discos de instalación, o se puede remitir al documento Hardware
and Software Minimum Requirements en E:\Program Files\hp openview\
www\htdocs\C\ReleaseNotes.html.

En la Tabla 2.8 se muestra la infraestructura mínima para el servidor que

soporta la solución para una consola de gestión.

Sistema Operativo Microsoft® Windows: Server 2000, XP Professional, Server

2003, or Server 2003 R2
Procesador Intel® Pentium processor, 333 MHz or greater
Memoria 1 GB RAM
Disco Duro 400 MB plus 512 MB free paging file space
Monitor 800x600 monitor with SVGA graphics card
Conexión de Red TCP/IP networking installed and configured
Network adapter card
TABLA 2.8. ARQUITECTURA DEL NMS PARA UNA CONSOLA

Ecuanet posee una gran infraestructura de red a nivel nacional que será
monitoreada por el NOC desde diferentes consolas de gestión; es por eso que
se ha dimensionado el servidor como se muestra en la Tabla 2.9 para 5
consolas de gestión.

Sistema Microsoft Windows Server 2003 Enterprise Edition

Operativo
Procesador Intel Xeon E5420 Passive Socket 771 QuadCore 2.5
GHz
Memoria 6 GB RAM
Disco Duro 3x72 GB
Conexión de Red 2 puertos TCP/IP
Ancho de Banda 1000 Mbps
TABLA 2.9. ARQUITECTURA DEL NMS PARA CINCO CONSOLA.
En la instalación del SO se realizó dos particiones, una partición de Disco E: en
la cual se instalará el producto HP OpenView Network Node Manager for
Windows v7.53 y una partición de Disco C: para el manejo de la información de
Gestión.

Al NMS se le asigno la dirección IP: 157.100.40.251, la cual no pasa por el

Firewall de la Red Interna de Ecuanet, y desde este se acceden a todos los
equipos de la RBE (CISCO, Psax, Alvarion, etc.).

Las Figura 2.5 y 2.6 muestran las propiedades del sistema del servidor de
gestión

FIGURA 2.5. PROPIEDADES DEL SISTEMA DEL NMS

FIGURA 2.6 NOMBRE DEL NMS

2.6 INSTALACIÓN DE LA HERRAMIENTA NETWORK NODE
MANAGER ADVANCE EDITION V7.53

2.6.1 PRERREQUISITOS PARA LA INSTALACIÓN

Antes de instalar Network Node Manager Advanced Edition v7.53 se deben

cumplir los siguientes prerrequisitos.

• Servicio TCP/IP
• Agente SNMP
• Internet Information Service (Web Server)
• Microsoft Terminal Services
• Instalación de un Web Browser
• Debe tener configurado un DNS (Domain Name System). Este punto no
se pudo cumplir por razones de seguridad, por lo que se usará un
archivo Host como esquema de resolución de nombres.

Estos prerrequisitos se configuraron durante la instalación del SO, pero en caso

de que no se lo haya hecho, a continuación se muestra la manera de
configurarlos:

2.6.1.1 Servicio TCP/IP

Para instalar servicios TCP/IP se debe seguir los siguientes pasos:

• Abrir el Control Panel

• Seleccionar Network Connections
• Hacer Clic derecho en Local Area Connection
• Elegir propiedades, si en la lista no aparece seleccionado (TCP/IP) se
debe instalar:
 o Clic Install
o Se selecciona Protocol
o Clic Add
o Se selecciona Internet Protocol (TCP/IP)
o Click OK
o Se inserta el DVD de Instalación del SO
o Click OK

• Verificar que esté instalado e ingresar una dirección IP, Mascara de

Subred, Puerta de enlace, y DNS validos.

2.6.1.2 Agente SNMP

Para instalar el agente SNMP se debe seguir los siguientes pasos:

• Abrimos el Control Panel
• Click en Add/Remove Programs
• Se selecciona Windows Components
• Se selecciona Management and Monitoring Tools
• Click en Details como se muestra en la Figura 2.7.1

FIGURA 2.7.1. ACTIVACIÓN DEL AGENTE SNMP

• Se selecciona Simple Network Management Protocol, como se muestra
en la Figura 2.7.2
• Clic OK
• Clic Next
• Se inserta el DVD de instalación del SO
• Clic OK , y empieza a configurar los componentes hasta que termine

FIGURA 2.7.2. ACTIVACIÓN DEL AGENTE SNMP

• Se deben revisar las comunidades configuradas, esto se puede hacer

dentro de la ventana de servicios del manejador de tareas.

o Clic derecho sobre el servicio SNMP Service como se muestra en

la Figura 2.7.3.
o Seleccionar Propiedades, donde se despliega una nueva ventana
o Las comunidades se configuran dentro del tab Security.
 Figura 2.7.3. Activación del Agente SNMP

2.6.1.3 Internet Information Service (Web Server)

El IIS se lo debe instalar de la siguiente manera:

• Abrir el Control Panel

• Clic Add/Remove Programs
• Clic Windows Components
• Seleccionar Internet Information Services
• Insertar el DVD de instalación del SO
• Clic OK y esperar mientras se configuran los componentes

Luego de haber instalado el IIS se debe iniciarlo de la siguiente manera:

• Abrir el Control Panel

• Clic en Administrative Tools
• Click en the Internet Information Services Manager
• Seleccionar Default Web Site
• Desde el Menú de IIS Manager, click Action → Start
2.6.1.4 Microsoft Terminal Services

Para instalar el Terminal Service se debe seguir los siguientes pasos:

• Abrir el Control Panel
• Click en Add/Remove Programs
• Clic en Windows Components
• Seleccionar Terminal Server Services
• Click OK

2.6.1.5 Instalación de un Web Browser

Se instaló Internet Explorer 6.0.3790.0 y Mozilla Firefox 3

2.6.2 INSTALACIÓN DE HP OPENVIEW NETWORK NODE MANAGER

FOR WINDOWS V7.53

El proceso de instalación de la herramienta HP OV NNM se encuentra

referenciado en el manual Installation Guide, y los pasos puntuales se
presentan a continuación:

o El CD de instalación fue copiado totalmente en el servidor en

E:\Instaladores\Instaladores Productos Gestión\NNM\CD1.

o Posteriormente se ejecutó la aplicación setup, para dar inicio al

Install Shield Wizard. En la pantalla inicial se muestra que es
NNM v7.53, como se observa en la Figura 2.8.1; sin embargo,
mientras procede la instalación muestra NNM v 7.50
FIGURA 2.8.1. PANTALLA INICIAL DE LA INSTALACIÓN DE NNM V7.53

o Inmediatamente se inició el Install Shield Wizard como se muestra

en la Figura 2.8.2.

FIGURA 2.8.2. INSTALACIÓN DE NNM AE V7.53

• Aparece una ventana con los términos de la licencia, por defecto NNM
es instalado como una versión trial de 60 días, después de coloca el
numero de la licencia adquirida por Ecuanet, como se muestra en la
Figura 2.8.3
 FIGURA 2.8.3. INSTALACIÓN DE NNM AE V7.53

• Después se debe ingresar el nombre con el que se va instalar el

software y la compañía a la cual pertenece.

• Se escoge el tipo de instalación que se quiere realizar, para lo cual se

debe escoger customizada (custom) ya que está es la única opción
donde permite deshabilitar el autodescubrimiento de la herramienta una
vez está termine de ser instalada.

Esto se hace porque por lo general siempre se quiere hacer un

descubrimiento limitado y controlado. En la Figura 2.8.4 se muestra la
pantalla

FIGURA 2.8.4.INSTALACIÓN DE NNM AE V7.53

• Para el caso de ECUANET se usó la ruta E:\Program Files\HP
OpenView, como se muestra en la Figura 2.8.5 Si está ruta no existe
debe aparecer una advertencia en la cual se indica que se va crear la
ruta que no existe.

FIGURA 2.8.5.INSTALACIÓN DE NNM AE V7.53

• En esta opción se deshabilita el autodescubrimiento como se muestra en

la Figura 2.8.6, para después utilizar archivos como filtros o hosts para
hacer cargas masivas según como más convenga.
Si se desea este autodescubrimiento puede ser vuelto a habilitar una
vez se instalé la herramienta, si así se desea.

FIGURA 2.8.6.INSTALACIÓN DE NNM AE V7.53

• Se muestra una ventana donde sale el resumen de lo que se va instalar
como muestra en la Figura 2.8.7.

FIGURA 2.8.7.INSTALACIÓN DE NNM AE V7.53

• Después arranca la instalación del producto en el cual muestra el

porcentaje que se ha instalado. Cuando se llega al 97% de la instalación
pide el segundo disco de instalación como se muestra en la Figura 2.8.8.

FIGURA 2.8.8.INSTALACIÓN DE NNM AE V7.53

• Una vez que se inserta el disco se hace clic en OK. La instalación sigue
normalmente hasta que aparece una ventana en la que se indica que se
ha finalizado como se muestra en la Figura 2.8.9.

FIGURA 2.8.9.INSTALACIÓN DE NNM AE V7.53

• Para la instalación de NNMv7.53 es necesario primero tener instalado

NNMv7.5 que constituye la plataforma de NNM, después se instalará la
versión 7.53 que es la versión que utilizará Ecuanet, como se describe a
continuación, el fabricante recomienda que una vez que se instale
NNM7.5 no se debe ingresar al aplicativo de NNM 7.53, se debe bajar
los servicios ejecutando el siguiente comando: ovstop –c.

• Insertar el CD de instalación de NNMv7.53. Si la instalación no inicia

inmediatamente, ejecutar el setup.exe desde el CD. En el Wizard que es
desplegado seleccionar Silent Installation (este instala todos los parches
necesarios para hacer la actualización de NNM 7.5) como se muestra en
la Figura 2.8.10.
 FIGURA 2.8.10.INSTALACIÓN DE NNM AE V7.53

o En la siguiente ventana se pregunta si se tiene una licencia para

“Advanced Routing”. En el caso de ECUANET esta no se tiene
por lo cual se debe seleccionar “no” como se muestra en la figura
2.8.11.

FIGURA 2.8.11.INSTALACIÓN DE NNM AE V7.53

o Ahora empieza la instalación de los diferentes parches como se

muestra en las figuras 2.8.12, 2.8.13, 2.8.14
 FIGURA 2.8.12.INSTALACIÓN DE NNM AE V7.53

FIGURA 2.8.13.INSTALACIÓN DE NNM AE V7.53

FIGURA 2.8.14.INSTALACIÓN DE NNM AE V7.53

o En la siguiente ventana se muestra el resumen de las

instalaciones que se realizaron (Figura 2.8.15.).
 FIGURA 2.8.15.INSTALACIÓN DE NNM AE V7.53

o Una vez hecho esto se termina con la instalación de la

actualización de NNM v7.53.

2.6.3 INSTALACIÓN DE PATCHES

Adicionalmente a la instalación del producto, también se realizó la instalación

de dos parches disponibles para versión de HPOV NNM instalada en
ECUANET

Los instaladores de estos parches están disponibles en C:\Parches_NNM en el

NMS

2.7 CONFIGURACIÓN DE LA HERRAMIENTA NETWORK

NODE MANAGER ADVANCE EDITION V7.53

2.7.1 INICIAR LOS SERVCIOS DE NNM (BACKGROUND PROCESSES)

NNM empieza a colectar datos y revisar actividad con la que se puede

empezar a personalizar la herramienta tan pronto como se inicien los servicios.
 • Para iniciar los servicios se puede hacer de la siguiente manera:
o Seleccionar Start:Programs:HP OpenView:
Network Node Manager Admin->NNM Services - Start.
o Ejecutar el siguiente comando: ovstart –v

• Para asegurarse que los servicios estén corriendo satisfactoriamente se

puede hacerlo de la siguiente manera:
o Seleccionar Start:Programs:HP OpenView:
Network Node Manager Admin->NNM Services - Status.
o Ejecutar el siguiente comando: ovstatus –c

• Para parar los servicios se puede hacerlo de la siguiente manera:

o Seleccionar Start:Programs:HP OpenView:
Network Node Manager Admin->NNM Services - Stop
o Ejecutar el siguiente comando: ovstop –c

2.7.2 ABRIENDO NNM (FOREGROUND PROCESSES)

La primera vez que se abra NNM tomará algunos minutos mientras los mapas
son sincronizados con las bases de datos. Para abrir NNM se lo puede hacer
de la siguiente manera:
• Seleccionar Start: Programs:HP OpenView:Network Node Manager.
• Ejecutar el siguiente comando: ovw
En NNM se puede utilizar dos clases de vistas:

2.7.2.1 Vista Clásica o de Contenedores

La vista clásica muestra la jerarquía de los mapas y se puede observar las

alarmas de manera visual, esta vista será la que se utilice por el NOC para
el monitoreo de primer nivel como se muestra en la Figura 2.9.
 FIGURA 2.9. VISTA CLÁSICA DE NNM

Los mapas de la RBE se crean jerárquicamente tal como se indica en la

Figura 2.10

FIGURA 2.10 PERSISTENCIA DE MAPAS

2.7.2.1.1 Submapa de Internet:

Redes IP, gateways, routers.

2.7.2.1.2 Submapa de Red:

Segmentos tipo bus, estrella, anillo; switches, hubs, y bridges.

2.7.2.1.3 Submapa de Segmento:

Hosts, gateways, routers, switches, hubs, y bridges.

2.7.2.1.4 Submapa de Nodos:

Tarjetas de Interface de Red

2.7.2.2 Vistas Dinámicas

Las vistas dinámicas de NNM se muestra a través del Home Base al que se lo
puede acceder de la siguiente manera:

• Seleccionar Start:Programs:HP OpenView:Network Node Manager

Home Base
• Mediante consola Web con el siguiente URL
o http://157.100.40.251:7510

NNM Home Base presenta un ambiente amigable y fácil de usar para los
operadores, que gracias a las vistas dinámicas permitirá filtrar información que
ayudará a un troubleshooting más eficiente. Las vistas dinámicas que posee el
Home base se muestra en la Figura 2.11.
 FIGURA 2.11. NNM HOME BASE.

2.7.3 AUTODESCUBRIMIENTO DE LA RED

El objetivo del proceso de autodescubrimiento es realizar el descubrimiento de

cada uno de los nodos que conforman la RBE.

El descubrimiento se hizo por medio de un archivo de Hosts por las siguientes

razones:
• El número de equipos era muy variado y no seguían un patrón al cual se
le pudiera aplicar una regla de filtro.
• Existen equipos dentro de la red que no se quieren monitorear (Red
Interna, Impresoras).
• El número de licencias es limitado a 250.
• Por Políticas de Seguridad Ecuanet prefirió no utilizar el DNS para el
descubrimiento.

El archivo de Hosts se encuentra ubicado en

C:\WINDOWS\system32\drivers\etc. En este archivo se agregaran los equipos
que serán monitoreados. El formato del archivo utilizado es el siguiente:
<IP Address> <Nombre del elemento de red>
Para cargar los nodos a NNM se ejecuta el siguiente comando:
loadhosts –v <nombre del archivo con la lista de nodos>

2.7.3.1 Configuración de la Topología Extendida

Para empezar un descubrimiento de la red se lo hace la siguiente manera:

• Desde NNM:
Options → Extended Topology Configuration
• Desde el Home Base:
Discovery Status →Extended Topology Configuration

Se ha configurado que NNM realice un descubrimiento automático a las 12:00

am lo que ayudará a que se actualicen los cambios, reconozca nuevos nodos
que se han agregado, verifique si los NE están respondiendo a la comunidad
SNMP, etc.

2.7.4 CARGA DE ARCHIVOS MIB

Para la configuración de NNM en ECUANET se cargaron las MIBs como se

muestra en la Figura 2.12. Estas MIBs incluyen Cisco, Psax y Standard para
Frame Relay.

Para cargar y probar un archivo MIB se debe seguir el siguiente procedimiento:

• Ingresar a la vista clásica de NNM
• Seleccionar Options
• Clic en Load
 FIGURA 2.12.1 CARGA DE ARCHIVOS MIBS

• Se selecciona el archivo correspondiente a la MIB que se desea cargar.

• Clic en Load como se muestra en la Figura 2.12.2

FIGURA 2.12.2. CARGA DE ARCHIVOS MIBS

Para probar que el archivo MIB funciona correctamente se debe hacer uso de
la utilidad SNMP MIB Browser como se indica en la Figura 2.12.3.

FIGURA 2.12.3 CARGA DE ARCHIVOS MIBS

En la siguiente ventana se escribe el nombre o la IP de un nodo que utilice la
MIB que se quiere probar, (En el ejemplo se utilizó uno de los PSAX Lucent).

Se navega por el árbol hasta encontrar la rama de la MIB que se cargó y se da

clic a Start Query como se muestra en la Figura 2.12.4. En el cuadro de texto
inferior deben empezar a aparecer los valores de la MIB en el nodo. Si no
aparece nada es porque el equipo seleccionado no soporta la MIB cargada y se
debe buscar otra diferente que si soporte.

FIGURA 2.12.4 CARGA DE ARCHIVOS MIBS

2.7.5 CONFIGURACIÓN DE LAS COMUNIDADES SNMP

En el caso de ECUANET se utilizo la versión SNMPv2C (Community-based

SNMPv2) del protocolo simple de gestión de red. En relación con la
configuración SNMP, los parámetros modificados en NNM en el menú Options

SNMP Configuration, se muestran a continuación:
2.7.5.1 Global Default

La comunidad SNMP de lectura configurada por defecto para los equipos que
conforman la red de ECUANET es megadatos; sin embargo, existen equipos
con otras comunidades.

En Global Default es posible configurar cada cuanto se realiza el poleo de

estado que consiste en enviar un ping ICMP a cada interfaz de cada dispositivo
gestionado para verificar si todavía son accesibles por el servidor de gestión
(Status Polling: 15 minutos para ECUANET). También es posible configurar el
número de intentos de poleo para cada equipo (Retries: 2) y el tiempo durante
el cual espera respuesta antes de desistir (timeout: 0.8 segundos) como se ve
en la Figura 2.13.1.

FIGURA 2.13.1 CONFIGURACIÓN DE LA COMUNIDAD SNMP.

2.7.5.2 IP Wildcards

En esta opción se define la comunidad SNMP para grupos de nodos. En este

caso la comunidad de lectura para algunos de los nodos de ECUANET varia,
por lo que fue necesario configurar Wildcards como se muestra en la Figura
2.13.2.
 FIGURA 2.13.2 CONFIGURACIÓN DE LA COMUNIDAD SNMP.

2.7.5.3 Specific Nodes

En la Figura 2.13.3, se muestra la configuración SNMP realizada para nodos

específicos que no usan la comunidad por defecto ni ninguno de los wildcards.

FIGURA 2.13.3.CONFIGURACIÓN DE LA COMUNIDAD SNMP.

2.7.6 POLLING

En relación con la configuración de polling los parámetros pueden ser

modificados:
 • En NNM el archivo de configuración paConfig.xml ubicado en la ruta
E:\Program Files\HP OpenView\conf\nnmet

• En la ventana de SNMP Configuration también es posible realizar la

configuración de poleo de nodos como switches pertenecientes a un
grupo especificado en un filtro, mediante el botón Poll Objects que se
encuentra en la parte inferior dentro de cualquiera de las opciones de
configuración SNMP ilustradas anteriormente.

2.7.7 INDICADORES DE GESTIÓN

Los indicadores de gestión se dividen en eventos y métricas, los cuales se

describen a continuación.

2.7.7.1 Métricas

Las métricas permiten la generación de estadísticas para el análisis de

tendencias sobre determinadas variables de medición como pueden ser CPU,
memoria y ancho de banda.

Las métricas recolectan valores y los comparan con los umbrales, en el caso
que esté fuera del rango normal de funcionamiento se generan eventos si así
se ha configurado.

La configuración de las métricas es realizada sobre el menú Options
Data

Collection & Threshold: SNMPcomo se muestra en la Figura 2.14. En la Tabla
2.10.1 y 2.10.2, se muestra algunos ejemplos de las métricas configuradas.
 FIGURA 2.14.CONFIGURACIÓN DE MÉTRICAS

CAMPO DETALLE
Número de Recolección 1
Nodo o Target Solo Routers.
Métrica a Recolectar ifSpeed
Mib Object ID. .1.3.6.1.2.1.2.2.1.5
Instancias. Todas las instancias.
Intervalo de Recolección. 30 días.
¿Genera evento? S/N N
Umbral.
Umbral de Restablecimiento.
No de Evento a Generar. No genera evento.
TABLA 2.10.1. MÉTRICAS CONFIGURADAS
CAMPO DETALLE
Número de Recolección 8
Nodo o Target Memoria libre Cisco
Métrica a Recolectar Utilización de Interfaz
Mib Object ID. .1.3.6.1.4.1.9.2.1.8.
Instancias. Interfaces Activas
Intervalo de Recolección. 12h
¿Genera evento? S/N S
Umbral. >60%
Umbral de Restablecimiento. <30%
No de Evento a Generar. 113
TABLA 2.10.2. MÉTRICAS CONFIGURADAS

2.7.7.2 Eventos

La labor de configurar eventos (Options
Event Configuration) es un proceso

que se debe realizar en la medida de la recepción de nuevos o diferentes
eventos en el Alarm Browser como se muestra en la Figura 2.15.1.

FIGURA 2.15.1.CONFIGURACIÓN DE EVENTOS.

Se abre la ventana de configuración de eventos. En el cuadro de texto superior

se encuentran las categorías de eventos, que son grupos de eventos que
tienen alguna relación, por ejemplo, se ve una categoría de alarmas de OSPF,
de RMON, Openview, como se puede observar en la Figura 2.15.2
 FIGURA 2.15.2.CONFIGURACIÓN DE EVENTOS.

Al seleccionar una categoría en el cuadro de texto inferior se verán los eventos

correspondientes. Para editar un evento se hace doble clic en el evento y se
abre la ventana de configuración que se muestra en la Figura 2.15.3.

Existen varios Tabs en los cuales se podrán hacer configuraciones. Se

explicarán los más importantes:

FIGURA 2.15.3.CONFIGURACIÓN DE EVENTOS.

En la Figura 2.15.4 se configuró el texto del mensaje así como la categoría a la
cual será asignado el evento.

En este caso el mensaje dice Node Down $10 Capabilities $15. El $10 y $15
representan variables que trae el evento de tal manera que se pueda tener una
información más precisa acerca del mismo.

Para el caso de los eventos de la categoría OpenView en el primer tab de

configuraciones se puede ver una descripción del evento, esta descripción
incluye una lista de las variables que se pueden utilizar.

FIGURA 2.15.4.CONFIGURACIÓN DE EVENTOS

En la Tabla 2.11 se muestra un ejemplo de los eventos configurados que se

relacionan con los equipos Cisco.
CAMPO DETALLE
Se recibirá de todos los nodos
Numero Evento 1
Nombre Trap. Node Down
Object ID. .1.3.6.1.4.1.11.2.17.1
Número TRAP 58916865
Descripción Nodo Abajo: Causa raíz **
Severidad Critical.
Categoría Status Alarms
Objeto Tipo de Elemento Comunicaciones.
Nodo <Nombre_Nodo>
Texto del Mensaje Nodo Abajo. Causa principal: $9 $10
Acción a ejecutar Auto Enviar correo
Instrucciones.
TABLA 2.11.EVENTO CONFIGURADO EN LOS EQUIPOS CISCO.

2.7.7.3 Notificaciones

Las notificaciones se configuran como acciones automáticas al recibir un

evento, para esto es necesario definir las personas encargadas de recibir
dichas notificaciones. Para el envío de emails se debe tener configurado el
servicio SMTP en el servidor. En caso de que exista un servidor de correo MS
Exchange, puede usarse para este fin.

IP Servidor SMTP: 157.100.45.45

Nombre Servidor SMTP: mail.relay.accessram.net

La configuración de acciones automáticas como lo es el envío de notificaciones

hacia el correo se lo puede realizar a través de Options
Event Configuration
en el tab de Actions.
 • La línea completa de la acción para enviar notificaciones a un solo
destinatario como se ve en la Figura 2.16. es la siguiente:

cmd /c bmail.bat "[email protected]" [email protected]

"Node Down $10 Capabilities: $15" "Node Down $10"

FIGURA 2.16.NOTIFICACIONES DE EVENTO A UN SOLO DESTINATARIO.

• La línea completa de la acción para enviar notificaciones a múltiples

destinatarios como se muestra en la Figura 2.17 es la siguiente:

cmd /c E:\"Program Files"\"HP OpenView"\"bin"\"bmail.exe" -s 157.100.45.45 -to

"[email protected],[email protected],[email protected],nocui
[email protected]" -f [email protected] -b "IF Down $5 $10 $6
Capabilities: $15" -a "IF Down $5 $10 $6"

FIGURA 2.17.NOTIFICACIONES DE EVENTO A MULTIPLES DESTINATARIOS

La configuración relacionada con el formato de los eventos se encuentra en el
archivo “trapd.conf” ubicado en C:\Program Files\HP OpenView\conf \C. En
este archivo quedan consignados todos lo nuevos eventos que se hayan
agregado para de esta manera el proceso “trapd” sabe qué hacer con los
diferentes trapd” que recibe de los elementos de red.

2.7.8 MAPAS DE RED

El mapa default fue el mapa diseñado con base en las ciudades que
comprenden tanto la Región 1 como la Región 2 en las cuales se encuentra
dividido ECUANET como se muestra en la Tabla 2.12.

Región 1 Región 2
Riobamba Galápagos
Ambato Manta
Latacunga Portoviejo
Santo Domingo Salinas
Quito Guayaquil
Ibarra Babahoyo
Loja Milagro
Cuenca Machala
Azogues Quevedo
Macas
Puyo
El Coca
TABLA 2.12. CIUDADES DEL MAPA DEFAULT.

Cada ciudad fue construida a través de un símbolo tipo Location y dentro de

cada una se movieron los equipos asociados a ellas.
Para poder realizar este movimiento de nodos es necesario configurar que la
persistencia o jerarquía de los submapas se haga a todos los niveles, para eso
se ingresa Map
Properties
Applications, como se muestra en la Figura
2.18.1, 2.18.2, 2.18.3.

FIGURA 2.18.1. CONFIGURACIÓN DE LA PERSISTENCIA DE MAPAS

FIGURA 2.18.2. CONFIGURACIÓN DE LA PERSISTENCIA DE MAPAS

Figura 2.18.3. Configuración de la persistencia de mapas

El submapa Internet del Mapa General se muestra a continuación en la Figura
2.19.

FIGURA 2.19.SUBMAPA INTERNET DE LA RBE

Para la creación de cada uno de los símbolos tipo Location se debe seguir el
siguiente procedimiento Edit
Add Object, como se muestra en la Figura 2.20

FIGURA 2.20. CREACIÓN DE UN SÍMBOLO.

En la siguiente ventana se selecciona el Symbol Class llamado Location, luego

en el Symbol Subclass se arrastra el símbolo deseado al submapa donde se
quiere ubicar como se ilustra en la Figura 2.21.
 FIGURA 2.21. CLASES DE SÍMBOLOS

Luego de haber hecho esto se procede a definir el nombre del símbolo (Figura
2.22).

FIGURA 2.22. CONFIGURACIÓN DEL SÍMBOLO

2.7.9 SEGURIDAD

En este ítem se detalla la configuración realizada sobre HPOV NNM en relación

al esquema de seguridad implementado para:
• Consola Remota
• Acceso vía Web (HP OpenView Launcher),
• Acceso vía Web (Vistas dinámicas Home Base)

2.7.9.1 Consola Remota

Debido a que el servidor no se encuentra registrado en el dominio de Ecuanet

la funcionalidad de la consola remota no se pudo implementar. Como
alternativa se optó por permitir acceso vía Terminal Services al servidor de
NNM y se configuraron usuarios locales con permisos de acuerdo a su perfil
(Administrador, Operador).

Para el acceso a la herramienta HPOV NNM desde Terminal Services, se

configuraron los permisos sobre la herramienta en los archivos ubicados en la
siguiente ruta: E:\Program Files\HP OpenView\Registration_Oper para los
operadores y E:\Program Files\HP OpenView\registration para los
administradores. Para que un operador ingresé con sus permisos
correspondientes se debe configurar la variable de ambiente de la siguiente
manera: OVWRegDir = E:\Program Files\HP OpenView\Registration_Oper

2.7.9.2 Perfiles y Usuarios

Se configurarán dos perfiles para acceso a la herramienta, los cuales tendrán

sus respectivas funcionalidades:

• Administrador: Podrá realizar modificaciones a la topología de los mapas

configurados, podrá añadir, modificar y suprimir recolecciones. Podrá
 agregar, suprimir o modificar políticas de configuración de la
herramienta.

• Operador: Solo tendrá la capacidad de visualizar, monitorear el estado

de los elementos, analizar variables de desempeño, recibir eventos
generados por los elementos. No podrá realizar ningún tipo de
modificación, ya sea en la topología de los mapas configurados, ni en las
recolecciones.

Los usuarios configurados fueron:

• Solo lectura:
o nocuio
o nocgye
o noccca

• Administrador:
o infradmin
o nocadmin

2.7.9.3 Acceso vía Web (Vistas dinámicas Home Base)

Los perfiles de seguridad de usuarios y perfiles se almacenan en el archivo

dynamicViewsUsers.xml que se encuentra en la ruta:

E:\Program Files\HP OpenView\tomcat\jakarta-tomcat-4.0.4\webapps\topology\WEB-

INF.

Éste es el archivo que debe cambiarse si se desea modificar y/o agregar

usuarios y passwords en el acceso Web (Dinamic Views). Si se realizan
cambios, se debe reiniciar los servicios.
Para realizar la configuración de las vistas dinámicas se debe modificar el
archivo WEB.xml que se encuentra también en la ruta mencionada
anteriormente. Los cambios consisten en quitar los comentarios en las líneas
que habilitan el acceso restringido a todas las Vistas Dinámicas, las cuales se
encuentran al final del archivo.

Los usuarios configurados para el ingreso a las vistas dinámicas son los
mismos que para el ingreso a la consola local.

Para el acceso a las vistas dinámicas se ingresa a la página:

http://157.100.40.251:7510, como se muestra en la Figura 2.23.

FIGURA 2.23.INGRESO AL HOME BASE.

2.7.9.4 Acceso vía Web (HP OpenView Launcher)

El acceso al OV Launcher se lo puede hacer a través de:

• Options
Report Configuration como se ve en la Figura 2.24
 FIGURA 2.24.ACCESO AL OV LAUNCHER

 Tools
Report Presenter tal como se indica en la Figura 2.25

FIGURA 2.25.ACCESO AL OV LAUNCHER.

Donde se abrirá el acceso vía Web que se muestra en la Figura 2.26.

FIGURA 2.26.OV LAUNCHER.

2.7.10 REPORTES

2.7.10.1 Report Configuration

Los reportes que pueden ser configurados con el Report Configuration son:
Avaliavility, Exception, Inventory y Performance, para el caso de ECUANET se
habilitaron algunos de los reportes relacionados con Availability, Exception e
Inventory.

En la Figura 2.27 se muestran los reportes configurados dentro de cada una de

las categorías. Además, dentro de las configuraciones que pueden realizarse
se encuentran la creación y la modificación de los reportes, así como ver los
reportes programados.

FIGURA 2.27.CONFIGURACIÓN DE REPORTES.

2.7.10.2 Report Presenter

Con el Report Presenter se pueden visualizar los reportes configurados con el

Report Configuration como se muestra en la Figura 2.28.

FIGURA 2.28.PRESENTACIÓN DE REPOSTES

2.8 DATAWAREHOUSE

Un Datawarehouse es un “deposito de datos” orientados a temas integrados,

no volátiles e históricos que se utilizan para entender cómo optimizar un
proceso de toma de decisiones en un negocio. En el NNM 7.53 el
Datawarehouse contiene datos de la red que puede proporcionar información
acerca de la frecuencia de problemas de red, el uso de elementos de la red, y
las tendencias de rendimiento de la red.

El Datawarehouse es un repositorio que almacena la información de

tendencias, eventos y topología del NNM. Estos datos son tomados de las
bases de datos embebidas del sistema, para ser utilizado con fines analíticos.
El Datawarehouse puede utilizar cualquiera base de datos embebida del NNM.
Para poder exportar los datos desde la base de datos embebida al
Datawarehouse se utiliza el Open Data Base Connectivity (ODBC), que
proporciona acceso a datos a través de consultas basadas en SQL (Structured
Query Language) como se muestra en la Figura 2.29.

FIGURA 2.29. EXPORTACIÓN DE DATOS A TRAVÉS DE ODBC

2.8.1 BASE DE DATOS EMBEBIDA

Una base de datos embebida es un fichero que se encuentra dentro del NNM y
que recopila información de los procesos que este genera o tiene, siendo
únicamente accesible por NNM. Es decir, sólo HP OV NNM puede acceder a
las tablas de la base de datos embebida, ya que es un código propietario.
Estas bases de datos están contenidas exclusivamente en memoria, por lo
tanto la información se refresca constantemente y en un periodo de 24h.
Por esta razón es de gran importancia la creación del Datawarehouse para
recopilar y guardar la información de la red backbone de Ecuanet.

2.8.2 TIPO DE BASES DE DATOS PROPIETARIAS DE NNM

La base de datos SQL de NNM interactúa con varios componentes, tales como
bases de datos, interfaces, procesos y archivos de registro local.

Las bases de datos son bases de datos internas que son utilizados por
procesos del NNM. No se puede acceder directamente a estas bases de datos,
aunque la mayoría de la información se puede exportar a un Datawarehouse.

NNM utiliza cinco tipos de bases de datos para sus operaciones. Cada tipo de
base de datos proporciona almacenamiento para un tipo diferente de
información. Los cinco tipos de bases de datos son los siguientes:

2.8.2.1 Base de datos objeto OVW

Gestiona todos los objetos e información en el campo de HP OpenView para

Windows. Esta base de datos no se almacena en una base de datos embebida.

2.8.2.2 Base de datos de Mapa

Contiene información específica de un mapa. Hay un mapa base de datos para

cada submapa en entorno NNM. Por ejemplo la información del mapa principal
incluye: símbolo de etiquetas, las correlaciones entre los símbolos y sus
objetos específicos, y la colocación de un símbolo en el mapa. Las bases datos
de mapa no se almacenan en una base de datos embebida.
2.8.2.3 Base de datos de Topología

Contiene la información básica con respecto a los nodos y las interfaces de los
dispositivos en una red. La topología de los datos es un "inventario" de la red.
Es decir, incluyen datos como nombres, direcciones IP, y la información de la
interfaz del router. Los datos se almacenan en un formato de base de datos
embebida; sin embargo, pueden ser exportados al Datawarehouse utilizando
ovdwtopo

2.8.2.4 Base de datos SNMP-Colección o Tendencias

SNMP contiene datos que se recogen por snmpCollect. Estos datos son
utilizados por otras aplicaciones de NNM. Los datos se almacenan en un
formato de base de datos embebida, y pueden ser exportados al
Datawarehouse utilizando ovdwtrend.

2.8.2.5 Base de datos de eventos

Contiene datos de eventos que se generan en NNM y que se envían como

alertas. Esta información es utilizada por muchas aplicaciones de NNM,
incluido el navegador y el browser de alarmas.

Los datos se almacenan en un formato de base de datos embebido, pero

pueden ser exportados al Datawarehouse utilizando ovdwevent
Los cinco tipos de bases de datos en el entorno NNM son controladas por
procesos. No se puede editar directamente ya que son propias del sistema.
2.8.3 OPEN DATABASE CONNECTIVITY (ODBC)

ODBC significa Open Database Connectivity, es decir, conectividad abierta de

base de datos. Éste es un formato definido por Microsoft para la comunicación
entre los clientes de bases de datos de Windows y los usuarios como NNM.

ODBC es un interfaz de programación de aplicaciones para acceso a bases de

datos a través de consultas SQL. Se basa en el CLI ó nivel de interfaz de
llamadas de las especificaciones de SQL Acceso Group.

El OBDC permite una forma neutral de acceso a los datos almacenados en los
ordenadores personales y diversas bases de datos, está diseñado para una
máxima interoperabilidad; es decir, la capacidad de una única solicitud para
acceder a diferentes bases de datos (sistemas de gestión de bases de datos)
con el mismo código fuente.

La fuente de datos ODBC es un nombre lógico que une la base de datos de

productos físicos a un nombre lógico. La fuente de datos ODBC utiliza un
controlador de configuración que le permite conectarse a una base de datos.
ODBC es un vínculo que permite la exportación de datos en los sistemas
operativos Windows.

2.8.4 SQL (STRUCTURED QUERY LANGUAGE)

SQL es un lenguaje y una herramienta para comunicarse con una base de

datos relacional. SQL es oficialmente reconocido como un estándar ANSI / ISO,
SQL es el lenguaje utilizado para comunicarse con bases de datos relacionales
en el medio ambiente de HP OpenView.
Algunas de las principales características de SQL incluyen:

• Para los usuarios y administradores de bases de datos, SQL

proporciona un conjunto de comandos para acceder a la consulta de
información en la base de datos.
 • Para los administradores de base de datos, SQL sirve como una
herramienta para la distribución de datos a través de múltiples
servidores y estaciones de trabajo dentro de una red. Cada puesto de
trabajo y el servidor SQL utiliza un lenguaje común para enviar, recibir y
compartir información a través de las bases de datos en la red.
• Para los desarrolladores de aplicaciones de bases de datos, comandos
SQL son los comandos de programación que permiten a un
desarrollador del programa acceso a la información de una base de
datos.

2.8.5 CAPACIDADES DE LAS BASE DE DATOS

Una base de datos debe tener la capacidad de extracción de información por

las siguientes razones:
• Para transferir información desde una base de datos a otra base de
datos en la misma red.
• Para transferir datos entre diferentes bases de datos sobre redes.
• Para la producción de información de una base de datos en un formato
diferente, como archivos de texto en línea o reportes.
• Otra capacidad de una base de datos es ser dinámica. La información se
puede añadir o eliminar de la base de datos.

2.8.6 ADMINISTRACIÓN DE BASE DE DATOS

Las capacidades administrativas más importantes de una base de datos deben

ser:

a. Creación de un mecanismo de seguridad que controla el usuario y

administrador de acceso a una base de datos.
b. Uso de lenguajes de programación de propiedad, construcciones,
ampliaciones o SQL para crear una base de datos o su contenido.
c. Gestión de la modificación de esquema de base de datos y tablas.
 d. Personalización de cualquier informe o formas de generación de
herramientas suministradas con la base de datos.
e. Integración de aplicaciones de terceros con HP OpenView para
proporcionar sistemas de gestión de red y la funcionalidad.

2.8.7 CARACTERÍSTICAS DATAWAREHOUSE

Un Datawarehouse es una colección de información sobre un conjunto de

objetos relacionados, la cual se almacena en una base de datos. Un
Datawarehouse está diseñado para que los usuarios puedan acceder a la base
de datos con una herramienta de consultas para obtener la información que
necesitan. Un ejemplo como se muestra en la Figura 2.30.

FIGURA 2.30.ACCESO DE USUARIOS AL DATAWAREHOUSE

Un Datawarehouse permite al usuario:

a. Realizar un análisis avanzado de la información obtenida utilizando la

herramienta más adecuada, como por ejemplo Excel.xls, Cristal Report,
OVPI, etc.
b. Elaborar los reportes que se ajusten a las especificaciones
personalizadas del usuario.
c. Analizar eventos, tendencia y datos después de un período de tiempo
especificado.
d. Eliminar la snmpCollect datos.
El Datawarehouse permite guardar la información diaria, semanal, mensual y
anual de las tablas como parte del proceso de exportación.
Para el caso de Ecuanet la información tendrá un historial de almacenamiento
de máximo un año, (Figura 2.31).

FIGURA 2.31.PROCESO DE EXPORTACIÓN DE DATOS

2.8.8 CONFIGURACIÓN DE LA BASE DE DATOS PARA EL

FUNCIONAMIENTO DEL DATAWAREHOUSE

Después de instalar el SQL Server, se procedió a la creación de la base de

datos que alojarán la información proveniente de NNM. Dicha base de datos
debe llevar por nombre “openview” como se muestra en la Figura 2.32.

FIGURA 2.32. BASE DE DATOS OPENVIEW

Se realizó la creación de la base de datos, confirmando su aparición en el
listado de base de datos que se observa en la siguiente Figura 2.33.

FIGURA 2.33.BASE DE DATOS OPENVIEW

Se procedió a crear un usuario llamado “ovdb”, nombre por defecto empleado

por NNM para la comunicación con la base de datos. Además se creó un
usuario y password como se puede observar en la Figura 2.34.

FIGURA 2.34.CONFIGURACIÓN DE LA BASE DE DATOS OPENVIEW

Se verificó los permisos de “Owner” sobre la base de datos openview para
permitirle la creación de las tablas y demás información necesaria en el
Datawarehouse.
Se validó la creación del usuario y el registro en el listado de “Logins” de la
herramienta como se muestra en la Figura 2.35.

FIGURA 2.35. LISTADO DE LOGINS.

2.8.9 PROCESO DE CREACIÓN DE INFORMACIÓN EN EL

DATAWAREHOUSE.

NNM emplea para su comunicación con la base de datos una conexión ODBC
por DNS, este DNS lleva por nombre OVSQL. Además emplea como login y
password el creado anteriormente para la base de datos y se conecta con la
base de datos openview como se muestra en la Figura 2.36.
 FIGURA 2.36 CONEXIÓN A LA BASE DE DATOS OPENVIEW

Se procedió a crear la conexión entre NNM y la base de datos. Para esto se

empleo una ventana de comandos y se ingreso la ruta “E:\Program Files\HP
OpenView\bin>”. Desde esta se ejecuta el comando ovdwconfig.ovpl –rbd
OVSQL –u ovdb – password XXXX –load –type msSqlSrvr como se puede ver
en la Figura 2.37 donde:

• Ovdwconfig.ovpl: es el comando que ejecuta la conexión.

• rbd: Es el ODBC de conexión a la base de datos creado anteriormente.
• u XXXX: Es la cuenta de usuario en la base de datos.
• password XXXX : Es la contraseña de acceso de la cuenta anterior.
• load: Es el comando que ejecuta la creación de las tablas.
• type msSqlSrvr: Es el tipo de base de datos que se va a emplear.
•

FIGURA 2.37.CONEXIÓN ENTRE NNM Y LA BASE DE DATOS OPENVIEW.

Se ejecutó y se comprobó la correcta creación de las tablas que conforman el
Datawarehouse. El resultado se observa en la Figura 2.38.

FIGURA 2.38.TABLAS EN EL DATAWAREHOUSE.

También se validó que los servicios de NNM se estén ejecutando, con el

comando ovstatus –c. Desde aquí se puede ver que NNM se encuentra
conectado a la base de datos SQL tal como se muestra a continuación a través
del comando ovdbcheck en la Figura 2.39.
 FIGURA 2.39. CONEXIÓN DE NNM A LA BASE DE DATOS SQL.

Además se configuró tres tareas programadas, que se muestra en la Figura

2.40, para exportar los datos desde la base de datos embebida de NNM hacia
la base de datos SQL que actúa como Datawarehouse. Dichas tareas
programadas están configuradas para ejecutarse todos los días, las cuales son:
• ovdwtopo – Exporta información de topología.
• ovdwtrend – Exporta información de tendencias.
• ovdwevent – Exporta información de eventos.

FIGURA 2.40. TAREAS PROGRAMADAS EN EL DATAWAREHOUSE.

Se concluye que la herramienta esta correctamente instalada y configurada de

acuerdo a los requerimientos de Ecuanet para monitorear la RBE, Por lo que se
proseguirá en el siguiente capítulo con las respectivas pruebas del SGM.
 CAPÍTULO 3

PRUEBAS Y ANÁLISIS DE RESULTADOS

En este capítulo se describirán las pruebas que se diseñaron para probar todo
el sistema implementado y se analizarán los resultados obtenidos para
determinar el correcto funcionamiento de la herramienta, así como la
importancia de las políticas de monitoreo establecidas en el SGM que se
podrán revisar desde la herramienta.

3.1 ALARMAS FALSAS

Luego de haber configurado la herramienta y cargado los nodos a monitorearse

se obtuvo un bombardeo de alarmas. Se determinó que muchas de las alarmas
no eran reales sino que aparecieron debido a la incorrecta aplicación de las
políticas de monitoreo establecidas en el SGM. Se detectaron diferentes tipos
de falsas alarmas las cuales se las describe a continuación y la manera como
se las corrigió.

3.1.1 INCORRECTA APLICACIÓN DE POLÍTICAS DE INTERFACES

LIBRES

La herramienta NNM reconoce cuando una interfaz está desconectada e

inmediatamente genera una alarma. Es por esto, que es de suma importancia
la aplicación correcta de la política de interfaces libres.
Debido a que la red está siendo constantemente manipulada por Ingenieros
tanto de Área de Infraestructura y del NOC, para los cuales se creó las
Instrucciones de Trabajo. Al tomar una muestra de algunos equipos [2] se
obtuvieron los resultados que se muestran a continuación en la Tabla 3.1, 3.2,
3.3, 3.4.

2 Únicamente se muestran algunas interfaces debido a las políticas de confidencialidad exigidas por la empresa Ecuanet.
EQUIPO CORE-TLPUIO-5
IP 157.100.40.5
OBSERVACIONES Correcta aplicación de las
Políticas de Interfaces Libres

TABLA 3.1. RESULTADOS DE POLÍTICAS DE INTERFACES LIBRES

EQUIPO SWL_TEGUEL_NOD
IP 157.100.192.42
OBSERVACIONES Incompleto. Se necesita poner en estado
Shutdown las interfaces que están libres

TABLA 3.2. RESULTADOS DE POLÍTICAS DE INTERFACES LIBRES

EQUIPO SW_COREGYE_TLP
IP 64.46.78.33
OBSERVACIONES Incompleto. Se necesita poner la descripción
de las interfaces que están en estado de
Shutdown

TABLA 3.3. RESULTADOS DE POLÍTICAS DE INTERFACES LIBRES

 EQUIPO SW_BACKBONE_MACHALA
IP 157.100.36.10
OBSERVACIONES Incompleto. Si el cliente cancelo el servicio se
debe liberar la interface y ponerla en estado
de Shutdown, de la misma manera cuando
existen cambios de configuración o es un
enlace de Backup.

TABLA 3.4. RESULTADOS DE POLÍTICAS DE INTERFACES LIBRES

3.1.2 ALARMAS DE EQUIPOS ACCESS SERVER Y CPE

Con esta prueba se analizó la necesidad de no recibir alarmas de interfaces de

equipos que no proporcionaron información relevante para correcto
funcionamiento de la RBE.

A continuación se analizará los siguientes casos:

3.1.2.1 Network Access Server

El NAS, Servidor de Acceso a la Red es un punto de entrada que permite a los

usuarios o clientes acceder a una red. Está destinado a actuar como una
puerta de entrada a un recurso protegido. El cliente se conecta al NAS y este a
su vez se conecta con otro recurso, preguntándole si las credenciales
suministradas por el cliente son válidas.
El NAS no contiene, información acerca de qué clientes pueden conectarse o
qué credenciales son válidas. Todos los NAS envían las credenciales
suministradas por el cliente a un recurso que sabrá cómo procesar dichas
credenciales.

3.1.2.2 Customer Premises Equipment

El CPE, Equipo Local del Cliente es un equipo de telecomunicaciones usado

tanto en interiores como en exteriores para originar, encaminar o terminar una
comunicación.

El equipo puede proveer una combinación de servicios incluyendo datos, voz,

video y un host de aplicaciones multimedia interactivos.

En Ecuanet se utilizan los equipos NAS para las conexiones Dial –Up y los
CPE para la red interna de los clientes.

Se deshabilitara el monitoreo de estos equipos desde el Servidor de Gestión ya

que las alarmas generadas por el NAS son cuantiosas debido a que los clientes
se conectan y desconectan a cada momento y las alarmas de los CPE
pertenecen a la red interna del cliente y la prioridad con la herramienta es
monitorear los nodos de Backbone.

En la Tabla 3.5 se muestra las interfaces asincrónicas del NAS que fueron
deshabilitadas desde el NNM, y en la Tabla 3.6 se muestra las interfaces a las
cuales están conectadas equipos CPE.
EQUIPO CORE-NODOAMB-6
IP 157.100.34.6

OBSERVACIONES Interfaz deshabilitada desde el equipo

Interfaz deshabilitada desde el NMS

TABLA 3.5. INTERFACES ASINCRÓNICAS DESHABILITADAS

 EQUIPO MEGA-AUNUIO-25
IP 69.65.135.25
OBSERVACIONES
Interfaz deshabilitada desde el equipo

Interfaz deshabilitada desde el NMS

TABLA 3.6. INTERFACES DE CPE DESHABILITADOS

3.2 PRUEBAS DE RESPUESTA

Las pruebas de respuesta fueron importantes porque demostraron que la

herramienta está apoyando el monitoreo de la RBE ya que permitió reconocer
rápidamente las incidencias y actuar proactivamente para su pronta solución.

Estas pruebas se les realizaron en dos partes, en la primera parte se cambió el

estado de la interfaz FastEthernet 0/0/1 del equipo CORE-NODOIBA-4 como
se muestra a continuación:
Se ingresó al NNM y se tomó un nodo al azar, en este caso el Nodo CORE-
NODOIBA-4, perteneciente a la ciudad de Ibarra. Paralelamente se ingresó al
equipo y se cambio el estado de la interfaz FastEthernet 0/0/1 a ShutDown,
dicha interfaz corresponde al cliente César Barreno, como se muestra en la
Figura 3.7.

FIGURA 3.7. CAMBIO DE LA INTERFAZ A SHUTDOWN

En la Figura 3.8 se muestra las pantallas de la vista clásica de NNM con la del
equipo CORE-NODOIBA-4 y el Browser de Alarmas.

En el equipo se hizo un Show Config donde se verificó que la interfaz

FastEthernet estaba en estado Shutdown. Además se observó la interfaz
alarmada por su cambio de color y se verificó en el Browser de Alarmas la
información con respecto a este evento.

FIGURA 3.8. INTERFAZ ALARMADA

Se configuró el estado de la interfaz a No Shutdown en lo que se restableció el

enlace hacia el cliente como se muestra en la Figura 3.9.
 FIGURA 3.9. NO SHUTDOWN A LA INTERFAZ FASTETHERNET 0/0/1

En la Figura 3.10 se muestra, en la vista clásica que la interfaz recuperó el

estado normal, así como en el Browser de Alarmas se observó que la interfaz
esta con el enlace operativo.

FIGURA 3.10. ENLACE OPERATIVO

Cabe indicar que el tiempo durante el cual se realizó este proceso es de 5

minutos, con lo que se reafirma que la Herramienta de Gestión apoya de
manera eficiente al proceso de monitoreo y soporte para Ecuanet y con esto se
pueden obtener nuevos índices de Calidad así como un mejor SLA.

En la segunda parte se tomó la última notificación que ha llegado al correo

[email protected] desde el Servidor de Gestión que corresponde al
cliente Agencia Sayago como se muestra en la Figura 3.11.
 FIGURA 3.11. CORREO DE MONITOREO

Se ingresó al NNM y en el Browser de Alarmas se había generado una alarma

que pertenece al cliente Agencia Sayago que esta configurado en la interfaz
Lo0/13 del equipo SW_GUAYAS-SFC como se muestra en la Figura 3.12, con
un clic en el source, automáticamente se va a la ubicación en la vista clásica
del equipo como se muestra en la Figura 3.13.

FIGURA 3.12.BROWSER DE ALARMAS-CLIENTE AGENCIA SAYAGO

FIGURA 3.13. ALARMA VISUAL-CLIENTE AGENCIA SAYAGO

Se ingresó al equipo mediante Telnet, se verificó que la configuración este

correcta como se muestra en la Figura 3.14 y 3.15. Frente a este hecho se
llamo al cliente a notificar que se encontró alarmado su enlace, pero el cliente
informo que esto se debió a que el apagó sus equipos.
 FIGURA 3.14. CONFIGURACIÓN DEL CLIENTE AGENCIA SAYAGO

FIGURA 3.15. CONFIGURACIÓN DEL CLIENTE AGENCIA SAYAGO

Se dio seguimiento a este cliente para verificar si al día siguiente, al prenderse

los equipos, el enlace opere correctamente.
En el Browser de Alarmas se verificó que el cliente encendió los equipos en la
mañana a las 8:16am y que el enlace se restableció correctamente como se
muestra en la Figura 3.16.

FIGURA 3.16.BROWSER DE ALARMAS-CLIENTE AGENCIA SAYAGO

El estado de las interfaces también se las puedo verificar desde la vistas
dinámica del NNM como se muestra en la Figura 3.17. y 3.18.

FIGURA 3.17. VITA DINÁMICA-INTERFAZ LO0/13 ALARMADA.

FIGURA 3.18. VISTA DINÁMICA-INTERFAZ LO0/13 EN ESTADO NORMAL.

3.3 GRÁFICAS DE CONSUMO

Con la herramienta NNM se puede obtener las gráficas de consumo de las

interfaces; es decir se puede verificar el tráfico entrante y saliente (throughput).
Para esta prueba se ha tomado como ejemplo la interfaz GigabitEthernet0/1 del
equipo MEGA-AUNUIO-25 como se muestra en la Figura 3.19.

FIGURA 3.19. THROUGHPUT A TRAVÉS DE LA INTERFAZ GIGABITETHERNET0/1

Además se ingresó al nodo mediante Telnet y mediante un Show Interface
GigabitEthernet0/1 se verificó que el throughput correspondiente a las gráficas
es similar al tráfico del equipo como se muestra en la Figura 3.20.

FIGURA 3.20. TRAFICO A TRAVÉS DE LA INTERFAZ GIGABITETERNET0/1

3.4 VISTA DINAMICA A TRAVÉS DEL WEB BROWSER

La vista dinámica de la herramienta NNM se la puede operar desde el web

browser con el URL http://157.100.40.251:7510, en esta prueba se observó la
necesidad de la instalación de Java Runtime Environment que incluye todos los
módulos de ejecución necesarios para esta aplicación que esta hecha con Java
como se muestra en la figura 3.21.

FIGURA 3.21.INSTALACION DE JAVA RUNTIME ENVIRONMENT

En la Figura 3.22 se observa que con la instalación del JRE se carga el
Home Base y nos solicita la clave de ingreso al NMS.

FIGURA 3.22.INGRESO AL HOME BASE

 La Advertencia de Seguridad que se muestra en la Figura 3.23 indica que
el certificado de seguridad es valido para la herramienta HP Open View
NNM y se confirma que se puede ejecutar el software.

FIGURA 3.23.CERTIFICADO DE SEGURIDAD PARA EJECUTAR NNM HB.

En la Figura 3.24 se puede observar que las vistas dinamicas a través del
Internet Explorer se carga correctamente.

FIGURA 3.24. PANTALLA PRINCIPAL DEL HOME BASE.

3.5 NOTIFICACIÓN DE EVENTOS

Para realizar estas pruebas se tomaron las alarmas de Interfaz Up e Interfaz

Down, la notificación de estos eventos serán enviados a las cuentas de correo
[email protected] y [email protected].

• En la Interfaz Up (If Up) se aplicará una línea de comandos para enviar las
notificaciones a un solo correo como se describe en el capitulo 2. en la
sección 2.7.7.3.
cmd /c bmail.bat "[email protected]"
[email protected] "IF Up $5 $10 $6 Capabilities: $15""IF Up
$5 $10 $6"

• En la Interfaz Down (If Down) se aplicará una línea de comandos para

enviar las notificaciones a múltiples correos como se describe en el
capitulo 2 en la sección 2.7.7.3.

cmd /c E:\"Program Files"\"HP OpenView"\"bin"\"bmail.exe" -s 157.100.45.45 -

to " [email protected],[email protected]" -f
[email protected] -b "IF Down $5 $10 $6 Capabilities: $15"
-a "IF Down $5 $10 $6"

En las pruebas realizadas se observó que a la cuenta monitoreonnn llegaron

notificaciones de If Up e If Down mientras que a la cuenta nocuio llegaron
notificaciones If Down. En la Figura 3.26 se puede verificar que llegan las
notificaciones satisfactoriamente.
 Figura 3.26. Notificaciones al correo

3.6 MAPAS
Está prueba nos permitió cambiar el aspecto del mapa principal del NNM.
En un inicio se cargo un mapa del Ecuador como se muestra en la Figura 3.27
pero luego de alguna pruebas se prefirió cambiarlo por el mapa de la Figura
3.28; el mapa que se desee cargar se descubrió debe ser una imagen con
extensión .gif como se muestra en la Figura 3.29.

FIGURA 3.27. IMAGEN MAPA FINAL VERSIÓN 1

 FIGURA 3.28. IMAGEN MAPA FINAL VERSIÓN 2

FIGURA 3.29. IMAGEN DEL MAPA DE ECUADOR CON EXTENCION.GIF

3.7 PRUEBAS Y RESULTADOS REALIZADOS CON LA
VISUALIZACIÓN DE ALARMAS.

Con esta prueba se pretende mostrar la detección de fallas en la red a través

de alarmas visuales que presenta el NNM7.53.

Estas alarmas visuales están representadas por colores los mismos que
representan el estado de una ciudad o contenedor, nodo, interfaz, etc., es decir
el color simboliza una etapa o cambio de estado y este puede variar desde no-
administrable “Unmanaged” hasta crítico “Critical/Down”.

El Hp OpenView Network Node Manager reconoce 10 condiciones de estado

de operación.

A continuación se muestra la categoría de alarmas por color y por estado

3.7.1 ESTADOS ADMINISTRATIVOS

3.7.1.1 Unmanaged:
Éste estado indica que el objeto no puede ser monitorizado y el estado
operacional puede ser ignorado.

3.7.1.2 Testing:
Éste estado indica que el objeto esta temporalmente en diagnostico o está
sometido a mantenimiento.

3.7.1.3 Restricted:
Éste estado indica que el objeto funciona normalmente pero no está disponible
para otros usuarios.
3.7.1.4 Disabled:
Éste estado indica que el objeto está inactivo aunque no necesariamente tenga
algún daño.

En la siguiente Figura 3.30 se observa los colores correspondientes a los 5

primeros estados.

FIGURA 3.30 REPRESENTACIÓN DE ESTADO DE ALARMAS POR COLOR

3.7.2 ESTADOS OPERACIONALES

3.7.2.1 Unknown:
Éste estado se presenta cuando el estado de un objeto no puede ser
determinado.

3.7.2.2 Normal:
Éste estado indica que el objeto está en estado de operación normal.

3.7.2.3 Warning:
Éste estado se presenta cuando un objeto puede tener un problema potencial.

3.7.2.4 Minor/Marginal:
Éste estado se presenta cuando un objeto tiene un problema menor, pero
puede seguir operando normalmente.
3.7.2.5 Major:
Éste estado indica que el objeto tiene un problema serio y en cualquier
momento puede dejar de operar normalmente.

3.7.2.6 Critical:
Indica que el objeto no está funcionando

En la Figura 3.31 se observa los colores correspondientes a los 5 últimos

estados

FIGURA 3.31. REPRESENTACIÓN DE ESTADO DE ALARMAS POR COLOR

El estado de las alarmas cambia dependiendo del estado de criticidad de las

interfaces y/o nodos.

3.8 COMPOSICION DEL ESTADO DE ALARMAS

El cambio de estado de una interfaz provoca el cambio de estado de un nodo, y

a su vez, el cambio de estado de un nodo o varios nodos provocan el cambio
de estado de un contenedor y esto se representa con un color, como se
observa en la Figura 3.32.
 FIGURA 3.33. CAMBIOS DE ESTADOS

El color de cada cambio de estado en nodos se compone de acuerdo a

porcentajes o umbrales de los cambios de estados en las interfaces, y el
cambio de estado de un contenedor se compone de porcentajes o umbrales de
los cambios de estados de los nodos. En Hp OpenView Network Node
Manager estos valores están configurados por defecto ya que esta opción es la
que presenta una visualización real de la RBE, lo que se puede observar en la
Figura 3.34.

FIGURA 3.34. COMPOSICIÓN DE ESTADO DE ALARMAS.

Si estos valores se alteran el resultado visual de las alarmas podría no
corresponder al estado real de la red.

Para probar está configuración en la Figura 3.35 se observa la propagación

mas critica; es decir, todas las alarmas desde estado menor corresponden a un
estado crítico en color “rojo”; es decir, solo los contenedores que no tienen
alarmas de ningún tipo serán de color “verde” o estado normal.

FIGURA 3.35. COMPOSICIÓN DE ESTADO DE ALARMA

Además se probó cambiando los porcentajes de los cambios de estado desde

warning a critical para verificar cuál de estas opciones se ajusta más al estado
real de la red; sin embargo, como se observa en la Figura 3.36, al colocar
valores predeterminados se presento un cambio radical en la visualización del
mapa principal.
 FIGURA 3.36. COMPOSICIÓN DE ESTADOS POR PORCENTAJES.

Al variar estos porcentajes los resultados que se visualizan son extremos; es

decir, todos los contenedores se colocan en estado crítico, como se observa en
la Figura 3.37, o se colocó en estado normal como se observa en la Figura
3.38.Por lo tanto, se verificó que la mejor opción para visualización de la red es
la que está por defecto en Hp OpenView Network Node Manager.

FIGURA 3.37. COMPOSICIÓN DE ESTADOS POR PORCENTAJES, VARIANTE 1

 FIGURA 3.38. COMPOSICIÓN DE ESTADOS POR PORCENTAJES, VARIANTE 2.

3.9 VERIFICACIÓN DE LAS CAMBIO DE ESTADO O ALARMAS

Los cambios de estado de alarmas se visualizan a través del “browser de

alarmas”, el cual se clasifica por categorías como se observa en la siguiente
Figura 3.39.

FIGURA 3.39 CATEGORÍA DE ALARMAS.

En el browser de alarmas se verificó que también presenta cambios de estado

por color, lo cual facilita la detección más rápida de fallos en la red como se
muestra en la Figura 3.40.
 FIGURA 3.40. BROWSER DE ALARMAS POR CONFIGURACIÓN

3.10 PRUEBA DEL SGM

Esta prueba consistió en verificar el funcionamiento del SGM, para lo cual se

tomó información que Ecuanet registra en su control de incidencias por tickets.

Se analizó un ticket del 2008 por monitoreo, en el cual se detectó una falla en
la red, sin embargo tiene un tiempo de solución de aproximadamente de 40
horas como se muestra en la Figura 3.41 y en la Figura 3.42 lo cual sobrepasa
el SLA que maneja Ecuanet S.A.

FIGURA 3.41. PANTALLA DE TICKET DEL 2008

 FIGURA 3.42. PANTALLA DE TICKET DEL 2008

Con este ticket se puede concluir que antes el monitoreo que poseía Ecuanet
era un proceso totalmente reactivo sin cumplimientos de SLA y con tiempos de
solución altos. Además se analizó un ticket de mayo del 2009 abierto por
monitoreo, en el cual con NNM7.53 se detectó la caída de un nodo, la solución
de esta incidencia fue en menos de 1 hora, como se observa en la Figuras 3.43
y 3.44.

Teniendo en cuenta que el SLA manejado por Ecuanet es de 99.6% de

disponibilidad lo que equivale a que el enlace únicamente puede estar fuera de
servicio 2.88 horas, con lo que podemos comprobar que el SGM cumple con
las expectativas que la empresa estableció para un servicio de calidad.
 FIGURA 3.43. PANTALLA DE TICKET DEL 2008

FIGURA 3.44. PANTALLA DE TICKET DEL 2008

Además se realizó un comparación del número de tickets abiertos, a través del
sistema de atención al cliente por monitoreo durante el periodo de enero del
2008 hasta enero del 2009 (Figura 3.45) con el numero de tickets abiertos
durante el periodo de enero a junio 2009 (Figura 3.46).

Con esta información se pudo constatar que los tickets abiertos por monitoreo
antes de la implantación del SGM eran reducidos, y se tomaba mucho tiempo
para la resolución de problemas encontrados en red y consecuencia de esto
eran altos índices de notas de crédito.
 Número de Tickets aperturados por monitoreo
20
18
16
14
12
10 Número de Tickets aperturados por monitoreo
8
6
4
2
0
Ene-08 Feb-08 Mar-08 Abr-08 May-08 Jun-08 Jul-08 Ago-08 Sep-08 Oct-08 Nov-08 Dic-08 Ene-09

FIGURA 3.45. [3] NÚMERO DE TICKETS POR MONITOREO DURANTE ENERO 2008 A ENERO 2009

FIGURA 3.46. [4] NÚMERO DE TICKETS POR MONITOREO DURANTE ENERO 2009 A JUNIO 2009

Con esta comparación se demuestra que el SGM con la herramienta de HP

OPV NNM7.53 constituye un instrumento que mejoró la pro actividad en la
detección de fallas en la red.

Después de realizar las pruebas sobre el funcionamiento de NNM se verifica

que la herramienta está operando correctamente, además que la utilización y
manejo de la información proporcionada por NNM representa un factor
importante para la solución de incidencias, comprobar el comportamiento de la
RBE en tiempo real, lo cual ha permitido mejorar los índices de calidad,
competitividad, obtener rentabilidad.

3 Gráfica proporcionada por el Departamento del Calidad de Ecuanet S.A.

4 Gráfica proporcionada por el Departamento del Calidad de Ecuanet S.A.
 CAPÍTULO 4

ANÁLISIS DE COSTOS

En este capítulo se realizará un análisis de la viabilidad y el financiamiento del

proyecto así como se buscará justificar la inversión para la empresa, aclarando
que la herramienta NNM AE v7.53 fue adquirida por Ecuanet previo al
desarrollo del SGM. Se detallará el contenido en el análisis de la dinámica del
sector de las telecomunicaciones.

Los valores utilizados en este capítulo fueron proporcionados por el

departamento financiero de Ecuanet y con ellos se determinará la robustez
económica del proyecto, además se deducirán los beneficios financieros que el
SGM proporciona a Ecuanet

El presente análisis de costos girará alrededor de los egresos por la

implementación del sistema de monitoreo utilizando la herramienta Hp NNM AE
v7.53 y, en contraparte, los ahorros de costos al detectar fallas y actuar
proactivamente en su solución.

4.1 DINAMICA DEL SECTOR DE LAS

TELECOMUNICACIONES

La dinámica del sector de las telecomunicaciones se considera bajo los

siguientes puntos de vista: Competencia, Clientes, Nueva Economía,
Tecnología y Servicios; los mismos que permitirán aclarar la importancia de
contar con un SGM.
4.1.1 COMPETENCIA

Como consecuencia de la liberación de mercados existe la entrada de nuevos

operadores de servicios, guerra de precios, modalidades de servicios y
reducción en los márgenes de ganancia.
El resultado de estas variables externas produce que los operadores deban
generar cambios radicales para enfrentar a la competencia, el servicio toma un
papel preponderante en la infraestructura de soporte. Como una de las
estrategia diferenciadoras en el mercado, Ecuanet determina necesaria la
adopción de un SGM, que frente al mercado marque una diferencia en el
servicio proactivo que presta a sus clientes.

4.1.2 CLIENTES

Los clientes desean soluciones a la medida, confiables, oportunas, de bajo

costo, que incluyan movilidad, grandes anchos de banda y posibilidades de
gestión.

4.1.3 NUEVA ECONÓMICA

La nueva economía se la entiende como la optimización de procesos en el

negocio y desarrollo de estrategias de Gestión de Telecomunicaciones. En el
caso presente la aplicación de un SGM.

4.1.4 TECNOLOGIA Y SERVICIOS

El desplazamiento de la orientación tecnológica hacia la satisfacción de las

necesidades de los clientes requiere diferenciación en los operadores basada
no en tecnología subyacente, sino en la calidad de los servicios prestados y
en la atención al cliente.
Las garantías para proporcionar calidad de servicio, además de una pro
actividad que facilite identificar problemas potenciales y resolverlos sin impacto
al cliente son indicadores de la necesitad de un SGM.

4.2 VIABILIDAD

Debido a la necesidad de marcar un servicio diferenciador frente al mercado de

empresas proveedoras de servicios de telecomunicaciones, Ecuanet optó por
la adopción de un SGM. Ecuanet para cumplir con esta proceso analizó
durante el periodo de un año (Enero 2008 – Enero 2009) todas aquellas
variables que afectan la rentabilidad de la empresa y de cómo con la adopción
de este SGM permitiría mejorar dichas variables.

Entre las variables analizadas se tiene:

• Cancelaciones: Hace referencia a las anulaciones de contratos de
clientes
• Notas de crédito: Hace referencia a la devolución de dinero por
indisponibilidad en el servicio calculado con el SLA
• Pérdida de ingresos: Hace referencia a las falta de ingreso por las
cancelaciones
• Tickets de monitoreo: Hace referencia a un sistema de registro diario
sobre incidencias o fallas en la RBE

A continuación se muestra en la Figura 4.1 el porcentaje (%) de cancelaciones

y notas de crédito por falta de pro actividad en el servicio. Generaron pérdidas
para la empresa durante el periodo de enero del 2008 hasta enero del 2009, en
un máximo de 20% en el mes de agosto y un mínimo de 6% en diciembre; sin
embargo, se observa un nuevo apuntalamiento en enero del 2009 de 17%.
 % Cancelaciones y Notas de Credito
25,00%

20,00%

15,00%
% Cancelaciones y Notas de Credito
10,00%

5,00%

0,00%
Ene- Feb- Mar- Abr- May- Jun- Jul-08 Ago- Sep- Oct- Nov- Dic- Ene-
08 08 08 08 08 08 08 08 08 08 08 09

FIGURA 4.1 PORCENTAJE DE CANCELACIONES DURANTE ENERO 2008 A ENERO 2009

La Figura 4.2 representa el número de tickets abiertos, a través del sistema de

atención al cliente por monitoreo durante el periodo de enero del 2008 hasta
enero del 2009. De las grafica se obtiene que la detección de fallas en la red
por monitoreo es baja y constituyen un referente de las limitantes de monitoreo
que Ecuanet poseía.

Número de Tickets aperturados por monitoreo

20
18
16
14
12
10 Número de Tickets aperturados por monitoreo
8
6
4
2
0
Ene-08 Feb-08 Mar-08 Abr-08 May-08 Jun-08 Jul-08 Ago-08 Sep-08 Oct-08 Nov-08 Dic-08 Ene-09

FIGURA 4.2 NÚMERO DE TICKETS POR MONITOREO DURANTE ENERO 2008 A ENERO 2009

Se observa en la Figura 4.3 el porcentaje (%) de pérdida en relación al ingreso

mes a mes como consecuencia de las cancelaciones de servicio.
 % Pérdida Ingreso
3,00%

2,50%

2,00%

1,50% % Pérdida Ingreso

1,00%

0,50%

0,00%
Ene-08 Feb-08 Mar-08 Abr-08 May-08 Jun-08 Jul-08 Ago-08 Sep-08 Oct-08 Nov-08 Dic-08 Ene-09

FIGURA 4.3 PORCENTAJE DE PÉRDIDAS DE INGRESO DURANTE ENERO 2008 A ENERO 2009

La curva muestra que en el mes de Agosto se llego hasta en un 2,5% de

pérdida de ingreso por falta de proactividad en la detección de problemas o
malos diagnósticos sobre los servicios de telecomunicaciones brindados a
clientes.

4.3 COSTOS DE IMPLEMENTACIÓN

El costo del SGM adoptado por Ecuanet se desglosará a continuación en la

Tabla 4.1 (software, hardware, horas hombre). Estos costos representan en
promedio el 5% de los ingreso de la empresa mes a mes.

CONCEPTO NÚMERO VALOR ($) VALOR

TOTAL ($)
Software HP NNM AE v7.53 1 28.764,96 28764,96
Hardware ( Servidor) 1 3.861,51 3862,51
Costo mensual hombre 2 800 1600
34.227,47
TABLA 4.1 COSTOS DE IMPLEMENTACIÓN

De la Tabla 4.1 se puede observar que el costo hora hombre se desglosará

para el caso presente en 40 horas semanales por 1 mes.
Por lo anteriormente mencionado, la adopción del SGM, teniendo como
premisa que el servicio brindado por parte de Ecuanet se convertiría en
proactivo en lugar de reactivo, es claramente viable pues durante dos meses,
evitando las pérdidas en cancelaciones y notas de crédito en el 1,5 %, se
cubren los costos iníciales de implementación. Ecuanet realizo la inversión
prorrateando su costo en 3 meses. Esto se muestra en la Tabla 4.2.

Dic-08 Ene-09 Feb-09 Mar-09

2008-12-05 2008-01-09 2008-02-06 2008-03-06
Costo Prorrateado $ 6,420.75 $ 6,420.75 $ 6,420.75 $ 6,420.75
IVA $ 3,081.96

Subtotales $ 6,420.75 $ 6,420.75 $ 6,420.75 $ 9,502.71

TOTAL $ 28,764.96

TABLA 4.2 COSTO PRORRATEANDO EN 3 MESES

4.4 FINANCIAMIENTO DEL PROYECTO

El financiamiento del proyecto está evaluado desde que fue implementado el

SGM en el mes de febrero, con lo cual se obtiene los siguientes resultados:
Como se puede apreciar en la Figura 4.4, luego de la implementación del SGM
en Ecuanet al mes de Marzo 2009 el porcentaje de cancelaciones y notas de
crédito esta en 10 %, además se observa un comportamiento hacia la baja.

FIGURA 4.4 PORCENTAJE DE CANCELACIONES DURANTE ENERO A JUNIO 2009

De las bases de datos que posee Ecuanet, el número de tickets abiertos por
monitoreo aumentó en comparación a los meses anteriores, justificando la
atención proactiva para clientes. Esto se muestra en la Figura 4.5.

FIGURA 4.5 NÚMERO DE TICKETS POR MONITOREO DURANTE ENERO A JUNIO 2009

Además, en la Figura 4.5 se evidencia la reducción de la pérdida en el ingreso

causado por cancelaciones y notas de crédito, lo cual significa una reducción
mayor al 1%.

% Perdidas Ingreso

2,50%

2,00%

1,50%
%Perdidas Ingreso
1,00%

0,50%

0,00%
dic-08 ene-09 ene-09 feb-09 mar-09 mar-09 abr-09 may-09 may-09 jun-09

FIGURA 4.5 PORCENTAJE DE PÉRDIDAS DE INGRESO DURANTE ENERO A JUNIO 2009

4.5 JUSTIFICACION DE LA INVERSIÓN

De acuerdo a las curvas descritas anteriormente se puede observar que el

proyecto fue justificable; durante los meses de Marzo, Abril, Mayo, Abril el
porcentaje de pérdida de ingreso se mantuvo por debajo del 1.5%; es decir, en
cuatro meses se pagó la inversión del Sistema de Gestión de Monitoreo (SGM)
(suponiendo que la tendencia de pérdida por sobre el 2% se mantenía sin la
aplicación del Sistema de Gestión).

Además, conforme a las diversas aplicaciones del SGM, se aprovechó su

información para ofrecer valor agregado a clientes a un costo del 2.5% del valor
de la inversión total del proyecto. Ecuanet receptó en el mes de Mayo 10
requerimientos por parte de clientes. Es decir, el sistema de monitoreo empezó
a generar rentabilidad después de cubrir su inversión inicial.

Se concluye que con la implementación del SGM se registró un descenso en la

pérdida de ingreso mes a mes, además de ingresos adicionales por las varias
ventajas que HP NNM 7.53 ofrece, por lo que se puede afirmar que el proyecto
es financiable.
 CAPÍTULO 5

CONCLUSIONES Y RECOMENDACIONES

5.1 CONCLUSIONES

Después de haber realizado el trabajo y sobre la base de las pruebas que se

realizaron al sistema se pueden extraer las siguientes conclusiones.

• Al realizar el análisis de las diferentes Herramientas de Monitoreo

existentes en el mercado se concluye que HP NNM V7.53 se constituye
como una herramienta robusta que soporta y procesa gran cantidad de
información y establece un respaldo fundamental en las tareas de
monitoreo que Ecuanet posee.

• El SGM desarrollado cumple con las expectativas de ECUANET ya que

con su implementación se ha logrado disminuir la perdida de ingreso por
falta de proactividad en la resolución de problemas en la red y mejorar el
SLA, por lo que se concluye que un SGM es fundamental para las
empresas de telecomunicaciones ya que esto permite mejorar los
procesos de detección de fallos, mejorar índices de calidad, y soluciones
en una red.

• Ecuanet manejaba una herramienta de monitoreo reactiva, debido a que

las alarmas que proveía eran únicamente de acuerdo al número de
paquetes que perdía. En consecuencia la información no era precisa y el
proceso de monitoreo era lento. Se puede concluir entonces que HP NNM
V7.53 es una herramienta amigable que le permite al usuario verificar el
estado de un nodo a través de una gama de opciones posibles por el
protocolo SNMP.
• La implantación de la herramienta NNM así como el uso de las
Instrucciones de Trabajo del SGM ayuda a la empresa a definir nuevos
índices de calidad. De aquí se concluye que el SLA es un factor crítico en
términos de la entrega de un servicio seguro y eficiente, ya que la
reducción de notas de crédito provee a la empresa mayores ganancias,
clientes satisfechos y prestigio en el servicio cumplido.

• Al estudiar el modelo de gestión TMN se encontró una estructura

organizada que permite que la gestión de red sea flexible, fiable,
económica y fácil de manejar sin embargo, está dirigida a la parte de la red
de una empresa y Ecuanet necesita un proceso de negocios que posee
TOM. Esta visión permite concluir que la capa de negocios (BML) de TMN
no es similar al proceso de Billing de TOM pero juntos manejan la
inversión, aprovisionamiento, utilización de prestaciones, soporte y
determinación de mano de obra mientras, órdenes de pago,
compensaciones, etc.

• Luego de la configuración de la herramienta NNM se realizaron las

pruebas pertinentes de las que es posible concluir que la Herramienta
NNM está operando correctamente y de acuerdo a las expectativas
solicitadas por Ecuanet

• La introducción de un SGM da a Ecuanet la capacidad real de tener éxito

tanto en el sistema de negocios como en el sistema de operaciones, por lo
que se concluye que al fusionar el modelo de gestión TMN y TOM se
garantiza una excelente solución para Ecuanet que involucra a los
elementos de red, clientes y ganancias, maximizando la eficiencia,
productividad y la calidad de los servicios.
• En Ecuanet no se implementó el Sistema de Gestión de Monitoreo en
función del modelo NGOSS debido a que Ecuanet no posee todas las
herramientas para esto, pero la herramienta NNM puede ser la plataforma
para un sistema como NGOSS.
En conclusión NNM es una herramienta que se podrá utilizar en caso de la
introducción de nuevos modelos de gestión.

• El monitoreo y control de los elementos de red es importante y la elección

correcta de la herramienta adecuada es indispensable para un SGM y así
mantener un óptimo performance de la red. Se puede concluir por lo dicho
que el diseño de un SGM proveerá un diagnostico y repuesta rápida a
cada problema potencial de la red y la empresa, apoyando la mejora del
QOS, la asignación de recursos, escalabilidad y la posibilidad de obtener
una certificación ISO.

• La solución NNM de HP OV permite a las empresas de

telecomunicaciones optimizar la experiencia de los clientes finales y
entregar un servicio lleno de satisfacción debido a que se le puede
adicionar módulos dependiendo de la clase de tecnología que la empresa
lo requiera como por ejemplo MPLS, FR, redes IP, etc. Esta característica
permite concluir que NNM es una poderosa herramienta de gestión que
puede ser base de diversos Sistemas de Gestión.

• Al realizar pruebas después de la configuración de la herramienta NNM se

concluye que NNM permite generar requerimientos, controlar , supervisar,
y dar soporte remotamente y en tiempo real además que provee una
interface flexible al usuario ya que NNM incluye web java based interface.

• De los resultados obtenidos, en forma general se puede concluir que todas

las aplicaciones de NNM están sincronizadas. En caso de tener alguna
falla se recomienda, en primera instancia, reiniciar los servicios o visitar a
la página de soporte de HP que posee información sobre el
troubleshooting de la herramienta NNM.
5.2 RECOMENDACIONES

De la experiencia adquirida durante el diseño del SGM así como de la

implantación de la herramienta NNM es posible extraer las siguientes
recomendaciones.

• NNM soporta el protocolo SNMP v1, v2, y v3, pero se recomienda la

utilización de la versión 2 debido al ahorro de recursos como memoria por
dar un ejemplo; además, que no se cambie la configuración actual en los
elementos de la RBE.

• Un modulo MIB envía un informe automáticamente al servidor de gestión a

través de un TRAP SNMP cuando ocurre un suceso significativo que sirve
para controlar el estado de la red, pero se recomienda configurar un
polling en la estación de gestión periódicamente en un tiempo adecuado
para no saturarle al servidor.

• La evolución de los sistemas de gestión de red ha permitido a las

empresas de telecomunicaciones introducir un Modelo de Gestión y
administren de manera más eficiente y segura las redes aun cuando
poseen diversas clases de tecnología y diferentes clases de dispositivos.
Sin embargo, se recomienda implementar un Modelo de Gestión que esté
acorte a las necesidades de la empresa, pero teniendo en cuenta el costo
de las herramientas que serán necesarias adquirir, su complejidad de
instalación y configuración.

• El Datawarehouse se configuró para almacenar la información y mantener

un data recovery por seis meses. Se recomienda limpiar las bases de
datos después de este tiempo.
• Los procesos desarrollados en el SGM para Ecuanet que se muestra en el
Capitulo 1 incluye el plan de trabajo para la implantación de la herramienta
NNM. Se recomienda que el plan debe cumplirse satisfactoriamente ya
que esto permitirá acelerar el proceso de configuración y operación del
Software.
SIGLAS

• UIT-T International Telecommunications Union – Telecommunications

• TMN Telecommunication Management Network - Red de Gestión de
las Telecomunicaciones
• TMF Telecommunication Management Forum – Foro de Gestión de
las Telecomunicaciones
• NGOSS New Generation Operations Software and Systems - Sistemas y
Software de Operaciones de Última Generación
• eTOM enhanced Telecommunication Operation Map - Mapa de
Operaciones de Telecomunicaciones mejorado
• TOM Telecommunication Operation Map - Mapa de Operaciones de
Telecomunicaciones
• NMS Network Monitoring System - Sistema de Monitoreo de Red
• SNMP Simple Network Management Protocol - Protocolo de Gestión de
Red Simple
• TCP/IP Transmission-Control-Protocol/ Internet Protocol - Protocolo de Control
de Transmisión/ Protocolo de Internet
• MIB Management Information Base - Base de Información de Gestión
• UDP User Datagram Protocol - Protocolo de Datagrama de Usuario
• PDU Protocol Data Units - Unidades de Datos de Protocolo
• USM User-Based Security Model
• VCAM Views-Based Access Control Model
• OID object identifier – identificador de objeto
• SMI Structure of Management Information - Estructura de Gestión de
Información
• OSI Open Systems Interconnection - Interconexión de Sistemas
Abiertos
• ICMP Internet Control Message Protocol - Protocolo de Mensajes de
Control de Internet
• CMIP Common Management Information Protocol - Protocolo de
Administración de Información Común
• GDMO Guidelines for the Definition of Managed Objects
• OSS Operation Support System - Sistemas de Operación y Soporte
• NE Network Elements-Elementos de Red
• OAM&P Operations, Administration, Maintenance, and Provisioning -
Operación, Administración, Mantenimiento y Aprovisionamiento
• OS Operations Systems - Sistemas de Operaciones
• DCN Data Communications Network - Redes de Comunicaciones de Datos
• MD Mediation Devices - Dispositivos Mediadores
• WS Workstations - Estaciones de Trabajo
• NE Network Elements - Elementos de Red
• QA Q Adapters - Adaptadores Q BML
• SML Service Management Layer - Nivel de Gestión del Servicio
• NML Network Management Layer - Nivel de gestión de Red
• EML Element Management Layer - Nivel de Gestión Elementos de
Red
• FCAPS Fauls, Configuration, Accounting, Performance, Security
• OSF Operations Systems Function - Función de Sistemas de Operaciones
• NEF Network Element Function - Función de Elemento de Red
• WSF Workstation Function - Función de Estación de Trabajo
• MF Mediation Function - Función de Mediación
• QAF Q Adaptor Function - Función de Adaptador Q
• CMISE Common Management Information Service Element - Elemento de
Servicio Común de Información de Gestión
• ROSE Remote Operation Service Elemen - Elemento de Servicio de Operación
Remota
• SMASE Systems Management Application Service Element - Elemento de
Servicio de Aplicación de Gestión de Sistemas
• ACSE Association Control Service Element - Elemento de Servicio de Control
de Asociación
• FTAM File Transfer, Access and Management - Transferencia de Archivo,
Acceso y Gestión
• ISP Internet Service Provider - Proveedor de Servicios de Internet
• EM Enterprise Management - Gestión Empresarial
• SIP Estrategia, Infraestructura y Productos
• CRM Gestión de las Relaciones con el Cliente
• SLA Service Level Agreement - Acuerdo de nivel de servicio
• RBE Red Backbone de Ecuanet
• NOC Network Operation Center
• SGM Sistema de Gestión de Monitoreo
• HP OV NNM AE v7.53 HP OpenView Network Node Manager Advance Edition
versión 7.53.
• SPI Smart Plug In
• LAN Local Area Connection - Conexión de Área Local
• WAN Wide Area Connection - Conexión de Área Extendida
• DNS Domain Name System - sistema de nombre de dominio
• SMTP Simple Mail Transfer Protocol - Protocolo Simple de
Transferencia de Correo
• CPE Customer Premises Equipment - Equipo Local del Cliente
• JRE Java Runtime Environment
REFERENCIAS BIBLIOGRÁFICAS

- www.afatecnologia.com%20-%20HP%20OpenView%20de%20Hewlett-
Packard.htm

- http://www.tenea.com/popups/servicios3_plataformas_pop1.html

- http://www.hispasec.com/unaaldia/3457/ejecucion-remota-codigo

- http://tuarroberos.blogcindario.com/2005/08/00251-ejecucion-arbitraria-
de-comandos-en-hp-openview-network-node-manager.html

- http://securitytracker.com/alerts/2005/Aug/1014791.html

- http://www.abox.com/productos.asp?pid=276

- http://msjft.wikidot.com/hpnm:introduccion#toc22

- http://www.slideboom.com/presentations/84669/Gesti%C3%B3n-de-
Redes-de-Telecomunicaciones

- http://www.eie.fceia.unr.edu.ar/ftp/Tecnologias%20de%20banda%20ang
osta/Notas_sobre_TMN.pdf

- http://www.cinit.org.mx/articulo.php?idArticulo=12

- http://www.prnewswire.co.uk/cgi/news/release?id=100851

- http://telcom2006.fing.edu.uy/trabajos/mvdtelcom-001.pdf

- http://www.emb.cl/gerencia/articulo.mv?sec=7&num=57&mag=1&wmag=
19

- http://ci.ucr.ac.cr/index.php?id=20

- http://www.osalt.com/es/openview-network-node-manager

- http://www.integracion-de-sistemas.com/analisis-y-monitoreo-de-
redes/index.html

- http://www.securityspace.com/es/smysecure/daudit_ports.html
- http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=
1252787

- http://es.kioskea.net/faq/108-mysql

- http://www.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/Snmp3.
html

- http://www.comsoc.org/livepubs/surveys/public/4q98issue/stallings.html

- http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=
2&mibName=SNMPv2-SMI

- http://www.faqs.org/rfcs/rfc1157.html

- http://ceres.ugr.es/~alumnos/gder/formulario.htm

- http://www.paessler.com/support/kb/questions/49/

- http://edocs.bea.com/snmpagnt/v210/mibref/1tmib.html

- http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_
services/avs/v50/user/guide/aMib.pdf

- http://www.alvestrand.no/objectid/1.3.6.1.2.1.html

- http://java.sun.com/j2se/1.5.0/docs/guide/management/SNMP.html

- http://www.networkview.com/