tesina final

INSTITUTO POLITÉCNICO NACIONAL

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

SEMINARIO DE SEGURIDAD DE LA INFORMACION

IMPLEMENTACION DE CONTROLES TECNICOS PARA MONITOREO DE SLA’S

EN PAGINAS WEB

INTEGRANTES

HERNANDEZ ROSA ISRAEL ISSAC

MIRANDA BAUTISTA ISRAEL FELIPE

VALLE GARCIA SALVADOR

ASESOR

DR. ANTONIO CASTAÑEDA SOLIS

ENERO-JUNIO DE 2011

IMPLEMENTACIÓN DE CONTROLES TÉCNICOS PARA MONITOREO DE SLA’S EN PAGINAS WEB

Contenido

OBJETIVO...................................................................................................................V

PLANTEAMIENTO DEL PROBLEMA.........................................................................VI

JUSTIFICACIÓ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 Station)...........................................................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 Monitorización de los niveles de servicio....................................................23

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

CAPITULO II CONCEPTOS BASICOS 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

2


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.2Selección del intervalo de muestreo adecuado...........................................61

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

4.2.4 Monitoreo con IP SLA monitor....................................................................64

CONCLUSIONES.......................................................................................................68

REFERENCIAS..........................................................................................................69

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

3


Figura 1.2 Arquitectura Centralizada.................................................................................................5Figura 1.3 Arquitectura distribuida.....................................................................................................6Figura 1.4 Arquitectura Jerárquica.....................................................................................................7Figura 1.5 Tareas del Modelo FCAPS...............................................................................................8Figura 1.6 Capas del Modelo TNM..................................................................................................16Figura 1.7 Gestión de Niveles de Servicio......................................................................................19Figura 2.1. Encabezado protocolo UDP..........................................................................................30Figura 2.2 Cabecera ICMP...............................................................................................................32Figura 3.1 Arquitectura NTP.............................................................................................................47Figura 4.1 Ejemplo de monitoreo de SLA.......................................................................................57Figura 4.2 Escenario planteado........................................................................................................59Figura 4.3 Tiempos de respuesta en operación http.....................................................................61Figura 4.4 Configuración para obtener los umbrales de servicio.................................................63Figura 4.5 Configuración de IP SLA Monitor..................................................................................65Figura 4.6 Configuración de Umbrales de Nivel de Servicio........................................................66Tabla 2.1. Tipos de Mensajes Informativos....................................................................................33Tabla 2.2 Tipos de mensajes de error de ICMP.............................................................................35Tabla 3.1 Códigos de Recurso.........................................................................................................43Tabla 3.2 Códigos de Severidad......................................................................................................44Tabla 3.3. SLA tradicional versus IOS de Cisco IP SLA...............................................................54Tabla 4.1. Tiempos de respuesta obtenidos para calculo de umbral..........................................64

4


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.

5


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 comercio electrónico,

acceso a bases de datos remotas, manejo de cuentas, etcétera. Por lo cual 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 del servicio

web. Por lo que estos últimos deben monitorizar que dichos acuerdos se cumplan,

según los indicadores establecidos y evitar posibles sanciones, a través de alarmas

generadas en cuanto ocurra alguna anomalía.

Cisco IP SLA es una herramienta ya integrada en sus dispositivos de ruteo, que nos

permite el monitoreo del tiempo de respuesta y la automatización del envió de

mensajes en caso de que ocurra alguna anomalía.

6


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 ofertan

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 negación de servicios web

como lo han reportado amazon, google, microsoft, sony, quienes han sido víctimas

de este tipo de ataques. Se puede decir que el mayor afectados fue el usuario final,

el cual no conto, con los servicios que estas empresas ofrecen, lo que se traduce en

pérdidas de clientes y sanciones gubernamentales.

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

alarmas o alertas que llegan al administrador, el cual puede hacer un análisis de lo

que está ocurriendo en la red.

7


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.

8


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 Station).

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.

9


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 y también de dar respuesta a las solicitudes

de este en caso de alguna anomalía.

10

NSM (Network Management Station) Protocolo Agente de Monitorización


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 una solo NMS que

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

manejar, una sola NMS puede llegar a sobrecargarse fácilmente.

11


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.

Figura 1.3 Arquitectura distribuida

12

NMS

Agente Agente Agente

NMS

Agente Agente

NMS

Agente Agente


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.

13


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 modelo para implementar una adecuada

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

14

NMS(Central)

NMS1

Agente Agente

NMS2

Agente Agente


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 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

Estas capas se describen a continuación.

15

FaultConfiguration

AccontingPerformance

Security


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 de la red y de 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.

5. Asignar recursos suficientes para su resolución.

6. Proveer una solución.

16


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 de la configuración de los recursos.

Facilidad de acceso remoto a los dispositivos

Simplificación de la configuración de los equipos

17


Gestión de análisis de datos: Contabiliza el tráfico y los generales

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 de la

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.

18


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 recogida 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

de 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 mediad 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.

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

elementos importantes en la resolución de problemas de

rendimiento.

19


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. Puede ser mediante

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

funciones de software, dividendo recursos dentro de áreas autorizadas

y no autorizadas.

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.

20


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

información.

1.3.2 Modelo De Administración TMN.

Su objetivo 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.

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.

21


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

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

propietario.

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 implementar 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

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 OSF:

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

Capa de gestión de red.

22


Capa de gestión de servicio.

Capa de gestión de negocio.

Figura 1.6 Capas del Modelo TNM

1.4 Gestión de Niveles de Servicio.

23

Gestión de Negocio

Gestión de Servicio

Gestion de Red

Gestion de elementos de Red


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) ofrecidos.

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 asumibles 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.

Establecer los indicadores claves de rendimiento del servicio TI.

24


Monitorizar 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).

25


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.

26


Estos indicadores deben cumplir las siguientes características:

Alcanzable. Los niveles de servicio deben ser logrables. 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/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 impuesto por alguna de las

partes. Esto es especialmente importante si el indicador se va a

usar en un acuerdo de servicio.

27


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 de 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 veces, por ejemplo, es

28


necesario analizar los eventos registrados en el sistema de mesón 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

compañía.

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.

29


Los SLAs 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 Monitorización de los niveles de servicio.

El proceso de monitorización 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.

La monitorización 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.

30


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

establecido con anterioridad unos 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 Niveles de Servicio es un proceso continuo que

requiere la continua revisión de la calidad de los servicios ofrecidos.

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

medibles resultado de la experiencia previa, los SLAs en vigencia

31


Este proceso de revisión no debe limitarse a aquellos SLAs 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.

32


CAPITULO II CONCEPTOS BASICOS DE PROTOCOLOS TCP/IP.

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

El TCP 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 (ISN).

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

más uno.

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

servidor más uno.

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

33


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 protocolo internet (IP) es un protocolo de conmutación de paquetes que

realiza direccionamiento y encaminamiento. 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 requerido 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 TTL (tiempo de vida, del inglés time to

live). El TTL indica a cada uno de los routers de la red entre el origen y el

destino cuánto 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

34


128, puede estar en la red durante 128 segundos o 128 saltos (cada parada, o

router, en la red), o una 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 es un protocolo no orientado a la conexión y es el responsable de la

comunicación de datos extremo a extremo. En cambio, 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.

El 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

conexión. El 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

35


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 pueden llegar duplicados y/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.

El protocolo UDP (Protocolo de datagrama de usuario) es un protocolo

no orientado a conexión de la capa de transporte del modelo TCP/IP.

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:

36

http://es.kioskea.net/contents/internet/tcpip.php3

http://es.kioskea.net/contents/internet/tcpip.php3


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.

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

37

http://es.kioskea.net/contents/base/control.php3

http://es.kioskea.net/contents/internet/port.php3


El Protocolo de Mensajes de Control y Error de Internet, ICMP, 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 o 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

38


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 ECO (tipo 8) y los de respuesta de Eco (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.

Tabla 2.1. Tipos de Mensajes Informativos.

0 Echo Reply (respuesta de eco)

39


3Destination Unreacheable (destino inaccesible)

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

5Redirect (redireccionar - cambio de ruta)

8 Echo (solicitud de eco)

11Time Exceeded (tiempo excedido para un datagrama)

12Parameter Problem (problema de parámetros

13Timestamp (solicitud de marca de tiempo)

14Timestamp Reply (respuesta de marca de tiempo)

15Information Request (solicitud de información) - obsoleto-

16Information Reply (respuesta de información) - obsoleto-

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

18Addressmask Reply (respuesta de máscara de dirección

2.4.2 Mensajes de error.

En el caso de obtener un mensaje ICMP de destino inalcanzable, con

campo "tipo" de valor 3, el error concreto que se ha producido vendrá

dado por el valor del campo "código", pudiendo presentar los siguientes

valores que se muestran en la parte derecha.

40


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 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

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

41


2 el destino no dispone del protocolo solicitado

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

4se 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

9la 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

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 tanto "oculto" al usuario final. El protocolo

42

http://www.w3.org/Protocols/


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, 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.

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

43


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.

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.

44


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 del mundo 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 (Management Information Base). 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

45


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

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, pues, 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

46


dispositivos tengan un software Agente funcionando en todo momento y

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

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 la 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.

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.

47


ICMP (Internet Communication Management Protocol): Cuenta el

número de mensajes ICMP recibidos y los errores.

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

conexiones TCP, retransmisiones, etc.

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.

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), normas RFC 1757

(antes 1271) para Ethernet y 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, ordenadores, 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.

48


3.2 SYSLOG.

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

1980 sólo para éste proyecto. 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

49


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.

Códigos de recurso

Los códigos observados en varios sistemas, basados en el RFC 3164

se numeran en la tabla 3.1.

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 19 Uso local 3

50


sobre la red

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

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

51


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, la cabecera, indica tanto el

tiempo como el nombre del ordenador 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 ordenador (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.

52


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.

53


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 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

54


todas las versiones son compatibles entre si, La única modificación entre la

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

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 y 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

55


herramienta de productividad. Los clientes demandan garantizar, servicios de

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

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

para 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 IOS IP SLA usa monitoreo de tráfico activo, la generación de tráfico de

manera continua, confiable y predecible, para medir el desempeño. Se puede

simular la red de datos y servicios IP y la información recopilar 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, calidad de voz de puntuación, y

el tiempo de respuesta del servidor. Cisco IOS 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. 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. SLA debe ser simple de

comprender y mejorar el tiempo medio de respuesta.

56


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

dispositivo adicional para implementar, aprender o manejar. Una herramienta

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

una solución escalable y rentable para la medición de rendimiento de la red.

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

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, se cuenta con un control de nivel de servicio 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 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,

57


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

(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 Simple Network Management

Protocol (SNMP) trap.

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

Control a través de SNMP o 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) y planificación y cálculo del

factor deterioro (ICPIF).

58


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 jitter, la latencia de red y los

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

puntuaciones MOS de calidad de voz.

Un router de 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.

59


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 proporcionar 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 Cisco IP SLA

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 el software Cisco IOS CLI.

60


Cisco IOS IP SLA realiza vigilancia activa mediante la generación y

análisis de tráfico para medir el rendimiento entre dispositivos de Cisco

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

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

comparan en la tabla 3.3:

Tabla 3.3. SLA tradicional versus IOS de Cisco IP SLA

Requisito SLA tradicional Cisco IOS 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.

61


Cisco IOS 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

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:

62


Cisco IOS IP SLA seguimiento

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

Red de monitoreo del desempeño

- 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

63


opciones configurables. La selección del correcto funcionamiento

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

64


CAPITULO IV CASO PRÁCTICO.

4.1 Monitoreo de los SLA con CISCO IP SLA.

En los SLA normalmente hay un nivel de servicio esperado y un nivel mínimo

de servicio. El nivel de servicio esperado es lo que se contrae y es necesario

dar un buen rendimiento, y el nivel mínimo de servicio sin duda dará malos

resultados. Así por ejemplo, si cae el servicio por debajo del 90% del servicio

esperado de un x número de veces durante un período específico de tiempo o

si cae por debajo del nivel mínimo de servicio de 80%, como se muestra en la

figura 4.1.

1 2 3 4 5 6 7 8 9 100

102030405060708090

100

Nivel de Servico 1Nivel de Servicio 2

Violacion de SLA

Figura 4.1 Ejemplo de monitoreo de SLA.

65


Cisco IP SLA se pueden utilizar para el análisis de la red, dar solución a

problemas en la red, la verificación de los QoS, y el control de nivel de

servicio. Varios de los temas deben ser resueltos antes de decidir cuándo

monitorear los niveles de rendimiento de redes y servicios.

¿Cuál es el objetivo principal de las mediciones? ¿Qué indicadores son

importantes para controlar? En otras palabras, ¿en qué días y horarios son las

medidas necesarias?

El segundo paso es hacer una amplia evaluación de los patrones de tráfico en

la red. Cuando las muestras de paquetes se distribuyen y se mide con mayor

frecuencia, los patrones de tráfico de la red son más confiables. Más puntos

significan que la información es más precisa. Las mediciones activas debe

imitar el tipo de tr áfico en la red de, por ejemplo, el tamaño de paquete

correcto, el espaciamiento de un intervalo para imitar un códec VoIP.

4.2 Escenario Planteado.

En la figura 4.2 se presenta el escenario planteado donde se tiene un sitio web

con el cual se tiene contacto a través de una VPN. En base a estos datos,

debe considerar cómo se puede medir y verificar los niveles de servicio. Por

otra parte, si no se cumplen con estos niveles de servicio, se debe notificar al

NMS desde el cual se hace el monitoreo.

66


Figura 4.2 Escenario planteado

4.2.1 Selección de la operación correcta.

El primer paso en la implementación de los SLA consiste en responder

a la pregunta de qué necesita ser analizada. Una variedad de tipos de

operación son compatibles con Cisco IP SLA. Ya que solo es necesario

obtener el tiempo de respuesta del servidor web las operaciones más

indicadas son:

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 (nivel 3) protocolo de Internet

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 eco UDP en el destino y la recepción de una respuesta de eco

UDP.

67


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), 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 consta 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.

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.

68


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, por lo que, la operación HTTP

será la más indicada para el cálculo de los umbrales de servicio y el

establecimiento del acuerdo de nivel de servicio.

4.2.2Selección del intervalo de muestreo adecuado

La frecuencia con la que Cisco IP SLA envía la supervisión activa y

paquetes muestra, configurado 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, esto no siempre es

factible. Por ejemplo, cuando la vigilancia a través de una conexión

69


WAN es más caro, el usuario no puede ser que desee crear una gran

cantidad de tráfico a través del enlace.

También es importante tener en cuenta el tráfico de vigilancia activa se

genera por el IP SLA en un dispositivo Cisco por software. El poder de

procesamiento podría ser una preocupación cuando un router Cisco de

gama baja se utiliza, o hay una gran cantidad de tráfico que pasa por el

router.

En este caso el intervalo de muestreo seleccionado es de 300

segundos 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 predefinir los umbrales de

rendimiento. Los ISP pueden proporcionar los SLA que especifican la

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

de un SLA particular, son más ambiguos, corresponde al administrador

de red para decidir qué tipo de umbrales para seleccionar

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

necesario hacer primero un monitoreo del tiempo de respuesta que

realmente nos está brindando el servidor HTTP.

Realizamos la primera implementa de CISCO IP SLA con la siguiente

configuración.

70


Figura 4.4 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.

71


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.

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 HTTP503

546 420 490 446543

595 501 524 … 584

TOTAL506

549 423 493 449546

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 empleo la herramienta de Solar Winds

IP SLA Monitor, la cual es muy fácil de usar y provee una intefaz

sencilla de configurar para medir los IP SLA’s de Cisco.

72


En la figura 4.5 podemos ver el modo de configurar el IP SLA, se indica

la dirección del la interfaz del router que realizara la operación y a la

cual el SNMP se encuentra conectado; se selecciona el tiempo de

operación y el intervalo de muestreo; se indica la dirección web a la

cual se medirá el tiempo de respuesta, en este caso se empleo la

dirección de red del servidor ya que no se cuenta con un servidor DNS.

Figura 4.5 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.6

73


Figura 4.6 Configuración de Umbrales de Nivel de Servicio

En la figura 4.7 se presentan algunas capturas de los estados del nivel

servicio que recibimos por el IP SLA monitor, teniendo en cuenta que

cuando se sobre pasa el umbral de tiempo de respuesta optimo la

alerta se presenta en amarillo, mientras que cuando sobrepasa el

umbral mínimo la alarma se presenta en rojo.

74


Figura 4.7 Alarmas obtenidas con IP SLA Monitor.

75


CONCLUSIONES.

Cisco IP SLA es una herramienta que resulto sumamente sencilla de utilizar al

momento de monitorear el tiempo de respuesta de un servidor HTTP; también

pudimos determinar los umbrales de servicio para que de acuerdo a estos se

verifiquen los tiempos de respuesta para determinar el cumplimiento de los acuerdos

de nivel de servicio.

En los casos en los que los umbrales establecidos fueron sobrepasados se

recibieron alertas indicándonos la gravedad del excedente en el tiempo de respuesta,

de esta forma podemos darnos cuenta cuando ocurre alguna anomalía en la

conexión con el servidor HTTP junto con el riesgo que representa a la disponibilidad

de nuestro servicio web; de tal modo que podamos dar una respuesta oportuna a

dicha anomalía.

76


REFERENCIAS

[1].http://gemini.udistrital.edu.co/comunidad/profesores/jruiz/jairocd/texto/redes/

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].Cisco IOS IP SLAs Configuration Guide.

[4].User Guide Cisco IOS IP Service Level Agreements.

77

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



http://gemini.udistrital.edu.co/comunidad/profesores/jruiz/jairocd/texto/redes/temas/admoredest.pdf

http://gemini.udistrital.edu.co/comunidad/profesores/jruiz/jairocd/texto/redes/temas/admoredest.pdf

tesina final

Documents

monitoreo de slas

monitoreo de redes

protocolo de mensajes

sla cisco

ejemplo de monitoreo

monitoreo de pginas

arquitectura centralizada

arquitectura ntp