IMPLEMENTACION DE CISCO IP SLA PARA MONITOREO DE SLA …

INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA

UNIDAD CULHUACAN

SEMINARIO DE TITULACIÓN “SEGURIDAD DE LA INFORMACIÓN”

TESINA

“IMPLEMENTACIÓN DE CISCO IP SLA PARA

MONITOREO DE SLA’S EN PAGINAS WEB”

QUE PRESENTAN PARA OBTENER EL TÍTULO DE INGENIERO EN COMPUTACIÓN

MIRANDA BAUTISTA ISRAEL FELIPE VALLE GARCÍA SALVADOR ALBERTO

INGENIERO EN COMUNICACIONES Y ELECTRÓNICA

HERNÁNDEZ DE LA ROSA ISRAEL ISAAC

Asesores:

DR. GABRIEL SANCHEZ PÉREZ

DR. ANTONIO CASTAÑEDA SOLÍS

VIGENCIA: DES/ESIME-CUL-2008/23/3/10

México, D.F., Mayo 2011

IMPLEMENTACIÓN DE CISCO IP SLA PARA MONITOREO DE SLA’S EN PAGINAS WEB

I

Contenido

OBJETIVO. ................................................................................................................. IV

PLANTEAMIENTO DEL PROBLEMA. ........................................................................ V

JUSTIFICACIÓN. ....................................................................................................... VI

INTRODUCCIÓN ...................................................................................................... VII

CAPITULO I CONCEPTOS DE ADMINISTRACIÓN Y MONITOREO DE REDES. .... 1

1.1 Elementos de la Administración de Red con SNMP. ......................................... 2

1.1.1 NMS (Network Management Stations). ........................................................ 2

1.1.2 Agentes. ....................................................................................................... 3

1.1.3 Protocolo. ..................................................................................................... 3

1.2 Arquitecturas de Administración de Red. ........................................................... 4

1.2.1 Arquitectura centralizada. ............................................................................ 4

1.2.2 Arquitectura Distribuida. ............................................................................... 5

1.2.3 Arquitectura Jerárquica. ............................................................................... 6

1.3 Modelos de administración y monitoreo de redes. ............................................. 7

1.3.1 Modelo OSI (FCAPS). .................................................................................. 8

1.3.2 Modelo de administración TMN. ................................................................ 14

1.4 Gestión de Niveles de Servicio. ....................................................................... 17

1.4.1 Indicadores de Nivel de Servicio. ............................................................... 19

1.4.2 Implementación de acuerdo de nivel de servicio. ...................................... 22

1.4.3 Monitoreo de los niveles de servicio. ......................................................... 23

1.4.4 Revisión de los acuerdos de nivel de servicio. .......................................... 24

CAPITULO II CONCEPTOS BÁSICOS DE PROTOCOLOS TCP/IP. ....................... 26

2.1 Protocolo de control de transmisión (TCP). ..................................................... 26

2.2 Protocolo Internet (IP). ..................................................................................... 27

2.3 Protocolo de datagramas de usuario (UDP). ................................................... 28

2.3.1 Características del protocolo UDP. ............................................................ 29


II

2.4 Protocolo de mensajes de control de Internet (ICMP). ..................................... 31

2.4.1 Mensajes informativos. .............................................................................. 32

2.4.2 Mensajes de error. ..................................................................................... 33

2.5 HTTP. ............................................................................................................... 35

CAPITULO III PROTOCOLOS Y HERRAMIENTAS TÍPICOS PARA MONITOREO. 38

3.1 SNMP. .............................................................................................................. 38

3.2 SYSLOG. ......................................................................................................... 42

3.2.1 Prioridad. ................................................................................................... 43

3.2.2 Cabecera. .................................................................................................. 45

3.2.3 Texto. ......................................................................................................... 45

3.3 NTP. ................................................................................................................. 46

3.3.1 Modos de operación. ................................................................................. 48

3.3.2 SNTP. ........................................................................................................ 48

3.4 IP SLA (Cisco). ................................................................................................. 48

3.4.1 Beneficios de Cisco IP SLA. ...................................................................... 51

3.4.2 Funcionamiento. ............................................................................................ 52

CAPITULO IV CASO PRÁCTICO. ............................................................................ 57

4.1 Monitoreo de los SLA con Cisco IP SLA. ......................................................... 57

4.2 Escenario Planteado. ....................................................................................... 58

4.2.1 Selección de la operación correcta. ........................................................... 59

4.2.2 Selección del intervalo de muestreo adecuado ......................................... 62

4.2.3 Selección de los umbrales de servicio ....................................................... 62

4.2.4 Monitoreo con IP SLA monitor. .................................................................. 65

CONCLUSIONES. ..................................................................................................... 69

GLOSARIO ................................................................................................................ 70

REFERENCIAS ......................................................................................................... 75


III

INDICE DE FIGURAS

Figura 1.1 Modelo Básico de Administración. .......................................................... 4

Figura 1.2 Arquitectura Centralizada. ....................................................................... 5

Figura 1.3 Arquitectura distribuida ........................................................................... 5

Figura 1.4 Arquitectura Jerárquica ........................................................................... 7

Figura 1.5 Tareas del Modelo FCAPS ..................................................................... 8

Figura 1.6 Capas del Modelo TNM ........................................................................ 16

Figura 1.7 Gestión de Niveles de Servicio ............................................................. 19

Figura 2.1. Encabezado protocolo UDP ................................................................. 30

Figura 2.2 Cabecera ICMP .................................................................................... 32

Figura 3.1 Arquitectura NTP. ................................................................................. 47

Figura 4.1 Ejemplo de monitoreo de SLA. ............................................................. 58

Figura 4.3 Tiempos de respuesta en operación http .............................................. 61

Figura 4.4 Configuración para obtener los umbrales de servicio. .......................... 63

Figura 4.5 Configuración para obtener los umbrales de servicio. .......................... 64

Figura 4.6 Configuración de IP SLA Monitor .......................................................... 66

Figura 4.7 Configuración de Umbrales de Nivel de Servicio .................................. 67

Figura 4.8 Alarmas obtenidas con IP SLA Monitor. ................................................ 68

INDICE DE TABLAS

Tabla 2.1. Tipos de Mensajes Informativos. ........................................................... 33

Tabla 2.2 Tipos de mensajes de error de ICMP ..................................................... 34

Tabla 3.1 Códigos de Recurso ............................................................................... 43

Tabla 3.2 Códigos de Severidad ............................................................................ 44

Tabla 3.3. SLA tradicional versus Cisco IP SLA .................................................... 54

Tabla 4.1. Tiempos de respuesta obtenidos para calculo de umbral ..................... 65


IV

OBJETIVO.

Implementar mediante la herramienta de Cisco IP SLA’s el monitoreo de páginas

web para garantizar el cumplimiento de los acuerdos de nivel de servicio.


V

PLANTEAMIENTO DEL PROBLEMA.

En la actualidad diversas funciones en las organizaciones, se realizan a través de

internet, específicamente por medio de páginas web, como son el comercio

electrónico, acceso a bases de datos remotas, manejo de cuentas, etcétera. Por lo

tanto es necesario garantizar la disponibilidad y operatividad de los servicios en la

página web de la organización, ya que la interrupción de estos servicios se traduce

en pérdidas económicas para la organización.

Mediante los acuerdos de nivel de servicio la organización puede trasladar estas

pérdidas, por medio de sanciones, a los proveedores o área encargada de brindar el

servicio web, estos últimos deben monitorizar que dichos acuerdos se cumplan,

según los indicadores establecidos para así evitar las posibles sanciones, a través

del monitoreo constante y poder generar las alarmas pertinentes en caso de que el

servicio caiga.

Cisco nos brinda herramientas ya integradas en sus dispositivos de ruteo que

permiten el monitoreo del tiempo de respuesta, mediante el envió de alertas

automatizadas en caso de que se encuentre alguna anomalía al momento de realizar

el monitoreo


VI

JUSTIFICACIÓN.

Para las organizaciones cuyas actividades se centran en los servicios web es

importante el mantener la calidad del servicio, para eso se crean un contrato

conocido como acuerdo de nivel de servicio, en el cual se asegura que el proveedor

del servicio tiene que mantener la disponibilidad de los servicios web que ofrecen

como son: bases de datos, archivos en servidores remotos, servicio de correo

electrónico, etcétera.

En los últimos años se han dado casos de ataques de denegación de servicio en la

web como lo han reportado Amazon, Google, Microsoft y Sony, quienes han sido

víctimas de este tipo de ataques. Se puede decir que el mayor afectado fue el

usuario final, el cual no tuvo con los servicios que estas empresas ofrecen, lo que se

traduce en pérdidas de clientes.

El monitoreo de los acuerdos de nivel de servicio, también ofrece la capacidad de

reaccionar a ciertas anomalías que pudieran indicar alguna amenaza a través de

alertas que llegan al administrador, el cual debe hacer un análisis de lo que está

ocurriendo en la red.


VII

INTRODUCCIÓN

La presente tesina es una implementación de la herramienta de monitoreo IP SLA

distribuida en los routers Cisco, que tiene como objetivo demostrar que mediante

esta herramienta es posible garantizar la disponibilidad y operatividad de los

servicios en una página web de alguna organización.

Se pretende mostrar cómo se calculan los umbrales para un escenario planteado, si

al realizar el monitoreo dichos umbrales fueran sobrepasados, se notifica mediante

alertas indicándonos la gravedad de la situación, de esta forma tendrá un indicador

cuando se presente alguna anomalía en la conexión con el servidor HTTP, y así

mismo el riesgo que conlleva con la disponibilidad del servicio web. De este modo

un proveedor de servicios puede tener la capacidad de reaccionar ante ciertas

anomalías que puedan presentarse mediante este sistema de alarmas generadas.


1

CAPITULO I CONCEPTOS DE ADMINISTRACIÓN Y MONITOREO DE REDES.

La administración de redes es un proceso de control, supervisión, previsión y

corrección de fallas para el óptimo funcionamiento de la red mediante el uso de

herramientas de gestión.

Sus objetivos son:

1. Mejorar la continuidad en la operación de la red.

2. Hacer uso eficiente de la red.

3. Reducir costos por medio del control de gastos y de mejores mecanismos de

cobro.

4. Hacer la red más segura.

5. Controlar cambios y actualizaciones en la red de modo que ocasionen las

menores interrupciones posibles, en el servicio a los usuarios.

El sistema de administración de red opera bajo las siguientes directivas:

1. Colección de información acerca del estado de la red y componentes del

sistema. La información recolectada de los recursos debe incluir: eventos,

atributos y acciones operativas.


2

2. Transformación de la información para presentarla en formatos apropiados

para el entendimiento del administrador.

3. Transporte de la información del equipo monitoreado al centro de control.

4. Almacenamiento de los datos coleccionados en el centro de control.

5. Análisis de parámetros para obtener conclusiones que permitan deducir

rápidamente lo que pasa en la red.

6. Actuación para generar acciones rápidas y automáticas en respuesta a una

falla mayor.

1.1 Elementos de la Administración de Red con SNMP.

La administración con el protocolo SNMP para el monitoreo de red se basa en

el modelo tradicional cliente-servidor compuesto por estaciones gestoras y

dispositivos administrados o agentes.

1.1.1 NMS (Network Management Stations).

Son los dispositivos independientes que sirven como interfaz entre el

administrador y la red. Poseen software que recibe información de

administración de los dispositivos gestionados o nodos.

Sus principales características son:

1. Aplicación de la administración donde se analizan los datos.

2. Interfaz que permite al administrador gestionar la red.

3. Control de dispositivos remotos.


3

4. Una base de información extraída de las diferentes MIBs

(Management Information Base).

1.1.2 Agentes.

Son programas o un conjunto de programas que se encuentran en los

nodos y recolectan información de estos; a esta colección se le cose

como MIB.

Transmite información a la NMS acerca de:

1. Notificación de problemas.

2. Datos de diagnóstico.

3. Identificador del nodo.

4. Características del nodo.

1.1.3 Protocolo.

Es el encargado de la comunicación entre el gestor y el agente,

dependiendo el modelo de gestión implementado.

En la figura 1.1 se muestran los elementos básicos de administración,

en donde el protocolo se encarga de transmitir la información del

agente de monitorización hacia el NMS, también debe dar respuesta a

las solicitudes de este en caso de alguna anomalía.


4

Figura 1.1 Modelo Básico de Administración.

1.2 Arquitecturas de Administración de Red.

La mayoría de las arquitecturas para la administración de redes utilizan la

misma estructura y conjuntos básicos de relaciones. Las estaciones

terminales, como los sistemas de cómputo y otros dispositivos de red, utilizan

un software que les permite enviar mensajes de alerta cuando se detecta

algún problema. Al recibir estos mensajes de alerta las entidades de

administración son programadas para reaccionar, ejecutando una o varias

acciones que incluyen la notificación al administrador, el cierre del sistema, y

un proceso automático para la posible reparación del sistema.

Se tienen tres tipos de arquitecturas centralizada, distribuida y jerárquica.

1.2.1 Arquitectura centralizada.

En esta arquitectura todas las consultas son enviadas a un sistema de

administración simple, como se muestra en la figura 1.2. Todas las

aplicaciones de administración son instaladas en un solo NMS que

NMS (Network

Management

Stations) Protocolo

Agente de

Monitorización


5

también responde a todos los avisos de los agentes. Si bien es fácil de

manejar, un solo NMS puede llegar a sobrecargarse fácilmente.

Figura 1.2 Arquitectura Centralizada.

1.2.2 Arquitectura Distribuida.

En una arquitectura distribuida se pueden tener varios NMS, ya sea

por ubicación geográfica o para asignar a cada NMS la responsabilidad

de dispositivos específicos.

El tener varios NMS evita que éstos se sobrecarguen, sin embargo,

limita las características del modelo centralizado ya que solo pueden

enviarse mensajes entre ellas pero no pueden actualizar consultas o

resultados de bases de datos de agentes administrados por otras NMS,

como se muestra en la Figura 1.3.

NMS

Agente Agente Agente


6

Figura 1.3 Arquitectura distribuida

1.2.3 Arquitectura Jerárquica.

La arquitectura jerárquica es una combinación de la centralizada y

distribuida. Se tiene una NMS centralizada que solo coordina consultas

enviadas de entidades NMS adicionales.

Se puede delegar varias tareas y responsabilidades a varios sistemas

en la red, de esta manera se mantiene y almacena la información de

una manera centralizada y sin embargo asegura que los sistemas

distribuidos sean responsables del procesamiento de consultas y

respuestas.

La principal desventaja de este sistema es que su complejidad aumenta

bastante.

En la figura 1.4 se muestra una arquitectura distribuida donde el NMS

central almacena toda la información de los agentes, y los NMS 1 y 2

se encargan de administrar a sus propios agentes.

NMS

Agente Agente

NMS

Agente Agente


7

Figura 1.4 Arquitectura Jerárquica

1.3 Modelos de administración y monitoreo de redes.

La administración y monitoreo tienen una gran importancia ya que este

se emplean para mantener el correcto funcionamiento de la red. Nos

permiten realizar un análisis completo en la búsqueda de posibles fallas

que pudieran presentarse en el funcionamiento de la red, así como,

garantizar óptimo rendimiento, ya que permite informar a los

administradores o automatizar reacciones cuando llega a ocurrir alguna

falla en la red.

Existen diversos modelos para implementar una adecuada

administración de red a continuación se describirán algunos de ellos.

NMS(Central)

NMS1

Agente Agente

NMS2

Agente Agente


8

1.3.1 Modelo OSI (FCAPS).

La ITU (International Telecomunicatión Union) desarrollo el concepto

de FCAPS (Fault, Configuration, Accounting, Performance,

Security), como asistencia para la administración de redes de

telecomunicaciones en la norma ITU-M.3400. Sin embargo fue la ISO

(International Standards Organitation) quien aplico este concepto a

redes de datos y lo denomino OSI (Open Systems Interconnect).

Como se muestra en la figura 1.5 FCAPS es un modelo que separa las

tareas de la administración del sistema en 5 categorías permitiendo una

mejor organización y no requiere de un protocolo específico.

Figura 1.5 Tareas del Modelo FCAPS

Fault

Configuration

Acconting

Performance

Security


9

Estas capas se describen a continuación.

Gestión de fallas: Una falla es cualquier anormalidad en el servicio y

perjudica el rendimiento de la red, por lo que la detección y corrección

inmediata son indispensables.

La Gestión de Fallas es un conjunto de funciones que permiten

detectar, aislar y corregir un funcionamiento anormal en la red y su

entorno.

Sus objetivos son:

Reconocer, aislar, corregir y registrar los problemas que ocurren

en la red.

Monitoreo continuo.

Establecimiento de alarmas.

Análisis de tendencias para predecir posibles errores.

Notificar de manera automática al administrador cuando ocurra

algún problema.

Procedimiento para la gestión de fallas:

1. Monitoreo continuo de los componentes de red

2. Identificación exacta de la ubicación de la falla.

3. Aislamiento de la falla para que la red opere sin interferencia.

4. Reacción ante la falla estableciendo su resolución.


10

5. Asignar recursos suficientes para su resolución.

6. Proveer una solución.

7. Notificación, creación de reportes de estado y seguimiento de la

reparación.

Gestión de configuración: La gestión de la configuración

proporciona las funciones para ejercer el control sobre la identificación,

recolección y suministro de datos de los elementos de red.

Por medio de este proceso se inicializan, identifican, configuran y

controlan las operaciones diarias de los dispositivos que conforman a la

red.

Sus objetivos son:

Obtener información para establecer ajustes y modificaciones de

configuración tanto de hardware o software.

Eliminación de los componentes obsoletos.

Generación de reportes y gestión de cambios dentro de la red.

En esta gestión se debe tener en cuenta:

Un acceso rápido a la información sobre configuraciones.

Un inventario continuamente actualizado de los elementos de la

red y la configuración de los recursos.

Facilidad de acceso remoto a los dispositivos


11

Simplificación de la configuración de los equipos

Gestión de análisis de datos: Contabiliza el tráfico generalmente por

elementos y enlaces de la red. Los sistemas de monitoreo recolectan a

diario esta información para almacenarla en una base de datos a fin de

generar información útil y manejable para diferentes objetivos.

Identificar el uso ineficiente de la red.

Evitar sobrecargas dentro de la red y perjuicios a otros usuarios.

Planificar el crecimiento de la red.

Verificar los servicios a los usuarios en función de sus

necesidades.

Gestión de rendimiento: Provee información del desempeño y calidad

actual, recolecta y analiza datos de rendimiento con el fin de asegurar

que las prestaciones estén acorde a la necesidad de los usuarios.

Permite establecer un historial estadístico de sucesos, para tomar

medidas preventivas y correctivas ante posibles conflictos que

degraden la calidad de los servicios prestados.

La supervisión de la calidad de funcionamiento comprende los

siguientes conjuntos de funciones:

Funciones de política de supervisión de la calidad de

funcionamiento.


12

Funciones de correlación y filtrado de eventos de supervisión de

la calidad de funcionamiento de la red.

Funciones de acceso a datos agregados e información para

pronóstico.

Funciones de recolección de datos específicos de la red.

Funciones sobre la situación del tráfico.

Funciones de supervisión del funcionamiento del tráfico.

Funciones de procesamiento de alertas por sobrepasar los

umbrales de los elementos de red.

Funciones de análisis de las tendencias de los elementos de red.

Funciones de acumulación de datos y supervisión de la calidad

del funcionamiento.

Funciones de detección, cómputo y almacenamiento de la

información.

La información recolectada del monitoreo debe ser interpretada a fin de

determinar el comportamiento de la red y tomar mediadas que ayuden

a mejorar su rendimiento. Se pueden detectar comportamientos

relacionados a:

Utilización elevada. Utilización en altos niveles de los

dispositivos o enlaces.


13

Trafico inusual. El tráfico fuera de los patrones normales aporta

elementos importantes en la resolución de problemas de

rendimiento.

Elementos principales. Al identificarse los elementos que más

reciben y transmiten información se puede establecer un

monitoreo más constante debido a su importancia. La detección

de elementos que generalmente no se encuentra dentro de un

patrón de equipos con más actividad ayuda a la detección de

posibles ataques a la seguridad.

Calidad de servicio. Garantizar las condiciones necesarias a

aplicaciones que requieren de un trato especial, como son VoIP,

video, entre otros.

Control de tráfico. El tráfico puede ser reenviado o ruteado por

otro camino cuando se detecte saturación en un enlace o al

detectar que se encuentra fuera de servicio.

Gestión de seguridad: Controla el acceso a los recursos de la red y

se protege la información para evitar alteraciones. Mediante la

implementación de controles de acceso, políticas, procedimientos o

funciones de software, dividendo recursos dentro de áreas autorizadas

y no autorizadas.


14

La gestión de seguridad sigue los siguientes puntos:

Identificación de la información que se quiere proteger y su

ubicación.

Identificación de los puntos de acceso a la información.

Protección y mantenimiento de los puntos de acceso a la

información.

1.3.2 Modelo de administración TMN.

El objetivo de TMN (Telecommunications Management Network) es

proporcionar una estructura de red organizada para interconectar

distintos tipos de sistemas de administración y dispositivos de

telecomunicación. Tiende a ser flexible escalable y confiable.

Se orienta hacia la cooperación entre los sistemas de gestión

individuales para conseguir un efecto coordinado en la red usando un

conjunto de arquitecturas siguientes:

Arquitectura funcional define la funcionalidad del modelo TNM en un

conjunto de bloques funcionales que se describen a continuación.

Bloque OSF (Operations System Functions): Lleva a cabo

funciones típicas de una administración gestor-agente.


15

Bloque NEF (Network Element Functions): Agrupa las funciones

que permiten a los elementos de red actuar como agentes de

gestión.

Bloque WSF (Work Station Functions): Otorga los medios

necesarios para conectar al usuario con el sistema de

operaciones.

Bloque QAF (Q Adaptor Functions): Permite la administración de

elementos de red que posean un sistema de gestión que no

soporten TMN.

Bloque MD (Mediation Function): Actúa sobre la información que

llega de los NEF y de los QAF para adaptarla, filtrarla y

condensarla al formato usado por los OSF.

Arquitectura física muestra la manera en que los bloques funcionales se

pueden implementarse en los dispositivos físicos interconectados

mediante interfaces.

Arquitectura de información está basada sobre un modelo orientado a

objetos y define el formato en que los datos se transmiten entre los

datos funcionales.

Arquitectura organizativa introduce una relación jerárquica entre los

diferentes sistemas de operación existentes en la red, de tal manera

que existan gestores de bajo nivel para la solución de problemas


16

técnicos y gestores de alto nivel encargados que garantizar la calidad

del servicio.

Como se muestra en la figura 1.6 el modelo TMN define las siguientes

cuatro capas de la arquitectura organizativa:

Capa de gestión de elemento de red (NE).

Capa de gestión de red.

Capa de gestión de servicio.

Capa de gestión de negocio.

Figura 1.6 Capas del Modelo TNM


17

1.4 Gestión de Niveles de Servicio.

La gestión de niveles de servicio es el proceso por el cual se definen,

negocian y supervisan la calidad de los servicios de tecnologías de

información (TI) ofrecidas.

La gestión de niveles de servicio es responsable de buscar un compromiso

realista entre las necesidades y expectativas del cliente y los costos de los

servicios asociados, de forma que estos sean accesibles tanto por el cliente

como por la organización TI.

El objetivo primordial de la gestión de niveles de servicio es definir, negociar y

monitorizar la calidad de los servicios ofrecidos. Si los servicios no se adecuan

a las necesidades del cliente, la calidad de los mismos es deficiente o sus

costos son desproporcionados, tendremos clientes insatisfechos y la

organización TI será responsable de las consecuencias que se deriven de ello.

La gestión de los niveles de servicio debe:

Documentar todos los servicios TI ofrecidos.

Presentar los servicios de forma comprensible para el cliente.

Centrarse en el cliente y su negocio y no en la tecnología.

Colaborar estrechamente con el cliente para proponer servicios TI

realistas y ajustados a sus necesidades.

Establecer los acuerdos necesarios con clientes y proveedores para

ofrecer los servicios requeridos.


18

Establecer los indicadores claves de rendimiento del servicio TI.

Monitorear la calidad de los servicios acordados con el objetivo último

de mejorarlos a un costo aceptable por el cliente.

Elaborar los informes sobre la calidad del servicio y los planes de

mejora del servicio (SIP).

Las principales actividades de la gestión de niveles de servicio se resumen en:

Planificación:

o Asignación de recursos.

o Elaboración de un catálogo de servicios.

o Desarrollo de SLAs.

o Herramientas para la monitorización de la calidad del servicio.

o Análisis e identificación de las necesidades del cliente.

o Elaboración del los requisitos de nivel de servicio (SLR) e

indicadores de nivel de servicio.

Implementación de los acuerdos de nivel del servicio:

o Negociación.

o Acuerdos de nivel de operación.

o Contratos de soporte.

Supervisión y revisión de los acuerdos de nivel de servicio:

o Elaboración de informes de rendimiento.

o Control de los proveedores externos.

o Elaboración de programas de mejora del servicio (SIP).


19

En la figura 1.7 podemos ver el diagrama de flujo que representa las etapas y

resultados de los de la Gestión de Niveles de Servicio

Figura 1.7 Gestión de Niveles de Servicio

1.4.1 Indicadores de Nivel de Servicio.

Para cada servicio considerado, se debe identificar y definir claramente

el indicador de nivel de servicio a utilizar. También se debe incluir una

descripción de cómo se mide el indicador.

Estos indicadores deben cumplir las siguientes características:

Petición del cliente

Planificación

Implementación

Monitorización

Revisión

SRL

SLA

Informes

SIP


20

Alcanzable. Los niveles de servicio deben ser logrables pues de

nada sirve establecer objetivos para el nivel de servicio que el

proveedor del servicio sabe de antemano que no podrá alcanzar.

Medible. Los indicadores definidos se deben poder medir, para lo

cual se debe disponer de los datos que lo componen, además

estos datos deben ser percibidos por ambas partes, cliente y

proveedor, como objetivos.

Con significado. Los indicadores deben tener un significado claro

para ambas partes de modo que sean útiles, en general los

indicadores propios de las organizaciones de TI no tienen

significado o no se entienden por los clientes, ya que entregan

una visión fragmentada del problema.

Controlable. El factor debe ser controlable por el proveedor del

producto o servicio para que pueda definirse un nivel de servicio.

Hay factores que pueden ser muy útiles, pero que están fuera

del control del proveedor directo, como por ejemplo un enlace

satelital.

Mutuamente aceptado. Un indicador de nivel de servicio, para

que sea válido, debe ser aceptado como tal por el proveedor y

por el cliente y de ninguna manera debe ser impuesto por alguna

de las partes. Esto es especialmente importante si el indicador

se va a usar en un acuerdo de servicio.


21

Costo-eficiente. El indicador, así como el nivel de calidad de

servicio a ofrecer, deben poder generarse a un costo razonable,

para que tenga sentido. El costo de obtener un indicador o un

reporte de servicio no debe superar el beneficio que significa

disponer de éste. En general se tiende a pensar que el costo de

obtener un reporte de servicio es despreciable, sin embargo hay

costos reales e incrementales de recolectar y analizar los datos

necesarios para generar dicho reporte.

Uno de los indicadores más importante para el cliente es el tiempo de

respuesta final (end to end) para transacciones en línea. Los

proveedores de servicio deben ser muy cautos al incorporar este

indicador en el acuerdo, ya que es muy difícil de medir en forma

precisa. Además, la medición tomada por el proveedor debe reflejar

más o menos lo que el usuario ve, de modo que éste no invalide el

indicador.

Un aspecto muy importante que se debe tener presente al definir

indicadores de nivel de servicio es que se requiere de creatividad. Es

efectivo que los indicadores deben ser medibles, lo que quiere decir

que debe existir una fuente de datos para esa información. Sin

embargo, no siempre existe una única fuente de que provea los datos

exactos que se requieren. En algunos casos fuentes alternativas

pueden entregar el mismo resultado y en otros casos es necesario

correlacionar datos de distintas fuentes para tener la visión final. A


22

veces, por ejemplo, es necesario analizar los eventos registrados en el

sistema de ayuda para generar los valores de un indicador.

En un SLA se pueden establecer tantos indicadores como se estime

necesario y de su evaluación se obtienen por ejemplo penalizaciones a

la empresa suministradora, identificación de puntos débiles del proceso

e indicaciones para procesos de mejora continua en determinadas

actividades

1.4.2 Implementación de acuerdo de nivel de servicio.

Un acuerdo de nivel de servicio o SLA (Service Level Agreement), es

un contrato en el que se estipulan los niveles de un servicio en función

de una serie de parámetros objetivos, establecidos de mutuo acuerdo

entre el cliente y el prestador del servicio. No está implicado

necesariamente con la contratación de servicios a terceras partes, sino

que puede implantarse a nivel interno, transformando una determinada

unidad de negocio en centro de servicios que provea a la propia

organización.

Un SLA tratará de mantener y de garantizar la calidad de un servicio

brindado a un cliente, mantener la disponibilidad de un determinado

servicio basado en un compromiso que puede ser medido y

demostrado.


23

Los SLA’s deben contener una descripción del servicio que abarque

desde los aspectos más generales hasta los detalles más específicos

del servicio.

Es conveniente estructurar los SLAs más complejos en diversos

documentos de forma que cada grupo involucrado reciba

exclusivamente la información correspondiente al nivel en que se

integra, ya sea en el lado del cliente como del proveedor.

La elaboración de un SLA requiere tomar en cuenta aspectos no

tecnológicos entre los que se encuentran:

La naturaleza del negocio del cliente.

Aspectos organizativos del proveedor y cliente.

Aspectos culturales locales.

1.4.3 Monitoreo de los niveles de servicio.

El proceso de monitoreo de los niveles de servicio es imprescindible si

queremos mejorar progresivamente la calidad del servicio ofrecido, su

rentabilidad y la satisfacción de los clientes y usuarios.

El monitoreo de la calidad del servicio requiere el seguimiento tanto de

procedimientos y parámetros internos de la organización como los

relacionados con la percepción de los usuarios.


24

Para llevar a cabo esta tarea de manera eficiente es necesario haber

establecido con anterioridad ciertos indicadores de calidad del servicio

que han de servir de guía en la elaboración de los informes

correspondientes.

Los informes de rendimiento elaborados deben cubrir factores clave

tales como:

Cumplimiento de los SLAs, con información sobre la frecuencia y

el impacto de los incidentes responsables de la degradación del

servicio.

Quejas, justificadas o no, de los clientes y usuarios.

Utilización de la capacidad predefinida.

Disponibilidad del servicio.

Tiempos de respuesta.

Costos reales del servicio ofrecido.

Problemas detectados y cambios realizados para restaurar la

calidad del servicio.

1.4.4 Revisión de los acuerdos de nivel de servicio.

La correcta gestión de los niveles de servicio es un proceso continuo

que requiere la continua revisión de la calidad de los servicios

ofrecidos.


25

Esta revisión debe realizarse en base a parámetros objetivos y

medibles, resultado de la experiencia previa de los SLA’s en vigencia

Este proceso de revisión no debe limitarse a aquellos SLA’s que por

una razón u otra han sido incumplidos, aunque, evidentemente, en

estos casos sea inexcusable, sino que debe tener como objetivo

mejorar y homogeneizar la calidad del servicio.

El resultado de la revisión debe ser un programa de mejora del servicio

(SIP) que tome en cuenta factores tales como:

Problemas relacionados con el servicio TI y sus posibles causas.

Nuevas necesidades del cliente.

Avances tecnológicos.

Cumplimiento de los niveles de servicio.

Evaluación de los costos reales del servicio.

Implicaciones de una degradación de la calidad del servicio en la

estructura organizativa del cliente.

Reasignación de recursos.

Percepción del cliente y usuarios sobre la calidad de servicio.

Necesidades de formación adicional a los usuarios de los

servicios.


26

CAPITULO II CONCEPTOS BÁSICOS DE PROTOCOLOS TCP/IP.

2.1 Protocolo de control de transmisión (TCP).

El TCP (Transmission Control Protocol) es el responsable de la transmisión fiable

de datos desde un nodo a otro. Es un protocolo orientado a la conexión y

establece una conexión (también conocida como una sesión, circuito virtual o

enlace) entre dos máquinas antes de transferir ningún dato. Para establecer

una conexión fiable, TCP utiliza lo que se conoce como “acuerdo en tres

pasos”. Establece el número de puerto y los números de secuencia de inicio

desde ambos lados de la transmisión. El acuerdo consta de tres pasos:

1. El solicitante envía al servidor un paquete especificando el número de

puerto que él planea utilizar y el número de secuencia inicial (SYN).

2. El servidor responde con su SYN, que consiste en el SYN del

solicitante más uno.

3. El solicitante responde a la respuesta del servidor con el SYN del

servidor más uno.


27

En orden a mantener una conexión fiable, cada paquete tiene que contener:

Un número de puerto TCP origen y destino.

Un número de secuencia para mensajes que tienen que dividirse en

partes más pequeñas.

Un checksum que asegura que la información se ha recibido sin error.

Un número de confirmación que indica a la máquina origen qué partes

de la información han llegado.

Ventanas deslizantes (sliding windows) TCP.

2.2 Protocolo Internet (IP).

El IP (Internet Protocol) es un protocolo de conmutación de paquetes que

realiza direccionamiento y ruteo. Cuando se transmite un paquete, este

protocolo añade una cabecera al paquete, de forma que pueda enviarse a

través de la red utilizando las tablas de encaminamiento dinámico. IP es un

protocolo no orientado a la conexión y envía paquetes sin esperar la señal de

confirmación por parte del receptor. Además, IP es el responsable del

empaquetado y división de los paquetes requeridos por el nivel físico y de

enlace de datos del modelo OSI. Cada paquete IP está compuesto por una

dirección de origen y una de destino, un identificador de protocolo, un

checksum (un valor calculado) y un tiempo de vida TTL (Time To Live). El TTL

indica a cada uno de los routers de la red entre el origen y el destino cuánto


28

tiempo le queda al paquete por estar en la red. Funciona como un contador o

reloj de cuenta atrás. Cuando el paquete pasa por el router, éste reduce el

valor en una unidad (un segundo) o el tiempo que llevaba esperando para ser

entregado. Por ejemplo, si un paquete tiene un TTL de 128, puede estar en la

red durante 128 segundos o 128 saltos para cada parada, o router, en la red,

o en combinación de los dos. El propósito del TTL es prevenir que los

paquetes perdidos o dañados (como correos electrónicos con una dirección

equivocada) estén vagando en la red. Cuando la cuenta TTL llega a cero, se

retira al paquete de la red.

2.3 Protocolo de datagramas de usuario (UDP).

UDP (User Datagram Protocol) es un protocolo no orientado a la conexión y

es el responsable de la comunicación de datos extremo a extremo. A

diferencia de TCP, UDP no establece una conexión, intenta enviar los datos e

intenta comprobar que el host de destino recibe los datos. UDP se utiliza para

enviar pequeñas cantidades de datos que no necesitan una entrega

garantizada. Aunque UDP utiliza puertos, son distintos de los puertos TCP; así

pues, pueden utilizar los mismos números sin interferirse.

UDP ofrece a las aplicaciones un mecanismo para enviar datagramas IP en

bruto encapsulados sin tener que establecer una conexión. Muchas

aplicaciones cliente-servidor que tienen una solicitud y una respuesta usan el

UDP en lugar de tomarse la molestia de establecer y luego liberar una


29

conexión, UDP se describe en el RFC 768. Un segmento UDP consiste en una

cabecera de 8 bytes seguida de los datos. La cabecera se muestra a

continuación. Los dos puertos sirven para lo mismo que en el TCP: para

identificar los puntos terminales de las máquinas origen y destino. El campo

de longitud UDP incluye la cabecera de 8 bytes y los datos. La suma de

comprobación UDP incluye la misma pseudocabecera de formato, la cabecera

UDP y los datos, rellenados con una cantidad par de bytes, de ser necesario.

UDP no admite numeración de los datagramas, factor que, sumado a que

tampoco utiliza señales de confirmación de entrega, hace que la garantía de

que un paquete llegue a su destino sea mucho menor que si se usa TCP. Esto

también origina que los datagramas puedan llegar duplicados o desordenados

a su destino. Por estos motivos el control de envío de datagramas, si existe,

debe ser implementado por las aplicaciones que usan UDP como medio de

transporte de datos, al igual que el re-ensamble de los mensajes entrantes. Es

por ello un protocolo del tipo best-effort (máximo esfuerzo), porque hace lo

que puede para transmitir los datagramas hacia la aplicación, pero no puede

garantizar que la aplicación los reciba.

2.3.1 Características del protocolo UDP.

Este protocolo es muy simple ya que no proporciona detección de

errores (no es un protocolo orientado a conexión).

Por lo tanto, el encabezado del segmento UDP es muy simple y se

muestra en la figura 2.1:


30

puerto de origen (16 bits);

puerto de destino (16 bits);

longitud total (16 bits);

suma de comprobación del encabezado

(16 bits);

datos (longitud variable).

Figura 2.1. Encabezado protocolo UDP

Puerto de origen: es el número de puerto relacionado con la aplicación

del remitente del segmento UDP. Este campo representa una dirección

de respuesta para el destinatario. Por lo tanto, este campo es opcional.

Esto significa que si el puerto de origen no está especificado, los 16 bits

de este campo se pondrán en cero. En este caso, el destinatario no

podrá responder (lo cual no es estrictamente necesario, en particular

para mensajes unidireccionales).

Puerto de destino: este campo contiene el puerto correspondiente a la

aplicación del equipo receptor al que se envía.

Longitud: este campo especifica la longitud total del segmento, con el

encabezado incluido. Sin embargo, el encabezado tiene una longitud de

4 x 16 bits (que es 8 x 8 bits), por lo tanto la longitud del campo es

necesariamente superior o igual a 8 bytes.

Suma de comprobación: es una suma de comprobación realizada de

manera tal que permita controlar la integridad del segmento.


31

2.4 Protocolo de mensajes de control de Internet (ICMP).

ICMP (Internet Control Message Protocol) es de características similares a

UDP, pero con un formato mucho más simple, y su utilidad no está en el

transporte de datos de usuario, sino en controlar si un paquete no puede

alcanzar su destino, si su vida ha expirado, si el encabezamiento lleva un valor

no permitido, si es un paquete de eco o respuesta, etc. Es decir, se usa para

manejar mensajes de error y de control necesarios para los sistemas de la

red, informando con ellos a la fuente original para que evite o corrija el

problema detectado. ICMP proporciona así una comunicación entre el

software IP de una máquina y el mismo software en otra.

El protocolo ICMP solamente informa de incidencias en la entrega de

paquetes o de errores en la red en general, pero no toma decisión alguna al

respecto. Esto es tarea de las capas superiores.

Los mensajes ICMP se transmiten como datagramas IP normales, con el

campo de cabecera "protocolo" con un valor 1, y comienzan con un campo de

8 bits que define el tipo de mensaje de que se trata. A continuación viene un

campo código, de 0 bits, que a veces ofrece una descripción del error concreto

que se ha producido y después un campo suma de control, de 16 bits, que

incluye una suma de verificación de errores de transmisión. Tras estos

campos viene el cuerpo del mensaje, determinado por el contenido del campo

"tipo". Contienen además los 8 primeros bytes del datagrama que ocasionó el

error. Como se puede observar en la figura


32

Figura 2.2 Cabecera ICMP

Los principales tipos de mensaje ICMP son los siguientes:

2.4.1 Mensajes informativos.

Entre estos mensajes hay algunos de suma importancia, como los

mensajes de petición de echo (tipo 8) y los de respuesta de echo (tipo

0). Las peticiones y respuestas de eco se usan en redes para

comprobar si existe una comunicación entre dos host a nivel de capa

de red, por lo que nos pueden servir para identificar fallos en este nivel,

ya que verifican si las capas física (cableado), de enlace de datos

(tarjeta de red) y red (configuración IP) se encuentran en buen estado y

configuración, algunos tipos de mensajes se describen en la tabla 2.1.


33

Tabla 2.1. Tipos de Mensajes Informativos.

0 Respuesta de eco (Echo Reply)

3 Destino inaccesible (Destination Unreacheable)

4 Disminución del tráfico desde el origen (Source Quench)

5 Redireccionar - cambio de ruta (Redirect)

8 solicitud de eco (Echo)

11 Tiempo excedido para un datagrama (Time Exceeded)

12 Problema de parámetros (Parameter Problem)

13 Solicitud de marca de tiempo (Timestamp)

14 Respuesta de marca de tiempo (Timestamp Reply)

15 Solicitud de información (Information Request) - obsoleta-

16 Respuesta de información (Information Reply) - obsoleta-

17 Solicitud de máscara de dirección (Addressmask)

18 Respuesta de máscara de dirección (Addressmask Reply)

2.4.2 Mensajes de error.

Este tipo de mensajes se generan cuando el tiempo de vida del

datagrama a llegado a cero mientras se encontraba en tránsito hacia el

host destino (código=0), o porque, habiendo llegado al destino, el

tiempo de reensamblado de los diferentes fragmentos expira antes de

que lleguen todos los necesarios (código=1), los tipos mas comunes se

error se describen en la tabla 2.2.

Los mensajes ICMP de tipo= 12 (problemas de parámetros) se originan

por ejemplo cuando existe información inconsistente en alguno de los

campos del datagrama, que hace que sea imposible procesar el mismo


34

correctamente, cuando se envían datagramas de tamaño incorrecto o

cuando falta algún campo obligatorio.

Por su parte, los mensajes de tipo=5 (mensajes de redirección) se

suelen enviar cuando, existiendo dos o más routers diferentes en la

misma red, el paquete se envía al router equivocado. En este caso, el

router receptor devuelve el datagrama al host origen junto con un

mensaje ICMP de redirección, lo que hará que éste actualice su tabla

de enrutamiento y envíe el paquete al siguiente router.

Tabla 2.2 Tipos de mensajes de error de ICMP

0 No se puede llegar a la red

1 No se puede llegar al host o aplicación de destino

2 El destino no dispone del protocolo solicitado

3 No se puede llegar al puerto destino o la aplicación destino no está libre

4 Se necesita aplicar fragmentación, pero el flag correspondiente indica lo contrario

5 La ruta de origen no es correcta

6 No se conoce la red destino

7 No se conoce el host destino

8 El host origen está aislado

9 La comunicación con la red destino está prohibida por razones administrativas

10 La comunicación con el host destino está prohibida por razones administrativas

11 No se puede llegar a la red destino debido al Tipo de servicio

12 no se puede llegar al host destino debido al Tipo de servicio


35

2.5 HTTP.

Cada transacción de información realizada en la Web es realizada utilizando el

protocolo HTTP (HyperText Transfer Protocol) por sus siglas en inglés, o

Protocolo de Transferencia de HyperTexto.

De este modo, las peticiones de acceso a una página y la respuesta brindada

por la misma en forma de contenido de hipertexto utilizan este sistema de

comunicación, el cual permanece un oculto al usuario final. El protocolo http

es utilizado también para enviar formularios con campos de texto, u otro tipo

de información en ambos sentidos.

La conexiones realizadas mediante este protocolo no son guardadas por el

mismo en ningún sitio, es decir que se trata de un protocolo sin estado, los

datos se pierden, por lo tanto, cuando la transacción de los mismos ha

terminado, cosa que da lugar a las cookies que son archivos livianos que se

guardan en determinado sitio del disco duro con el objetivo de almacenar

información del usuario. De tal forma, el sitio Web sabrá de quién se trata al

volver a acceder al mismo, mostrando por ejemplo su nombre y o permitiendo

su acceso sin necesidad de ingresar contraseña, etc.

Las cookies también son utilizadas por ciertos sitios Web para llevar una

estadística de sus visitantes.


36

Es útil saber que los sitios web cuya dirección de Internet comienza con https

serán seguros; por lo general los navegadores web informan de esto

mostrando un fondo amarillo detrás del texto de la url, y algún candado.

El http facilita la definición de la sintaxis y semántica que utilizan los distintos

softwares web (tanto clientes, como servidores y proxys) para interactuar

entre sí.

Este protocolo opera por petición y respuesta entre el cliente y el servidor. A

menudo las peticiones tienen que ver con archivos, ejecución de un programa,

consulta a una base de datos, traducción y otras funcionalidades. Toda la

información que opera en la Web mediante este protocolo es identificada

mediante el url o dirección.

La típica transacción de protocolo http se compone de un encabezado seguido

por una línea en blanco y luego un dato. Este encabezado define la acción

requerida por el servidor.

Desde su creación, el http evolucionó en diversas versiones. Entre ellas, la

0.9, la 1.0, la 1.1 y la 1.2.

El protocolo de este tipo opera con códigos de respuesta de tres dígitos, que

comunican si conexión fue rechazada, si se realizó con éxito, si ha sido

redirigida hacia otro url, si existe un error por parte del cliente, o bien, por

parte del servidor.


37

Las aplicaciones y navegadores web tienden a complementar la acción del

http como ocurre, por ejemplo, con las denominadas “cookies”, que permiten

almacenar información de la sesión, función de la que no dispone este

protocolo, ya que opera sin estado.


38

CAPITULO III PROTOCOLOS Y HERRAMIENTAS TÍPICOS PARA MONITOREO.

3.1 SNMP.

SNMP (Simple Network Management Protocol), es un conjunto de

aplicaciones de gestión de red que emplea los servicios ofrecidos por TCP/IP,

es un protocolo de UNIX que ha llegado a convertirse en un estándar.

Para el protocolo SNMP la red constituye un conjunto de elementos básicos

Administradores o Management Stations ubicados en el o los equipos de

gestión de red y los gestores Network Agents elementos pasivos ubicados en

los nodos (host, routers, modems, multiplexores, etc.) a ser gestionados,

siendo los segundos los que envían información a los primeros, relativa a los

elementos gestionados, ya sea por iniciativa propia o al ser interrogados

(polling) de manera secuencial, apoyándose en los parámetros contenidos en

sus MIB. Su principal inconveniente es el exceso de tráfico que se genera, lo

que lo puede hacer incompatible para entornos amplios de red.

Las versiones de SNMP más utilizadas son SNMP versión 1 (SNMPv1) y

SNMP versión 2 (SNMPv2). SNMP en su última versión (SNMPv3) posee

cambios significativos con relación a sus predecesores, sobre todo en


39

aspectos de seguridad, sin embargo no ha sido mayoritariamente aceptado en

la industria.

Los cinco tipos de mensajes SNMP intercambiados entre los Agentes y los

Administradores, son:

Get Request.- Una petición del administrador al agente para que envíe

los valores contenidos en el MIB (base de datos).

Get Next Request.-Una petición del administrador al agente para que

envíe los valores contenidos en el MIB referente al objeto siguiente al

especificado anteriormente.

Get Response.-La respuesta del agente a la petición de información

lanzada por el administrador.

Set Request.- Una petición del administrador al agente para que

cambie el valor contenido en el MIB referente a un determinado objeto.

Trap.- Un mensaje espontáneo enviado por el agente al administrador,

al detectar una condición predeterminada, como es la

conexión/desconexión de una estación o una alarma.

El protocolo de gestión SNMP facilita de una manera simple y flexible el

intercambio de información en forma estructurada y efectiva, proporcionando

significantes beneficios para la gestión de redes, aunque necesita de otras

aplicaciones en el NMS que complementen sus funciones y que los

dispositivos tengan un software agente funcionando en todo momento y

dediquen recursos a su ejecución y recolección de datos.


40

A través del MIB se tiene acceso a la información para la gestión, contenida

en la memoria interna del dispositivo en cuestión. MIB es una base de datos

completa y bien definida, con una estructura en árbol, adecuada para manejar

diversos grupos de objetos (información sobre variables/valores que se

pueden adoptar), con identificadores exclusivos para cada objeto.

La arquitectura SNMP opera con un reducido grupo de objetos que se

encuentran definido con detalle en el RFC 1066 (base de información de

gestión para la gestión de redes sobre TCP/IP).

Los 8 grupos de objetos habitualmente manejados por MIB (MIB-I), que

definen un total de 114 objetos (recientemente, con la introducción de MIB-II

se definen hasta un total de 185 objetos) son:

Sistema: Incluye la identidad del vendedor y el tiempo desde la última

reinicialización del sistema de gestión.

Interfaces: Un único o múltiples interfaces, local o remoto, etcétera.

ATT (Address Translation Table): Contiene la dirección de la red y las

equivalencias con las direcciones físicas.

IP (Internet Protocol): Proporciona las tablas de rutas, y mantiene

estadísticas sobre los datagramas IP recibidos.

ICMP (Internet Communication Management Protocol): Cuenta el

número de mensajes ICMP recibidos y los errores.


41

TCP (Transmission Control Protocol): Facilita información acerca de las

conexiones TCP, retransmisiones, etcétera.

UDP (User Datagram Protocol): Cuenta el número de datagramas UDP,

enviados, recibidos y entregados.

EGP (Exterior Gateway Protocol): Recoge información sobre el número

de mensajes EGP recibidos, generados, etcétera.

Además de éstos, ciertos fabricantes están cooperando para el desarrollo de

extensiones particulares para ciertas clases de productos y la gestión remota

de dispositivos, conocidas como RMON (Remote MONitor), definidas en el

RFC 1757 (antes 1271) para Ethernet y el RFC 1513 para Token Ring del

IETF (Internet Engineering Task Force), que incluyen sobre unos 200 objetos

clasificados en 9 grupos: alarmas, estadísticas, historias, filtros,

computadoras, n principales, matriz de tráfico, captura de paquetes y sucesos.

Con RMONv2 se decodifican paquetes a nivel 3 de OSI, lo que implica que el

trafico puede monitorizarse a nivel de direcciones de red (puertos de los

dispositivos) y aplicaciones específicas.

RMON define las funciones de supervisión de la red y los interfaces de

comunicaciones entre la plataforma de gestión SNMP, los monitores remotos

y los agentes de supervisión que incorporan los dispositivos inteligentes.


42

3.2 SYSLOG.

Syslog fue desarrollado por Eric Allman en 1980 como parte del proyecto

Sendmail. Sin embargo, se comprobó que era muy útil y otras aplicaciones

empezaron también a usar syslog. Hoy en día syslog está presente por

defecto en casi todos los sistemas Unix y GNU/Linux, y también se encuentran

diversas implementaciones de syslog para otros sistemas operativos, como

Microsoft Windows.

El protocolo syslog es muy sencillo, existe un servidor ejecutando el servidor

de syslog, conocido como syslogd (demonio de syslog). El cliente envía un

pequeño mensaje de texto (de menos de 1024 bytes). Los mensajes de syslog

se suelen enviar vía UDP, por el puerto 514, en formato de texto plano.

Algunas implementaciones del servidor, como syslog-ng, permiten usar TCP

en vez de UDP, y también ofrecen Stunnel para que los datos viajen cifrados

mediante SSL/TLS.

Aunque syslog tiene algunos problemas de seguridad, su sencillez ha hecho

que muchos dispositivos lo implementen, tanto para enviar como para recibir.

Eso hace posible integrar mensajes de varios tipos de sistemas en un solo

repositorio central.

El mensaje enviado se compone de tres campos:

Prioridad

Cabecera


43

Texto

Entre todos no han de sumar más de 1024 bytes, pero no hay longitud

mínima.

3.2.1 Prioridad.

La prioridad es un número de 8 bits que indica tanto el recurso (tipo de

aparato que ha generado el mensaje) como la severidad (importancia

del mensaje), números de 5 y 3 bits respectivamente. Los códigos de

recurso y severidad los decide libremente la aplicación, pero se suele

seguir una convención para que clientes y servidores se entiendan.

Tabla 3.1 Códigos de Recurso

0 Mensajes del kernel 12 Subsistema de NTP

1 Mensajes del nivel de usuario

13 Inspección del registro

2 Sistema de correo 14 Alerta sobre el registro

3 Demonios de sistema 15 Demonio de reloj

4 Seguridad/Autorización 16 Uso local 0

5 Mensajes generados internamente

17 Uso local 1

6 Subsistema de impresión 18 Uso local 2

7 Subsistema de noticias sobre la red

19 Uso local 3

8 Subsistema UUCP 20 Uso local 4

9 Demonio de reloj 21 Uso local 5

10 Seguridad/Autorización 22 Uso local 6

11 Demonio de FTP 23 Uso local 7


44

Códigos de recurso

Los códigos de recurso observados en varios sistemas, basados en el

RFC 3164 se numeran en la tabla 3.1 siendo los 5 bits mas

significativos.

Códigos de severidad

Los 3 bits menos significativos del campo prioridad dan 8 posibles

grados descritos de igual forma en el RFC 3164 y numerados en la

tabla 3.2.

Tabla 3.2 Códigos de Severidad

0 Emergencia: el sistema está inutilizable

1 Alerta: se debe actuar inmediatamente

2 Crítico: condiciones críticas

3 Error: condiciones de error

4 Peligro: condiciones de peligro

5 Aviso: normal, pero condiciones notables

6 Información: mensajes informativos

7 Depuración: mensajes de bajo nivel

Para conocer la prioridad final de un mensaje, se aplica la siguiente

fórmula:

Prioridad = Recurso * 8 + Severidad

Por ejemplo, un mensaje de kernel (recurso=0) con severidad=0

(emergencia), tendría prioridad igual a 0*8+0 = 0. Uno de FTP (11) de


45

tipo información (6) tendría 11*8+6=94. Los valores más bajos indican

mayor prioridad.

3.2.2 Cabecera.

El segundo campo de un mensaje syslog es la cabecera, indica tanto el

tiempo como el nombre de la computadora que emite el mensaje. Esto

se escribe en codificación ASCII (7 bits), por tanto es texto legible.

El primer campo, tiempo, se escribe en formato Mmm dd hh:mm:ss,

donde Mmm son las iniciales del nombre del mes en inglés, dd, es el

día del mes, y el resto es la hora. No se indica el año.

Justo después viene el nombre de la computadora (hostname), o la

dirección IP si no se conoce el nombre. No puede contener espacios,

ya que este campo acaba cuando se encuentra el siguiente espacio.

3.2.3 Texto.

Lo que queda de paquete syslog al llenar la prioridad y la cabecera es

el propio texto del mensaje. Éste incluirá información sobre el proceso

que ha generado el aviso, normalmente al principio (en los primeros 32

caracteres) y acabado por un carácter no alfanumérico (como un

espacio, ":" o "["). Después, viene el contenido real del mensaje, sin

ningún carácter especial para marcar el final.


46

3.3 NTP.

El protocolo NTP (Network Time Protocol) es un protocolo de internet

ampliamente utilizado para transferir el tiempo a través de una red. NTP es

normalmente utilizado para sincronizar el tiempo en clientes de red a una hora

precisa.

El protocolo NTP, es uno de los más antiguos de Internet y sigue estando en

uso hoy en día. Ha estado en continuo uso desde hace más de 25 años. Fue

en un primer momento diseñado originalmente para sincronizar computadoras

y procesos críticos dependientes del tiempo sobre la red. Fue inicialmente

pensada para el sistema operativo Linux, pero luego fue migrado también a

Windows, aunque sigue siendo instalado por defecto en muchos sistemas

Unix y distribuciones BSD. Por este motivo, hay una gran cantidad de

servidores NTP que utilizan Linux debido a su kernel especializado y sus

algoritmos de tiempo.

NTP es un protocolo basado en un sistema cliente-servidor. Provee a los

clientes con tres productos fundamentales: clock offset, round-trip delay y

referencia de dispersión. El offset especifica la diferencia entre la hora del

sistema local y la referencia externa de reloj. Round-trip delay especifica las

latencias de tiempo medidas durante la transferencias de paquetes dentro de

la red. La referencia de dispersión de tiempo especifica el máximo número de

errores asociados con la información de tiempo recibido de un reloj externo.


47

El protocolo tiene una estructura jerárquica. Un servidor Stratum 1, es el

servidor primario de referencia y se asienta en el más alto nivel de la jerarquía.

Este servidor primario está seguido de servidores secundarios de referencia y

clientes. Un servidor NTP primario generalmente se sincroniza mediante una

referencia externa de reloj, como puede ser un reloj de radio o GPS como se

muestra en la figura 3.1.

Figura 3.1 Arquitectura NTP.

El protocolo NTP usa el protocolo UDP el cual es una parte integrada de la

pila TCP/IP. Actualmente, la versión actual que se está utilizando es NTP 4, y

todas las versiones son compatibles entre sí. La única modificación entre la

versión 3 y 4 es una variación en la cabecera para acomodar IPv6.


48

3.3.1 Modos de operación.

Un servidor NTP stratum 1 tiene tres modos de operación unicast,

anycast y multicast. El cliente inicia los modos unicast y anycast,

mientras el servidor responde con un mensaje de tiempo NTP con el

que el cliente se sincroniza. Multicast es un modo de envío de

mensajes a solo ciertos elementos de la red, a diferencia de broadcast,

el cual habla con todos. A periodos regulares, el dominio es inundado

por estos mensajes con motivos de sincronización.

3.3.2 SNTP.

El protocolo SNTP (Simple Network Time Protocol), es una versión

simplificada de NTP. Normalmente es utilizada donde la precisión y

complejidad de NTP no es necesaria. Ambos protocolos son

compatibles e intercambiables, es decir, cualquier cliente SNTP puede

sincronizar con un servidor NTP.

3.4 IP SLA (Cisco).

Los servicios de red han cambiado drásticamente en los últimos años, debido

a la adición de voz, vídeo y otras aplicaciones sensibles de misión crítica,

demora y rendimiento sensible. La red ha sido adoptada como una

herramienta de productividad. Los clientes demandan garantizar, servicios de

red fiable para aplicaciones críticas de negocio Cisco IP Service Level


49

Agreements (SLAs) es una capacidad integrada en casi todos los dispositivos

que ejecutan el software Cisco IOS, que permite a los clientes de Cisco IP

comprender los niveles de servicio para los servicios IP, aumentar la

productividad, reducir los costes operativos, y reducir la frecuencia de las

interrupciones de red.

Cisco IP SLA usa el monitoreo del tráfico activo, para la generación de tráfico

de manera continua, confiable y predecible para poder medir el desempeño.

Se puede simular la red de datos y servicios IP para obtener información y

recopilar el rendimiento de la red en tiempo real. Esto incluye datos sobre el

tiempo de respuesta, latencia en un solo sentido, jitter, pérdida de paquetes,

puntuación de calidad de voz, y el tiempo de respuesta del servidor. Cisco IP

SLA también puede monitorear el desempeño de las diferentes clases de

tráfico a través de la misma conexión.

Los niveles de servicio son fundamentales porque afectan a la prestación de

servicios IP y aplicaciones críticas del negocio. Los SLA entre los proveedores

de servicios y clientes o entre los departamentos de TI corporativos de

empresa y los usuarios finales tienen por objeto proporcionar garantías de

servicio y validar el rendimiento de la red de manera continua. Un SLA debe

ser simple de comprender y mejorar el tiempo medio de respuesta.

Cisco IP SLA está incrustado dentro del software Cisco IOS y no hay ningún

dispositivo adicional para implementar, aprender o manejar. Es una

herramienta confiable para verificar los niveles de servicio IP, Cisco IP SLA


50

proporcionan una solución escalable y rentable para la medición del

rendimiento de la red.

Cisco IP SLA recopila información de rendimiento de la red en tiempo real de:

el tiempo de respuesta, la latencia en un solo sentido, el jitter, pérdida de

paquetes, la medición de la calidad de voz, y otras estadísticas de la red. El

usuario podrá continuamente contar con un sistema confiable, predecible y

podrá medir el rendimiento de la red de forma proactiva y vigilar la salud de la

red. Con Cisco IP SLA, cuenta con un control de nivel de servicio que es

automático, los niveles de servicio IP pueden estar seguros, el funcionamiento

de la red puede ser verificada de manera proactiva, y el rendimiento de la red

se puede medir con precisión. La supervisión activa continuamente mide el

rendimiento de la red entre varias rutas en la red, proporcionando información

continua en base del rendimiento.

Los administradores de red también pueden utilizar Cisco IP SLA como una

herramienta de solución de problemas. Pueden obtener mediante hop-by-hop

estadísticas de rendimiento entre dos routers de Cisco, o entre un enrutador y

un servidor. Si el nivel de rendimiento de la red cae durante la operación (por

ejemplo: debido a la congestión), el administrador de red puede identificar

rápidamente la ubicación de los cuellos de botella y resolver el problema.

Cisco IP SLA También puede realizar una evaluación de la red para un nuevo

servicio IP y verificar los niveles de calidad de servicio (QoS). Por ejemplo,

Cisco IOS IP SLA puede determinar si la red está lista para la voz sobre IP


51

(VoIP) mediante la simulación de los codecs de VoIP y medir el rendimiento

de la red y la calidad de VoIP a través de la red IP.

3.4.1 Beneficios de Cisco IP SLA.

Los beneficios que plantea Cisco por el uso de la medición de lP SLA

se listan a continuación:

Integrado en el software Cisco IOS

Automatizada y en tiempo real, vigilancia del rendimiento preciso

de la red y la salud de la red.

Es capaz de comprobar y medir los niveles de servicio IP y los

parámetros necesarios para los acuerdos de nivel de servicio.

Monitoreo de tráfico por la clase de QoS.

Flexibilidad de programación.

Notificaciones proactivas con SNMP trap.

Hop-by-hop y la medición de extremo a extremo.

Control a través de SNMP o por software Cisco IOS interfaz de

línea de comandos (CLI)

VoIP simulación códec VoIP y la medición de la calidad;

Puntuación de opinión media (MOS) o planificación y cálculo del

factor deterioro (ICPIF).


52

Multiprotocol Label Switching (MPLS) para la monitorización de

red.

Integrado en varios productos de los socios de terceros y la

gestión del rendimiento.

3.4.2 Funcionamiento.

Cisco IOS IP SLA mide el rendimiento mediante el envío de uno o más

paquetes a un dispositivo IP de destino o un router de Cisco. Cisco IOS

IP SLA utilizar la información de fecha y hora para el cálculo de

métricas de rendimiento, tales como el jitter, la latencia de red y los

tiempos de respuesta del servidor, la pérdida de paquetes, y las

puntuaciones MOS en calidad de voz.

Un router destino que ejecuta el software Cisco IOS se puede

configurar como una respuesta de Cisco IP SLA, que procesa los

paquetes de medición y proporciona información detallada de marca de

tiempo. La respuesta puede enviar información acerca de retrasar el

proceso del router destino de nuevo a la fuente del router Cisco. Este

retraso se elimina durante el cálculo para mejorar aún más la precisión.

Las mediciones de una sola dirección también son posibles con Cisco

IP SLA. Los usuarios pueden programar una operación de Cisco IOS IP

SLA en cualquier momento o de forma continua en cualquier intervalo

de tiempo.


53

Cisco IOS IP SLA se pueden configurar para controlar el tráfico por

clase sobre el mismo enlace mediante el establecimiento de la Diff-Serv

Code Point (DSCP).

También se puede utilizar para solucionar problemas de las

operaciones de red MPLS, la medición de los resultados son esenciales

para el servicio de monitoreo de MPLS VPN.

Cisco IOS IP SLA proporciona una función de notificación proactiva con

una captura de SNMP, cada operación de medición puede controlar

con un umbral de rendimiento preestablecido. Cisco IP SLA generar

una trap SNMP para alertar a las aplicaciones de gestión cuando este

umbral se cruza. Una alerta se produce si se supera un determinado

valor entre dos puntos de la red, y una trap envía a un sistema de

administración de redes (NMS) para alertar al administrador de la red.

Los administradores también pueden configurar los IP SLAs para

ejecutar una nueva operación automáticamente cuando se cruza el

umbral. Esta característica, combinada con la capacidad de medición

hop-by-hop, permite el análisis inmediato problemas en tiempo real. Los

resultados de las mediciones de rendimiento de la red están disponibles

tanto con SNMP y con el software Cisco IOS CLI.

Cisco IP SLA realiza vigilancia activa mediante la generación y análisis

de tráfico para medir el rendimiento entre dispositivos de Cisco IOS

mediante software o de servicios de aplicación de red. Cisco IP SLA


54

permite la funcionalidad más allá de los SLAs tradicionales y se

comparan en la tabla 3.3:

Tabla 3.3. SLA tradicional versus Cisco IP SLA

Requisito SLA tradicional Cisco IP SLA

Seguimiento de extremo a extremo

Limitada Sí

Sin costo de hardware No Sí

Penetrante Frame Relay o ATM (Sólo)

Sí

Facilidad de implementación Pobres Sí

Compatibilidad con QoS No Sí

Las mediciones de latencia No Sí

Las mediciones de voz No Sí

IP Application Aware No Sí

Soporte capa 2 Frame Relay o ATM (Sólo)

Sí

El ciclo de implementación de los SLA reduce el tiempo de despliegue

de nuevas aplicaciones. Permite a los usuarios comprender su servicio

desplegado rendimiento de la red IP, y hacer realidad los beneficios de

la gestión y probar el servicio y la diferenciación de la aplicación.

Cisco IP SLA recoge estadísticas sobre la demora, pérdida de

paquetes, jitter, la secuencia de paquetes, conectividad, ruta y tiempo

de descarga. Los paquetes con IP configurable y opciones de la capa


55

de aplicación, incluyendo la dirección IP de origen y destino, UDP /

números de puerto TCP, byte ToS (incluye servicios diferenciados

punto de código (DSCP) y el período bits Prefijo), VRF, y la URL. Como

es de nivel 2 de transporte independiente, Cisco IOS IP SLA se pueden

configurar de extremo a extremo a través de redes diferentes a fin de

reflejar mejor las métricas que un usuario final es probable que la

experiencia.

Cisco IOS IP SLA tiene un subconjunto único de las métricas de

rendimiento siguientes:

Retraso (tanto de ida y vuelta y en un solo sentido)

Variación (direccional)

Pérdida de paquetes (direccional)

Paquete de Secuenciación (paquete de pedido)

Ruta (por salto)

Conectividad (direccional)

El servidor web o el tiempo de descarga

Las puntuaciones de calidad de voz

Estas capacidades permiten la ejecución de las funciones de red:

Cisco IP SLA seguimiento

- Seguimiento del SLA, medición y verificación

Red de monitoreo del desempeño


56

- Medida de jitter, latencia o pérdida de paquetes en la red

IP de la red de servicios de evaluación de salud

- Verificar la calidad de servicio de red es suficiente para

los nuevos servicios IP

- Continua, confiable, predecible y mediciones después de

la implementación de servicios

Red de extremo a extremo la disponibilidad de supervisión

- Pruebas de verificación proactiva y la conectividad de los

recursos de red (por ejemplo: ¿cuál es la disponibilidad de

la red de un servidor NFS utiliza para almacenar datos

críticos del negocio desde un sitio remoto?)

Solución de problemas de funcionamiento de la red

- De conformidad y la medición confiable de inmediato

localiza problemas y reduce el tiempo de solución de

problemas

Cada una de estas áreas funcionales proporciona soporte para el

despliegue con éxito de las aplicaciones críticas de negocio. Cisco IP

SLA admite estas funciones a través de una serie de operaciones.

Cada operación tiene ciertas capacidades, la métrica, el protocolo y las

opciones configurables. La selección del correcto funcionamiento

depende en gran medida de la aplicación requerida y la función.


57

CAPITULO IV CASO PRÁCTICO.

4.1 Monitoreo de los SLA con Cisco IP SLA.

Para realizar el monitoreo se debe plantear que es lo que debemos esperar

del análisis del nivel de servicio, comúnmente se establece por convención

que un sistema al decaer por debajo del 90% de su nivel optimo de servicio

puede representar un problema, en el caso de los SLA existen dos niveles de

alerta que son: el nivel de servicio esperado y el nivel de servicio mínimo,

denominadas también como violaciones de SLA

Un ejemplo de las violaciones a los niveles de servicio se representa en la

figura 4.1. donde para “Nivel de Servicio 1” el nivel mínimo de servicio se

presenta cuando el nivel de servicio cae por debajo del 90%, pero aun sigue

siendo funcional aunque su rendimiento cae considerablemente y la violación

del acuerdo de nivel de servicio se presenta cuando este cae n número de

veces por debajo del nivel mínimo. Para el caso de “Nivel de Servicio 2” el

nivel de servicio mínimo se presentara cuando el nivel de servicio esperado

cae debajo del 80% y representa una alerta grave para la integridad del

sistema si el servicio sigue decayendo aun mas, puede llegar al punto donde

se presente la denegación del servicio en caso de que el acceso al servicio

sea tan deficiente que no se pueda acceder dicho servicio.


58

Figura 4.1 Ejemplo de monitoreo de SLA.

Para realizar el monitoreo debemos saber que vamos a medir por lo que se

deben responder las siguientes preguntas, ¿Cuál es el objetivo principal de las

mediciones?, ¿Qué indicadores son importantes para controlar? y ¿En qué

días y horarios es necesario realizar las medidas necesarias?; en otras

palabras debemos seleccionar que operación es la mejor la medición

requerida, determinar los umbrales de nivel de servicio y la frecuencia con la

que se realizaran las mediciones tomando en cuenta cuanto trafico de red

podríamos generar con dichas mediciones.

4.2 Escenario Planteado.

EL escenario que se propone es el siguiente, se tiene un sitio web el cual se

contacta a través de una VPN, se requiere garantizar la disponibilidad de los

niveles de servicio proporcionados por el sitio web, utilizando las herramientas

Violación de SLA


59

IP SLA de Cisco. En base a esto se considera que los niveles de servicio

estarán representados por el tiempo de respuesta que presente el servidor

http, en caso de no cumplirse los niveles de servicio estos deben ser

notificados al NMS, desde el cual se realiza el monitoreo, dado las limitaciones

con las que nos enfrentamos al momento de realizar las pruebas este fue

nuestro mejor escenario.

Figura 4.2 Escenario planteado

A continuación se presentan los pasos realizados en la implementación y

monitoreo de la herramienta CISCO IP SLA

4.2.1 Selección de la operación correcta.

Para la selección de cual operación se debe utilizar, los IP SLA de

Cisco define varios tipos de operaciones, en nuestro caso solo

requerimos de la obtención del tiempo de respuesta de un servidor http

por lo que entre las opciones con las que se disponen son las

siguientes:


60

Operación UDP echo: La operación UDP echo mide el tiempo de

respuesta de extremo a extremo o la conectividad entre un router Cisco

y dispositivos IP o UDP en la capa de red que informa de los errores y

proporciona información pertinente para el procesamiento de paquetes

IP. El tiempo de respuesta se calcula midiendo el tiempo transcurrido

entre el envío del mensaje de solicitud de echo UDP en el destino y la

recepción de una respuesta del echo UDP.

Operación TCP: Mide el tiempo respuesta de la conexión TCP se

calcula tomando la diferencia entre los tiempos empleados para solicitar

el TCP, SYN y ACK. Este resultado será útil para probar la conexión a

puertos específicos en los servidores

Operación HTTP: La operación http mide el tiempo de ida y vuelta

(RTT Round-Trip Time), adoptada para conectarse y acceder a los

datos de un servidor http, que se puede especificar con una dirección

url. Las mediciones del tiempo de respuesta del servidor http constan

de tres tipos:

Búsqueda en DNS -RTT necesario para realizar operaciones de

búsqueda del nombre de dominio.

Conexión TCP -RTT necesario para realizar una conexión TCP

con el servidor http.


61

Tiempo de transacción HTTP -RTT adoptadas para enviar una

solicitud y obtener una respuesta desde el servidor http para la

página web completa o el primer byte de la página web.

La figura 4.3 muestra los componentes de la medición del tiempo

respuesta en la operación http.

Figura 4.3 Tiempos de respuesta en operación http

Dado que la conexión al servidor es desde una red interna que no

pasara por internet las operaciones UDP Echo y TCP, tendrán un

tiempo de respuesta demasiado bajo, la operación http es la más

indicada para el cálculo de los umbrales de servicio y el establecimiento

del acuerdo de nivel de servicio.


62

4.2.2 Selección del intervalo de muestreo adecuado

La frecuencia con la que Cisco IP SLA realiza la supervisión se

configura en función de las necesidades y requerimientos de ancho de

banda de red. El muestreo se puede producir de forma frecuente a fin

de obtener la valoración más precisa de los niveles de servicio de red,

por desgracia, esta no siempre es factible. Por ejemplo, cuando la

vigilancia es a través de una conexión WAN suele ser más cara, el

usuario no puede desear crear una gran cantidad de tráfico a través del

enlace.

También es importante tener en cuenta que la vigilancia de tráfico

activo, se genera en un dispositivo Cisco por software. El poder de

procesamiento podría ser una preocupación cuando se utiliza un router

Cisco de gama baja, o cuando existe una gran cantidad de tráfico que

pasa por el router.

En nuestro caso el intervalo de muestreo seleccionado es de 300

milisegundos, para no generar tráfico tanto tráfico en el servidor.

4.2.3 Selección de los umbrales de servicio

Los proveedores de servicios a veces predefinen los umbrales de

rendimiento, un ISP pueden proporcionar los SLA que especifican una


63

cantidad de latencia o un porcentaje de disponibilidad. Si los términos

de un SLA particular, son ambiguos, corresponde al administrador de

red el decidir qué tipo de umbrales se deben seleccionar.

Para hacer la correcta de selección de los umbrales de servicio es

necesario hacer primero un monitoreo del tiempo de respuesta que

realmente nos está brindando el servidor http.

Se realizo la primera implementación de Cisco IP SLA con la siguiente

configuración que se muestra en las figuras 4.4 y 4.5.

Figura 4.4 Configuración para obtener los umbrales de servicio.


64

Figura 4.5 Configuración para obtener los umbrales de servicio.

La principal característica de esta configuración es que se presenta con

el intervalo de muestreo mínimo aceptado por la operación http (60

segundos), esto se debe a que se pretende generar algo de tráfico en

el servidor.

Con los datos obtenidos se genera una tabla y se obtiene la media para

tener una referencia a partir del cual se seleccionara el nivel de servicio

óptimo y el nivel se servicio mínimo; en la tabla 4.1 se pueden ver

algunos de los tiempos de respuesta obtenidos para realizar el cálculo

del umbral para el nivel de servicio aceptable.


65

Tabla 4.1. Tiempos de respuesta obtenidos para calculo de umbral

Muestra 1 2 3 4 5 6 7 8 9 … n

RTT DNS 0 0 0 0 0 0 0 0 0 … 0

RTT TCP 3 3 3 3 3 3 3 3 3 … 3

RTT HTTP 503 546 420 490 446 543 595 501 524 … 584

TOTAL 506 549 423 493 449 546 598 504 527 … 587

La media que se obtuvo del tiempo de respuesta fue de 514ms, por lo

que para el umbral de servicio optimo se tomaron 600 ms, mientras que

para el umbral de servicio mínimo se tomaron 1000 ms, ya que este

último es casi el doble del tiempo de respuesta promedio.

4.2.4 Monitoreo con IP SLA monitor.

Finalmente para el monitoreo se implementó con la herramienta IP

SLA Monitor de Solar Winds, la cual consta de una interfaz muy

sencilla para configurar y monitorear los IP SLA’s de Cisco.

En la figura 4.6 se muestra como se configura el IP SLA Monitor, se

indica la dirección de la interfaz del router que realiza la operación y a

la cual el NMS se encuentra conectado; se selecciona el tipo de

operación y el intervalo de muestreo; se indica la dirección web a la que

se realiza la medición del tiempo de respuesta, en este caso se empleo

la dirección de red del servidor ya que no se cuenta con un servidor


66

DNS, por lo que no se puede determinar a través del la resolución por

nombre de dominio.

Figura 4.6 Configuración de IP SLA Monitor

Después de configurar la operación de IP SLA se introducen los

umbrales de nivel de servicio óptimo y mínimo como se muestra en la

figura 4.7


67

Figura 4.7 Configuración de Umbrales de Nivel de Servicio

En la figura 4.8 se presentan la captura de los estados del nivel servicio

que recibimos por el IP SLA monitor, se muestra que cuando el servicio

es optimo se presenta la alerta en verde, cuando se sobre pasa el

umbral de tiempo de respuesta optimo la alerta se presenta en color

amarillo, mientras que cuando se llega al umbral mínimo la alarma se

presenta en color rojo, para obtener estos resultados se modificaron los

umbrales del servicio ya que no se obtuvieron todas las alarmas al

realizar la medición original por lo que se opto por modificar estos

parámetros con el fin de demostrar todos los tipos de alertas generadas

por el monitor.


68

Figura 4.8 Alarmas obtenidas con IP SLA Monitor.


69

CONCLUSIONES.

La implementación del monitoreo para páginas web con la herramienta de Cisco IP

SLA fue sencillo de implementar ya que dichas herramientas cuentan con soporte de

diversas herramientas de terceros, que se plantea como uno de los beneficios del

uso de los IP SLA de Cisco, en nuestro caso nos apoyamos con la herramienta IP

SLA Monitor de Solar Winds, se obtuvieron las alertas de las posibles anomalías que

pueden existir al medir el nivel de servicio con una interfaz más amigable que la que

ofrece el CLI de Cisco.

Se puede concluir que a pesar de que resulta un trabajo sencillo por las condiciones

en las que fue elaborado por cuestiones de tiempo y de infraestructura; se pueden

determinar cuáles son los posibles escenarios en los que se presentan anomalías o

violaciones del nivel de servicio y poder así garantizar que el servicio siempre se

encuentre a un nivel aceptable.

Este trabajo pudiera ser la base para una implementación mayor como puede ser el

desarrollo de una herramienta para realizar el monitoreo en lugar de utilizar

aplicaciones de terceros, o para la realización de un análisis más especializado de

los tiempos de respuesta del servidor y como mejorarlos a través de mejores

técnicas de ruteo.


70

GLOSARIO

ATM (Asynchronous Transfer Mode). Es una tecnología de telecomunicación

desarrollada para hacer frente a la gran demanda de capacidad de transmisión para

servicios y aplicaciones.

Broadcast. Es un modo de transmisión de información donde un nodo emisor envía

información a una multitud de nodos receptores de manera simultánea, sin necesidad

de reproducir la misma transmisión nodo por nodo.

BSD (Berkeley Software Distribution). Es un sistema operativo derivado del

sistema Unix nacido a partir de los aportes realizados a ese sistema por la

Universidad de California en Berkeley.

Byte ToS (Type of service). Byte en la cabecera del protocolo IP que india el tipo de

servicio.

Codecs. Abreviatura de codificador-decodificador.

Datagrama. Un datagrama es un fragmento de paquete que es enviado con la

suficiente información para que la red pueda simplemente encaminar el fragmento

hacia el equipo terminal de datos receptor, de manera independiente a los

fragmentos restantes.


71

DNS (Domain Name System). Es un sistema de nomenclatura jerárquica que asocia

información de nombres de dominios asignado a dirección IP des dispositivo de red.

DSCP (Differentiated Services Code Point). Hace referencia al segundo byte en la

cabecera de los paquetes IP que se utiliza para diferenciar la calidad en la

comunicación que quieren los datos que se transportan.

Frame Relay. Es una técnica de comunicación mediante retransmisión de tramas

para redes de circuito virtual; consiste en una forma simplificada de tecnología

de conmutación de paquetes que transmite una variedad de tamaños de tramas o

marcos (“frames”) para datos, perfecto para la transmisión de grandes cantidades de

datos.

Hop by hop. Es un método común de enrutamiento en redes en las que hay nodos

intermedios entre la fuente y el destino, va a la dirección del siguiente nodo principal

hasta el punto de destino en la lista. Así que cuando un paquete de datos llega a un

nodo en particular, usa la tabla de rutas para encontrar la dirección del siguiente

nodo.

ICPIF (Impairment Calculated Planning Impairment Factor). Es un estándar

G.113 del UIT-T para la medición de la calidad del servicio, representa

combinaciones predefinidas de pérdida y retraso en la llamada red de VoIP.

Host. Es todo equipo informático que posee una dirección IP y que se encuentra

interconectado con uno o más equipos.


72

Jitter. Es la variabilidad temporal durante el envío de señales digitales, una ligera

desviación de la exactitud de la señal de reloj.

Kernel. En informática es un software que constituye la parte más importante del

sistema operativo. Es el encargado de gestionar recursos, a través de servicios de

llamada al sistema.

MPLS (Multiprotocol Label Switching) Es un mecanismo de transporte de datos

estándar que opera entre la capa de enlace de datos y la capa de red del

modelo OSI; fue diseñado para unificar el servicio de transporte de datos para las

redes basadas en circuitos y las basadas en paquetes. Puede ser utilizado para

transportar diferentes tipos de tráfico, incluyendo tráfico de voz y de paquetes IP.

Multicast. Es un servicio de red en el cual un único flujo de datos, proveniente de

una determinada fuente, puede ser enviada simultáneamente para diversos

destinatarios.

Polling. Operación de consulta constante, generalmente hacia un dispositivo de

hardware, para crear una actividad sincrónica sin el uso de interrupciones.

Puntuación MOS. Uno de los sistemas más utilizados es el de puntuación media

(MOS), el cual se basa en la reproducción de unas muestras (ya sean de video o de

voz) a una serie de personas, las cuales se puntúan en una escala del 1 al 5 (siendo

el 5 la mejor puntuación) en términos de calidad de experiencia. El MOS fue

originariamente utilizado para la ayuda en el diseño, la investigación y el desarrollo

de los sistemas digitales de telefonía, convirtiendo la señal de voz analógica en


73

digital y viceversa. El término MOS se ha convertido en un sinónimo de QoE para las

llamadas de voz.

QoS (Quality of Service). Calidad de Servicio son las tecnologías que garantizan la

transmisión de cierta cantidad de información en un tiempo dado (throughput).

Calidad de servicio es la capacidad de dar un buen servicio. Es especialmente

importante para ciertas aplicaciones tales como la transmisión de vídeo o voz.

RFC (Request for Comments). Son una serie de notas sobre Internet que

comenzaron a publicarse en 1969, se abrevian como RFC. Cada una de ellas

individualmente es un documento cuyo contenido es una propuesta oficial para un

nuevo protocolo de la red Internet (originalmente de ARPANET), que se explica con

todo detalle para que en caso de ser aceptado pueda ser implementado sin

ambigüedades.

RTT (Round-Trip Time) tiempo que tarda un paquete enviado desde un emisor en

volver a este mismo emisor habiendo pasado por el receptor de destino.

Ruteo. Función de buscar un camino entre todos los posibles en una red de

paquetes cuyas topologías poseen una gran conectividad.

Stunnel. Es un programa de computadora de software libre multi-plataforma,

utilizado para la creación de túneles TLS/SSL.

Unicast. Es el envío de información desde un único emisor a un único receptor.


74

URL (Uniform Resource Locator). Es una cadena de caracteres con la cual se asigna

una dirección única a cada uno de los recursos de información disponibles en

la Internet.

VRF (Virtual Routing and Forwarding). Es una tecnología utilizada que permite la

coexistencia de múltiples instancias de tablas de ruteo en un mismo router.

WAN (Wide Area Network). Es un tipo de red capaz de cubrir distancias desde unos

100 hasta unos 1000 km, proveyendo de servicio a un país o un continente.


75

REFERENCIAS

[1]. http://gemini.udistrital.edu.co/comunidad/profesores/jruiz/jairocd/texto/re

des/temas/admoredest.pdf

[2]. http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_niveles

_de_servicio/proceso_gestion_de_niveles_de_servicio/planificacion_de

_niveles_de_servicio.php

[3]. http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hs

thresh.html

[4]. http://www.cisco.com/en/US/technologies/tk648/tk362/tk920/technologie

s_white_paper09186a00802d5efe.html

[5]. http://www.profesores.frc.utn.edu.ar/sistemas/ingsanchez/Redes/Archiv

os/Protocolo_UDP.pdf

[6]. http://es.kioskea.net/contents/internet/tcp.php3

[7]. http://www.mitecnologico.com/Main/ProtocoloHttp

[8]. http://www.profesores.frc.utn.edu.ar/sistemas/ingsanchez/Redes/Archiv

os/Protocolo_ICMP.pdf

[9]. http://www.coit.es/publicac/publbit/bit102/quees.htm

[10]. RFC 3164

http://www.ietf.org/rfc/rfc3164.txt

[11]. http://support.ntp.org/bin/view/IETF/WebHome


76

[12]. Estudio para la implementación de un Centro NOC (Network Operations

Center) en la Intranet de Petroproducción y realización de un proyecto

piloto para la Matriz Quito, Autores: Bastidas Flores Danny Alexander y

Ushiña Gusque Daniel Santiago, Escuela Politécnica Nacional Ecuador,

Septiembre 2010.

Documents

IMPLEMENTACION DE CISCO IP SLA PARA MONITOREO DE SLA …