Portada de la Tesis1 CORREGIDA

“ La Técnica al Servicio de la Patria”

INSTITUTO POLITÉCNICO NACIONAL

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

UNIDAD "CULHUACAN”

Implementación de la Solución de Monitoreo de

Redes con IBM Tivoli Netview

T E S I N A

SEMINARIO DE TITULACIÓN:

Ínterconectividad y Segmentación de Redes de Alta Velocidad

PARA OBTENER EL TÍTULO DE:

INGENIERO EN INFORMÁTICA (UPIICSA) ING. JOSE LUIS LUNA CEDILLO INGENIERO EN INFORMÁTICA (UPIICSA) ING. LUIS RODOLFO ROSAS ESPINDOLA INGENIERO EN INFORMÁTICA (UPIICSA) ING. FRANCISCO SAÚL VERGARA GALVÁN INGENIERO EN COMUNICACIONES Y ELECTRÓNICA ING. JOSE ALBERTO PINEDA SALAZAR ASESOR: M. EN C. RAYMUNDO SANTANA ALQUICIRA

MÉXICO, D.F. JUNIO 2007

AGRADECIMIENTOS

Antes que nada quiero agradecerle a Dios por darme la vida y la oportunidad de

haber terminado mi carrera.

También quiero agradecerle a mis padres a quienes nunca podré pagar todos sus desvelos ni aún con las riquezas más grandes del mundo. Porque gracias a su apoyo y consejos, he llegado a realizar la más grande de mis metas. La cual constituye la herencia más valiosa que pudiera recibir. Tampoco puedo olvidarme del resto de mi familia, que me ha apoyado y comprendido en todo momento. Además agradezco a mis amigos y a mi pareja que durante mi vida han estado conmigo en situaciones difíciles y también en momentos muy alegres. Ellos ya saben quienes son y tienen mi más sincera gratitud por todo. Por ultimo agradezco a mis asesores y a mis profesores ya que sin su apoyo y sus

conocimientos no habría sido posible concluir con mi carrera satisfactoriamente.

Con Amor, Admiración y Respeto

José Luis Luna

AGRADECIMIENTOS A mi padre Jorge Rodolfo Rosas que esta en el cielo y que gracias a el pude terminar mi carrera y ser un hombre de bien (gracias apa), a mi madre Gloria Espindola quien siempre ha estado a mi lado apoyandome en las buenas y en las malas y siempre ofreciendome su amor incondicional y a mis hermanos Enrique, Edgardo y Gloria que siempre han estado conmigo apoyandome. A la banda Jose Luis, Saul, Beto, Nick, Juan Ma, Yadira y Panda quienes me han apoyado a lo largo de la carrera y en los momentos mas dificiles de mi vida (gracias carnales).

Luis R. Rosas Espindola

Agradezco: A todos aquellos que en cualquier momento me estuvieron apoyando y soportando en mis malos ratos y sobre todo cuando necesite de ellos. En especial quiero agradecer a mi Mama Marina Galván, A mi hermana Mónica Vergara (y a Nena), a mi Papa Elías Vergara, a mi hermana Mariana Galván, y a mis sobrinos Karla, Oscar y Kevin por su cariño, comprensión y apoyo. A mis amigos y compañeros de generación con quienes se formo una estrecha relación de amistad y apoyo mutuo.

Gracias por todo……….!!

Saúl Vergara Galván

AGRADECIMIENTOS

Agradezco el apoyo brindado a Lucia Salazar Hernandez y a Jose Cesar Adan Pineda Oliver quienes siempre me han apoyado a lo largo de mi carrera y

siempre han estado conmigo para apoyarme en los momentos mas dificiles

Implementación de la solución de monitoreo de redes con IBM Tivoli Netview

IBM Tivoli NetView

Página: 2/92 Información confidencial - propiedad intelectual de

CONTENIDO

INTRODUCCIÓN ...................................................................................................................... 5 OBJETIVO ................................................................................................................................ 6 PLANTEAMIENTO DEL PROBLEMA...................................................................................... 6 JUSTIFICACIÓN....................................................................................................................... 6 ALCANCE................................................................................................................................. 6 CAPÍTULO 1: INTRODUCCIÓN A LAS REDES ..................................................................... 7

1.1 INTRODUCCIÓN............................................................................................................. 7 1.2 ¿QUÉ ES UNA RED INFORMÁTICA?............................................................................. 7 1.3 ESTRUCTURA DE LAS REDES...................................................................................... 8 1.4 TIPOS DE REDES ........................................................................................................... 8

1.4.1 Redes LAN................................................................................................................ 9 1.4.2 Redes MAN............................................................................................................... 9 1.4.3 Redes WAN ............................................................................................................ 10 1.4.4 Redes INTERNET................................................................................................... 10 1.4.5 Redes Inalámbricas ................................................................................................ 11

1.5 TOPOLOGÍAS DE RED ................................................................................................. 11 CAPÍTULO 2: TCP/IP ............................................................................................................. 12

2.1 DEFINICIÓN .................................................................................................................. 13 2.2 CAPAS DE TCP/IP......................................................................................................... 13 2.3 FIABILIDAD ................................................................................................................... 16 2.4 CONEXIONES............................................................................................................... 17 2.5 FORMATO DEL SEGMENTO TCP................................................................................ 18 2.6 ESTABLECIMIENTO DE UNA CONEXIÓN................................................................... 20

CAPÍTULO 3: SWITCHEO Y RUTEO .................................................................................... 22 3.1 SWITCH......................................................................................................................... 22

3.1.1 Conmutación de Redes........................................................................................... 23 3.2 FUNCIONAMIENTO DE SWITCHES LAN..................................................................... 24 3.3 RUTEO .......................................................................................................................... 25

3.3.1Parámetros............................................................................................................... 25 3.4 ENCAMINAMIENTO EN REDES DE CIRCUITOS VIRTUALES Y DE DATAGRAMAS. 26 3.5 CLASIFICACIÓN DE LOS MÉTODOS DE ENCAMINAMIENTO................................... 26

3.5.1 Determinísticos ó Estáticos..................................................................................... 26 3.5.2 Adaptativos ó Dinámicos......................................................................................... 26 3.5.3 Encaminamiento Adaptativo con Algoritmos Distribuidos....................................... 27

3.6 PROTOCOLOS DE ENRUTAMIENTO .......................................................................... 28 3.6.1 IGRP ....................................................................................................................... 28 3.6.2 EIGRP ..................................................................................................................... 28 3.6.3 IS-IS ........................................................................................................................ 29

IBM Tivoli NetView

Página: 3/92 Información confidencial - propiedad intelectual de Grupo

3.6.4 OSPF ...................................................................................................................... 29 3.6.5 RIP .......................................................................................................................... 29 3.6.6 Border Gateway Protocol ........................................................................................ 30

CAPÍTULO 4: ADMINISTRACIÓN DE REDES Y SNMP....................................................... 31 4.1 ADMINISTRACIÓN DE REDES..................................................................................... 31 4.2 ARQUITECTURA DE LA ADMINISTRACIÓN DE REDES ............................................ 32 4.3 MODELO DE ADMINISTRACIÓN DE REDES ISO ....................................................... 33 4.4 PLATAFORMAS DE LA ADMINISTRACIÓN DE REDES .............................................. 33 4.5 COMPONENTES DE LA ARQUITECTURA SNMP ....................................................... 34

4.5.1 Network Management Station................................................................................. 34 4.5.2 Agentes ................................................................................................................... 34 4.5.3 Management Information Base (MIB). .................................................................... 35

4.6 PROTOCOLO DE ADMINISTRACIÓN Ó SNMP ........................................................... 38 4.6.1 Funcionamiento de SNMP ...................................................................................... 39 4.6.2 Versiones de SNMP................................................................................................ 42

CAPÍTULO 5: DESCRIPCION DE LA SOLUCION DE MONITOREO DE LA RED DE DUPONT S.A. DE C.V. ........................................................................................................... 44

5.1 PROBLEMÁTICA DE LA RED . .............................................................................................. 44 5.1.1 Problemas de la red ................................................................................................ 44

5.2 ANÁLISIS DE LA PROBLEMÁTICA Y DE LA SOLUCIÓN .............................................................. 44 5.2.1 Descripción de la red .............................................................................................. 44 5.2.2 Análisis del problema y de la solución .................................................................... 46

5.3 SOLUCIÓN DE MONITOREO. ............................................................................................... 46 5.3.1 Diseño Físico .......................................................................................................... 46 5.3.2 Especificaciones de Operación............................................................................... 48 5.3.3 Configuración del producto. .................................................................................... 51

CONCLUSIONES. .................................................................................................................. 66 GLOSARIO ............................................................................................................................. 67 INDICE DE TABLAS............................................................................................................... 69 INDICE DE FIGURAS............................................................................................................. 69 ANEXO 1 DIAGRAMAS DE LA SOLUCIÓN DEL MONITOREO.......................................... 71 ANEXO 2 CONFIGURACION SNMP EN RUTEADORES Y POLEO.................................... 74 ANEXO 3 FIGURAS DE LAS METRICAS PARA IMPRESIÓN............................................. 77 ANEXO 4 FIGURAS PARA LOS PROCEDIMIENTOS LAN CISCO..................................... 79

Procedimiento disponibilidad de interfaces...................................................................... 79 Procedimiento para el monitoreo de utilización CPU en switches................................... 80 Procedimiento para la utilización de memoria en switches ............................................. 83 Procedimiento para errores en interfaces de Switches ................................................... 84

IBM Tivoli NetView


ANEXO 5 FIGURAS PARA LOS PROCEDIMIENTOS WAN CISCO.................................... 86 Procedimiento para uso de memoria en ruteadores........................................................ 86 Procedimiento para utilización de ancho de banda en ruteadores .................................. 87 Procedimiento para la configuración de los eventos ....................................................... 90

BIBLIOGRAFÍA ...................................................................................................................... 92

IBM Tivoli NetView


INTRODUCCIÓN La proliferación de redes de datos a lo largo de la década de los 90, tanto LAN’s como WAN’s, y el funcionamiento entre ellas hace que los aspectos relativos a su control y administración sean cada vez más tenidos en cuenta, convirtiéndose en algo a lo que todos los responsables de redes han de prestar una gran atención. El monitoreo y el aseguramiento de la disponibilidad de la red es fundamental para que el funcionamiento de sistema cumpla con los niveles requeridos. Es aquí donde la administración de dispositivos TCPIP se convierte en una práctica de administración necesaria en la administración de sistemas. Actualmente, la infraestructura de negocio requiere de herramientas de administración y monitoreo de la disponibilidad que permitan visualizar todo el sistema con el objetivo de asegurar que cualquier pico en el uso de los sistemas no afecte el proceso de negocio actual. Las claves para mantener un ambiente de red libre de problemas y la habilidad para aislar y reparar rápidamente daños en la red son la documentación, planificación y la comunicación. Para esto se requiere de una base de procedimientos y de personal puestos en los sitios estratégicos de la red antes de que los problemas sucedan. Network Management es el arte de acoplar los ambientes de redes hacia los requerimientos de negocio. Esto proporciona a las áreas de TI el importante significado de realizar las siguientes tareas: planear, configurar, mantener y monitorear a las redes que soportan los procesos de negocio de la manera más eficiente. Un modelo que enfatiza la relación que existe entre la parte de TI y los usuarios de servicios es el que proporcionan las grandes empresas. IBM organiza los productos Tivoli de acuerdo a las necesidades de los clientes. IBM Tivoli Netview monitorea pro-activamente los recursos de red, enfocado a ambientes empresariales, permite al administrador detectar fallas en la disponibilidad de dispositivos TCPIP y/o servidores de cómputo, o incluso, mediante la captura de información de rendimiento, detectar indicios de falla antes de que se afecte la operación de los mismos y genere un impacto en el negocio. La tecnología de aislamiento de fallas en enrutamiento (Router Fault Isolation) de IBM Tivoli NetView rápidamente identifica y se centra en el problema que causó el error en la red e inicia acciones correctivas. Asimismo, captura los datos que resuelven los problemas de la red, dando lugar a soluciones rápidas y la alta disponibilidad de los sistemas que requiere la empresa DUPONT S.A. de C.V.

IBM Tivoli NetView


OBJETIVO Implementar la solución de monitoreo de red a través de SNMP, con la finalidad de mejorar la disponibilidad y el rendimiento de los diferentes dispositivos TCPIP, mediante la automatización del monitoreo de ruteadores, switches e impresoras que conforman la red de comunicaciones de la empresa Dupont S.A. de C.V

PLANTEAMIENTO DEL PROBLEMA La empresa DUPONT S.A. de C.V. actualmente no cuenta con un sistema que le permita monitorear los diferentes componentes que conforman su red y por consiguiente le es imposible llevar una buena administración y control de los mismos. Estas limitaciones traen como resultado el no poder llevar a cabo las acciones necesarias y no poder actuar de manera oportuna ante la presencia de un evento determinado en cualquier dispositivo de la red.

JUSTIFICACIÓN La implementación de la solución tiene la finalidad de reducir tiempos de respuesta en la detección y corrección de fallas en dispositivos o en enlaces en la red de datos, así como la centralización de la administración y mantenimiento de la red de una manera pro-activa y eficiente, resumiendo como razones principales que justifican el proyecto tenemos:

• Detección de fallas.

• Mejorar el rendimiento.

• Documentación.

• Reportes.

ALCANCE El diseño de la solución presentado en este documento ha sido creado para adaptarse al ambiente operativo actual en la red de Dupont S.A. de C.V., es decir el monitoreo de la red utilizando SNMP y únicamente sobre ruteadores y switches de la marca Cisco e impresoras HP. Esta solución provee una gran flexibilidad y escalabilidad sin que sea necesario un cambio radical en el diseño.

IBM Tivoli NetView


CAPÍTULO 1: INTRODUCCIÓN A LAS REDES

1.1 INTRODUCCIÓN

El desarrollo del hombre desde el nivel físico de su evolución, pasando por su crecimiento en las áreas sociales y científicas hasta llegar a la era moderna se ha visto apoyado por herramientas que extendieron su funcionalidad y poder como ser viviente.

Sintiéndose conciente de su habilidad creativa, metódicamente elaboró procedimientos para organizar su conocimiento, sus recursos y manipular su entorno para su comodidad, impulsando las ciencias y mejorando su nivel de vida a costa de sacrificar el desarrollo natural de su ambiente, produciendo así todos los adelantos que un gran sector de la población conoce: automóviles, aeroplanos, trasatlánticos, teléfonos, televisiones, etc.

En el transcurso de todo este desarrollo, también evolucionó dentro del sector tecnológico el cómputo electrónico. Este nació con los primeros ordenadores en la década de los años 40, porque la necesidad del momento era extender la rapidez del cerebro humano para realizar algunos cálculos aritméticos y procedimientos repetitivos.

Este esfuerzo para continuar avanzando, se reflejó en crear unidades de procesamiento cada vez más veloces, divididas en cuatro generaciones bien definidas: la primera con tubos al vacío, la segunda con transistores, la tercera con circuitos integrados y la cuarta con circuitos integrados que permitieron el uso de computadoras personales y el desarrollo de las redes de datos.

Este último elemento, las redes de ordenadores, consisten en "compartir recursos", y uno de sus objetivos principales es hacer que todos los programas, datos y hasta los propios equipos estén disponibles para cualquier usuario que así lo solicite, sin importar la localización física del recurso y del propio usuario.

1.2 ¿QUÉ ES UNA RED INFORMÁTICA?

Una red es un sistema donde los elementos que lo componen (por lo general ordenadores) son autónomos y están conectados entre sí por medios físicos y/o lógicos y que pueden comunicarse para compartir recursos. Independientemente a esto, definir el concepto de red implica diferenciar entre el concepto de red física y red de comunicación.

Respecto a la estructura física, los modos de conexión física, los flujos de datos, etc.; una red la constituyen dos o más ordenadores que comparten determinados recursos, sea hardware (impresoras, sistemas de almacenamiento...) o sea software (aplicaciones, archivos, datos...).

IBM Tivoli NetView


Desde una perspectiva más comunicativa, podemos decir que existe una red cuando se encuentran involucrados un componente humano que comunica, un componente tecnológico (ordenadores, televisión, telecomunicaciones) y un componente administrativo (institución o instituciones que mantienen los servicios). En fin, una red, más que varios ordenadores conectados, la constituyen varias personas que solicitan, proporcionan e intercambian experiencias e informaciones a través de sistemas de comunicación.

1.3 ESTRUCTURA DE LAS REDES

Las redes tienen tres niveles de componentes: software de aplicaciones, software de red y hardware de red.

El Software de Aplicaciones, programas que se comunican con los usuarios de la red y permiten compartir información (como archivos, gráficos o vídeos) y recursos (como impresoras o unidades de disco).

El software de Red, programas que establecen protocolos para que los ordenadores se comuniquen entre sí. Dichos protocolos se aplican enviando y recibiendo grupos de datos formateados denominados paquetes.

El Hardware de Red, formado por los componentes materiales que unen los ordenadores. Dos componentes importantes son los medios de transmisión que transportan las señales de los ordenadores (típicamente cables o fibras ópticas) y el adaptador de red, que permite acceder al medio material que conecta a los ordenadores, recibir paquetes desde el software de red y transmitir instrucciones y peticiones a otros ordenadores.

En resumen, las redes están formadas por conexiones entre grupos de ordenadores y dispositivos asociados que permiten a los usuarios la transferencia electrónica de información. En estas estructuras, los diferentes ordenadores se denominan estaciones de trabajo y se comunican entre sí a través de un cable o línea telefónica conectada a los servidores.

Dichos servidores son ordenadores como las estaciones de trabajo pero con funciones administrativas y están dedicados en exclusiva a supervisar y controlar el acceso a la red y a los recursos compartidos. Además de los ordenadores, los cables o la línea telefónica, existe en la red el módem para permitir la transferencia de información convirtiendo las señales digitales a analógicas y viceversa, también existen en esta estructura los llamados Hubs y Switches con la función de llevar acabo la conectividad.

1.4 TIPOS DE REDES

Las redes según sea la utilización por parte de los usuarios pueden ser:

Redes Compartidas, aquellas a las que se une un gran número de usuarios, compartiendo todas las necesidades de transmisión e incluso con transmisiones de otra naturaleza.

IBM Tivoli NetView


Redes exclusivas, aquellas que por motivo de seguridad, velocidad o ausencia de otro tipo de red, conectan dos o más puntos de forma exclusiva. Este tipo de red puede estructurarse en redes punto a punto o redes multipunto.

Otro tipo se analiza en cuanto a la propiedad a la que pertenezcan dichas estructuras, en este caso se clasifican en:

Redes privadas, aquellas que son gestionadas por personas particulares, empresa u organizaciones de índole privado, en este tipo de red solo tienen acceso los terminales de los propietarios.

Redes públicas, aquellas que pertenecen a organismos estatales y se encuentran abiertas a cualquier usuario que lo solicite mediante el correspondiente contrato.

Otra clasificación, la más conocida, es según la cobertura del servicio en este caso pueden ser:

Redes LAN (Local Area Network), redes MAN (Metropolitan Area Network), redes WAN (Wide Area Network), redes internet y las redes inalámbricas.

1.4.1 Redes LAN

LAN es la abreviatura de Local Area Network (Red de Área Local o simplemente Red Local). Una red local es la interconexión de varios ordenadores y periféricos. Su extensión esta limitada físicamente pp a un edificio o a un entorno de unos pocos kilómetros. Su aplicación más extendida es la interconexión de ordenadores personales y estaciones de trabajo en oficinas, fábricas, etc; para compartir recursos e intercambiar datos y aplicaciones. En definitiva, permite que dos o más máquinas se comuniquen.

El término red local incluye tanto el hardware como el software necesario para la interconexión de los distintos dispositivos y el tratamiento de la información.

1.4.2 Redes MAN

Una red de área metropolitana (Metropolitan Area Network o MAN, en inglés) es una red de alta velocidad (banda ancha) que dando cobertura en un área geográfica extensa, proporciona capacidad de integración de múltiples servicios mediante la transmisión de datos, voz y vídeo, sobre medios de transmisión tales como fibra óptica y par trenzado de cobre a velocidades que van desde los 2 Mbit/s hasta 155 Mbit/s.

El concepto de red de área metropolitana representa una evolución del concepto de red de área local a un ámbito más amplio, cubriendo áreas mayores que en algunos casos no se limitan a un entorno metropolitano sino que pueden llegar a una cobertura regional e incluso nacional mediante la interconexión de diferentes redes de área metropolitana.

IBM Tivoli NetView


1.4.3 Redes WAN

Una red de área amplia, WAN, acrónimo de la expresión en idioma inglés Wide Area Network, es un tipo de red de computadoras capaz de cubrir distancias desde unos 100 hasta unos 1000 km, dando el servicio a un país o un continente. Un ejemplo de este tipo de redes sería RedIRIS, Internet o cualquier red en la cual no estén en un mismo edificio todos sus miembros (sobre la distancia hay discusión posible).

Muchas WAN son construidas por y para una organización o empresa particular y son de uso privado, otras son construidas por los proveedores de internet (ISP) para proveer de conexión a sus clientes.

Hoy en día internet proporciona WAN de alta velocidad, y la necesidad de redes privadas WAN se ha reducido drásticamente mientras que las VPN que utilizan cifrado y otras técnicas para hacer esa red dedicada aumentan continuamente.

Normalmente la WAN es una red punto a punto, es decir, red de paquete conmutado. Las redes WAN pueden usar sistemas de comunicación vía satélite o de radio. Fue la aparición de los portátiles y los PDA´s la que trajo el concepto de redes inalámbricas.

Una red de área amplia o WAN (Wide Area Network), se extiende sobre un área geográfica extensa, a veces un país o un continente; y su función fundamental está orientada a la interconexión de redes o equipos terminales que se encuentran ubicados a grandes distancias entre sí. Para ello cuentan con una infraestructura basada en poderosos nodos de conmutación que llevan a cabo la interconexión de dichos elementos, por los que además fluyen un volumen apreciable de información de manera continua. Por esta razón también se dice que las redes WAN tienen carácter público, pues el tráfico de información que por ellas circula proviene de diferentes lugares, siendo usada por numerosos usuarios de diferentes países del mundo para transmitir información de un lugar a otro. A diferencia de las redes LAN, la velocidad a la que circulan los datos por esta suele ser menor que la que se puede alcanzar en las LAN. Además, las redes LAN tienen carácter privado, pues su uso está restringido normalmente a los usuarios miembros de una empresa, o institución, para los cuales la red fue diseñada.

1.4.4 Redes INTERNET Una Interred es un sistema de comunicación compuesto por varias redes que se han enlazado juntas para proporcionar unas posibilidades de comunicación ocultando las tecnologías y los protocolos y métodos de interconexión de las redes individuales que la componen. Estas son necesarias para el desarrollo de sistemas distribuidos abiertos extensibles. En ellas se puede integrar una gran variedad de tecnología de redes de área local y amplia, para proporcionar la capacidad de trabajo en red necesaria para cada grupo de usuario. Así, las intercedes aportan gran parte de los beneficios de los sistemas abiertos a las comunicaciones de los sistemas distribuidos.Las interredes se construyen a partir de varias redes.

IBM Tivoli NetView


Estas están interconectadas por computadoras dedicadas llamadas routers y computadores de propósito general llamadas gateways, y por un subsistema integrado de comunicaciones producidos por una capa de software que soporta el direccionamiento y la transmisión de datos a los computadores a través de la interred. Los resultados pueden contemplarse como una red virtual construida a partir de solapar una capa de interred sobre un medio de comunicación que consiste en varias redes, routers y gateways subyacentes. 1.4.5 Redes Inalámbricas La conexión de los dispositivos portátiles y de mano necesitan redes de comunicaciones inalámbricas (wireless networks). Algunos de ellos son la IEEE802.11(wave lan) son verdaderas redes LAN inalámbricas (wireless local area networks;WLAN) diseñados para ser utilizados en vez de los LAN . También se encuentran las redes de area personal inalámbricas, incluida la red europea mediante el Sistema Global para Comunicaciones Moviles, GSM (Global System for Mobile Communication). En los Estados Unidos , la mayoría de los teléfonos móviles están actualmente basados en la análoga red de radio celular AMPS, sobre la cual se encuentra la red digital de comunicaciones de Paquetes de Datos Digitales Celular, CDPD(Cellular Digital Packet Data). Dado el restringido ancho de banda disponible y las otras limitaciones de los conjuntos de protocolos llamados Protocolos de Aplicación Inalámbrica WAP (Wireless Aplication Protocol).

1.5 TOPOLOGÍAS DE RED

Cuando se menciona la topología de redes, se hace referencia a la forma geométrica en que están distribuidas las estaciones de trabajo y los cables que las conectan. Su objetivo es buscar la forma más económica y eficaz de conexión para, al mismo tiempo, aumentar la fiabilidad del sistema, evitar los tiempos de espera en la transmisión, permitir un mejor control de la red y lograr de forma eficiente el aumento del número de las estaciones de trabajo.

Dentro de las topologías que existen, las más comunes son:

Bus: Las estaciones están conectadas a un único canal de comunicaciones.

Fig. 1. 1 Topología en bus

Anillo: Las estaciones se conectan formando un anillo. Cada una está conectada a la siguiente y la última está conectada a la primera.

IBM Tivoli NetView


Fig. 1. 2 Topología en Anillo

Estrella: Las estaciones están conectadas directamente al servidor y todas las comunicaciones se han de hacer necesariamente a través de él.

Fig. 1. 3 Topología en Estrella

Árbol: En esta topología los nodos están conectados en forma de árbol. Esta conexión es semejante a una serie de redes en estrella interconectadas.

Fig. 1. 4 Topología en Árbol

Malla: En esta topología se busca tener conexión física entre todos los ordenadores de la red, utilizando conexiones punto a punto lo que permitirá que cualquier ordenador se comunique con otros de forma paralela si fuera necesario.

Fig. 1. 5 Topología en Malla

CAPÍTULO 2: TCP/IP

IBM Tivoli NetView


2.1 DEFINICIÓN

El protocolo TCP (Transmission Control Protocol, protocolo de control de transmisión) está basado en IP que es no fiable y no orientado a conexión, y sin embargo es:

• Orientado a conexión. Es necesario establecer una conexión previa entre las dos máquinas antes de poder transmitir ningún dato. A través de esta conexión los datos llegarán siempre a la aplicación destino de forma ordenada y sin duplicados. Finalmente, es necesario cerrar la conexión.

• Fiable. La información que envía el emisor llega de forma correcta al destino.

El protocolo TCP permite una comunicación fiable entre dos aplicaciones. De esta forma, las aplicaciones que lo utilicen no tienen que preocuparse de la integridad de la información: dan por hecho que todo lo que reciben es correcto.

El flujo de datos entre una aplicación y otra viajan por un circuito virtual. Sabemos que los datagramas IP pueden seguir rutas distintas, dependiendo del estado de los encaminadores intermedios, para llegar a un mismo sitio. Esto significa que los datagramas IP que transportan los mensajes siguen rutas diferentes aunque el protocolo TCP logré la ilusión de que existe un único circuito por el que viajan todos los bytes uno detrás de otro (algo así como una tubería entre el origen y el destino). Para que esta comunicación pueda ser posible es necesario abrir previamente una conexión. Esta conexión garantiza que los todos los datos lleguen correctamente de forma ordenada y sin duplicados. La unidad de datos del protocolo es el byte, de tal forma que la aplicación origen envía bytes y la aplicación destino recibe estos bytes.

Sin embargo, cada byte no se envía inmediatamente después de ser generado por la aplicación, sino que se espera a que haya una cierta cantidad de bytes, se agrupan en un segmento y se envía el segmento completo. Para ello son necesarias unas memorias intermedias o buffers. Cada uno de estos segmentos viaja en el campo de datos de un datagrama IP. Si el segmento es muy grande será necesario fragmentar el datagrama, con la consiguiente pérdida de rendimiento; y si es muy pequeño, se estarán enviando más cabeceras que datos. Por consiguiente, es importante elegir el mayor tamaño de segmento posible que no provoque fragmentación.

El protocolo TCP envía un flujo de información no estructurado. Esto significa que los datos no tienen ningún formato, son únicamente los bytes que una aplicación envía a otra. Ambas aplicaciones deberán ponerse de acuerdo para comprender la información que se están enviando. Cada vez que se abre una conexión, se crea un canal de comunicación bidireccional en el que ambas aplicaciones pueden enviar y recibir información, es decir, una conexión es full-dúplex.

2.2 CAPAS DE TCP/IP

IBM Tivoli NetView


5 Aplicación

Ej. HTTP, FTP, DNS (protocolos de enrutamiento como BGP y RIP, que por varias razones funcionen sobre TCP y UDP respectivamente, son considerados parte del nivel de red)

4 Transporte Ej. TCP, UDP, RTP, SCTP (protocolos de enrutamiento como OSPF, que funcionen sobre IP, son considerados parte del nivel de red)

3 Interred

Para TCP/IP este es el Protocolo de Internet (IP) (protocolos requeridos como ICMP e IGMP funcionan sobre IP, pero todavía se pueden considerar parte del nivel de red; ARP no funciona sobre IP

2 Enlace Ej. Ethernet, Token Ring, etc.

1 Físico Ej. medio físico, y técnicas de codificación, T1, E1

Fig. 2. 1 Capas del modelo TCP/IP El nivel Físico El nivel físico describe las características físicas de la comunicación, como las convenciones sobre la naturaleza del medio usado para la comunicación (como las comunicaciones por cable, fibra óptica o radio), y todo lo relativo a los detalles como los conectores, código de canales y modulación, potencias de señal, longitudes de onda, sincronización y temporización y distancias máximas. La familia de protocolos de Internet no cubre el nivel físico de ninguna red. El nivel de Enlace de datos El nivel de enlace de datos especifica como son transportados los paquetes sobre el nivel físico, incluido los delimitadores (patrones de bits concretos que marcan el comienzo y el fin de cada trama). Ethernet, por ejemplo, incluye campos en la cabecera de la trama que especifican que máquina o máquinas de la red son las destinatarias de la trama. Ejemplos de protocolos de nivel de enlace de datos son Ethernet, Wireless Ethernet, SLIP, Token Ring y ATM. PPP es un poco más complejo y originalmente fue diseñado como un protocolo separado que funcionaba sobre otro nivel de enlace, HDLC/SDLC. Este nivel es a veces subdividido en Control de enlace lógico (Logical Link Control) y Control de acceso al medio (Media Access Control).... El nivel de Interred

IBM Tivoli NetView


Como fue definido originalmente, el nivel de red soluciona el problema de conseguir transportar paquetes a través de una red sencilla. Ejemplos de protocolos son X.25 y Host/IMP Protocol de ARPANET. Con la llegada del concepto de Interred, nuevas funcionalidades fueron añadidas a este nivel, basadas en el intercambio de datos entre una red origen y una red destino. Generalmente esto incluye un enrutamiento de paquetes a través de una red de redes, conocidada como Internet. El nivel de Transporte Los protocolos del nivel de transporte pueden solucionar problemas como la fiabilidad y la seguridad de que los datos llegan en el orden correcto. En el conjunto de protocolos TCP/IP, los protocolos de transporte también determinan a que aplicación van destinados los datos. Los protocolos de enrutamiento dinámico que técnicamente encajan en el conjunto de protocolos TCP/IP (ya que funcionan sobre IP) son generalmente considerados parte del nivel de red; un ejemplo es OSPF (protocolo IP número 89). Esta es una de las principales diferencias con UDP, y puede convertirse en una desventaja en flujos en tiempo real (muy sensibles a la variación del retardo) o aplicaciones de enrutamiento con porcentajes altos de pérdida en el nivel de interred. UDP (protocolo IP número 17) es un protocolo de datagramas sin conexión. Es un protocolo no fiable (best effort al igual que IP) - no porque sea particularmente malo, sino porque no verifica que los paquetes lleguen a su destino, y no da garantías de que lleguen en orden. Si una aplicación requiere estas características, debe llevarlas a cabo por sí misma o usar TCP. UDP es usado normalmente para aplicaciones de streaming (audio, video, etc) donde la llegada a tiempo de los paquetes es más importante que la fiabilidad, o para aplicaciones simples de tipo petición/respuesta como el servicio DNS, donde la sobrecarga de las cabeceras que aportan la fiabilidad es desproporcionada para el tamaño de los paquetes. El nivel de Aplicación El nivel de aplicación es el nivel que los programas más comunes utilizan para comunicarse a través de una red con otros programas. Los procesos que acontecen en este nivel son aplicaciones específicas que pasan los datos al nivel de aplicación en el formato que internamente use el programa y es codificado de acuerdo con un protocolo estándar. Algunos programas específicos se considera que se ejecutan en este nivel. Proporcionan servicios que directamente trabajan con las aplicaciones de usuario. Estos programas y sus correspondientes protocolos incluyen a HTTP (HyperText Transfer Protocol), FTP (Transferencia de archivos), SMTP (correo electrónico), SSH (login remoto seguro), DNS (Resolución de nombres de dominio) y a muchos otros. Una vez que los datos de la aplicación han sido codificados en un protocolo estándar del nivel de aplicación son pasados hacia abajo al siguiente nivel de la pila de protocolos TCP/IP.

IBM Tivoli NetView


En el nivel de transporte, las aplicaciones normalmente hacen uso de TCP y UDP, y son habitualmente asociados a un número de puerto bien conocido (well-known port). Los puertos fueron asignados originalmente por la IANA.

2.3 FIABILIDAD

¿Cómo es posible enviar información fiable basándose en un protocolo no fiable? Es decir, si los datagramas que transportan los segmentos TCP se pueden perder, ¿cómo pueden llegar los datos de las aplicaciones de forma correcta al destino?

La respuesta a esta pregunta es sencilla: cada vez que llega un mensaje se devuelve una confirmación (acknowledgement) para que el emisor sepa que ha llegado correctamente. Si no le llega esta confirmación pasado un cierto tiempo, el emisor reenvía el mensaje.

Veamos a continuación la manera más sencilla (aunque ineficiente) de proporcionar una comunicación fiable. El emisor envía un dato, arranca su temporizador y espera su confirmación (ACK). Si recibe su ACK antes de agotar el temporizador, envía el siguiente dato. Si se agota el temporizador antes de recibir el ACK, reenvía el mensaje. Los siguientes esquemas representan este comportamiento:

Fig. 2. 2 Esquema de Comunicación 1

IBM Tivoli NetView


Fig. 2. 3 Esquema de Comunicación 2

Este esquema es perfectamente válido aunque muy ineficiente debido a que sólo se utiliza un sentido de la comunicación a la vez y el canal está desaprovechado la mayor parte del tiempo. Para solucionar este problema se utiliza un protocolo de ventana deslizante, que se resume en el siguiente esquema. Los mensajes y las confirmaciones van numerados y el emisor puede enviar más de un mensaje antes de haber recibido todas las confirmaciones anteriores.

2.4 CONEXIONES

Una conexión son dos pares dirección IP:puerto. No puede haber dos conexiones iguales en un mismo instante en toda la Red. Aunque bien es posible que un mismo ordenador tenga dos conexiones distintas y simultáneas utilizando un mismo puerto. El protocolo TCP utiliza el concepto de conexión para identificar las transmisiones. En el siguiente ejemplo se han creado tres conexiones. Las dos primeras son al mismo servidor Web (puerto 80) y la tercera a un servidor de FTP (puerto 21).

IBM Tivoli NetView


Fig. 2. 4 Apertura pasiva y Activa

Para que se pueda crear una conexión, el extremo del servidor debe hacer una apertura pasiva del puerto (escuchar su puerto y quedar a la espera de conexiones) y el cliente, una apertura activa en el puerto del servidor (conectarse con el puerto de un determinado servidor).

2.5 FORMATO DEL SEGMENTO TCP

Ya hemos comentado que el flujo de bytes que produce una determinada aplicación se divide en uno o más segmentos TCP para su transmisión. Cada uno de estos segmentos viaja en el campo de datos de un datagrama IP. Para facilitar el control de flujo de la información los bytes de la aplicación se numeran. De esta manera, cada segmento indica en su cabecera el primer byte que transporta. Las confirmaciones o acuses de recibo (ACK) representan el siguiente byte que se espera recibir (y no el número de segmento recibido, ya que éste no existe).

0 10 20 30 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Puerto TCP origen Puerto TCP destino Número de secuencia Número de acuse de recibo HLEN Reservado Bits código Ventana Suma de verificación Puntero de urgencia Opciones (si las hay) Relleno Datos ...

Fig. 2. 5 Formato de Trama de TCP

IBM Tivoli NetView


Puerto fuente (16 bits). Puerto de la máquina origen. Al igual que el puerto destino es necesario para identificar la conexión actual.

• Puerto destino (16 bits). Puerto de la máquina destino. • Número de secuencia (32 bits). Indica el número de secuencia del primer byte que

trasporta el segmento. • Número de acuse de recibo (32 bits). Indica el número de secuencia del siguiente byte

que se espera recibir. Con este campo se indica al otro extremo de la conexión que los bytes anteriores se han recibido correctamente.

• HLEN (4 bits). Longitud de la cabecera medida en múltiplos de 32 bits (4 bytes). El valor mínimo de este campo es 5, que corresponde a un segmento sin datos (20 bytes).

• Reservado (6 bits). Bits reservados para un posible uso futuro. • Bits de código o indicadores (6 bits). Los bits de código determinan el propósito y

contenido del segmento. A continuación se explica el significado de cada uno de estos bits (mostrados de izquierda a derecha) si está a 1.

• URG. El campo Puntero de urgencia contiene información válida. • ACK. El campo Número de acuse de recibo contiene información válida, es decir, el

segmento actual lleva un ACK. Observemos que un mismo segmento puede transportar los datos de un sentido y las confirmaciones del otro sentido de la comunicación.

• PSH. La aplicación ha solicitado una operación push (enviar los datos existentes en la memoria temporal sin esperar a completar el segmento).

• RST. Interrupción de la conexión actual. • SYN. Sincronización de los números de secuencia. Se utiliza al crear una conexión

para indicar al otro extremo cual va a ser el primer número de secuencia con el que va a comenzar a transmitir (veremos que no tiene porqué ser el cero).

• FIN. Indica al otro extremo que la aplicación ya no tiene más datos para enviar. Se utiliza para solicitar el cierre de la conexión actual.

• Ventana (16 bits). Número de bytes que el emisor del segmento está dispuesto a aceptar por parte del destino.

• Suma de verificación (24 bits). Suma de comprobación de errores del segmento actual. Para su cálculo se utiliza una pseudo-cabecera que también incluye las direcciones IP origen y destino.

• Puntero de urgencia (8 bits). Se utiliza cuando se están enviando datos urgentes que tienen preferencia sobre todos los demás e indica el siguiente byte del campo Datos que sigue a los datos urgentes. Esto le permite al destino identificar donde terminan los datos urgentes. Nótese que un mismo segmento puede contener tanto datos urgentes (al principio) como normales (después de los urgentes).

• Opciones (variable). Si está presente únicamente se define una opción: el tamaño máximo de segmento que será aceptado.

• Relleno. Se utiliza para que la longitud de la cabecera sea múltiplo de 32 bits. • Datos. Información que envía la aplicación.

IBM Tivoli NetView


2.6 ESTABLECIMIENTO DE UNA CONEXIÓN Antes de transmitir cualquier información utilizando el protocolo TCP es necesario abrir una conexión. Un extremo hace una apertura pasiva y el otro, una apertura activa. El mecanismo utilizado para establecer una conexión consta de tres vías.

Fig. 2. 6 Esquema de Conexión TCP de Tres Vías

La máquina que quiere iniciar la conexión hace una apertura activa enviando al otro extremo un mensaje que tenga el bit SYN activado. Le informa además del primer número de secuencia que utilizará para enviar sus mensajes.

1. La máquina receptora (un servidor generalmente) recibe el segmento con el bit SYN activado y devuelve la correspondiente confirmación. Si desea abrir la conexión, activa el bit SYN del segmento e informa de su primer número de secuencia. Deja abierta la conexión por su extremo.

2. La primera máquina recibe el segmento y envía su confirmación. A partir de este momento puede enviar datos al otro extremo. Abre la conexión por su extremo.

3. La máquina receptora recibe la confirmación y entiende que el otro extremo ha abierto ya su conexión. A partir de este momento puede enviar ella también datos. La conexión ha quedado abierta en los dos sentidos.

Observamos que son necesarios 3 segmentos para que ambas máquinas abran sus conexiones y sepan que la otra también está preparada.

Números de secuencia.— Se utilizan números de secuencia distintos para cada sentido de la comunicación. Como hemos visto el primer número para cada sentido se acuerda al establecer la comunicación. Cada extremo se inventa un número aleatorio y envía éste como inicio de secuencia. Observamos que los números de secuencia no comienzan entonces en el cero. ¿Por qué se procede así? Uno de los motivos es para evitar conflictos: supongamos que la conexión en un ordenador se interrumpe nada más empezar y se crea una nueva. Si

IBM Tivoli NetView


ambas han empezado en el cero es posible que el receptor entienda que la segunda conexión es una continuación de la primera (si utilizan los mismos puertos).

Cuando una aplicación ya no tiene más datos que transferir, el procedimiento normal es cerrar la conexión utilizando una variación del mecanismo de 3 vías explicado anteriormente.

El mecanismo de cierre es algo más complicado que el de establecimiento de conexión debido a que las conexiones son full-duplex y es necesario cerrar cada uno de los dos sentidos de forma independiente.

Fig. 2. 7 Esquema de conexión TCP (Full-Dúplex)

1. La máquina que ya no tiene más datos que transferir, envía un segmento con el bit FIN activado y cierra el sentido de envío. Sin embargo, el sentido de recepción de la conexión sigue todavía abierto.

2. La máquina receptora recibe el segmento con el bit FIN activado y devuelve la correspondiente confirmación. Pero no cierra inmediatamente el otro sentido de la conexión sino que informa a la aplicación de la petición de cierre. Aquí se produce un lapso de tiempo hasta que la aplicación decide cerrar el otro sentido de la conexión.

3. La primera máquina recibe el segmento ACK. 4. Cuando la máquina receptora toma la decisión de cerrar el otro sentido de la

comunicación, envía un segmento con el bit FIN activado y cierra la conexión. 5. La primera máquina recibe el segmento FIN y envía el correspondiente ACK.

Observemos que aunque haya cerrado su sentido de la conexión sigue devolviendo las confirmaciones.

6. La máquina receptora recibe el segmento ACK.

IBM Tivoli NetView


CAPÍTULO 3: SWITCHEO Y RUTEO 3.1 SWITCH Un switch (en español "conmutador") es un dispositivo electrónico de interconexión de redes de computadoras que opera en la capa 2 (nivel de enlace de datos) del modelo OSI (Open Systems Interconection). Un switch interconecta dos o más segmentos de red, funcionando de manera similar a los puentes (bridges), pasando datos de un segmento a otro, de acuerdo con la dirección MAC de destino de los datagramas en la red. La conmutación es una técnica que nos sirve para hacer un uso eficiente de los enlaces físicos en una red de computadoras. Si no existiese una técnica de conmutación en la comunicación entre dos nodos, se tendría que enlazar en forma de malla. Una ventaja adicional de la conmutación de paquetes, (además de la seguridad de transmisión de datos) es que como se parte en paquetes el mensaje, éste se está ensamblando de una manera más rápida en el nodo destino, ya que se están usando varios caminos para transmitir el mensaje, produciéndose un fenómeno conocido como "transmisión en paralelo". Además, si un mensaje tuviese un error en un bit de información, y estuviésemos usando la conmutación de mensajes, tendríamos que retransmitir todo el mensaje; mientras que con la conmutación de paquetes solo hay que retransmitir el paquete con el bit afectado, lo cual es mucho menos problemático. Lo único negativo, quizás, en el esquema de la conmutación de paquetes es que su encabezado es más grande. La conmutación de paquetes se trata del procedimiento mediante el cual, cuando un nodo quiere enviar información a otro lo divide en paquetes. Cada paquete es enviado por el medio con información de cabecera. En cada nodo intermedio por el que pasa el paquete se detiene el tiempo necesario para procesarlo. Los conmutadores poseen la capacidad de aprender y almacenar las direcciones de red de nivel 2 (direcciones MAC) de los dispositivos alcanzables a través de cada uno de sus puertos. Por ejemplo, un equipo conectado directamente a un puerto de un conmutador provoca que el conmutador almacene su dirección MAC. Esto permite que, a diferencia de los concentradores o hubs, la información dirigida a un dispositivo se dirija únicamente desde el puerto origen al puerto que permite alcanzar el dispositivo destino. En el caso de conectar dos conmutadores o un conmutador y un concentrador, cada conmutador aprenderá las direcciones MAC de los dispositivos accesibles por sus puertos, por tanto en el puerto de interconexión se almacenan las MAC de los dispositivos del otro conmutador. El switch se denomina puente multipuerto, así como el hub se denomina repetidor multipuerto. La diferencia entre el hub y el switch es que los switches toman decisiones basándose en las direcciones MAC y los hubs no toman ninguna decisión. Como los switches son capaces de tomar decisiones, así hacen que la LAN sea mucho más eficiente.

IBM Tivoli NetView


Los switches hacen esto "conmutando" datos sólo desde el puerto al cual está conectado el host correspondiente. A diferencia de esto, el hub envía datos a través de todos los puertos de modo que todos los hosts deban ver y procesar (aceptar o rechazar) todos los datos. Esto hace que la LAN sea más lenta.

A primera vista los switches parecen a menudo similares a los hubs. Tanto los hubs como los switches tienen varios puertos de conexión (pueden ser de 8, 12, 24 o 48, o conectando 2 de 24 en serie), dado que una de sus funciones es la concentración de conectividad (permitir que varios dispositivos se conecten a un punto de la red). 3.1.1 Conmutación de Redes

Conmutación de circuitos

ISO define a la conmutación de circuitos como el procedimiento que enlaza a voluntad dos o más equipos terminales de datos y que permite la utilización exclusiva de un circuito de datos durante la comunicación. Una propiedad importante de la conmutación de circuitos es la necesidad de establecer una ruta de extremo a extremo “antes” de que cualquier conjunto de datos puedan ser enviados. A través de un sistema de este tipo, los equipos terminales de datos pueden establecer comunicaciones ya sea de tipo asíncrono o síncrono.

Conmutación de mensajes

Método de conmutación de tráfico de datos, cuyo conmutador suele ser una computadora y varias terminales conectadas mediante líneas telefónicas privadas o conmutadas. La computadora examina la dirección que aparece en la cabeza del mensaje y encamina el paquete hacia el DTE que ha de recibirlo, esta tecnología permite grabar la información para atenderla después gracias al almacenamiento disponible que posee el conmutador. Puesto que los datos suelen ser almacenados, el tráfico no puede considerarse interactivo o en tiempo real, sin embargo pueden darse prioridades a las distintas clases de tráfico. Esta tecnología suele operar siguiendo una relación maestro-esclavo. Normalmente el conmutador efectúa los sondeos y selecciones necesarios para gestionar el tráfico que entra y sale de él. Cuando se utiliza esta forma de conmutación, no hay un establecimiento anticipado de la ruta entre el que envía y el que recibe. En su lugar, cuando el que envía tienen listo un bloque de datos, este se almacena en la primera central de conmutación, cada bloque se recibe íntegramente, se revisa en busca de errores y se retransmite con posterioridad. A las redes que emplean esta técnica se les conoce como redes de almacenamiento y reenvío.

La conmutación de mensajes adolece de tres defectos: si el conmutador falla toda la red dejará de funcionar; si existe embotellamiento dentro del conmutador disminuirá el

IBM Tivoli NetView


tiempo de respuesta y la cantidad de tráfico cursado, y por último, esta técnica no aprovecha completamente la línea telefónica. Conmutación de paquetes Los datos de usuario (mensajes) se descomponen en trozos más pequeños. Estos fragmentos o paquetes están insertados dentro de informaciones del protocolo, y recorren la red como elementos independientes. La existencia de varios conmutadores permite distribuir la carga de la red en varios puntos, lo cual permite establecer estructuras alternativas de encaminamiento, evitando los nodos ocupados o averiados.

3.2 FUNCIONAMIENTO DE SWITCHES LAN Los switches de LAN se consideran puentes multipuerto sin dominio de colisión debido a la microsegmentación. Los datos se intercambian a altas velocidades haciendo la conmutación de paquetes hacia su destino. Al leer la información de Capa 2 de dirección MAC destino, los switches pueden realizar transferencias de datos a altas velocidades de forma similar a los puentes. El paquete se envía al puerto de la estación receptora antes de que la totalidad de la trama ingrese al switch. Esto provoca niveles de latencia bajos y una alta tasa de velocidad para el envío de paquetes. La conmutación Ethernet aumenta el ancho de banda disponible en una red. Esto se hace creando segmentos de red dedicados, o conexiones punto a punto, y conectando estos segmentos en una red virtual dentro del switch. Este circuito de red virtual existe solamente cuando dos nodos necesitan comunicarse. Esto se denomina circuito virtual ya que existe sólo cuando es necesario y se establece dentro del switch. Aunque el switch LAN reduce el tamaño de los dominios de colisión, todos los hosts conectados al switch pertenecen al mismo dominio de broadcast. Por lo tanto, un broadcast emitido de un nodo lo percibirán todos los demás nodos conectados a través del switch LAN. Los switches son dispositivos de enlace de datos que, al igual que los puentes, permiten que múltiples segmentos físicos de LAN se interconecten para formar una sola red de mayor tamaño. De forma similar a los puentes, los switches envían e inundan el tráfico basándose en las direcciones MAC. Dado que la conmutación se ejecuta en el hardware en lugar del software, es significativamente más veloz. Se puede pensar en cada puerto de switch como un micropuente; este proceso se denomina microsegmentación. De este modo, cada puerto de switch funciona como un puente individual y otorga el ancho de banda total del medio a cada host.

IBM Tivoli NetView


3.3 RUTEO Se trata de la función de buscar un camino entre todos los posibles en una red de paquetes cuyas topologías poseen una gran conectividad. Dado que se trata de encontrar la mejor ruta posible, lo primero será definir que se entiende por mejor ruta y en consecuencia cual es la métrica que se debe utilizar para medirla. El router interconecta segmentos de red, o algunas veces hasta redes enteras. Hace pasar paquetes de datos entre redes tomando como base la información de la capa de red.

El router toma decisiones basadas en diversos parámetros con respecto a la mejor ruta para el envío de datos a través de una red interconectada y luego redirige los paquetes hacia el segmento y el puerto de salida adecuados.

Una de las más importantes es decidir la dirección de la red hacia la que va destinado el paquete (En el caso del protocolo IP esta sería la dirección IP). Otras decisiones son la carga de tráfico de red en las distintas interfaces de red del router y establecer la velocidad de cada uno de ellos, dependiendo del protocolo que se utilice.

3.3.1Parámetros

Métrica de la red: Puede ser por ejemplo el número de saltos necesarios para ir de un nodo a otro. Aunque esta no se trata de una métrica óptima ya que supone “1” para todos los enlaces, es sencilla y suele ofrecer buenos resultados.

Otro tipo es la medición del retardo de tránsito entre nodos vecinos en la que la métrica se expresa en unidades de tiempo y sus valores no son constantes sino que dependen del tráfico de la red.

Mejor Ruta: Entendemos por mejor ruta aquella que cumple las siguientes condiciones:

*0 Presenta el menor retardo medio de tránsito. *1 Consigue mantener acotado el retardo entre pares de nodos de la red. *2 Consigue ofrecer altas cadencias efectivas independientemente del retardo medio de tránsito *3 Permite ofrecer el menor coste.

El criterio más sencillo es elegir el camino más corto, es decir la ruta que pasa por el menor número de nodos. Una generalización de este criterio es el de “coste mínimo”. En general, el concepto de distancia o coste de un canal es una medida de la calidad del enlace en base a la métrica que se haya definido. En la práctica se utilizan varias métricas simultáneamente.

IBM Tivoli NetView


3.4 ENCAMINAMIENTO EN REDES DE CIRCUITOS VIRTUALES Y DE DATAGRAMAS

Cuando la red de conmutación de paquetes funciona en modo circuito virtual, generalmente la función de encaminamiento establece una ruta que no cambia durante el tiempo de vida de ese circuito virtual. En este caso el encaminamiento se decide por sesión.

Una red que funciona en modo datagrama no tiene el compromiso de garantizar la entrega ordenada de los paquetes, por lo que los nodos pueden cambiar el criterio de encaminamiento para cada paquete que ha de mandar. Cualquier cambio en la topología de la red tiene fácil solución en cuanto a encaminamiento se refiere, una vez que el algoritmo correspondiente haya descubierto el nuevo “camino óptimo”.

3.5 CLASIFICACIÓN DE LOS MÉTODOS DE ENCAMINAMIENTO

Los algoritmos de encaminamiento pueden agruparse en:

3.5.1 Determinísticos ó Estáticos

No tienen en cuenta el estado de la subred al tomar las decisiones de encaminamiento. Las tablas de encaminamiento de los nodos se configuran de forma manual y permanecen inalterables hasta que no se vuelve a actuar sobre ellas. Por tanto, la adaptación en tiempo real a los cambios de las condiciones de la red es nula.

El cálculo de la ruta óptima es también off-line por lo que no importa ni la complejidad del algoritmo ni el tiempo requerido para su convergencia.

3.5.2 Adaptativos ó Dinámicos

Pueden hacer frente a cambios en la subred tales como variaciones en el tráfico, incremento del retardo o fallas en la topología. El encaminamiento dinámico o adaptativo se puede clasificar a su vez en tres categorías, dependiendo de donde se tomen las decisiones y del origen de la información intercambiada:

• Adaptativo centralizado. Todos los nodos de la red son iguales excepto un nodo central que es quien recoge la información de control y los datos de los demás nodos para calcular con ellos la tabla de encaminamiento. Este método tiene el inconveniente de que consume abundantes recursos de la propia red.

• Adaptativo distribuido. Este tipo de encaminamiento se caracteriza porque el algoritmo correspondiente se ejecuta por igual en todos los nodos de la subred. Cada nodo recalcula continuamente la tabla de encaminamiento a partir de dicha información y de la que contiene en su propia base de datos. A este tipo pertenecen

IBM Tivoli NetView


dos de los más utilizados en Internet que son los algoritmos por vector de distancias y los de estado de enlace.

• Adaptativo aislado. Se caracterizan por la sencillez del método que utilizan para adaptarse al estado cambiante de la red. Su respuesta a los cambios de tráfico o de topología se obtiene a partir de la información propia y local de cada nodo. Un caso típico es el encaminamiento “por inundación” cuyo mecanismo consiste en reenviar cada paquete recibido con destino a otros nodos, por todos los enlaces excepto por el que llegó.

3.5.3 Encaminamiento Adaptativo con Algoritmos Distribuidos

El encaminamiento mediante algoritmos distribuidos constituye el prototipo de modelo de encaminamiento adaptativo. Los algoritmos se ejecutan en los nodos de la red con los últimos datos que han recibido sobre su estado y convergen rápidamente optimizando sus nuevas rutas.

El resultado es que las tablas de encaminamiento se adaptan automáticamente a los cambios de la red y a las sobrecargas de tráfico. A cambio, los algoritmos tienen una mayor complejidad. Existen dos tipos principales de algoritmos de encaminamiento adaptativo distribuido.

Algoritmos por “Vector de Distancias”

Cada nodo envía a sus vecinos las distancias que conoce a través de este paquete. Los nodos vecinos examinan esta información y la comparan con la que ya tienen, actualizando su tabla de encaminamiento.

Ejemplos de protocolos por vector de distancias: RIP (versión 1 y 2), IGRP.

El encaminamiento de un protocolo basado en vector de distancias requiere que un router informe a sus vecinos de los cambios en la topología periódicamente y en algunos casos cuando se detecta un cambio en la topología de la red.

El algoritmo VD se basa en calcular la dirección y la distancia hasta cualquier enlace en la red. El costo de alcanzar un destino se lleva a cabo usando cálculos matemáticos como la métrica del camino. RIP cuenta los saltos efectuados hasta llegar al destino mientras que IGRP utiliza otra información como el retardo y el ancho de banda.

Los cambios son detectados periódicamente ya que la tabla de encaminamiento de cada router se envía a todos los vecinos que usan en mismo protocolo. Una vez que el router tiene toda la información, actualiza su propia tabla reflejando los cambios y luego informa a sus vecinos de los mismos.

IBM Tivoli NetView


Algoritmos de “Estado de Enlace” Este tipo de encaminamiento se basa en que cada nodo llegue a conocer la topología de la red y los costes (retardos) asociados a los enlaces, para que a partir de estos datos, pueda obtener el árbol y la tabla de encaminamiento tras aplicar el algoritmo de coste mínimo (algoritmo de Dijkstra) al grafo de la red. El encaminamiento por estado de enlace nace en 1979 cuando en ARPANET sustituyó al método de vector de distancias.

Los protocolos estado de enlace incluyen OSPF e IS-IS.

Lo podemos dividir en cinco pasos fundamentales:

1. Descubrir a sus vecinos y sus direcciones 2. Medir el costo a cada uno de sus vecinos 3. Construir el paquete con la información recabada 4. Enviar este paquete al resto de routers. 5. Calcular la ruta mínima al resto de routers

3.6 PROTOCOLOS DE ENRUTAMIENTO 3.6.1 IGRP

IGRP (Interior Gateway Routing Protocol, o Protocolo de enrutamiento de gateway interior) es un protocolo patentado y desarrollado por CISCO que se emplea con el protocolo TCP/IP según el modelo (OSI) Internet. La versión original del IP fue diseñada y desplegada con éxito en 1986. Se utiliza comúnmente como IGP pero también se ha utilizado extensivamente como Exterior Gateway Protocol (EGP) para el enrutamiento inter-dominio.

IGRP es un protocolo de enrutamiento basado en la tecnología vector-distancia. Utiliza una métrica compuesta para determinar la mejor ruta basándose en el ancho de banda, el retardo, la confiabilidad y la carga del enlace. El concepto es que cada router no necesita saber todas las relaciones de ruta/enlace para la red entera. Cada router publica destinos con una distancia correspondiente. Cada router que recibe la información, ajusta la distancia y la propaga a los routers vecinos. La información de la distancia en IGRP se manifiesta de acuerdo a la métrica. Esto permite configurar adecuadamente el equipo para alcanzar las trayectorias más óptimas.

3.6.2 EIGRP

Es un protocolo de encaminamiento híbrido, propietario de Cisco Systems, que ofrece lo mejor de los algoritmos de vector de distancias y del estado de enlace. Se considera un protocolo avanzado que se basa en las características normalmente asociadas con los protocolos del estado de enlace. Algunas de las mejores funciones de OSPF, como las

IBM Tivoli NetView


actualizaciones parciales y la detección de vecinos, se usan de forma similar con EIGRP. Sin embargo, EIGRP es más fácil de configurar que OSPF. EIGRP mejora las propiedades de convergencia y opera con mayor eficiencia que IGRP.

3.6.3 IS-IS

IS-IS (Intermediate Systema to Intermediate System) es un protocolo OSI de encaminamiento jerárquico de pasarela interior o IGP (Interior Gateway Protocol), que usa el estado de enlace para encontrar el camino más corto mediante el algoritmo SPF (Shortest Path First).

A pesar de que sea un protocolo OSI, se puede usar también con TCP/IP. De tal manera que es capaz de encaminar paquetes IP Y CLNP (ConnectionLess Network Protocol). No emplea encapsulación para los paquetes, ni ninguna diferencia relevante entre ellos, excepto que en IP añade información adicional.

El protocolo tiene un gran parecido con OSPF ya que en ambos se utiliza el estado de enlace para la búsqueda de caminos (utilizan puentes designados para eliminar bucles) y la asignación de redes en grupos para mejorar la eficiencia de la red. Pero IS-IS tiene ciertas ventajas respecto a OSPF tales como compatibilidad con IPv6 o que permite conectar redes con protocolos de encaminamiento distintos.

3.6.4 OSPF

Open Shortest Path First (frecuentemente abreviado OSPF) es un protocolo de encaminamiento jerárquico de pasarela interior o IGP (Interior Gateway Protocol), que usa el algoritmo Dijkstra enlace-estado (LSA - Link State Algorithm) para calcular la ruta más corta posible. Usa cost como su medida de métrica. Además, construye una base de datos enlace-estado idéntica en todos los encaminadores de la zona.

OSPF es probablemente el tipo de protocolo IGP más utilizado en redes grandes. Puede operar con seguridad usando MD5 para autentificar a sus puntos antes de realizar nuevas rutas y antes de aceptar avisos de enlace-estado. Como sucesor natural a RIP, es VLSM o sin clases desde su inicio. A lo largo del tiempo, se han ido creando nuevas versiones, como OSPFv3 que también soporta IPv6 o como las extensiones multidifusión para OSPF (MOSPF), aunque no están demasiado extendidas.

3.6.5 RIP RIP son las siglas de Routing Information Protocol (Protocolo de información de encaminamiento). Es un protocolo de puerta de enlace interna o IGP (Internal Gateway Protocol) utilizado por los routers (enrutadores), aunque también pueden actuar en equipos, para intercambiar información acerca de redes IP.

IBM Tivoli NetView


Versiones RIP Ripv1: No soporta subredes ni CIDR. Tampoco incluye ningún mecanismo de autentificación de los mensajes. RIPv2: Soporta subredes, CIDR y VLSM. Soporta autenticación utilizando uno de los siguientes mecanismos: no autentificación, autentificación mediante contraseña, autentificación mediante contraseña codificada mediante MD5 (desarrollado por Ronald Rivest). RIPng: RIP para IPv6. Su especificación está recogida en el RFC 2080. 3.6.6 Border Gateway Protocol

El BGP o Border Gateway Protocol es un protocolo mediante el cual se intercambian prefijos los ISP registrados en Internet. Actualmente la totalidad de los ISP intercambian sus tablas de rutas a través del protocolo BGP. Este protocolo requiere un router que tenga configurado cada uno de los vecinos que intercambiarán información de las rutas que cada uno conozca. Se trata del protocolo más utilizado para redes con intención de configurar un EGP (external gateway protocol.

IBM Tivoli NetView


CAPÍTULO 4: ADMINISTRACIÓN DE REDES Y SNMP 4.1 ADMINISTRACIÓN DE REDES Administración de redes (Network Management) significa diferentes cosas a personas diferentes. En algunos casos, implica a un consultor solitario de la red que supervisa la actividad de la red con un analizador de protocolos. En otros casos, la administración de la red implica una base de datos distribuida, poleo automático de los dispositivos de la red, y estaciones de trabajo high-end que generan vistas graficas en tiempo real de los cambios y el trafico en la topología de la red. La administración de la red es generalmente un servicio que emplea una variedad de herramientas, aplicaciones, y de dispositivos para asistir a los administradores de la red en el monitoreo y el mantenimiento de las redes. El monitoreo de recursos de red es el componente principal usado en la administración de redes. Primero cubriremos las cinco razones principales que justifican la necesidad de la administración de redes.

• Detección de fallas. Problemas que ocurrirán eventualmente en cada red. La clave es minimizar el impacto de estos problemas. Usando una herramienta de administración de redes para detectar las fallas puede reducir enormemente el tiempo de resolución del problema.

• Detección de problemas potenciales. Problemas de red pueden ocurrir con pequeño o

no alertamiento, pero algunos problemas de red dan signos de alertamiento. Un ejemplo, es la falla de una fuente backup de energía. Si tu no estas conciente de esto (y reparas esto), y la fuente primaria de energía falla, tu tendrás una falla mayor en la cual ocuparte.

• Mejorar el rendimiento. El constante desarrollo y despliegue de aplicaciones

hambrientas de mayor ancho de banda, requiere de una vista proactiva al desempeño histórico y en tiempo real de los recursos de red.

• Documentación. Una fotografía precisa de que contiene tu red, tanto como saber que

piezas están conectadas unas con otras, es una necesidad para todas las cosas desde el valor de la administración hasta un esquema topológico.

• Reportes. Recibir, analizar, y generar información útil de los datos esta convirtiéndose

en una parte importante de la administración de la red cada día.

IBM Tivoli NetView


4.2 ARQUITECTURA DE LA ADMINISTRACIÓN DE REDES

La mayoría de las arquitecturas de la administración de redes utilizan la misma estructura y sistema básicos de relaciones. Estaciones terminales (dispositivos manejados), como computadoras y otros dispositivos de red, ejecutan software que habilita el envió de alertas cuando reconocen los problemas (por ejemplo, cuando se exceden los umbrales de operación de un enlace). Al recibir estas alertas, la administración deberá estar programada para reaccionar ejecutando una, varias o un grupo de acciones, incluyendo la notificación a el operador, registro del evento, shutdown al sistema, e intentos automáticos en la reparación del sistema. La administración también tiene la función del poleo de las estaciones finales para checar valores de ciertas variables. El poleo puede ser automático o iniciado por el usuario, y los agentes en los dispositivos manejados responden a estos poleos. Los agentes son módulos de software que primero compilan la información acerca de los dispositivos manejados en los cuales ellos residen, después almacenan esta información en una base de datos de administración, y finalmente la proporcionan (proactivamente o de forma reactiva) a entidades de administración con sistema de administración de redes o NMS (Network Management Station), vía un protocolo de administración de red. Protocolos de administración de redes incluyen al protocolo de administración de red simple o SNMP (Simple Network Management Protocol) y al protocolo de administración de información común o CMIP (Common Management Information Protocol). Proxies son entidades que proporcionan información de administración del comportamiento de otras entidades. La siguiente figura muestra la arquitectura típica de la administración de redes.

Fig. 4. 1 Network Management System

IBM Tivoli NetView


4.3 MODELO DE ADMINISTRACIÓN DE REDES ISO ISO ha contribuido mucho a la estandardización de las redes. Su modelo de la administración de redes es el medio primario para entender las funciones principales de los sistemas de la administración de redes. Este modelo consiste en cinco áreas conceptuales:

• Administración del desempeño, monitorea y hace mediciones de aspectos del desempeño de modo que el desempeño total pueda ser mantenido en un nivel aceptable.

• Administración de la configuración, aspectos de la configuración de los dispositivos como es la administración de los archivos de configuración, administración de inventarios, y administración del software.

• Administración de la contabilidad, Uso de la información en los recursos de la red. • Administración de fallas, detecta, aísla, notifica, y corrige las fallas presentadas en la

red. • Administración de la seguridad, proporciona acceso a los dispositivos de la red y

recursos a individuos autorizados.

4.4 PLATAFORMAS DE LA ADMINISTRACIÓN DE REDES Una plataforma de administración de redes instalada en una empresa maneja una infraestructura que consiste de elementos de red multivendor. La plataforma recibe y procesa los eventos de los elementos de la red. Los eventos de servidores y de recursos críticos también pueden ser diseccionados a una plataforma de administración. Las siguientes funciones comúnmente disponibles están incluidas en una plataforma de administración estándar:

• Descubrimiento de la red • Mapas de la topología de los elementos de la red • Manejador de eventos • Colección de datos del desempeño y graficador • Navegador de datos de administración

Las plataformas de administración de redes se pueden ver como la consola principal para las operaciones de la red en la detección de fallas en la infraestructura. La capacidad de detectar problemas rápidamente en cualquier red es crítica. El personal de las operaciones de la red puede confiar en un mapa gráfico de la red para desplegar los estados operacionales de los elementos críticos de la red tales como ruteadores y switches.

IBM Tivoli NetView


4.5 COMPONENTES DE LA ARQUITECTURA SNMP Los componentes de snmp se basan en la figura 1 y los cuales definimos como:

• NMS (Network Management Station) • Agente • MIB (Management Information Base) • Protocolo de administración (Network Management Protocol) o SNMP

4.5.1 Network Management Station La estación de administración es la interfaz del administrador de red al sistema de red. Posee los programas para manipular los datos y controlar la red. La estación de administración también mantiene una base de datos de información de administración (MIB) extraída de los dispositivos bajo su administración. 4.5.2 Agentes Los periféricos que tienen integradas las capacidades para SNMP corren un paquete pequeño de software agente para administración (generalmente de 64kB), cargado como parte de un ciclo de arranque o guardado en la memoria fija (firmware) del dispositivo. Estos dispositivos que tienen agentes SNMP se dice que se tratan de dispositivos o nodos administrados. No todos los nodos son agentes, ni pueden serlo. Agente Apoderado (o proxy): Administra los dispositivos que no pueden ejecutar un agente local. Se localiza externamente al nodo administrado. Los dispositivos administrados por SNMP (puentes, ruteadores, concentradores y switches) se comunican con el software servidor SNMP que está localizado en cualquier parte de la red y les permitan ser controlados por la estación de administración. El agente de administración responde a la estación de administración de dos maneras:

• Poleo: la estación de administración requiere datos desde el agente y el agente responde con los datos solicitados.

• Traps: tal que se establecen umbrales (límites superiores o inferiores) en el

dispositivo administrado y si se supera este umbral en el dispositivo, envía un mensaje de alerta a la estación de administración.

En ocasiones se puede combinar ambos métodos, conocido como poleo dirigido a trap.

IBM Tivoli NetView


4.5.3 Management Information Base (MIB). Es un esquema o un modelo que contiene la orden jerárquica de todos los objetos manejados. Cada objeto manejado en un MIB tiene un identificador único. El identificador incluye el tipo (tal como contador, secuencia, galga, o dirección), el nivel de acceso (tal como read/write), restricciones del tamaño, y la información de la gama del objeto. Define las variables necesitadas por el protocolo del SNMP para supervisar y para controlar componentes en una red. Los encargados traen o almacenan en estas variables. MIB-ii refiere a una base de datos extendida de la gerencia del SNMP que contenga las variables no compartidas por CMOT y el SNMP. Los formatos del MIB de CMIP y del SNMP diferencian en estructura y complejidad. En SNMP el formato de representación de la información Abstract Syntax Notation.1 (ASN.1) define la sintaxis específica para el intercambio de información independientemente del dispositivo que la procesa, similar a XDR (eXternal Data Representation) en RPCs. ASN.1 es una norma de representación de datos. El protocolo SNMP usa el ASN.1 para representar sus objetos administrados. En ella se consideran cuatro tipos posibles para un dato:

• Universal: Boolean, Integer y Real. • Específica al contexto: Definidos para el contexto local en que se usan estos tipos. • Aplicación: Definidos para la aplicación específica. • Privada: Definidos por el usuario.

Cada uno de estos tipos es:

• Primitivo (un único entero). • Construido (cadena de caracteres).

La sintaxis de transferencia se define especificando cómo se codifican los distintos tipos de datos. Define la forma de convertir (y decodificar en el receptor) sin ambigüedad los valores expresados con ASN.1 para su transmisión (y recuperación) por la red. La codificación comienza con un tag que especifica el tipo de datos. Cada tipo tiene su propia regla de codificación. La sintaxis de transferencia se denomina BER (Basic Encoding Rules). Tras usar las reglas que muchas veces son recurrentes llegamos a tener un flujo de objetos primitivos organizados.

IBM Tivoli NetView


Este estándar no define cómo se han de codificar esos datos, sino que es una sintaxis abstracta para indicar el significado de los datos. Para la codificación de los datos se usan otras normas como: BER (basic encoding rules) (BER - X.209), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules), PER (Packed Encoding Rules) y XER (XML Encoding Rules), las cuales no son tratadas en este documento. SMI: Structure o Management Information SMI presenta una estructura en forma de árbol global para la información de administración, convenciones, sintaxis y las reglas para la construcción de MIBs. La MIB está organizada en niveles, que a su vez lo hace en módulos que contienen grupos de variables interrelación Nota: la estructura SMI guarda similitud con el DNS y sus zonas de autoridad, o variables definidas por cada fabricante. Ejemplo de GRUPOS de variables en MIB-2 en la SMI: System (identifica el hw y sw), AT (traducción de dirección de Ethernet a IP), IP (contador de paquetes, fragmentación), ICMP (contador de cada tipo de mensaje ICMP), TCP y UDP (conexiones abiertas TCP), EGP (estadística de protocolo externo) Este formato para la representación de variables puede ser expresadas tanto en ASCII como números separados por puntos, en una notación intermedia entre ASCII y ASN1 conocida como OID (Object Identifier) o descriptor. En esta notación inicialmente se identifica el organismo de estandarización, ISO y dentro de éste está ORG y dentro DOD (Departamanet of Defense), donde la primera rama del árbol desde DOD es Internet. Así sucesivamente hasta especificar la variable (u objeto) y el puerto a consultar. Los valores de los datos son identificados y obtenidos por la posición en el MIB. Los objetos MIB pueden ser direccionados por el nombre del objeto o el ID del objeto. El siguiente ejemplo muestra como acceder el valor sysUptime

.1.3.6.1.2.1.1.3 = .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime La siguiente figura muestra gráficamente el árbol de información para el objeto sysUptime.

IBM Tivoli NetView


Fig. 4. 2 Árbol de información para el objeto sysUptime

Standard y Enterprise MIBs Standard MIB. Estas MIBs están definidas por un Standard para definiciones de dispositivos de red comunes. La dirección standard de un MIB object empieza:

.iso.org.dod.internet.mgmt Enterprise-specific MIB. Estas MIBs están usualmente definidas por un producto específico. Enterprise-specific MIBs siguen ciertos estándares. La dirección de un Enterprise-specific MIB object empieza: .iso.org.dod.internet.private.enterprise

IBM Tivoli NetView


4.6 PROTOCOLO DE ADMINISTRACIÓN Ó SNMP El protocolo de administración de redes simple o SNMP (Simple Network Management Protocol), es un protocolo de la capa de aplicación que facilita el intercambio de información de administración entre dispositivos de red. Este protocolo es parte del conjunto de protocolos TCP/IP (Transmisión 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: administrar el rendimiento, encontrar y solucionar problemas, y planificar el crecimiento futuro de la red. SNMP se diseñó para supervisar y controlar: ruteadores, 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). Primitivas El SNMP define ocho mensajes que pueden enviarse:

• Get Request • Get Next Request • Get Bulk Request (en SNMP v2) • Set Request • Set Next Request • Get Response • Trap • Inform Request (en SNMP v2)

Get Request

Solicita uno o más (lista) atributos (valores) de un objeto (o variable). Transmitida por el nodo administrador Recibida por el agente que contesta

IBM Tivoli NetView


Get Next Request Solicita el siguiente atributo de un objeto Transmitida por el nodo administrador Recibida por el agente que contesta

Get Bulk Request

Solicita un conjunto amplio de atributos en vez de solicitar uno a uno Transmitida por el nodo administrador Recibida por el agente

Set Request

Actualiza uno o varios atributos de un objeto Transmitida por el nodo administrador Recibida por el agente

Set Next Request

Actualiza el siguiente atributo de un objeto Transmitida por el nodo administrador Recibida por el agente

Get Response

Devuelve los atributos solicitados Transmitida por el agente Recibida por el nodo administrador

Trap

Informa fallos como la perdida de comunicación con un vecino Transmitida por el agente Recibida por el nodo administrador

Inform Request

Describe la base local de información de administración MIB para intercambiar información de nodos de administración entre si

Transmitida por el nodo administrador Recibida por otro nodo administrador

4.6.1 Funcionamiento de SNMP La forma normal de uso del SNMP es: 1.- Pregunta: que la estación administradora envíe una solicitud a un agente (proceso que atiende petición SNMP) pidiéndole información o mandándole actualizar su estado de cierta manera. Este método se conoce como poleo.

IBM Tivoli NetView


2.- Respuesta: la información recibida del agente es la respuesta o la confirmación a la acción solicitada. El problema del poleo es que se incrementa con los nodos administrados y en ocasiones puede llegar a perjudicar el rendimiento de la red. Interrupción (trap): Es mejor que un agente pueda mandar la información al nodo administrador puntualmente, ante una situación predeterminada, por ejemplo una anomalía detectada en la red. Este método es conocido como interrupción. Obtención de información

Fig. 4. 3 Esquema del método de interrupción (obtención de información)

IBM Tivoli NetView


Modificación de información

Fig. 4. 4 Esquema del método de Interrupción (Modificación de la información)

Generación de interrupciones

Fig. 4. 5 del método de Interrupción (Generación de interrupciones)

IBM Tivoli NetView


4.6.2 Versiones de SNMP SNMP versión 1 (SNMPv1), SNMP versión 2 (SNMPv2) y SNMP versión 3 (SNMPv3). SNMPv1 constituye la primera definición e implementación del protocolo SNMP, estando descrito en las RFC 1155, 1157 y 1212 del IETF (Internet Engineering Task Force). El vertiginoso crecimiento de SNMP desde su aparición en 1988, puso pronto en evidencia sus debilidades, principalmente su imposibilidad de especificar de una forma sencilla la transferencia de grandes bloques de datos y la ausencia de mecanismos de seguridad; debilidades que tratarían de ser subsanadas en las posteriores definiciones del protocolo. SNMPv2 apareció en 1993, estando definido en las RFC 1441-1452. SNMPv1 y SNMPv2 tienen muchas características en común, siendo la principal mejora la introducción de tres nuevas operaciones de protocolo: GetBulk para que la estación de administración recupere de una forma eficiente grandes bloques de datos, tales como las columnas de una tabla; Inform para que un agente envíe información espontánea a la estación administradora y reciba una confirmación; y Report para que el agente envíe de forma espontánea excepciones y errores de protocolo. SNMPv2 también incorpora un conjunto mayor de códigos de error y más colecciones de datos. En 1995 apareció una revisión de SNMPv2, denominada SNMPv2c y descrita en las RFC 1901-1910, añadiendo como mejoras una configuración más sencilla y una mayor modularidad; pero manteniendo el sencillo e inseguro mecanismo de autentificación de SNMPv1 y SNMPv2 basado en la correspondencia del denominado nombre de comunidad. La nueva y última versión de SNMP, SNMPv3, refuerza las prestaciones de seguridad, incluyendo autentificación, privacidad y control de acceso; y de administración de protocolo, con una mayor modularidad y la posibilidad de configuración remota. SNMPv3 apareció en 1997, estando descrito en las RFC 1902-1908 y 2271-2275. Cabe destacar que SNMPv3 no se trata de un estándar que reemplaza a SNMPv1 y/o SNMPv2, sino que define una serie de capacidades adicionales de seguridad y administración a ser utilizadas en conjunción con SNMPv2 (preferiblemente) o SNMPv1. Estas mejoras harán que SNMP se constituya en un protocolo de administración susceptible de ser utilizado con altas prestaciones en todo tipo de redes, desplazando a medio plazo a CMIP como estándar de administración de las grandes redes. El modelo de seguridad basado en usuario o USM (User-Based Security Model) proporciona los servicios de autentificación y privacidad en SNMPv3. El mecanismo de autentificación en USM asegura que un mensaje recibido fue, de hecho, trasmitido por la entidad indicada en el campo correspondiente a la fuente en la cabecera del mensaje; y además, que el mensaje no fue alterado durante su tránsito y que no fue artificialmente retardado o repetido. Para conseguir la autentificación, la estación de administración y el agente que desean comunicarse deben compartir la misma clave de autentificación secreta configurada previamente fuera de SNMPv3 (no es almacenada en la MIB y no es accesible mediante SNMP).

IBM Tivoli NetView


El protocolo de autentificación utilizado puede ser el HMAC-MD5-96 o el HMAC-SHA- 96. Para asegurarse de que los mensajes llegan dentro de una ventana temporal razonable que descarte el posible retardo de mensajes y el ataque mediante mensajes repetidos, se utilizan mecanismos de sincronización entre emisor y receptor y el chequeo de la ventana temporal constituida por el momento de emisión del mensaje y su momento de recepción. Por otro lado, la facilidad de privacidad de USM posibilita a las estaciones de administración y a los agentes encriptar mensajes para prevenir que sean analizados por intrusos. De nuevo, la estación de administración y el agente deben compartir una clave secreta configurada previamente. El algoritmo de encriptación utilizado es el CBC (Cipher Block Chaining) de DES (Data Encryption Standard), conocido también por DES-56. El modelo de control de acceso basado en vistas o VCAM (Views- Based Access Control Model) permite proporcionar diferentes niveles de acceso a las MIB de los agentes para las distintas estaciones de administración en SNMPv3. Un agente puede, de este modo, restringir el acceso de ciertas estaciones de administración a parte de su MIB o bien limitar las operaciones susceptibles de realizar por ciertas estaciones de administración sobre una parte de su MIB. La política de control de acceso a ser utilizada por el agente para cada estación de administración debe estar configurada previamente; consistiendo básicamente en una tabla que detalla los privilegios de acceso para las distintas estaciones de administración autorizadas. Mientras que la autentificación es realizada por usuario, el control de acceso es realizado por grupos, donde un grupo podría ser un conjunto de usuarios.

IBM Tivoli NetView


CAPÍTULO 5: Descripcion de la solucion de monitoreo de la red de Dupont S.A. de C.V.

5.1 Problemática de la red 5.1.1 Problemas de la red Dupont no cuenta con herramientas y procedimientos eficientes para el monitoreo de la red por lo que frecuentemente se presentan problemas en la red, estos problemas impactan directamente a los procesos del negocio, operaciones, usuarios, servicios, etc. Y con frecuencia no se sabe por donde atacar los problemas, la detección, análisis y solución a los problemas toma mucho tiempo, los problemas más comunes que se presentan en la red son los siguientes:

• Caídas de puertos en ruteadores y switches • Fallas en los enlaces • Caídas de switches y ruteadores • Problemas con el rendimiento de los ruteadores y switches • Lentitud en la red • Problemas con las impresoras (toner, papel, status, etc.) • No existe monitoreo centralizado • No se cuenta con herramientas de monitoreo • No existe un esquema de notificación

En el anexo 1 Fig. A1.1 se muestra el diagrama general de la red en el estado actual, es decir sin el monitoreo.

5.2 Análisis de la problemática y de la solución 5.2.1 Descripción de la red La red de Dupont S.A. de C.V. esta compuesta básicamente por una red WAN y una red LAN denominada Homero. La red WAN de Dupont S.A. de C.V. está entre las ciudades de Guadalajara, Altamira, Tijuana, Lerma, Monterrey, Tlalnepantla, San Martin y Matamoros. Esta a su vez conecta a una red LAN con el nombre de Homero por medio de una red de servicios digitales proporcionada por la empresa Telmex.

IBM Tivoli NetView


La red cuenta con un total de 26 switches WS-C2950G-48-EI.Cisco Catalyst 2950 de 48 puertos, distribuidos de la siguiente manera:

• 14 switches de la marca Cisco para la red LAN denominada Homero • 4 switches de la marca cisco para la ciudad de Lerma • 8 switches de la marca Cisco para el municipio de Tlalnepantla, Edo. De Mexico.

También se cuenta con 12 ruteadores marca Cisco modelo 7204VXR/CPE Router distribuidos de la siguiente manera:

• 2 routers de la marca Cisco para la red LAN denominada Homero • 1 router de la marca Cisco para la ciudad de Altamira • 1 routers de la marca Cisco para el municipio de Tlalnepantla Edo. De Mexico • 2 routers de la marca Cisco para la ciudad de Tijuana • 1 router de la marca Cisco para la ciudad de Lerma • 2 routers de la marca Cisco para la ciudad de Guadalajara • 2 routers de la marca Cisco para la ciudad de Monterrey • 1 router de la marca Cisco para la ciudad de San Martín

En el anexo 1 tabla 1.1 se muestra la lista de dispositivos ruteadores y switches a monitorear. Se cuentan con 200 PC´s para los usuarios de la red, divididas de la siguiente manera:

• 60 computadoras marca Dell modelo Dimension E520 las cuales se encuentran distribuidas 10 PC´s en Altamira, 15 PC´s en Tijuana, 20 PC´s en Monterrey y 15 PC´s en Guadalajara.

• 80 computadoras marca Compaq modelo Presario serie SR2000 las cuales se encuentran todas en las oficinas generales (LAN Homero y Tlalnepantla).

• 30 computadoras marca HP modelo Pavilion desktop PC, distribuidas 15 en San Martin, 15 en Matamoros.

• 30 computadoras marca Compaq modelo Presario serie SR2120LA desktop PC las cuales se encuentran 15 en Monterrey y 15 en Guadalajara.

Tambien la red cuenta con 20 impresoras de marca HP modelos laserjet 5000n, laserjet 8000dn, laserjet 8500dn y laserjet 5si, las cuales se encuentran distribuidas 12 en las oficinas generales (5 laserjet 5000n, 2 laserjet 8500dn, 2 laserjet 5si, 2 laserjet 8000dn y una laserjet 8000dn). Las restantes se encuentras asignadas 3 laserjet 5000n en Guadalajara, 2 laserjet 8500dn en Monterrey, una laserjet 5si en Matamoros una laserjet 8000dn San Martin y una laserjet 8000dn Altamira.

IBM Tivoli NetView


Además se cuenta con servidores 3 servidores de internet marca Dell modelo PowerEdgeTM sc440 Básico, 3 servidores para almacenamiento de bases de datos de la marca Sun modelo Sun Fire V490 y 3 servidores de clientes Microsoft marca HP ProLiant ML para administración de los usuarios de la red, conectados por los switches Cisco mencionados para la LAN Homero. 5.2.2 Análisis del problema y de la solución De acuerdo a la descripción de la red se observa que es una red con un gran numero de elementos como computadoras personales, servidores, impresoras y dispositivos de comunicaciones, muchos de estos elementos son de misión critica y requieren el establecimiento de parámetros de monitoreo esenciales, los cuales aseguren el correcto funcionamiento de la red. El monitoreo de la red deberá ser basado en estándares de SNMP y con tecnologías lideres en el mercado de monitoreo de redes. El analisis identifica a la disponibilidad como un elemento que transforma el monitoreo de cada uno de los recursos de red de reactivo en proactivo. De esta forma se logra detectar las fallas antes de producido el problema. Así Dupont evitará caer en costos producidos por la imposibilidad de brindar los servicios. La infraestructura de comunicaciones a monitorear se encuentra conformada por los siguientes elementos de red: switches, routers e impresoras. Estos elementos requieren ser sujetos de las siguientes actividades:

• Contar con un monitoreo centralizado que permita conocer el estado de la red • Mostrar de manera gráfica mediante el uso de mapas, la topología de la red • Monitorear la disponibilidad y métricas de los dispositivos de red • Obtención de métricas mediante el protocolo SNMP, que permitan predecir problemas

de rendimiento de los diferentes dispositivos TCPIP • Administración de los eventos provenientes de los dispositivos de comunicaciones.

5.3 Solución de monitoreo. 5.3.1 Diseño Físico El diseño físico de la solución presentada es de acuerdo a las necesidades de monitoreo en la red, con respecto al producto IBM Tivoli Netview. En el anexo A1 Fig. A1.2 se muestra el diagrama de la solución de monitoreo de red, el cual esta conformado por la red LAN y los ocho sitios remotos donde se encuentran los ruteadores, los enlaces remotos se encuentran a través de una nube Frame Relay y con capacidades diferentes algunos sitios con capacidad de E0 y otros de E1, en la red LAN es donde se encuentra la red corporativa y por lo tanto el backbone de toda la red de Dupont, es desde donde se centraliza el monitoreo

IBM Tivoli NetView


incluyendo todos los switches que conforman la red LAN. El servidor de Tivoli Netview (NMS) queda instalado y operando con todos los dispositivos: ruteadores, switches e impresoras (agentes SNMP), enviando peticiones y recibiendo respuesta de todos estos agentes, utilizando paquetes de SNMP e ICMP (pings) tal y como trabaja un esquema de monitoreo con un NMS y sus agentes SNMP.

Servidor Tivoli NetView Tivoli Netview habilita al administrador a descubrir redes TCP/IP, desplegar topologías de red, correlacionar y administrar eventos y traps SNMP, monitorear el desempeño de la red y obtener información de desempeño de la misma. Esta herramienta provee al administrador de redes del sistema de un medio para detectar problemas a través de una interfaz gráfica, así como el monitoreo de los dispositivos de red y el manejo de eventos. De acuerdo al análisis realizado al ambiente actual de la red y a los requerimientos de los responsables se determinó una arquitectura basada en un solo servidor para IBM Tivoli Netview. Consolas NetView ó clientes Las consolas Tivoli Netview forman parte de la arquitectura activa de monitoreo de NetView, permitiendo a los administradores y/o operadores de la solución monitorear el estado de los dispositivos, visualizar eventos recibidos y/o detectados, ejecutar comandos de diagnóstico tales como ping, remote ping, traceroute, entre otros. IBM Tivoli NetView ofrece dos consolas de monitoreo:

• Consola Nativa La consola nativa es 100% gráfica y ofrece toda la funcionalidad al operador y administrador, permitiendo desplegar la funcionalidad de la herramienta entre las que se encuentran:

o Visualizar el mapa de topología de red o Configuración de descubrimiento o Configuración de opciones de seguridad o Configuración de eventos, traps o Monitoreo de dispositivos o Diagnóstico de elementos críticos o Etc.

La consola nativa se encuentra localizada en el servidor de Netview y esta se puede acceder también mediante la toma de escritorio remoto.

IBM Tivoli NetView


• Consola Web La consola en modalidad Web es 100% JAVA, por lo que ofrece un ambiente flexible para los operadores que se están moviendo de un sitio a otro, ofrece una interfase gráfica, mediante la cual puede:

o Visualizar el mapa de topología de red o Monitoreo de dispositivos o Diagnóstico de elementos críticos o Etc.

El cliente Web de Tivoli Netview esta soportado por Windows XP/2000/2003, Solaris, AIX, y es soportado por los siguientes navegadores.

• Microsoft Internet Explorer V4.0 or higher • Netscape Navigator or Netscape Communicator V4.5 or higher • El cliente Web puede correr como una aplicación Java.

Para iniciar el cliente Web de Netview se accede al URL: http://host:8080/NetviewApplet.html desde el navegador. 5.3.2 Especificaciones de Operación. Esta sección describirá el diseño operativo definido para la red. Esta provee información acerca de la forma en que Tivoli Netview interactúa con todos los componentes de la red. Un elemento fundamental para el monitoreo es la presentación de los diferentes componentes a ser monitoreados. Para cumplir con esto, es necesario crear los mapas o vistas de monitoreo en Tivoli NetView. Conforme lo solicitado por Dupont, será necesario tener un mapa de administración y monitoreo el cual contendrá a todos los elementos que integran la red. Los requerimientos que se cumplen con esta solución son:

• Ambiente centralizado que permita conocer el status de la red • Contar con un mapa con todos los elementos que componen la red • Monitoreo de los routers, switches y servidores; así como tener la capacidad de

ejecutar algunas funciones de administración sobre los dispositivos. El descubrimiento de los nodos que conforman la red se limitará a través de un archivo de configuración.

IBM Tivoli NetView


Descubrimiento de equipos Se hará un descubrimiento de todos los routers, switches e impresoras a través de un archivo semilla (seed file). El archivo se encuentra en la ruta /usr/OV/conf y se llama netmon.seed Este mecanismo permite a NetView descubrir únicamente los elementos indicados en el archivo semilla. Los equipos descubiertos serán aquellos que se encuentran en la Figura 1 del anexo 1. Monitoreo de la red. La forma de operación de Tivoli Netview es mediante el envío de paquetes SNMP o ICMP a todos los servidores, switches, routers e impresoras que componen la red, los tres tipos de polling que hará son:

• Poleo de status (Status polling) • Poleo de configuración (Configuration polling) • Poleo de colección de datos (Data collection polling)

El tiempo utilizado para status polling será de 3 minutos, para las colecciones de datos se manejara de acuerdo a el número de colecciones que se implementen para las diferentes métricas de los switches, routers e impresoras, y el tiempo utilizado en configuration polling será el que tiene por default (12 horas). Mediante el uso de la consola nativa o de Web de Netview, y en forma visual podemos detectar en los mapas y submapas que componen la red la disponibilidad de los routers, switches, impresoras, interfaces y puertos. En este caso la disponibilidad se refiere al status de los switches, routers, impresoras, interfaces y puertos de la red, el status muestra estados: UP, DOWN, marginal y critico estos estados son visualizados en el mapa indicándonos un status de acuerdo a el color en que se encuentre el símbolo en el mapa, ver figura A1.3 del anexo 1:

• Símbolo en color verde equivale a un status normal. Este status se visualiza en cualquier elemento o dispositivo de la red y que se encuentra OK en el momento en que Netview le realiza una prueba de poleo de status.

• Símbolo en color amarillo equivale a un status marginal o precautorio. Este status se presenta en los nodos de la red y que alguna de sus interfaces se encuentra Down en el momento en que Netview le realiza una prueba de poleo, el color amarillo se refleja en el símbolo contenedor de la interfaz que se encuentra Down, cabe mencionar que el color amarillo se presentara solo si el símbolo contenedor de la interfaz tiene mas interfaces que tengan un status normal, porque si solo se tiene una interfaz entonces el color que se reflejara es el rojo.

IBM Tivoli NetView


• Símbolo en color rojo equivale a un status crítico. Este status se presenta en interfaces y nodos de la red y que en el momento en que Netview le realiza una prueba de poleo sobre la interfaz esta se encuentra Down, inmediatamente cambia a color rojo y si es la única interfaz sobre el nodo entonces este color rojo de critico se reflejara en símbolo contenedor de la interfaz, este símbolo seria un nodo.

También en cuanto se presente algún evento correspondiente a alguno de los estados anteriores en alguno de los elementos de la red, inmediatamente serán desplegadas notificaciones en la ventana de eventos de Netview. Las colecciones de datos se habilitan en el servidor de Tivoli Netview, la información se estará colectando principalmente sobre los switches, routers e impresoras de la red y corresponde a: LAN CISCO

• Disponibilidad de interfaces • Uso de CPU • Uso de memoria y Back Plain en switches • Errores de entrada y salida en interfaces de switches

WAN CISCO

• Disponibilidad de interfaces e interfaces seriales • Uso de CPU • Uso de memoria en ruteadores • Errores de entrada y salida en interfaces de ruteadores • Utilización de ancho de banda en interfaces de ruteadores • Utilización de umbrales en dispositivos cisco

IMPRESORAS

• Colección de datos de total de hojas impresas • Configuración de las impresoras • Status de la impresora

Información manejada por Netview Tivoli Netview mantiene la información en bases de datos propietarias, la información que maneja es almacenada dependiendo de la naturaleza de esta, pudiendo ser información de la topología, objetos y eventos.

IBM Tivoli NetView


5.3.3 Configuración del producto. 5.3.3.1 Configuración de los intervalos de poleo SNMP.

Acorde con los requerimientos de la solución, TIVOLI NetView utiliza el Agente de SNMP (Simple Network Managment Protocol) que actúa sobre los nodos manejados que se localizan sobre la red. La solución opera principalmente bajo el protocolo de red TCP/IP que es aplicado comúnmente en diferentes dispositivos de red como ruteadores, hubs, gateway, switches etc., es decir, los nodos viven en la red con direcciones IP asignadas a cada uno, conformando toda la red. Usualmente una red es una colección de máquinas en la misma localización geográfica, o puede haber varias redes conectadas entre si mediante ruteadores, hubs, gateways o switches. Estas redes pueden estar también divididas en segmentos, donde estos segmentos son colecciones de equipos contenidos en el mismo segmento. El proceso de descubrimiento de la red inicia configurando del menú Options las siguientes opciones Polling, SNMP y Discovery. En la ventana de Discovery se indica si se quiere descubrir toda la red o solo el segmento de la red local donde se encuentra Netview, para este caso se indico Discover all Networks , también se indico la velocidad de descubrimiento la cual en un inicio se indica como High, también se indico que el descubrimiento de algunos nodos se hiciera por medio de un archivo llamado netmon.seed localizado en el path e:\usr\ov\conf , el cual contiene direcciones IP de nodos específicos que Netview tiene problemas para descubrir, también en este archivo se puede definir si se quiere que algún nodo lo excluya de la red. El archivo contiene una ayuda para la edición de la correcta sintaxis. Para el correcto funcionamiento del producto, es necesario configurar los tiempos de poleo de la herramienta, utilizados para verificar el estado de los dispositivos. Para configurar estos parámetros se debe seleccionar la opción Polling… que se encuentra bajo el menú Options…de la barra de menús de TIVOLI NetView. El número de los agentes SNMP que pueden ser soportados depende de la velocidad del poleo, de la velocidad de cada uno de los eventos ocurridos, y del tamaño de la red que se quiere administrar. Por esta razón se consideraron los tiempos de poleo que se muestran en la tabla A2.1 del Anexo 2 5.3.3.2 Configuración de SNMP en Ruteadores y Switches y en el servidor de Netview. La configuración de snmp en un ruteador y switch cisco se muestra en el procedimiento que se muestra en el anexo 2. Los nombres de comunidad (community names) utilizados se configuraron bajo la opción de SNMP... del menú Options. Estas community names deberán estar definidas y configuradas en ruteadores, switches e impresoras, y cualquier equipo sujeto a monitoreo, así como la habilitación del agente SNMP en todos estos equipos. La community name por default es

IBM Tivoli NetView


public y se configuraron community names de ruteadores, switches, impresoras y servidores en la parte de Specifics Nodes los cuales se muestran en la figura A2.1 del anexo 2. Configuración de SNMP para Switches Para configurar el soporte de SNMP, hay que realizar las tareas que indicaremos a continuación. En todas ellas, excepto para los comandos show y debug, hay que estar en el modo de configuración global: 1. Crear el control de acceso para una comunidad SNMP Hay que emplear un nombre de comunidad para definir la relación entre el gestor SNMP y el agente. Dicha comunidad actúa como una palabra clave para regular el acceso al agente que se haya en el switch. Se pueden especificar opcionalmente algunas características adicionales: Una vista de la MIB, que define el subconjunto de los objetos de la MIB accesibles para la comunidad dada (veremos ahora después como se crea una vista). Permiso de lectura y escritura o de sólo lectura para los objetos de la MIB accesibles. Una lista de control de acceso (ACL) con direcciones IP de los gestores SNMP a los que se permite acceder al agente empleando el nombre de comunidad especificado. El comando que hay que emplear para definir una comunidad es el siguiente: Switch (config) # snmp-server community nombre_comunidad [view nombre_vista] [ro|rw] [número_de_acl] Si se quiere deshabilitar una comunidad, hay que emplear el siguiente comando: Switch(config)# no snmp-server community nombre_comunidad. Por defecto, si no se especifican los parámetros opcionales, se facilita acceso de sólo lectura a toda la MIB (vista por defecto everything) y a todos los hosts. 2. Crear un registro de vista SNMP Otros comandos SNMP requieren una vista como argumento. Las vistas se emplean para delimitar los objetos de la MIB accesibles para un gestor SNMP. Se puede usar una vista predefinida, o bien, crear nuevas vistas. Las vistas predefinidas son dos: everything, que abarca toda la MIB, y restricted, que incluye sólo los grupos system, snmpStats y snmpParties. El comando que hay que usar para crear o modificar un registro de vista SNMP es: Switch(config)# snmp-server view nombre_vista arbol_OID {included | excluded}

IBM Tivoli NetView


Se puede introducir este comando varias veces para el mismo registro de vista. Lo que se hace es añadir o eliminar elementos de dicha vista, dependiendo de si se especifica included o excluded. Si un identificador de objeto se incluye en dos o más comandos, es el más reciente el que tiene efecto. El parámetro “árbol _ oíd” es el identificador de objeto del nodo raíz del subárbol dentro del árbol de nombres al que va a afectar el comando. El siguiente comando elimina por completo un registro de vista: Switch(config)# no snmp-server view nombre_vista. 5.3.3.3 Descripción de las MIB’s Mibs para CPU Descripción. AvgBusy5 indica el promedio de utilización de CPU en los pasados 5 minutos y busyPer indica el procedimiento de utilización de CPU en los últimos 5 segundos.

• .iso.org.dod.internet.private.enterprises.cisco.local.lsystem.AvgBusy5 • .iso.org.dod.internet.private.enterprises.cisco.local.lsystem.busyPer

MIBs para Memoria Descripción. ciscoMemoryPoolName es un nombre textual asignado al pool de memoria. El objeto es conveniente para el uso del operador humano. Tambien es usado para distinguir entre los diversos tipos de pool y especialmente sobre el pool dinámico.

• .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.CiscoMemoryPoolTable.CiscoMemoryPoolEntry.ciscoMemoryPoolName ó .1.3.6.1.4.1.9.9.48.1.1.1.2 donde:

o .1.3.6.1.4.1.9.9.48.1.1.1.2.7 es la memoria NVRAM y o .1.3.6.1.4.1.9.9.48.1.1.1.2.8 es la memoria MBUF Back Plain

Descripción. ciscoMemoryPoolUsed Indica el numero de bytes del pool de memoria que se encuentra en uso en el dispositivo y ciscoMemoryPoolFree indica el numero de bytes del pool de memoria que se encuentra sin usar en el dispositivo. La suma de ambas es la memoria total en el pool.

• .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.CiscoMemoryPoolTable.CiscoMemoryPoolEntry.ciscoMemoryPoolUsed ó .1.3.6.1.4.1.9.9.48.1.1.1.5

• .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.CiscoMemoryPoolTable.CiscoMemoryPoolEntry.ciscoMemoryPoolFree ó .1.3.6.1.4.1.9.9.48.1.1.1.6

IBM Tivoli NetView


MIBs para Errores en interfases Descripcion. IfInErrors y ifOutErrors son el número de paquetes a la entrada y salida de la interface que contienen errores, previniendo su liberación a los protocolos de las capas superiores

• ifInErrors • ifOutErrors

MIBs Para Utilización de ancho de banda Descripción. BandwidthUtilHdx, BandwidthUtilIn y BandwidthUtilOut son expresiones de valores MIB que trae por defecto Tivoli Netview y se refieren a la utilización del ancho de banda en enlaces halfduplex, entrada y salida de la interfase respectivamente.

• BandwidthUtilHdx (Utilización de ancho de banda en dispositivos cisco). • BandwidthUtilIn (Utilización de ancho de banda de entrada en interfaces de

ruteadores). BandwidthUtilOut (Utilización de ancho de banda de salida en interfaces de ruteadores).

5.3.3.4 Monitoreo de impresoras. Métricas a monitorear en impresoras Con la configuración de SNMP y definidas las community names para que SNMP haga las peticiones de monitoreo y configuración de dispositivos en la red, se consiguieron los archivos mibs para los modelos de impresoras: laserjet 5000n, laserjet 8000dn, laserjet 8500dn, laserjet 5si, dichos archivos son:

• Clj4500.mib • Clj8500.mib • Lj2100_snmp.mib • Lj4050.mib • Lj4v.mib • Lj5.mib • Lj5si.mib • Lj5simop.mib • Lj6p.mib • Lj8000.mib • Lj8000mbm.mib • Lj8000stap.mib • Lj8100.mib • Lj8100.mbm.mib • Lj8100stap.mib • Ljs4000.mib

IBM Tivoli NetView


• Ljs5000.mib Se cargaron a la base de datos de Netview mediante la opción del menú Tools > MIB > Load. Ver figura A3.1 en anexo 3 Una vez cargadas las mibs se utilizo el MIB Browser para hacer consultas y conseguir los valores que se requieren para la solución Tivoli Netview en impresoras. En este punto se presentaron los siguientes problemas con los modelos de impresoras laserjet (5000N, 8000DN, 8500DN, 4500), al realizar la consulta mediante el MIB Browser de valores sobre los subárboles mib:

• .iso.org.dod.internet.private.enterprises.hp.nm.hpsystem.net-peripheral.netdm.dm.printmib

• .iso.org.dod.internet.private.enterprises.hp.nm.hpsystem.net-peripheral.netdm.dm.hrm

Se noto que la consulta no arrojo valores, y el único subárbol que arrojo valores fue: .iso.org.dod.internet.private.enterprises.hp.nm.hpsystem.net-peripheral.netdm.dm.device De los subárboles donde no se obtuvieron valores, se opto por usar los valores que se obtienen mediante mibs genéricas de dispositivos hp (hpnp.mib), los cuales cumplen con los valores solicitados para la solución como son status y obtención de algunas métricas en impresoras de cualquier modelo. El modelo de impresora Laserjet 5si no presenta problemas al consultar todos los subárboles. De los valores que se ha pedido sean obtenidos a través de mibs son:

• No. De serie de la impresora • Hardware address • IP Address • Subnet Mask • Default Gateway • Community name • Hostname • Appletalk Status • port config • StatusPaperOut • StatusPaperJam • StatusTonerLow • StatusBusy • StatusDoorOpen • StatusPrinting • StatusDisplay

IBM Tivoli NetView


• Numero Total de paginas impresas por la impresora • Numero parte del cartucho

Todos estos valores son obtenibles a través del MIB Browser y la forma en que se pueden presentar es, mediante el MIB Browser o creando una aplicación utilizando la herramienta de Netview opción Tools > MIB > Tool Builder la cual presenta los datos obtenidos en forma de Tabla, Forma o Grafica. Se crearon cuatro aplicaciones las cuales el Tool Builder las integra al menú Monitor > Other > PrinterStatus, TonerDescrip, Total page printed y Specific Configuration:

Colección de datos de total de hojas impresas por impresora. La finalidad de esta colección de datos es la creación de un archivo en formato ASCII con información del número total de páginas impresas por impresora con la finalidad de manipularlo en Excel para obtener reportes. Se genera mediante una colección de datos, la cual se configura mediante el archivo snmpCol.conf en el path e:\usr\ov\conf, en la figura A3.5 de archivo de configuración de expresiones en el anexo 3 observamos que las líneas que se adhirieron al archivo para la colección de datos es: MIB .1.3.6.1.2.1.43.10.2.1.4 .* TotPagPrinted units GAUGE R mxrs7 C smartset:Printers 0xffffffff 120 > 0.000000 <= 0.000000 x% s 58720263 Donde: .1.3.6.1.2.1.43.10.2.1.4 = OID (Object Identifier) .* = Instancias a monitorear TotPagPrinted = Nombre de la colección Units GAUGE = unidades y tipo de datos R = Guardar la información obtenida Mxrs7 = hostname de Netview C = Indica que se encuentra coleccionando Smarset:Printers = Objetos sobre los cuales se hace la colección 120 = lapso de tiempo en segundos entre colecciones, este valor es de 86400 para el lapso de 1 día. Los datos que se obtienen se almacenan en la base de datos de netview y se pueden desplegar abriendo la aplicación de Collect MIB Data y seleccionando la colección deseada se pide traer la información mediante el botón Data, una vez desplegada la información requerida se puede guardar en dos formatos de archivo diferentes: *.txt y *.html mediante el botón Save as ... También se creo una colección de datos sobre el numero total de hojas duplex por impresora, duplex-page-count y esta se realizo mediante la ventana de Collect MIB Data. Las dos colecciones se hicieron sobre el smartset Printers. Las figuras A3.1, A3.2, A3.3 y A3.4 en el anexo 3 muestran la carga de mibs, aplicaciones para graficas y tablas y colección de datos para las impresoras de acuerdo a las métricas solicitadas.

IBM Tivoli NetView


5.3.3.5 LAN CISCO. Disponibilidad de interfaces. La disponibilidad de interfaces es implementada en el momento que Netview descubre y empieza a monitorear los nodos (servidores, ruteadores, switches, interfaces, etc.) de la topología de la red, en este caso la disponibilidad se refiere al status de la interfase, la cual muestra dos estados: UP y DOWN, estos estados son desplegados en la ventana de eventos de Netview cuando a través del proceso netmon de Netview detecta un cambio en el estado de la interfase. Adicionalmente se implemento el envió de mensajes a Skytel mediante la configuración de la opción trap settings. Procedimiento disponibilidad de interfaces 1. Visualizacióln de status de interfaces en la ventana de eventos de Netview. Se abre desde el menú de Monitor > Events > All 2. Configuración de eventos.

• Abrir la ventana del menú Options->Trap Settings Donde se selecciono el Enterprise Netview, y en la parte de Trap se seleccionaron los siguientes traps: IntfDown y IntfUp:

• Se oprime el botón Properties... , donde en la ventana desplegada se escribe el comando en la línea: Run this command when the trap is received = comando o programa a ejecutar cuando se recibe el evento, en este caso se ejecuta un shell que envía un mensaje del status de la interfase.

En el anexo 4 se muestran las figuras A4.1, A4.2, A4.3 y A4.4 del procedimiento para la disponibilidad de las interfaces. Uso de CPU Para el monitoreo de CPU se investigo sobre los MIBs OID de cisco los siguientes objetos: .iso.org.dod.internet.private.enterprises.cisco.local.lsystem.AvgBusy5 .iso.org.dod.internet.private.enterprises.cisco.local.lsystem.busyPer El monitoreo de CPU de un dispositivo cisco se realiza mediante la utilización de DataCollections, el procedimiento para habilitar Data collections se muestra a continuación y las correspondientes figuras A4.5, A4.6, A4.7, A4.8 y A4.9 en el anexo 4.

IBM Tivoli NetView


Procedimiento para uso de CPU. Avgbusy5 y busyPer Data Collections (Utilización promedio de CPU). 1. Se seleccionó en Start->Programs->Netview->Tasks->Collect MIB Data 2. Para el caso de la colección de avgBusy5, ya existe por default en Netview, entonces solo se configura oprimiendo el botón de Properties... Donde: Label muestra el nombre de la colección. Instance muestra las instancias o interfaces sobre las cuales se tomara la colección de datos. Station muestra el host donde se guardaran las colecciones. 3. Aquí se selecciono la colección de datos en los nodos de smartset: CiscoDevices y se oprime el botón Polling Properties..., desplegando la siguiente ventana y la descripción de los campos a llenar es la siguiente: Poll Node Every = rango de tiempo en el cual netview colectara datos de las instancias. Store MIB Data = seleccionando esta opción los datos se almacenan en el path: e:\usr\OV\databases\snmpcollect y en la base de datos de MS SQL. Check Thresholds = seleccionado esta opción habilta el envió de traps cuando se sobrepasa el umbral de utilización especificado (Send Trap), y cuando se regresa a un estado de utilización establecido como normal (Rearm), estos umbrales se pueden definir en las relaciones de =, >, <, etc. y en términos de porcentaje o valor absoluto. Colección de datos busyPer. 1. Se agrega presionando el botón New... de la ventana Collections, en la ventana Collection Wizard se selecciona la pestaña de MIB Object en la cual se navega a través de el árbol de mibs para seleccionar el objeto: .iso.org.dod.internet.private.enterprises.cisco.local.lsystem.busyPer , el cual es el valor promedio de utilización de CPU en los últimos 5 segundos. 2. Aquí se selecciona los nodos o smartsets donde se realizaran las colecciones, para este caso se selecciono el smartset CiscoDevices y la descripción de los campos a llenar es la siguiente: Poll Node Every = rango de tiempo en el cual netview colectara datos de las instancias. Store MIB Data = seleccionando esta opción los datos se almacenan en el path: e:\usr\OV\databases\snmpcollect y en MS SQL. Check Thresholds = seleccionado esta opción habilita el envió de traps cuando se sobrepasa el umbral de utilización especificado (Send Trap), y cuando se regresa a un estado de utilización establecido como normal (Rearm), estos umbrales se pueden definir en las relaciones de =, >, <, etc. y en términos de porcentaje o valor absoluto.

IBM Tivoli NetView


Uso de memoria y Back Plain en switches. Para el monitoreo de uso de memoria en switches se realizan colecciones de datos sobre MIB OID propietarias de cisco, para este caso se selecciono la memoria NVRAM y MBUF (Back Plain) las cuales se encuentran en los siguientes OIDs: .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.CiscoMemoryPoolTable.CiscoMemoryPoolEntry.ciscoMemoryPoolName ó .1.3.6.1.4.1.9.9.48.1.1.1.2 donde: .1.3.6.1.4.1.9.9.48.1.1.1.2.7 es la memoria NVRAM y .1.3.6.1.4.1.9.9.48.1.1.1.2.8 es la memoria MBUF Back Plain De esta misma ruta se eligieron los siguientes OIDs para definir la expresión que calcula el porcentaje de memoria utilizada: .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.CiscoMemoryPoolTable.CiscoMemoryPoolEntry.ciscoMemoryPoolUsed ó .1.3.6.1.4.1.9.9.48.1.1.1.5 .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.CiscoMemoryPoolTable.CiscoMemoryPoolEntry.ciscoMemoryPoolFree ó .1.3.6.1.4.1.9.9.48.1.1.1.6 Para calcular el uso de la memoria en porcentaje se crearon dos expresiones que se integran a la pestaña MIB Expresions de la ventana Collection Wizard, el procedimiento para crear expresiones para la colección de datos se muestra a continuación y las correspondientes figuras A4.10, A4.11 y A4.12 en el anexo 4 Procedimiento para la utilización de memoria en switches 1. Se detiene el proceso snmpcollect con el siguiente comando: ovstop snmpcollect 2. En la ruta e:\usr\ov\conf se edita el archivo mibexpr.conf para adicionar las expresiones que calculan el porcentaje de utilización de memoria, el archivo contiene una descripción de como dar de alta expresiones. 3. La formula que se utilizo es la siguiente: %memoria utilizada = (100 * ciscoMemoryPoolUsed) / (ciscoMemoryPoolUsed + ciscoMemoryPoolFree) El nombre empleado para definir cada una de las expresiones es el siguiente: SWNVRAMUtil para la memoria NVRAM BackPlainUtil para la memoria Back Plain La siguiente ventana muestra la formula ya adicionada al archivo mibexpr.conf:

IBM Tivoli NetView


4. Se ejecuta el comando ovw_config. 5. Se levanta el proceso snmpCollect con el comando: ovstart snmpcollect 6. Adicionar las colecciones de datos sobre las expresiones creadas. Las colecciones SWNVRAMUtil y BackPlainUtil se agregan presionando el botón New... de la ventana Collections, después en la ventana Collection Wizard pestaña MIB Expresión se selecciona alguna de las expresiones y se oprime el botón Next >. La descripción de los campos es la siguiente: Label es el nombre de la colección seleccionada. Instance instancias o interfaces sobre las cuales se tomara la colección de datos, * en este caso significa instancias 7 y 8. 7. En la ventana siguiente se selecciona los nodos o smartsets donde se realizaran las colecciones, el tiempo de poleo, almacenamiento de las colecciones y los umbrales, la descripción de los campos a llenar es la siguiente: Poll Node Every = rango de tiempo en el cual netview colectara datos de las instancias. Store MIB Data = seleccionando esta opción los datos se almacenan en el path: e:\usr\OV\databases\snmpcollect y en MS SQL Check Thresholds = seleccionado esta opción habilita el envió de traps cuando se sobrepasa el umbral de utilización especificado (Send Trap), y cuando se regresa a un estado de utilización establecido como normal (Rearm), estos umbrales se pueden definir en las relaciones de =, >, <, etc. y en términos de porcentaje o valor absoluto. Errores de entrada y salida en interfaces de switches. El monitoreo de errores en las interfaces se realizo sobre los siguientes oids:

• ifInErrors Data Collection (errores de entrada en interfaces de switches). • ifOutErrors Data Collection (errores de salida en interfaces de switches).

EL procedimiento para crear las colecciones de datos ifInErrors e ifOutErrors se describe a continuación y las correspondientes figuras A4.13 y A4.14 en el anexo 4. Procedimiento para errores en interfaces de Switches 1. New... de la ventana Collections, en la ventana Collection Wizard se selecciona la pestaña de MIB Object en la cual se navega a través del árbol de mibs para seleccionar los MIB Object ID: .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifInErrors .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifOutErrors La descripción de los campos a llenar es la siguiente: Label es el nombre de la colección seleccionada Instance instancias o interfaces sobre las cuales se tomara la colección de datos, * significa todas.

IBM Tivoli NetView


2. En la ventana Collection Wizard 2 se selecciona los nodos o smartsets donde se realizaran las colecciones, para este caso se selecciono el smartset CiscoDevices y la descripción de los campos a llenar es la siguiente: Poll Node Every = rango de tiempo en el cual netview colectara datos de las instancias. Store MIB Data = seleccionando esta opción los datos se almacenan en el path: e:\usr\OV\databases\snmpcollect y en MS SQL. Check Thresholds = seleccionado esta opción habilita el envió de traps cuando se sobrepasa el umbral de utilización especificado (Send Trap), y cuando se regresa a un estado de utilización establecido como normal (Rearm), estos umbrales se pueden definir en las relaciones de =, >, <, etc. y en términos de porcentaje o valor absoluto. 5.3.3.6 WAN CISCO. Disponibilidad de interfaces. La disponibilidad de interfaces es implementada en el momento que Netview descubre y empieza a monitorear los nodos (servidores, ruteadores, switches, interfaces, etc.) de la topología de la red, en este caso la disponibilidad se refiere al status de la interfase, la cual muestra dos estados: UP y DOWN, estos estados son desplegados en la ventana de eventos de Netview cuando a través del proceso netmon de Netview detecta un cambio en el estado de la interfase. Adicionalmente se implemento el envió de mensajes a Skytel mediante la configuración de la opción trap settings. El procedimiento para la disponibilidad de las interfaces es el mismo descrito para las interfaces LAN Uso de CPU Para el monitoreo de CPU se utilizaron los siguientes MIBs OID de cisco: .iso.org.dod.internet.private.enterprises.cisco.local.lsystem.AvgBusy5 .iso.org.dod.internet.private.enterprises.cisco.local.lsystem.busyPer El monitoreo de CPU de un dispositivo cisco se realiza mediante la utilización de DataCollections, el procedimiento para habilitar colecciones de datos para CPU es el mismo que se detalla en el procedimiento de LAN cisco. Uso de memoria en ruteadores. Para el monitoreo de uso de memoria en ruteadores se realizan colecciones de datos sobre MIB OID propietarias de cisco, para este caso se selecciono la memoria Processor la cual se encuentra en el siguiente OIDs: .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.CiscoMemoryPoolTable.CiscoMemoryPoolEntry.ciscoMemoryPoolName ó .1.3.6.1.4.1.9.9.48.1.1.1.2 donde: .1.3.6.1.4.1.9.9.48.1.1.1.2.1 es la memoria Processor

IBM Tivoli NetView


De esta misma ruta se eligieron los siguientes OIDs para definir la expresión que calcula el porcentaje de memoria utilizada: .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.CiscoMemoryPoolTable.CiscoMemoryPoolEntry.ciscoMemoryPoolUsed ó .1.3.6.1.4.1.9.9.48.1.1.1.5 .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.CiscoMemoryPoolTable.CiscoMemoryPoolEntry.ciscoMemoryPoolFree ó .1.3.6.1.4.1.9.9.48.1.1.1.6 Para calcular el uso de la memoria en porcentaje se crea una expresión que se integra a la pestaña MIB Expresions de la ventana Collection Wizard, el procedimiento para crear expresiones para la colección de datos de memoria se muestra a continuación y las correspondientes figuras A5.1, A5.2 y A5.3 se muestran en el anexo 5. Procedimiento para uso de memoria en ruteadores 1. Se detiene el proceso snmpcollect con el siguiente comando: ovstop snmpcollect 2. En la ruta e:\usr\ov\conf se edita el archivo mibexpr.conf para adicionar las expresiones que calculan el porcentaje de utilización de memoria, el archivo contiene una descripción de como dar de alta expresiones. 3. La formula que se utilizo es la siguiente: %memoria utilizada = (100 * ciscoMemoryPoolUsed) / (ciscoMemoryPoolUsed + ciscoMemoryPoolFree) El nombre empleado para definir la expresión es el siguiente: RouterMemProcUtil para la memoria Processor La siguiente ventana muestra la formula ya adicionada al archivo mibexpr.conf: 4. Se ejecuta el comando ovw_config. 5. Se levanta el proceso snmpCollect con el comando: ovstart snmpcollect 6. Adicionar la colección de datos sobre la expresión creada. La colección RouterMemProcUtil se agrega presionando el botón New... de la ventana Collections, después en la ventana Collection Wizard pestaña MIB Expresión se selecciona la expresión y se oprime el botón Next >. La descripción de los campos es la siguiente: Label es el nombre de la colección seleccionada. Instance instancias o interfaces sobre las cuales se tomara la colección de datos, * en este caso significa instancia 1. 7. En la ventana siguiente se selecciona los nodos o smartsets donde se realizaran las colecciones, el tiempo de poleo, almacenamiento de las colecciones y los umbrales, la descripción de los campos a llenar es la siguiente: Poll Node Every = rango de tiempo en el cual netview colectara datos de las instancias.

IBM Tivoli NetView


Store MIB Data = seleccionando esta opción los datos se almacenan en el path: e:\usr\OV\databases\snmpcollect y en MS SQL Check Thresholds = seleccionado esta opción habilita el envió de traps cuando se sobrepasa el umbral de utilización especificado (Send Trap), y cuando se regresa a un estado de utilización establecido como normal (Rearm), estos umbrales se pueden definir en las relaciones de =, >, <, etc. y en términos de porcentaje o valor absoluto. Errores de entrada y salida en interfaces de ruteadores. El monitoreo de errores en las interfaces se realizo sobre los siguientes oids:

• ifInErrors Data Collection (errores de entrada en interfaces de ruteadores). • ifOutErrors Data Collection (errores de salida en interfaces de ruteadores).

El procedimiento para las colecciones de datos ifInErrors e ifOutErrors es el mismo descrito en la sección LAN cisco. Utilización de ancho de banda en interfaces de ruteadores El monitoreo de utilización de ancho de banda en las interfaces se realizo sobre las siguientes expresiones las cuales ya se tienen por defecto en Tivoli Netview:

• BandwidthUtilHdx Data Collection (Utilización de ancho de banda en dispositivos cisco).

• BandwidthUtilIn Data Collection (Utilización de ancho de banda de entrada en interfaces de ruteadores).

• BandwidthUtilOut Data Collection (Utilización de ancho de banda de salida en interfaces de ruteadores).

El procedimiento para las colecciones de datos de ancho de banda se detalla a continuación y las correspondientes figuras A5.4, A5.5 y A5.6 se muestran en el anexo 5. Procedimiento para utilización de ancho de banda en ruteadores 1. Se selecciona Start->Programs->Netview->Tasks->Collect MIB Data y en esta ventana se selecciona el botón New… 2. BandwidthUtilHdx, BandwidthUtilIn y BandwidthUtilOut (estas colecciones son expresiones de valores MIB), ya existen en Netview en la pestaña de MIB Expression, se selecciona alguna de estas y entonces se oprime el botón de Next>. La descripción de los campos es la siguiente: Label es el nombre de la colección seleccionada Instance instancias o interfaces sobre las cuales se tomara la colección de datos, * significa todas. 3. En la ventana siguiente se selecciona los nodos o smartsets donde se realizaran las colecciones y la descripción de los campos a llenar es la siguiente:

IBM Tivoli NetView


Poll Node Every = rango de tiempo en el cual netview colectara datos de las instancias. Store MIB Data = seleccionando esta opción los datos se almacenan en el path: e:\usr\OV\databases\snmpcollect y en MS SQL Check Thresholds = seleccionado esta opción habilita el envió de traps cuando se sobrepasa el umbral de utilización especificado (Send Trap), y cuando se regresa a un estado de utilización establecido como normal (Rearm), estos umbrales se pueden definir en las relaciones de =, >, <, etc. y en términos de porcentaje o valor absoluto. 5.3.3.7 Utilización de umbrales en dispositivos cisco. La utilización de umbrales se define en las colecciones de datos de utilización de ancho de banda, memoria, cpu y errores, el procedimiento se describe en las respectivas secciones de cada monitoreo, en la parte de Collection Wizard step 2 of 2 Check Thresholds = seleccionando esta opción habilita el envió de traps cuando se sobrepasa el umbral de utilización especificado (Send Trap), y cuando se regresa a un estado de utilización establecido como normal (Rearm), estos umbrales se pueden definir en las relaciones de =, >, <, etc. y en términos de porcentaje o valor absoluto. 5.3.3.8 Personalización de mapas y submapas de Netview La finalidad de personalizar los mapas y submapas es la de dar una mejor presentación y mayor facilidad de navegación a través de los mapas y submapas, con ello también se agrupa de manera familiar los nodos (routers, switches, printers, etc). La personalización se realizo con el redescubrimiento de la red, esto es mediante el borrado de la base de datos de Netview y redefiniendo la localización de segmentos y nodos de red de acuerdo a su ubicación geográfica. Esta operación se realiza mediante la edición del archivo location.conf, el archivo contiene una descripción de la sintaxis que se deberá emplear, el archivo esta ubicado en el path e:\usr\ov\conf , en el cual se definen los segmentos y símbolos a insertar en los mapas y submapas, esta operación deberá realizarse antes de borrar y redescubrir el mapa. El borrado y redescubrimiento del mapa se hace desde la ventana de Server Setup y en la opción de Databases se selecciona Clear Databases, Restart Discovery y Preserve SmartSets. Este proceso borra la base de datos de Netview, reinicia daemons y redescubre la red acomodando segmentos y nodos de red de acuerdo a el archivo location.conf. El anexo 5 muestra las figuras A5.7 y A5.8 donde se realizo la personalización de los mapas de la red 5.3.3.9 Configuración de eventos. Con el propósito de brindar información oportuna de los eventos generados inesperadamente en la red se configuraron acciones que envían mensajes cuando se genera un evento de severidad crítica o de información de algún status de dispositivos en la red.

IBM Tivoli NetView


Estas notificaciones se envían a números de skytel mediante el email cuando se presenta un nodo DOWN, interfase DOWN y cuando se rebasa el umbral para el caso de ancho de banda, de los smartset Cisco_Switches y Routers cuando se presenta un aumento en la utilización del ancho de banda en dispositivos Cisco. Las notificaciones para interfaces y nodos se definieron en las secciones de LAN CISCO y WAN CISCO, en esta parte se definirá el caso para umbrales. El procedimiento que se realizo para la configuración de estas notificaciones se detalla a continuación y las correspondientes figuras A5.9, A5.10, A5.11, A5.12 y A5.13 en el anexo 5.

Procedimiento para la configuración de los eventos 1. Se abrió la ventana de el menú Options->Trap Settings ...

Donde se selecciono el Enterprise Netview, y en la parte de Trap se seleccionaron los siguientes traps: CollDetThresh, CollRe-arm.

2. Se editaron las propiedades de cada trap y en línea Run this command when trap is

received, se inserto el comando que realiza la acción de notificación.

Donde: nvmail –server cdcln05 –recipient [email protected] -message “$2 with $3” Es el comando de netview para enviar un email, la descripción de la sintaxis es la siguiente: -server = servidor que utiliza netview para dar salida al email en este caso usa el servidor cdcln05 -recipient = dirección email a donde se envía el mensaje, ejem. [email protected] -message = mensaje a enviar entre comillas , ya que es mas de una palabra a enviar y en este caso $2 significa el nodo que presenta el evento, y $3 significa la descripción del evento. Las notificaciones para el caso de utilización de ancho de banda se presentan en el skytel con el texto que a continuación se muestra, tomado de la sintaxis que se uso en el comando nvmail.

IBM Tivoli NetView


Conclusiones. El proceso de implementación de la solución de monitoreo de red a través de IBM Tivoli Netview para la empresa DUPONT, S.A. DE C.V. obtuvo un resultado SATISFACTORIO, tomando como notas los siguientes puntos CENTRALES:

• Durante la instalación y configuración de IBM Tivoli Netview se aplicaron criterios de ajuste de acuerdo a la experiencia de los administradores de la red, para la definición de la integración de monitoreo de impresoras, dispositivos cisco, adecuaciones a los mapas y submapas de la red de datos de DUPONT. Tivoli Netview ayudo a optimizar los tiempos de respuesta en la detección y corrección de fallas en los elementos que conforman la red de datos, así como el monitoreo de manera centralizada y eficaz en la red de datos.

• La presente funge como documento de aceptación por parte de DUPONT, S.A. DE C.V.

de que la implementación de la solución con el producto IBM Tivoli Netview, esta completa y cumple con los requerimientos en lo que se refiere a las funciones de monitoreo de dispositivos de red.

IBM Tivoli NetView


GLOSARIO

Bandwidth. Medida de la capacidad de un medio de comunicación para transmitir datos. Community name. Es un password que permite a SNMP accesar valores MIB en un agente. Daemon. Programa que se ejecuta de forma desatendida de un servicio standard. Evento. En el ambiente Tivoli es un cambio significativo en el estado de un recurso de sistema, recurso de red o aplicación de red. Un evento puede ser generado por un problema, por la resolución de un problema o por la terminación exitosa de una tarea. Hub. En una red es un punto donde circuitos son conectados o conmutados. Por ejemplo en una red de estrella, el hub es el nodo central. Java. Lenguaje de programación orientado a objetos de codigo portable que soporta la interacción con una gran cantidad de objetos remotos. LAN (Local Area Network) es una red de computadoras limitada a un área geográfica. Mapa. En Tivoli Netview, es una base de datos representada por un conjunto de submapas que proporcionan una presentación gráfica y jerarquica de una red y sus sistemas. MIB. Base de información de administración, es un conjunto de características de los dispositivos de la red que pueden ser consultadas por una estación de monitoreo SNMP. MIB tree. En SNMP es la estructura de la MIB. MIB variable. En SNMP es una instancia especifica de datos definida en un modulo MIB. Mid-Level Manager (MLM). En Tivoli Netview, es el componente que ejecuta ciertas tareas de administración de sistemas y redes como: polling, monitoreo de status y descubrimiento de nodos. Navigation tree. En Tivoli Netview, componente de la interfaz grafica de usuario que despliega una jerarquia de los submapas abiertos, ilustrando el parentesco de los submapas y su relación entre ellos. Network topology database. Es la representación de la actual conectividad de los nodos de la red. Object Identifier (OID). Un valor asignado administrativamente a un dato definido en notación de sintaxis abstracta 1 (ASN.1).

IBM Tivoli NetView


Polling. En administración de redes es el proceso mediante el cual se pregunta a uno o mas nodos manejados a intervalos regulares. Ruteador. Dispositivo conectado a dos o mas redes que se encarga del envio de información usando métricas para determinar la ruta optima, operan en la capa de red del modelo OSI( interconexión de sistemas abiertos )de vez en cuando denominado gateway. Seed File. En tivoli netview es un archivo que contiene una lista de nodos, el cual es usado en el proceso de descubrimiento de la red. Sheel script. En el sistema operativo unix, es una serie de comandos, combinados en un archive, que ejecutan una función particular cuando este archivo se corre o cuando se al archivo se le especifica como un valor del comando SH. SNMP. Protocolo para la administración simple de una red. Símbolo. En Tivoli Netview, es una imagen o un icono en un submapa que representa un objeto (una aplicación o un recurso de red). Cada símbolo pertenece a una clase, representado por la forma del símbolo y a una subclase, representada por el diseño de la figura. El símbolo refleja características del objeto al que representa. Submapa. Porción de una red, la cual comparte direcciones de red con otras porciones de red. Esta porción de red es donde se encuentra el servidor de Netview en el momento del descubrimiento de los elementos de la red. SWAP. Espacio en el disco duro usado como memoria virtual y es una extensión de la memoria real de la computadora Switch. Dispositivo que filtra y direcciona paquetes entre segmentos LAN. Los switches operan en la capa del enlace de datos del modelo OSI. TCP. Protocolo de control de la transmisión, es el protocolo de transporte en la suite de protocolos de internet. Threshold. En productos de software es un valor que define un limite para una condición monitoreada. La respuesta particular del producto cuando la condición monitoreada sobrepasa el umbral especificado. Trap. Mensaje enviado por un nod manejado (agente) a una estación de administración para reportar una condición. X-window. Interfaz grafica utilizada en el sistema operativo UNIX

IBM Tivoli NetView


Indice de Tablas Tabla A1. 1 Tabla de Dispositivos a monitorear ..................................................................... 72 Tabla A2. 1 Configuracion de poleo........................................................................................ 74 Indice de Figuras Fig. 1. 1 Topologia en bus....................................................................................................... 11 Fig. 1. 2 Topologia en Anillo.................................................................................................... 12 Fig. 1. 3 Topología en Estrella ................................................................................................ 12 Fig. 1. 4 Topología en Árbol .................................................................................................... 12 Fig. 1. 5 Topología en Malla.................................................................................................... 12 Fig. 2. 1 Capas del modelo TCP/IP......................................................................................... 14 Fig. 2. 2 Esquema de Comunicación 1 ................................................................................... 16 Fig. 2. 3 Esquema de Comunicación 2 ................................................................................... 17 Fig. 2. 4 Apertura pasiva y Activa............................................................................................ 18 Fig. 2. 5 Formato de Trama de TCP ....................................................................................... 18 Fig. 2. 6 Esquema de Conexión TCP de Tres Vías ................................................................ 20 Fig. 2. 7 Esquema de conexión TCP (Full-Dúplex)................................................................. 21 Fig. 4. 1 Network Management System .................................................................................. 32 Fig. 4. 2 Árbol de información para el objeto sysUptime......................................................... 37 Fig. 4. 3 Esquema del metodo de interrupción (obtención de información)............................ 40 Fig. 4. 4 Esquema del método de Interrupción (Modificación de la información) ................... 41 Fig. 4. 5 del método de Interrupción (Generación de interrupciones)..................................... 41 Fig. A1. 1 Diagrama de red actual (antes del monitoreo SNMP) ............................................ 71

Fig. A1. 2 Diagrama de la solucion de monitoreo ................................................................... 73

Fig. A1. 3 Status de elementos de la red ................................................................................ 73

Fig. A2. 1 Configuración SNMP en servidor de Netview......................................................... 76 Fig. A3. 1 Carga de MIBs de impresión en Netview ............................................................... 77 Fig. A3. 2 Ventana que muestra Status de impresora ............................................................ 77 Fig. A3. 3 Ventana que muestra configuración de impresora ................................................. 77 Fig. A3. 4 Ventana que muestra configuración de impresora ................................................. 78 Fig. A3. 5 Archivo snmpCol.conf ............................................................................................. 78 Fig. A4. 1 Browser de eventos ................................................................................................ 79 Fig. A4. 2 Configuración de eventos ....................................................................................... 79 Fig. A4. 3 Propiedades de los eventos 1 ................................................................................ 80

IBM Tivoli NetView


Fig. A4. 4 Propiedades de los eventos 2 ................................................................................ 80 Fig. A4. 5 Colecciones de datos.............................................................................................. 80 Fig. A4. 6 Propiedades para la colección de datos avgBusy5 ................................................ 81 Fig. A4. 7 Propiedades de las colecciones de datos .............................................................. 81 Fig. A4. 8 Propiedades de las colecciones 1 ......................................................................... 82 Fig. A4. 9 Propiedades de las colecciones 2 .......................................................................... 82 Fig. A4. 10 Expresiones para la memoria en switches ........................................................... 83 Fig. A4. 11 Propiedades de la colección de datos 1 ............................................................... 83 Fig. A4. 12 Propiedades de la colección de datos 2 ............................................................... 84 Fig. A4. 13 Propiedades de la colección de datos 1 ............................................................... 84 Fig. A4. 14 Configuración de parámetros para ifOutErrors..................................................... 85 Fig. A5. 1 Expresiones para la memoria en ruteadores.......................................................... 86 Fig. A5. 2 Propiedades de la colección de datos 1 ................................................................. 86 Fig. A5. 3 Propiedades de la colección de datos 2 ................................................................. 87 Fig. A5. 4 Collections donde se adhieren nuevas colecciones de datos ................................ 87 Fig. A5. 5 Propiedades de la colección de datos 1 ................................................................. 88 Fig. A5. 6 Configuración de parámetros para BandwidthUtilIn ............................................... 88 Fig. A5. 7 Ventana donde se muestra como se borra el mapa............................................... 89 Fig. A5. 8 Descubrimiento de la red........................................................................................ 89 Fig. A5. 9 de selección de Enterprise y traps.......................................................................... 90 Fig. A5. 10 Configuración de evento de Threshold................................................................. 90 Fig. A5. 11 Configuración de evento de threshold .................................................................. 91 Fig. A5. 12 Mensaje de ancho de banda con utilización arriba del 90%................................. 91 Fig. A5. 13 Mensaje de ancho de banda con utilización normalizada abajo de 75% ............. 91

IBM Tivoli NetView


Anexo 1 Diagramas de la solución del monitoreo

Red DupontSin monitoreo

HomeroHomeroHomero

Cisco 3745Cisco 3745Cisco 3745

IntranetIntranetIntranet

Switch CiscoSwitch CiscoSwitch Cisco

CorreoCorreoCorreo ProxyProxyProxyPC’s

ServidoresServidores

Cisco 1760Cisco 1760

Cisco CatalystCisco Catalyst

PC’s




PC’s




PC’s




PC’s




PC’s




PC’s




PC’s




PC’s

TelmexFrame Relay

TelmexFrame Relay

Sitio MtySitio Mty

Sitio TijuanaSitio Tijuana

Sitio LermaSitio Lerma

Sitio MatamorosSitio Matamoros

Sitio San MartinSitio San Martin

Sitio GdlSitio Gdl

Switch CiscoSwitch CiscoSwitch Cisco

Fig. A1. 1 Diagrama de red actual (antes del monitoreo SNMP)

IBM Tivoli NetView


Tabla A1. 1 Tabla de Dispositivos a monitorear

Hostname Dirección IP Dispositivo/Marca SNMP

mxsw6500_2.mx.dupont.com 52.44.8.2 Switch/Cisco Cmu$rw$01 mxsw48p002.mx.dupont.com 52.44.8.9 Switch/Cisco Cmu$rw$01 mxsw48apb.mx.dupont.com 52.44.8.30 Switch/Cisco Cmu$rw$01 mxsw48apa.mx.dupont.com 52.44.8.10 Switch/Cisco Cmu$rw$01 mxsw48p014.mx.dupont.com 52.44.8.11 Switch/Cisco Cmu$rw$01 mxsw48p007.mx.dupont.com 52.44.8.12 Switch/Cisco Cmu$rw$01 mxsw48p008.mx.dupont.com 52.44.8.13 Switch/Cisco Cmu$rw$01 mxsw48p009.mx.dupont.com 52.44.8.33 Switch/Cisco Cmu$rw$01 mxsw24p003.mx.dupont.com 52.44.8.14 Switch/Cisco Cmu$rw$01 mxsw24apb.mx.dupont.com 52.44.8.15 Switch/Cisco Cmu$rw$01 mxsw24p010.mx.dupont.com 52.44.8.16 Switch/Cisco Cmu$rw$01 lersw5500.lm.dupont.com 52.44.8.17 Switch/Cisco Cmu$rw$01 mxsw24p015.mx.dupont.com 52.44.8.18 Switch/Cisco Cmu$rw$01 lersw48cor.lm.dupont.com 52.44.8.19 Switch/Cisco Cmu$rw$01 mxsw6500.mx.dupont.com 52.44.8.20 Switch/Cisco Cmu$rw$01 lersw24cor.lm.dupont.com 52.44.8.40 Switch/Cisco Cmu$rw$01 lersw24ger.lm.dupont.com 52.44.8.21 Switch/Cisco Cmu$rw$01 tlasw5500.mx.dupont.com 52.44.8.23 Switch/Cisco Cmu$rw$01 tlasw48og1.mx.dupont.com 52.44.8.25 Switch/Cisco Cmu$rw$01 tlasw48ccd.mx.dupont.com 52.44.8.45 Switch/Cisco Cmu$rw$01 tlasw48og2.mx.dupont.com 52.44.8.41 Switch/Cisco Cmu$rw$01 tlasw48og3.mx.dupont.com 52.44.8.30 Switch/Cisco Cmu$rw$01 tlasw48mnt1.mx.dupont.com 52.44.8.11 Switch/Cisco Cmu$rw$01 tlasw48lab1.mx.dupont.com 52.44.93.100 Switch/Cisco Cmu$rw$01 tlasw48comp.mx.dupont.com 52.44.93.101 Switch/Cisco Cmu$rw$01 mxsw48p011.mx.dupont.com 52.44.93.102 Switch/Cisco Cmu$rw$01 mxcis1.mx.dupont.com 10.44.8.254 Ruteador/Cisco rwswzov alcis1.al.dupont.com 52.44.25.254 Ruteador/Cisco rwswzov tncis1.tn.dupont.com 52.44.34.254 Ruteador/Cisco rwswzov qucis1.qu.dupont.com 52.44.113.254 Ruteador/Cisco rwswzov smcis1.rm.dupont.com 52.44.80.254 Ruteador/Cisco rwswzov tdcis1.td.dupont.com 52.44.106.254 Ruteador/Cisco rwswzov tjcis1.tj.dupont.com 52.44.105.254 Ruteador/Cisco rwswzov lmcis1.lm.dupont.com 52.44.91.254 Ruteador/Cisco rwswzov bicis1.bi.dupont.com 52.44.39.254 Ruteador/Cisco rwswzov mxcis3.mx.dupont.com 52.44.7.200 Ruteador/Cisco Rwswzov gdwcis1.gd.dupont.com 52.44.107.254 Ruteador/Cisco Rwswzov mtcis1.mt.dupont.com 52.44.51.254 Ruteador/Cisco Rwswzov

IBM Tivoli NetView


Fig. A1. 2 Diagrama de la solución de monitoreo

Fig. A1. 3 Status de elementos de la red

IBM Tivoli NetView


Anexo 2 Configuración SNMP en ruteadores y poleo

Configuración SNMP en Tivoli Netview

Tabla A2. 1 Configuración de poleo

Campo de poleo Tiempo Descripción Poll all nodes 3 m Es el tiempo en segundos, minutos, días o semanas

indicando el intervalo en que netmon utiliza un ping para comprobar el estado de un nodo.

Node Down Delete Interval 1w Es el tiempo en segundos, minutos, horas, días o semanas. Para borrar los nodos que no respondan el Status Poling.

Poll to discover new nodes 15m Es el tiempo en segundos, minutos, horas, días o semanas. Especificando el tiempo en que se hace un poleo para verificar la existencia de nuevos nodos con agente SNMP.

Poll for node configuration 1d Es el tiempo en segundos, minutos, horas, días o semanas. Especificando el tiempo en que se hace un poleo para verificar si ha cambiado la configuración en el agente SNMP de los nodos que lo contienen.

Configuración SNMP en ruteadores y switches

IBM Tivoli NetView


IBM Tivoli NetView


Fig. A2. 1 Configuración SNMP en servidor de Netview

IBM Tivoli NetView


Anexo 3 Figuras de las metricas para impresión

Fig. A3. 1 Carga de MIBs de impresión en Netview

Fig. A3. 2 Ventana que muestra Status de impresora

Fig. A3. 3 Ventana que muestra configuración de impresora

IBM Tivoli NetView


Fig. A3. 4 Ventana que muestra configuración de impresora

Fig. A3. 5 Archivo snmpCol.conf

IBM Tivoli NetView


Anexo 4 Figuras para los procedimientos LAN Cisco Procedimiento disponibilidad de interfaces

Fig. A4. 1 Browser de eventos

Fig. A4. 2 Configuración de eventos

IBM Tivoli NetView


Fig. A4. 3 Propiedades de los eventos 1

Fig. A4. 4 Propiedades de los eventos 2 Procedimiento para el monitoreo de utilización CPU en switches

Fig. A4. 5 Colecciones de datos

IBM Tivoli NetView


Fig. A4. 6 Propiedades para la colección de datos avgBusy5

Fig. A4. 7 Propiedades de las colecciones de datos

IBM Tivoli NetView


Fig. A4. 8 Propiedades de las colecciones 1

Fig. A4. 9 Propiedades de las colecciones 2

IBM Tivoli NetView


Procedimiento para la utilización de memoria en switches

Fig. A4. 10 Expresiones para la memoria en switches

Fig. A4. 11 Propiedades de la colección de datos 1

IBM Tivoli NetView



Procedimiento para errores en interfaces de Switches


IBM Tivoli NetView


Fig. A4. 14 Configuración de parámetros para ifOutErrors.

IBM Tivoli NetView


Anexo 5 Figuras para los procedimientos WAN Cisco Procedimiento para uso de memoria en ruteadores

Fig. A5. 1 Expresiones para la memoria en ruteadores


IBM Tivoli NetView


Fig. A5. 3 Propiedades de la colección de datos 2 Procedimiento para utilización de ancho de banda en ruteadores

Fig. A5. 4 Collections donde se adhieren nuevas colecciones de datos

IBM Tivoli NetView



Fig. A5. 6 Configuración de parámetros para BandwidthUtilIn

IBM Tivoli NetView


Procedimiento para la personalización de mapas

Fig. A5. 7 Ventana donde se muestra como se borra el mapa

Fig. A5. 8 Descubrimiento de la red

IBM Tivoli NetView


Procedimiento para la configuración de los eventos

Fig. A5. 9 de selección de Enterprise y traps

Fig. A5. 10 Configuración de evento de Threshold

IBM Tivoli NetView


Fig. A5. 11 Configuración de evento de threshold

Fig. A5. 12 Mensaje de ancho de banda con utilización arriba del 90%

Fig. A5. 13 Mensaje de ancho de banda con utilización normalizada abajo de 75%

IBM Tivoli NetView


BIBLIOGRAFÍA

"Comunicaciones y Redes de Computadores". W. Stallings Ed. MacMillan 6ta edicion. “Redes de Computadoras” Andrew S. Tanenbaum Ed. Pearson Education 4ta. Edicion "Telecommunications Switching, Traffic and Networks". E. Flood, Ed. Prentice-Hall 1ª Edicion SNMP, SNMPv2 and CMIP: The Practical Guide to Network Management Standards. W. Stallings Ed. McGraw-HillMcGraw-Hill 6ta Edicion PÁGINAS DE APOYO http://www.monografias.com/ http://es.wikipedia.org/wiki/Simple_Network_Management_Protocol http://es.wikipedia.org/wiki/Router http://es.wikipedia.org/wiki/Switch http://www.conmutadores.net/

Portada de la Tesis1 CORREGIDA

Documents

Transcript of Portada de la Tesis1 CORREGIDA