ETAPA 3 - TRABAJO COLABORATIVO 1

TELEMÁTICA

39

YAQUELINE CHACON
ADOLFO PADILLA
VICTOR ALFONSO OROZCO
FERNANDO ELIECER PIRACOCA

GRUPO 301120A_471

TUTOR:

EDGAR ALFONSO BOJACA

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA “UNAD”

FACULTAD DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA
ABRIL 2018
 INTRODUCCIÓN

Hoy en día las redes telemáticas son la parte fundamental de la comunicación a nivel
global, sin embargo, siempre estarán expuestas a una infinidad de cambios que ayuden a
optimizar nuestros niveles de comunicación en cualquier parte del mundo; en el presente 39
trabajo mostraremos las diferentes soluciones desde varios puntos los cuales fueron
aprendidos en la unidad del curso, teniendo en cuenta un caso estudio “Oficina”. Las
soluciones propuestas tienen como finalidad, diseñar e implementar una red de
computadores “estaciones de trabajo” aplicando las normas de calidad y mejores prácticas
para mitigar riesgos, garantizando que la operatividad de la oficina continúe de forma
adecuada sin presentar pérdidas de dinero y tiempo.
 OBJETIVOS

Desarrollar habilidades que permitan dar solución a problemas inherentes al diseño de

redes telemáticas. 39

Específicos
Diseñar una red telemática donde se detalle todas las fases requeridas para el
diseño de una red telemática.
Conocer todos los servicios que ofrecen las redes telemáticas.
Aprender sobre los medios de transmisión de datos y su normatividad.
Investigar sobre las normas y sistemas de calidad que se encargan de
asegurar los procesos y procedimientos de implementación de redes
telemáticas.
Dimensionar un proyecto de red telemática teniendo en cuenta todos los
requerimientos del cliente.
Capacidad para diseñar sistemas que integran las diversas tecnologías de acceso
a redes ópticas de transporte masivo de información.
Capacidad para conocer y seleccionar los lenguajes adecuados para le diseño,
implantación, análisis y prueba de protocolos, y en particular los lenguajes de
modelado promovidos por organismos de normalización en el área de las redes
de telecomunicación.
TEMA NO 1:
 Explicación del ciclo de vida de una red usando el modelo PDIOO como referencia.
 Descripción de las tareas y objetivos de las distintas fases (Dar una explicación de
las fases)
 Gestión de la disponibilidad 39
 Descripción d ela arquitectura
 Clasificación y ejemplificación de los tipos de herramientas de monitorización.
 Indicadores y métricas
 El firmware en los dispositivos de comunicaciones

Explicación del ciclo de vida de una red usando el modelo PDIOO como referencia
Las redes informáticas están sometidas a continuos cambios, toda red tiene un ciclo de vida
útil. Al cabo de un tiempo puede que se tenga que diseñar una nueva red por el avance de
las nuevas tecnologías, o solo tenga que realizar algunos cambios para que la red sigan
operando sin inconvenientes.
Enviar una foto hoy en día o descargar una película no es lo mismo que hace un tiempo,
como en los años 90, no tienes que esperar tanto como en esos tiempos.
Las diferentes etapas en las que se dividen el siclo de vida de una red: PPDIOO
 Planificar: identificar lo que necesita la red.
 Diseñar: elección de la solución óptima.
 Implementar: crear la red
 Operar: probar y poner en funcionamiento.
 Optimizar: mejorar la red y arreglar problemas
 Retirar: cambiar algún elemento o dar por finalizado el ciclo de vida.
Esta última no se incluye en las siglas, pero siempre hay que tenerla en cuenta.
Con este modelo se estructura de manera lógica las diferentes tareas a lo largo del siclo de
vida de una red.
Una empresa u organización con una nueva red o mejorar una existente, con este modelo
puede llevar a cabo todas las tareas de manera lógica y ordenada.
Descripción de las tareas y objetivos de las distintas fases (Dar una explicación de las
fases).
Planificar: Aquí se identifican todos los requerimientos de la red. Se analizan nuevas
tecnologías y la forma en que se pueden desarrollar. En esta etapa es crucial identificar todo
lo que pueda afectar una red.
Diseñar: Teniendo en cuenta los requerimientos de la fase anterior, es la elaboración de un
plano con la distribución lógica de la red. Este plano irá acompañado de esquemas con
direccionamiento IP, distribución de vlan, elementos de seguridad, especificaciones
técnicas, etc. Luego se elabora un plano con la distribución física de la red, donde se
especifica la ubicación de cada elemento.
Implementar: En esta etapa se lleva a cabo lo diseñado en la anterior. Esto se hará
estableciendo un plan de despliegue que incluirá los plazos de ejecución.
 Se puede empezar con la colocación de tomas de corriente y rosetas de 39
comunicación.
 Luego, el tendido del cableado, e instalación de puntos de acceso inalámbricos.
 Seguimos con la instalación de los rack, pruebas y etiquetas del cableado.
 Instalación de equipos o dispositivos de red (Switch, Router, servidores, etc.).
 Configuración de los dispositivos.
Operar: Se pone a funcionar y se prueba. Aquí por hacer la documentación definitiva del
diseño (mapas lógicos y físicos, esquema de direccionamiento, etc.). Para esto hay que
monitorizar la red con diversos programas que informan el estado de los diferentes
recursos.
Optimizar: Los posibles errores encontrados en la etapa anterior se corrigen en esta etapa.
El mantenimiento de la red debe ser constante, todo bien documentado y de manera ordena.
Retirar: Al final de todas las etapas sigue esta, en el cual se tiene los resultados y se toman
decisiones.
 La red ha llegado al final de su vida útil: no hay posibilidad de mejorar o de
satisfacer las necesidades planteadas, habrá que construir una nueva red.
 La red necesita algunas mejoras que son asumibles en costos y tecnología: Se retira
lo que no sirve y se sustituye por nuevos.
 La red funciona perfectamente: no hay que retirar nada y se vuelve a empezar con la
fase de “planificar” por el avance de la tecnología.

Gestión de la disponibilidad. Es la responsable de optimizar la red y de la revisión

permanente de los servicios que ofrece para que esto funcione lo más ininterrumpidamente
posible y de manera fiable. Elaborará los planes de contingencia y de mantenimiento
preventivo.
Descripción de la arquitectura. Es una “guía” con la que se conectan los protocolos y los
demás programas de software.
La arquitectura de una red viene definida por tres características fundamentales, que
depende de la tecnología empleada para su construcción:
Topología: la topología es la organización del cableado.
Método de acceso a la red: todas las redes que poseen un medio compartido para
transmitir la información necesitan ponerse de acuerdo a la hora de enviar información, ya
que no pueden hacerlo a la vez.
Protocolo de comunicaciones: como ya sabemos son las reglas y procedimientos
utilizados en la red para realizar la comunicación. Existen diferentes niveles de protocolos:
Protocolos de alto nivel, definen cómo se comunican las aplicaciones (programas de
ordenador). Protocolos de bajo nivel, definen cómo se transmiten las señales por el cable.
Entre los protocolos de alto y bajo nivel, hay protocolos intermedios que realizan otras
funciones.
39

Clasificación y ejemplificación de los tipos de monitorización

Existen varios tipos de herramientas que se encargan del monitoreo y análisis de la red. En
particular, los denominados sniffers son de gran utilidad. La palabra sniffer es una marca
registrada de Network Associates, Inc.

En la actualidad sniffer es una denominación aceptada para aquellas herramientas cuya

función principal es monitorizar y analizar tráfico, o sea, examinar paquetes, protocolos y
tramas enviadas a través de la red. La captura y visualización de las tramas de datos por sí
sola puede no ser muy útil o eficiente, es por ello que los analizadores de protocolos
también muestran el contenido de los datos de los paquetes.

Teniendo los paquetes de datos y la información del flujo de tráfico, los administradores
pueden comprender el comportamiento de la red, como por ejemplo las aplicaciones y
servicios disponibles, la utilización de los recursos de ancho de banda y las anomalías en
materia de seguridad, por citar algunos ejemplos.

Los sniffers han formado parte de las herramientas de gestión de redes desde hace bastante
tiempo y han sido usados fundamentalmente con dos objetivos: apoyar a los
administradores en el correcto funcionamiento y mantenimiento de la red a su cargo, o para
facilitar a aquellos individuos malintencionados a acceder e irrumpir en computadoras,
servidores y dispositivos como routers y switches.

Indicadores y métricas

Métrica

Una medida se utiliza para determinar un valor cuantificable de las tablas o las propiedades
de ObjectServer. Ejemplos de métricas son:
  Número actual de conexiones de cliente con un servidor
 Número de sucesos de red sin resolver
 Número de sucesos de red escalados
 La Web GUI tiene varias métricas predefinidas que abarcan muchos de los casos
más frecuentes en la supervisión de redes. Sin embargo, un sitio puede definir su 39
propia colección de métricas además de las que se suministran.

Indicadores

Son los elementos que se utiliza para indicar o señalar algo. Cada indicador puede tener cualquiera
de los seis aspectos siguientes:

Nombre Ejemplos Descripción

Marcador Indican el valor de métrica
mediante el puntero y la altura del
indicador.

Por ejemplo, en el marcador la

aguja, sube y baja por la escala a
Termómetro medida que el valor de la métrica
cambia. Los demás iconos
muestran si el valor de lamétrica
es bajo, medio o alto, según los
umbrales del indicador.

Semáforos
Todos de los indicadores pueden
utilizar cualquiera de los los
aspectos mencionados.
Símbolo
meteorológico
 Nombre Ejemplos Descripción
Emoticono De este modo, el sitio poede elegir
el tipo de indicador más apropiado
para cada métricia.

Botón Estado 39

En los indicadores existen los umbrales que son el conjunto de valores de cada indicador se
divide en tres rangos: bajo, medio y alto.

Hay dos umbrales que determinan la transición de un rango a otro. Cada umbral se expresa
como el porcentaje del rango de valores completo del indicador. Por ejemplo, el umbral
entre bajo y medio puede ser el 50%, y el umbral entre medio y alto puede ser el 90%.

El administrador puede definir los valores de los umbrales de cualquier indicador. Esto
permite adaptar las visualizaciones a la importancia de la métrica.

Cuando el usuario pulsa un indicador, el sistema puede llevar a cabo estas acciones:
 Mostrar una página asociada con un URL completo, como un mapa o una lista de
sucesos ligera (LEL).
 Ejecutar código JavaScript.
 También es posible que un indicador no tenga ninguna acción de pulsación.
 Las posibilidades de JavaScript y URL significan que se pueden producir muy
diversas acciones cuando un usuario pulsa el indicador. Por ejemplo, el sistema
puede mostrar una lista de sucesos asociada a la métrica del indicador, o lanzar otra
aplicación Web GUI, o incluso aplicaciones de otros componentes de Tivoli que se
basan en Tivoli Integrated Portal.

Un usuario accede a Indicadores para supervisar las condiciones de la red. Puede utilizar
los valores de los indicadores y los rangos bajo, medio y alto para identificar las
condiciones que requieren una atención inmediata. Si un indicador tiene asociada una
acción de pulsación, el usuario puede obtener más detalles sobre la métrica del indicador.
Un usuario con los roles de usuario apropiados, el administrador de la Web GUI, puede
personalizar la página y sus indicadores.

El usuario puede hacer lo siguiente:

 Cambiar el título de la página.
39
 Establecer el tamaño de visualización de los indicadores.
 Definir la velocidad de renovación de los indicadores.
 Seleccionar los orígenes de datos y ObjectServer que proporcionan datos a la
página.
 Modificar las propiedades de cualquier indicador.
 Añadir y eliminar indicadores.
 Cambiar el orden de los indicadores de una página.
 Definir los umbrales bajo, medio y alto de cualquier indicador.
 Crear nuevas métricas.
 Cambiar los valores de internacionalización de la página, como la dirección del
texto.

Los administradores también pueden definir el aspecto predeterminado y el contenido de la

página para todos los usuarios. Por lo tanto, el administrador puede definir la página inicial
del sitio. Posteriormente un usuario puede adaptar su copia de la página conforme a sus
necesidades, si tiene los roles de usuario necesarios.

Tal como se suministra, la Web GUI incluye dos páginas de indicadores:

 Rendimiento: muestra las métricas de rendimiento clave de la pasarela y la Web
GUI como por ejemplo el número de conexiones con la Web GUI.
 Detalles y diarios: muestra las métricas de sucesos clave como el número de
sucesos sin resolver y el número de sucesos reconocidos.

Para abrir las páginas de indicadores suministradas,

pulse Disponibilidad > Sucesos > Indicadores clave de rendimiento (KPI).

El firmware en los dispositivos de comunicaciones

El firmware es un programa de ordenador que se inserta en un dispositivo de hardware, por

ejemplo, un microcontrolador. También puede ser proporcionado en ROMS de flash o
como un archivo de imagen binaria que se puede cargar en el hardware existente por un
usuario.
Como su nombre indica, el firmware se encuentra entre el hardware y el software. Al igual
que el software, es un programa que es ejecutado por una computadora.

39
El firmware, cuyo nombre hace referencia a la programación en firme, forma parte del
hardware ya que se encuentra integrado a la electrónica, pero también está considerado
como parte del software al estar desarrollado bajo algún lenguaje de programación. Podría
decirse que el firmware actúa como intermediario entre las órdenes externas que reciben el
dispositivo y sus componentes electrónicos.
Los microprocesadores, las impresoras, los monitores y los chips de memoria son algunos
de los dispositivos que cuentan con firmware. Un ejemplo de firmware es el programa
BIOS de la computadora, que comienza a funcionar apenas se enciende la máquina.
La arquitectura de la computadora está compuesta por una serie de capas con distintos
niveles de abstracción. El hardware es la base y luego aparece el firmware. Sobre él se
suceden el ensamblador, el kernel, el sistema operativo y, al final, las aplicaciones.
Cabe destacar que el usuario, por lo general, cuenta con la posibilidad de actualizar el
firmware de un dispositivo para corregir errores o mejorar sus prestaciones. Estas
actualizaciones, de todas formas, son riesgosas ya que si se produce algún fallo en el
proceso el dispositivo puede dejar de funcionar.

En términos prácticos, las actualizaciones de firmware pueden mejorar el rendimiento y la

fiabilidad, de hecho, incluso la funcionalidad básica dispone de un dispositivo, y muchos se
benefician de los dispositivos ordinarios de actualizaciones de firmware. Uno de los
dispositivos más comunes que se han originado son los dispositivos de grabación óptica de
los medios de comunicación, como los escritores (DVD, CD, HD DVD, Blu-ray), de
manera que estas actualizaciones garantizan que el hardware se mantenga actualizado y
compatible.
 39

TEMA NO 2:
 Explicación del concepto de administración de redes como el conjunto de las fases
operar y Optimizar el modelo PDIOO
 Gestión de la capacidad
 Base de información de Administración (MIB)
 Criterios de identificación de los servicios a monitorizar
 Identificación de indicadores de rendimiento de la red.
 Recomendaciones básicas de buenas prácticas
 Relación entre mantenimiento preventivo y los planes de calidad

 Explicación del concepto de administración de redes como el conjunto de las

fases operar y Optimizar el modelo PDIOO.
Fases Prepare, Plan, Design, Implement, Operate and Optimize (PPDIOO)

Cuatro grandes beneficios:

Fases Prepare, Plan, Design, Implement, Operate and Optimize (PPDIOO)

 Baja el costo total de propiedad por validación de requerimientos de tecnología y 39

planeamiento para cambios de infraestructura y requerimientos de recursos.
 Incrementa la disponibilidad de la red por la producción de un sólido diseño de red
y validaciones en las operaciones.
 Mejora la agilidad de negocios estableciendo requerimientos y estrategias
tecnológicas.
 Velocidad de acceso para aplicaciones y servicios, mejorando disponibilidad,
fiabilidad, seguridad, escalabilidad y performance.

Al ciclo de vida de una red en seis fases como dice el título PPDIOO

Explicación detallada por fases

 Fase de preparación: Esta fase crea un caso de negocios para establecer una
justificación financiera para la estrategia de red. La identificación de la tecnología
que soportará la arquitectura.
 Fase de planeación: Identifica los requerimientos de red realizando una
caracterización y evaluación de la red, realizando un análisis de las deficiencias
contra las buenas prácticas de arquitectura. Un plan de proyecto es desarrollado para
administrar las tareas, parte responsables, hitos y recursos para hacer el diseño y la
implementación. Este plan de proyecto es seguido durante todas las fase del ciclo.
 Fase de diseño: El diseño de la red es desarrollado asado sobre los requerimientos
técnicos y de negocios, obtenidos desde las fases anteriores. Esta fase incluye
diagramas de red y lista de equipos. El plan de proyecto es actualizado con
información mas granular para la implementación. Después de esta fase aprobada
empieza la implementación.
 Fase de implementación: Nuevo equipamiento es instalado y configurado en esta
fase. El plan de proyecto es seguido durante esta fase. Los cambios deben ser
comunicados en una reunión de control de cambios, con la necesaria aprobación
 para proceder. Cada paso en la implementación debe incluir una descripción, guía
de implementación, detallando tiempo estimado para implementar, pasos para
rollback en caso de falla e información de referencia adicional.
 Fase Operativa: Esta fase mantiene el estado de la red día a día. Esto incluye
administración y monitoreo de los componentes de la red, mantenimiento de ruteo,
39
administración de actualizaciones, administración de performance, e identificación
y corrección de errores de red. Esta fase es la prueba final de diseño.
 Fase de Optimización: Esta fase envuelve una administración pro-activa,
identificando y resolviendo cuestiones antes que afecten a la red. Esta fase puede
crear una modificación al diseño si demasiados problemas aparecen, para mejorar
cuestiones de performance o resolver

 La gestión de la capacidad

Es un proceso utilizado para gestionar las tecnologías de la información (a partir de aquí

TI). El objetivo es asegurar que la capacidad de los sistemas de TI cumplen los requisitos
presentes y futuros de la organización con unos costes asumibles. Una de las definiciones
habituales de gestión de la capacidad se encuentra definida por el marco de trabajo ITIL.
Las distintas versiones de ITIL consideran que la gestión de la capacidad engloba tres
subprocesos: gestión de la capacidad de negocio, gestión de la capacidad del servicio y
gestión de la capacidad de los componentes (conocido como gestión de la capacidad de los
recursos en la versión 2 de ITIL).

A medida que el uso de los servicios TI cambia y las funcionalidades evolucionan, la

capacidad de procesamiento, memoria, etc. también cambia. Es necesario entender el
impacto de carga en los recursos/infraestructura de la demanda de Negocio actual y como
esta cambiará a lo largo del tiempo, para planificar los planes de acción necesarios que
garanticen que se cubren las necesidades del Negocio al tiempo que se eliminan la
previsión de riesgos (posible saturación de sistemas, posible rotura de Sla´s, etc...) para que
la gestión de servicios TI sea proactiva y se simplifique (menor nº de incidencias). Por
ejemplo, si hay subidas repentinas de necesidad de capacidad de procesamiento a una
determinada hora del día, debe analizarse que ocurre en esas horas y realizar los cambios
necesarios para maximizar las infraestructuras necesarias, como por ejemplo realizar una
puesta a punto de las aplicaciones o programar ciclos de proceso por lotes a un horario con
menor uso.

Estas actividades se realizan para optimizar el rendimiento y la eficiencia, y para planificar

y justificar inversiones. La gestión de la capacidad tiene en cuenta: 39

 Monitorización del rendimiento y la carga de un servidor o conjunto de servidores.

 Análisis del rendimiento y medición de datos, incluyendo análisis del impacto de
nuevas instalaciones en la capacidad
 Ajustes de rendimiento para asegurar el uso más eficiente de la infraestructura
 Comprensión de las demandas del servicio y planes futuros de aumento o
disminución de carga
 Influencia en la petición de recursos informáticos
 Planificación de la capacidad y desarrollo de un plan para el servicio.

 Base de información de Administración (MIB)

Una Base de Información de Administración (MIB) es una colección de información que

está organizada jerárquicamente. Las MIB’s son accedidas usando un protocolo de
administración de red, como por ejemplo, SNMP.

Un objeto administrado es uno de cualquier número de características específicas de un

dispositivo administrado. Los objetos administrados están compuestos de una o más
instancias de objeto, que son esencialmente variables.

Existen dos tipos de objetos administrados:

Escalares y tabulares. Los objetos escalares definen una simple instancia de objeto. Los
objetos tabulares definen múltiples instancias de objeto relacionadas que están agrupadas
conjuntamente en tablas MIB.

Un ejemplo de un objeto administrado es atInput, que es un objeto escalar que contiene una
simple instancia de objeto, el valor entero que indica el número total de paquetes AppleTalk
de entrada sobre una interfaz de un router.
Un identificador de objeto (object ID) únicamente identifica un objeto administrado en la
jerarquía MIB. La jerarquía MIB puede ser representada como un árbol con una raíz
anónima y los niveles, que son asignados por diferentes organizaciones.

Los vendedores pueden definir ramas privadas que incluyen los objetos administrados para
sus propios productos. Las MIB’s que no han sido estandarizadas típicamente están 39
localizadas en la rama experimental.

El objeto administrado atInput podría ser identificado por el nombre de objeto

iso.identified-
organization.dod.internet.private.enterprise.cisco.temporary.AppleTalk.atInput o por el
descriptor de objeto equivalente 1.3.6.1.4.1.9.3.3.1.

El corazón del árbol MIB se encuentra compuesto de varios grupos de objetos, los cuales en
su conjunto son llamados mib-2. Los grupos son los siguientes:

 System (1).
 Interfaces (2).
 AT (3).
 IP (4).
 ICMP (5).
 TCP (6).
 UDP (7.
 EGP (8).
 Transmission (10).
 SNMP (11).

 Criterios de identificación de los servicios a monitorizar

Mientras que un sistema de detección de intrusiones monitoriza una red de amenazas del
exterior, un sistema de monitorización de red monitoriza la red buscando problemas
causados por servidores sobrecargados y/o caídos, conexiones de red, u otros dispositivos.
Por ejemplo, para determinar el status de un web server, un software de monitorización
puede enviar periódicamente un pedido de HTTP para buscar una página. Para servidores
email, un mensaje de prueba puede ser enviado a través de SMTP y recuperado por IMAP o
POP3. Normalmente las únicas métricas de medición son tiempo de respuesta,
disponibilidad y tiempo de funcionamiento, aunque las métricas de consistencia y fiabilidad
están empezando a ganar popularidad. La suma extendida de dispositivos de optimización
está teniendo un efecto adverso en la mayoría de las herramientas de monitorización –
especialmente cuando se trata de medir apropiadamente el tiempo de respuesta de punta a
punta debido a que limitan la visibilidad de ida y vuelta. Las solicitudes de estado de fallos
39
—tales como cuando una conexión no puede ser establecida, expira, o un documento o un
mensaje no puede ser recuperado— usualmente produce una acción por parte del sistema
de monitorización. Estas acciones varían —una alarma puede ser enviada (vía SMS, email,
etc.)— para el administrador del sistema residente, sistemas automáticos de conmutación
por error pueden ser activados para remover del servicio el servidor con problemas hasta
que pueda ser reparado, etc. Monitorizar la performance de una red de uplink es también
conocido como medición de tráfico de red, y más software está en la lista.

Varios tipos de protocolos

El servicio de monitorización de la web puede chequear páginas HTTP, HTTPS, SNMP,

FTP, SMTP, POP3, IMAP, DNS, SSH, TELNET, SSL, TCP, IC, MS, SIP, UDP, Media
Streaming y un rango de otros puertos con una variedad de intervalos de chequeo que van
desde cada cuatro horas a cada minuto. Obviamente, la mayoría de los servicios de
monitorización de red comprueban su servidor entre 1 vez por hora a 1 vez por minuto.

 Identificación de indicadores de rendimiento de la red.

Rendimiento

El rendimiento en una red está compuesto por los niveles de capacidad , el retardo y el
RMA. En una Red es de suma importancia mantener niveles óptimos en estos
componentes, ya que los diferentes flujos de información generados por los usuarios,
dispositivos o aplicaciones pueden verse fuertemente afectados en sus actividades debido a
variaciones de los niveles de rendimiento.
Se entiende entonces por arquitectura de rendimiento el conjunto de mecanismos que se
utilizan para configurar, operar, gestionar, disponer y listar los recursos en la red que
soportan los tráficos de flujo de información.

Capacidad
39
La capacidad se puede definir genéricamente como la habilidad que tiene el sistema para
lograr la transferencia de información a través de la red. Comúnmente al término de
capacidad se le liga con términos como:

Ancho de banda: es la capacidad que tiene una red para transmitir datos a través de ella,
normalmente se refiere a la cantidad de datos que se pueden transmitir en determinado
momento a través de la red. Comúnmente es medido en bits por segundo(bit/s) o en sus
múltiplos.

Throughput: Se refiere a la tasa promedio de datos o mensajes que han sido transferidos
exitosamente y sin errores en la red de un nodo a otro.

Goodput: Es la cantidad de bits de información utilizables, que se envía en la red a un

destino determinado, por unidad de tiempo.

Retardo

Es la cantidad de tiempo que se toma la transferencia de una unidad de información a través

del sistema desde un origen a un destino. Usuarios que utilizan aplicaciones a tiempo real o
interactivas esperan que el retardo en la red sea mínimo. Así también aplicaciones que
hagan uso de voz o vídeo, se espera que tenga niveles de retardo mínimos. El término
utilizado cuando se dan variaciones en el retardo es conocido como "jitter" y este provoca
alteraciones en transmisiones de voz y video. El retardo es un punto que hay que darle
mucha importancia en las tecnologías dedicadas a la transmisión de información, pero son
especialmente cruciales para los enlaces satelitales y las conexiones con cables muy largos.

RMA

El acrónimo en inglés provienen de los vocablos "reliability, maintainability, y availability"

que en español se traducen como "confiabilidad, mantenibilidad y disponibilidad".
Confiabilidad (reliability): Es un indicador de la frecuencia de fallos que ocurren en la red
y sus componentes, y representa las interrupciones no programadas de los servicios.

Mantenibilidad (maintainability): Es una medición estadística del tiempo que se tarda la

red para volver a estar en optimas condiciones después de haber sufrido una interrupción en
sus funciones de manera inesperada. 39

Disponibilidad (availability): Es la relación que existe entre la cantidad de fallas que

sufren las misiones críticas en el sistema y la cantidad de tiempo que le toma a ese sistema
recuperarse y trabajar adecuadamente.

Desarrollo de los objetivos de rendimiento

El establecer objetivos de desempeño es un punto muy importante al realizar la

planificación de la red y representa como desea el administrador que se comporte la red. El
desarrollo de objetivos se genera en el paso de "análisis de rendimiento" de una forma
generalizada, mencionando que aspectos representan temas de mayor relevancia para el
funcionamiento de la red (normalmente solicitado por un cliente).

Los objetivos son el punto al que se desea llegar cuando se ha terminado la estructuración
de la red, por lo que estos objetivos deben ser desarrollados con cuidado y detenimiento en
el paso de la arquitectura de rendimiento. Los mecanismos que utilicemos deben ser
suficientes para satisfacer las necesidades del cliente, por consiguiente suficientes para
cumplir con los objetivos.

Mecanismos de rendimiento

Los mecanismos proporcionan los medios para identificar los tipos de tráfico de flujo,
medir sus características temporales y adoptar diversas medidas para mejorar el
rendimiento de los flujos individuales, grupales, o para todos los flujos de la red en general.

Calidad de servicios

Se utiliza para la determinar, ajustar e interpretar los niveles de prioridad en los flujos de
tráficos.

Priorizar, gestión de tráfico, planificación y las colas

Priorizar: Proceso por el cual se determinar qué usuarios, aplicaciones, dispositivos, flujos
y conexiones obtendrán el servicio delante de los demás o conseguir un mayor nivel de
servicio.

Gestión de tráfico: Consiste en el control de admisión y acondicionamiento del tráfico.

39
Planificación: Mecanismo que determina el orden en el que el tráfico se procesa para su
transmisión. La planificación usa niveles de prioridad para determinar qué flujos de tráfico
se procesan primero y con más frecuencia.

Colas: Es el proceso donde se ponen en espera o se almacenan los paquetes IP dentro de un

dispositivo de red mientras esperan para su procesamiento.

Acuerdos de nivel de servicios

Son los contratos que se establecen entre proveedor y cliente, en donde el proveedor se
compromete a prestar sus servicios de acuerdo a los parámetros previamente discutidos con
el usuario y el alcance de la responsabilidad si no se cumplen esas responsabilidades por
parte del proveedor.

Políticas

Reglas que pueden ser informales o formales acerca de cómo son los recursos de red (y por
tanto también el rendimiento) se distribuirán entre los usuarios, aplicándose también a los
niveles de acceso que tendrá cada tipo de usuario, a la computación, el almacenamiento u
otros recursos que estén disponibles para los usuarios.

 Recomendaciones básicas de buenas prácticas

Para construir una plataforma telemática resistente a las amenazas cibernéticas.

 Implementar la transferencia segura de datos.

 Firmar digitalmente las actualizaciones.
 Habilitar la protección del código de hardware.
 Ser consciente de que el código es público, para no depender de secretos.
 Utilizar números aleatorios criptográficamente fuertes que no puedan ser sometidos
a prácticas de ingeniería inversa.
  Individualizar datos de seguridad críticos.
 Utilizar distintas claves para roles distintos.
 Supervisar los metadatos para detectar intentos de piratería.
 No olvidar deshabilitar características para depurar errores.
 Realizar auditorías de terceros.
 Limitar el acceso al servidor.
 Aplicar prácticas de diseño seguras. 39
 Implementar apoyo para las actualizaciones de software o firmware.
 Verificar y comprobar.
 Desarrollar una cultura de seguridad.

 Relación entre mantenimiento preventivo y los planes de calidad

El mantenimiento tiene un enlace directo con la calidad de los productos. El equipo con un
buen mantenimiento produce menos desperdicios que el equipo con un mantenimiento
deficiente. El mantenimiento puede contribuir de manera significativa a mejorar y mantener
productos de calidad; por ejemplo, la capacidad de una máquina/herramienta en su mejor
condición producirá más del 99% de piezas dentro de las tolerancias aceptadas. Después de
que la máquina ha estado en servicio durante algún tiempo y se ha presentado desgaste en
algunos de los componentes de la máquina, habrá mayor traqueteo y vibración. La
distribución de las características de calidad tendrá mayor variación y se producirán más
piezas fuera de las especificaciones. Además, más piezas tendrán algunas características de
calidad particulares alejadas del valor meta de dichas características. En términos generales,
un proceso fuera de control genera productos defectuosos y, en consecuencia, aumenta los
costos de producción, lo cual se refleja en una menor rentabilidad, que pone en peligro la
supervivencia de la organización. El mantenimiento preventivo basado en las condiciones
emplea una estrategia de mantenimiento de ciclo cerrado en la que se obtiene información
del equipo y se utiliza para tomar decisiones para el mantenimiento planeado. La decisión
de mantenimiento generalmente se basa en el empleo de un umbral, el cual, una vez
alcanzado, significa que debe realizarse mantenimiento. Tal estrategia asegurará una alta
calidad del producto, especialmente si el umbral se elige de tal manera que el equipo no se
deteriore hasta un grado en el que se generen productos defectuosos o casi defectuosos. El
mantenimiento es un sistema que opera en paralelo con la función de producción. La
principal salida de la producción es el producto deseado con un cierto nivel de calidad, que
es definida por el cliente. Conforme continúa el proceso de producción, se genera una
salida secundaria, a saber, la demanda de mantenimiento, que es una entrada al proceso de
mantenimiento.

La salida del mantenimiento es un equipo en condiciones de dar servicio. Un equipo con un

buen mantenimiento aumenta la capacidad de producción y representa una entrada 39
secundaria a producción. Por lo tanto, el mantenimiento afecta la producción al aumentar la
capacidad de producción y controlar la calidad y la cantidad de la salida. La siguiente figura
ilustra las relaciones entre producción, calidad y mantenimiento.

Relación entre producción, calidad y mantenimiento.

Un informe mensual sobre el porcentaje de trabajos repetidos y rechazados de productos,

puede ayudar a identificar cuáles máquinas requieren una investigación para determinar las
causas de problemas de calidad. Una vez que se investigan las máquinas, se tomará una
medida de acción correctiva para remediar el problema. La medida puede dar por resultado
una modificación de la política actual de mantenimiento y de la capacitación de la fuerza de
trabajo de un oficio particular.
 39

TEMA NO 3:
 Visión general y procesos comprendidos
 Gestión de la seguridad
 Explicación del Concepto TRAP.
 Criterios de planificar los procedimientos de monitorización para que tengan la
menor
 Identificación de indicadores de rendimiento de sistemas
 El centro de operaciones de red
 Objetivos y características de SNMP

TEMA NO 4:
 Gestión de la Configuración
 Componentes de la infraestructura y arquitectura
 incidencia en el funcionamiento de la red.
 Identificación de indicadores de rendimiento de servicios
 Protocolos de administración de red

Mapa de Red Universidad Unad:

 39

 Gestión de la Configuración
Con relación la Gestión de la Configuración en la Implementación de una Red en la
Unad, se debe tener en cuenta la preparación del hardware que se va a utilizar y los
sitios donde se va a instalar el servidor y las estaciones de trabajo, impresoras,
comprobación de los discos, equipos que se van a utilizar como también los cables a
conectarse.

De acuerdo a lo anterior la gestión de la configuración en nuestro proyecto

consistiría en conectar todas las estaciones de trabajo e instalar el software del
sistema operativo, el de red y el de las aplicaciones, para lo cual debemos contar
con un administrador de red que tendrá como función mantener el rendimiento de
los servicios, adicionalmente seria el responsable del diseño, configuraciones,
mantenimiento y planificaciones de la red.
 39

 Componentes de la infraestructura y arquitectura

En una red se debe tener en cuenta el tener una gran variedad de aplicaciones y
también servicios, adicionalmente el funcionamiento de la misma con diferentes
tipo de infraestructuras físicas.

Con relación a lo anterior, la arquitectura de nuestra red debe ser creada y diseñada
para superar las fallas que se presenten, como fallas en software o hardware la cual
se deberá recuperar rápidamente cuando se presenta una inconsistencia y/o error,
garantizando que si algo falla los mensajes se enruten correctamente, a continuación
un ejemplo de la arquitectura de una red:
 39

 incidencia en el funcionamiento de la red.

Existen varias causas que pueden afectar el funcionamiento de una red, en donde
algunos de ellos no se pueden evitar, como por ejemplo los naturales, razón por la
cual para nuestro proyecto se debe tener en cuenta algunas mediciones para poder
bajar los niveles de impacto en el rendimiento de nuestra red. A continuación
relaciono algunos factores:
 rangos de cobertura
 accesos compartidos
 interferencias
 obstrucciones físicas

Respecto a lo anterior se haría necesario mantener un registro de las incidencias que

ocurran:

 Identificación de indicadores de rendimiento de servicios

Con relación al rendimiento óptimo de una red, se deben tener rendimientos
óptimos en los niveles de capacidad y retardo, puesto que las informaciones
generadas por los diferentes usuarios, aplicaciones o dispositivos implementados se
 verían afectados. Por tal razón debemos tener en cuenta realizar la planificación de
la red.

39

 Protocolos de administración de red

Para hacer la administración de una red, (IP), mas eficiente, se debe tener en cuenta
el monitoreo para observar el comportamiento de la misma y un control para de ser
necesario modificar su comportamiento.
De acuerdo a lo anterior, El administrador de la red controla un elemento de red
solicitando al agente del elemento que actualice los parámetros de configuración y
que le de un informe sobre su estado, intercambiando mensajes con el administrador
de la red con el protocolo SNMP. Cualquier elemento que participe en la red puede
ser administrado, incluidos host, ruteadores, concentradores, puentes, multiplexores,
módems, switches de datos, entre otros. Cuando el aparato controlado no soporta, se
usa un agente Proxy, el cual se encargara de actuar como un intermediario entre la
aplicación de administración de red.
TEMA NO 5

 Gestión de Incidencias
 Explicación de las limitaciones de SNMP y la necesidad de monitorización remota
en redes.
 Caracterización de RMON 39
 Comparación de las versiones indicando las capas del modelo TCP/IP en las que
opera cada una.
 Ejemplificación y comparación de herramientas comerciales y de código abierto.
 Planificación del análisis del rendimiento
 Definición y objetivos de mantenimiento preventivo

Tema 5

GESTIÓN DE INCIDENCIAS

La Gestión de Incidencias (Incident Management) es un proceso ITIL enmarcado en la fase

de Operación del Servicio.

Una incidencia es toda interrupción o reducción de la calidad no planificada del servicio.

Pueden ser fallos o consultas reportadas por los usuarios, el equipo del servicio o por
alguna herramienta de monitorización de eventos.

El principal objetivo de la gestión de incidencias es restaurar cuanto antes la operativa

normal del servicio minimizando el impacto negativo en las operaciones de negocio.

Se entiende por operativa normal aquella que se encuentra dentro de los límites del SLA.

3 conceptos básicos sobre la Gestión de Incidencias

Escala de tiempos

A partir del SLA se establecen los tiempos máximos en los que se deben responder y
resolver las incidencias.

Debemos usar herramientas de gestión para el cálculo y la asignación de estas escalas de

tiempo, así como para utilizar alertas y escalados para facilitar la respuesta/resolución de
las incidencias dentro del tiempo máximo definido.
Modelos de incidencia

Los modelos de incidencia permiten optimizar el proceso de resolución.

Existen incidencias que no son nuevas, sino que ya se han producido anteriormente y que se
volverán a producir en el futuro. Muchas empresas encuentran útil la definición de modelos
39
de incidencia que se puedan aplicar a incidencias recurrentes del servicio.

Un modelo de incidencia debería incluir:

Los pasos a seguir para la resolución de la incidencia.

El orden cronológico de estos pasos y sus dependencias si las hubiera.

Responsabilidades: quién debe hacer qué.

Plazos para la realización de las actividades.

Procedimientos de escalado: quién debería ser contactado y cuando.

Incidencias graves

Cada servicio debe definir cuáles son los criterios para que una incidencia se considere
grave.

Las incidencias graves deben tener asociado su propio procedimiento de resolución y

escalado, y tener una escala de tiempos menor que el resto. La actividad de priorización,
que veremos más adelante, debe tener en cuenta estos criterios.

Actividades principales de la Gestión de Incidencias según ITIL v3

Detección

Cuanto antes se detecte una incidencia, menor será su impacto en el negocio.

Por lo tanto, es importante monitorizar los recursos con el objetivo de detectar incidencias
potenciales y normalizar el servicio antes de que se produzca un impacto negativo en los
procesos de negocio o, si esto no es posible, que el impacto sea mínimo.

Registro
Todas las incidencias del servicio deben ser registradas, y cada incidencia debe registrarse
de forma independiente.

La información a registrar generalmente incluye:

– Identificador único.
39
– Categorización.

– Urgencia, impacto y prioridad.

– Fecha y hora.

– Persona/grupo que registra la incidencia.

– Canal de entrada.

– Datos del usuario.

– Síntomas.

– Estado.

– CIs (Configuration Items, elementos de configuración) asociados.

– Persona/grupo asignado para la resolución.

– Problema/Known error asociado.

– Actividades realizadas para la resolución.

– Fecha y hora de la resolución.

– Categoría del cierre.

– Fecha y hora de cierre.

Categorización

En esta actividad se establece el tipo exacto de la incidencia.

Generalmente se establece una categorización multinivel con dependencias entre niveles. El
número de niveles dependerá de la granularidad con la que necesitemos tipificar las
incidencias.

A veces, no se categoriza adecuadamente una incidencia en el momento del registro. Si

esto sucede, debemos asegurarnos de que en el momento del cierre la categorización queda 39
correctamente establecida.

Priorización

Generalmente, la prioridad de la incidencia nos indica cómo se ha de gestionar.

La prioridad de la incidencia suele depender de:

– La urgencia: rapidez con que la incidencia necesita ser resuelta.

– El impacto: generalmente se determina por el número de usuarios afectados, aunque lo

realmente importante es la criticidad para el negocio de los usuarios afectados por la
incidencia. Al final, lo que realmente determina el impacto son los aspectos adversos que la
incidencia tiene en el negocio.

Además de la urgencia y el impacto, la prioridad también puede depender de otros factores

como si el usuario es VIP, el departamento del usuario, etc.

Es muy conveniente que la herramienta de soporte utilizada sea capaz de calcular la

prioridad en base a reglas. En cualquier caso, el equipo de soporte debe conocer estas reglas
para poder priorizar adecuadamente.

Diagnóstico inicial

Cuando el personal de soporte de primer nivel recibe una incidencia, la diganostica en base
a los síntomas y, si está capacitado para ello, la resuelve.

Escalado
Existen dos tipos de escalado:

1. Funcional: el soporte de primer nivel se ve incapaz de resolver la incidencia y la asigna

al grupo resolutor correspondiente.

2. Jerárquico: en caso de que se den ciertas circunstancias (incidencias graves o críticas,

39
riesgo de incumplimiento del SLA) que se deban notificar a los responsables del servicio
correspondiente.

A pesar de que se produzca un escalado, la incidencia sigue perteneciendo al equipo de

Service Desk, y es éste es el responsable de hacer el seguimiento de la misma y mantener
informados a los usuarios hasta su cierre.

Investigación y diagnóstico

Si la incidencia hace referencia a un fallo en el sistema, lo más probable es que se necesite

investigar la causa del fallo.

Las tareas más comunes dentro de esta actividad son las siguientes:

Establecer exactamente qué es lo que no funciona correctamente y para qué secuencia de

acciones del usuario (casuística).

Establecer el impacto potencial de la incidencia.

Determinar si la incidencia está producida por la implantación de un cambio.

Buscar en la base de datos de conocimiento (base de datos de errores conocidos, registro de

incidencias, etc.) posibles soluciones y/o workarounds.

Resolución

Cuando se detecta una solución potencial, ésta debería ser aplicada y testeada. Una vez
comprobada la resolución, la incidencia se da por resuelta y se asigna al equipo de Service
Desk para su cierre.

Asimismo, se deben registrar todas las acciones realizadas para resolver la incidencia en el
historial de la misma.
Cierre

Antes de cerrar la incidencia el equipo del Service Desk debería validar lo siguiente:

Si el usuario está satisfecho con la resolución de la incidencia. 39

Si el cierre ha sido categorizado.

Si se han cumplimentado todos los datos necesarios.

Si es un problema recurrente. En este caso, generar un problema.

Eventualmente, se puede pasar una encuesta de satisfacción al usuario.

Por qué Gestión de Incidencias

Como hemos visto, toda empresa de servicios necesita la Gestión de Incidencias para
prevenir o restaurar tan pronto como sea posible cualquier interrupción o reducción no
planificada en la calidad de su servicio.

Sin embargo, debemos ser conscientes de los desafíos y riesgos de la Gestión de

Incidencias con el fin de garantizar la mejor operación de servicio.

IntroducciÓn a SNMP

El protocolo de gestión de red simple o SNMP (Simple Network Management Protocol), es

un protocolo de la capa de aplicación que facilita el intercambio de información de gestión
entre dispositivos de red. Este protocolo es parte del conjunto de protocolos TCP/IP
(Transmission Control Protocol/Internet Protocol) y, por su amplia utilización en redes
empresariales, es considerado el estándar de facto en detrimento del protocolo CMIP
(Common Management Information Protocol) de la familia de protocolos OSI (Open
Systems Interconnection), más utilizado en las grandes redes de las operadoras de
telecomunicación. SNMP permite a los administradores: gestionar el rendimiento, encontrar
y solucionar problemas, y planificar el crecimiento futuro de la red.

Si bien SNMP se diseñó, en un principio, con el propósito de hacer posible supervisar de

39
forma sencilla y resolver problemas, en routers y bridges; con su ampliación, este protocolo
puede ser utilizado para supervisar y controlar: routers, switches, bridges, hubs, servidores
y estaciones Windows y Unix, servidores de terminal, etc.

El protocolo SNMP opera sobre varios protocolos de transporte, originalmente y

habitualmente sobre UDP (User Datagram Protocol), aunque actualmente también soporta,
OSI CLNS (ConnectionLess Network Service), AppleTalk DDP (Datagram-Delivery
Protocol), y Novell IPX (Internet Packet Exchange).

Componentes bÁsicos de SNMP

Los componentes básicos de una red gestionada con SNMP, son: los agentes, componentes
software que se ejecutan en los dispositivos a gestionar; y los gestores, componentes
software que se ejecutan en los sistemas de gestión de red. Un sistema puede operar
exclusivamente como gestor o como agente, o bien puede desempeñar ambas funciones
simultáneamente. Por consiguiente, el protocolo SNMP tiene una arquitectura cliente
servidor distribuida, como se ilustra en la Figura 1.

La parte servidora de SNMP consiste en un software SNMP gestor, responsable del sondeo
de los agentes SNMP para la obtención de información específica y del envío de peticiones
a dichos agentes solicitando la modificación de un determinado valor relativo a su
configuración. Es decir, son los elementos del sistema de gestión ubicados en la plataforma
de gestión centralizada de red, que interaccionan con los operadores humanos y
desencadenan las acciones necesarias para llevar a cabo las tareas por ellos invocadas o
programadas.
La parte cliente de SNMP consiste en un software SNMP agente y una base de datos con
información de gestión o MIB. Los agentes SNMP reciben peticiones y reportan
información a los gestores SNMP para la comunidad a la que pertenecen; siendo una
comunidad, un dominio administrativo de agentes y gestores SNMP. Es decir, son los 39
elementos del sistema de gestión ubicados en cada uno de los dispositivos a gestionar, e
invocados por el gestor de la red.

El principio de funcionamiento reside, por consiguiente, en el intercambio de información

de gestión entre nodos gestores y nodos gestionados. Habitualmente, los agentes mantienen
en cada dispositivo gestionado información acerca de su estado y su configuración. El
gestor pide al agente, a través del protocolo SNMP, que realice determinadas operaciones
con estos datos de gestión, gracias a las cuales podrá conocer el estado del recurso y podrá
influir en su comportamiento. Cuando se produce alguna situación anómala en un recurso
gestionado, los agentes, sin necesidad de ser invocados por el gestor, emiten los
denominados eventos o notificaciones que son enviados a un gestor para que el sistema de
gestión pueda actuar en consecuencia.

El gestor SNMP puede lanzar cualquiera de estos tres comandos sobre un agente SNMP:

Get. Una petición por el valor específico de un objeto en la MIB del agente. Este
comando es utilizado por el gestor para monitorizar los dispositivos a gestionar.

Get-next. Una petición por un valor en el siguiente objeto en la MIB del agente. Este
comando es utilizado para obtener cada valor sucesivo en un subconjunto o rama de la
MIB.

Set. Utilizado para cambiar el valor de un objeto en la MIB de un agente, en el caso de

que el objeto tenga habilitada la lectura y escritura de su valor. Debido a la limitada
seguridad de SNMP, la mayoría de los objetos de la MIB sólo tienen acceso de lectura. Este
comando es utilizado por el gestor para controlar los dispositivos a gestionar.

Por otro lado, un agente SNMP podría también mandar un mensaje a un gestor SNMP sin el
39
envío previo de una solicitud por parte de éste. Este tipo de mensaje es conocido como
Trap. Los Traps son generalmente enviados para reportar eventos, como por ejemplo el
fallo repentino de una tarjeta del dispositivo gestionado.

El protocolo SNMP debe tener en cuenta y ajustar posibles incompatibilidades entre los
dispositivos a gestionar. Los diferentes ordenadores utilizan distintas técnicas de
representación de los datos, lo cual puede comprometer la habilidad de SNMP para
intercambiar información entre los dispositivos a gestionar. Para evitar este problema,
SNMP utiliza un subconjunto de ASN.1 (Abstract Syntax Notation One) en la
comunicación entre los diversos sistemas.

La principal ventaja de SNMP para los programadores de herramientas de gestión de red, es

su sencillez frente a la complejidad inherente a CMIP. De cara al usuario de dichas
herramientas, CMIP resuelve la mayor parte de las muchas limitaciones de SNMP, pero por
contra, consume mayores recursos (alrededor de 10 veces más que SNMP), por lo cual es
poco utilizado en las redes de telecomunicación empresariales.

Puesto que la consulta sistemática de los gestores, es más habitual que la emisión
espontánea de datos por parte de los agentes cuando surgen problemas, SNMP es un
protocolo que consume un considerable ancho de banda, lo cual limita su utilización en
entornos de red muy extendidos. Esto es una desventaja de SNMP respecto a CMIP, que
puesto que trabaja en modo conectado en vez de mediante sondeo secuencial, permite
optimizar el tráfico. SNMP, en su versión original, tampoco permite transferir
eficientemente grandes cantidades de datos.
No obstante, la limitación más importante de SNMP es que carece de autentificación, lo
cual supone una alta vulnerabilidad a varias cuestiones de seguridad, como por ejemplo:
modificación de información, alteración de la secuencia de mensajes, enmascaramiento de
la entidad emisora, etc. En su versión original, cada gestor y agente es configurado con un 39
nombre de comunidad, que es una cadena de texto plano. Los nombres de comunidad,
enviados junto a cada comando lanzado por el gestor, sirven como un débil mecanismo de
autentificación, ya que puesto que el mensaje no está cifrado, es muy sencillo que un
intruso determine cual es dicho nombre capturando los mensajes enviados a través de la
red. Cuando un agente SNMP captura una petición SNMP, primero comprueba que la
petición que le llega es para la comunidad a la cual pertenece. Solamente en el caso de que
el agente pertenezca a dicha comunidad, o bien consulta en la MIB el valor del objeto
solicitado y envía una respuesta al gestor SNMP con dicho valor en el caso de un comando
Get, o bien cambia el valor en el caso de un comando Set. CMIP, por trabajar en modo
conectado, ofrece una mayor seguridad que SNMP.

Finalmente señalar que, como hemos visto, SNMP sólo define el protocolo para el
intercambio de información de gestión entre el gestor y el agente y el formato para
representar la información de gestión o MIB. Por ello, para facilitar la gestión de red, es
conveniente adquirir un gestor de red gráfico multifabricante basado en SNMP, utilizando
plataformas comerciales como: OpenView de Hewlett Packard (que es el producto más
representativo con más de un 40% de cuota de mercado), SunNet de Sun Microsystems,
NetView de IBM, etc. Muchas veces, estas plataformas multifrabricante, suelen convivir
con otras plataformas de gestión de red monofabricante, con el fin de aprovechar al
máximo los desarrollos propios y particulares de cada proveedor.

Red gestionada con SNMP

 39

Figura 1: Esquema de una red gestionada con SNMP.

Referencia

https://www.servicetonic.es/itil/itil-v3-gestion-de-incidencias/

https://www.ramonmillan.com/tutoriales/snmpv3.php
 39

CONCLUSIONES

Dentro De la organización sistemática y telemática, es necesario generar los planes de

desarrollo de la red, los cuales deben estar legislados y normativos según la aplicación y
uso de la misma.

Para ello podemos generar planes de calidad y disponibilidad, tomando como referencia
el modelo PPDIOO el cual se enfoca en hacer del desarrollo de la red una estructura
sólida, analítica y viable.

Nuestra redo puede ser abierta a un sin número de posibilidades, de avance y

actualización, igualmente se puede limitar según los requerimientos de la empresa y
proyecciones, para ello se establecen los, equipos, vida útil de ellos, compatibilidades con
otros programas y demás.

BIBLIOGRAFIA
FiRmWaRE. (10 de 2011). Obtenido de http://firmware-santiago.blogspot.com.co/

IBM® Knowledge Center. (s.f.). Obtenido de

https://www.ibm.com/support/knowledgecenter/es/SSNFET_9.2.0/com.ibm.netcool
_OMNIbus.doc_7.4.0/webtop/wip/concept/web_ovr_gauges.html

39