Bogotá D.C. Febrero 24 de 2003 Señora Maria Teresa Torres
77
Bogotá D.C. Febrero 24 de 2003 Señora Maria Teresa Torres Coordinadora de Pregrado Departamento de Ingeniería Eléctrica y Electrónica UNIVERSIDAD DE LOS ANDES L.C. Cordial saludo, Con el objeto de cumplir con los requisitos exigidos por la Universidad y el Departamento de Ingeniería Eléctrica y Electrónica para optar el titulo de Ingeniero Eléctrico hago entrega de mi tesis titulada “ METODOLOGIA PARA LA CONSTRUCCION DE UNA SIMULACION EN UNA RED DE DATOS UNIVERSITARIA “ Cordialmente GALVARINO CAMILO GALVIS FAJARDO C.C. 79.801.072 de Bogotá.
Transcript of Bogotá D.C. Febrero 24 de 2003 Señora Maria Teresa Torres
Bogotá D.C. Febrero 24 de 2003
SeñoraMaria Teresa TorresCoordinadora de PregradoDepartamento de Ingeniería Eléctrica y ElectrónicaUNIVERSIDAD DE LOS ANDESL.C.
Cordial saludo,
Con el objeto de cumplir con los requisitos exigidos por la Universidad y elDepartamento de Ingeniería Eléctrica y Electrónica para optar el titulo deIngeniero Eléctrico hago entrega de mi tesis titulada “ METODOLOGIA PARALA CONSTRUCCION DE UNA SIMULACION EN UNA RED DE DATOSUNIVERSITARIA “
Cordialmente
GALVARINO CAMILO GALVIS FAJARDOC.C. 79.801.072 de Bogotá.
METODOLOGIA PARA LA CONSTRUCCION DE UNASIMULACION EN UNA RED DE DATOS UNIVERSITARIA
“TESIS DE GRADO”
GALVARINO CAMILO GALVIS FAJARDO
Asesor:Ing. Néstor Peña, PHD.
Ing. Rodrigo Ferrer.
UNIVERSIDAD DE LOS ANDESFACULTAD DE INGENIERIA
DEPARTAMENTO DE INGENIERIA ELECTRICA Y ELECTRÓNICA
Bogotá D.C. Mayo de 2002.
TABLA DE CONTENIDO
Pag.
1. INTRODUCCIÓN 1
1.1 Objetivos 1
1.1.1 Generales 1
1.1.2 Específicos 1
1.2 Motivación 2
1.3 Alcance 3
2. JUSTIFICACIÓN 4
3. METODOLOGÍA 5
3.1 Indagar quien tiene la información. 5
3.1.1 Función sobre la red. 6
3.2 Documentar la información según cada elemento de red. 7
3.2.1 Servidores y aplicaciones 7
3.2.1.1 Servidores 7
3.2.1.2 Disco Duro 8
3.2.1.3 Aplicaciones 9
3.2.2 Switches, hub, enrutadores 13
3.2.3 Tipo de enlaces 15
3.3 Realizar un esquema general de la red. 17
3.4 Llevar los parámetros sobre COMNET III 18
3.4.1 Construcción de una distribución 19
3.4.1.1 Parametrizada 19
3.4.1.2 Tabulada 21
3.4.2 Construcción de comandos 24
3.4.2.1 Globales 24
3.4.2.2 Locales 28
3.4.3 Generadores de tráfico 31
3.4.3.1 Fuente de mensaje. 32
3.4.3.2 Fuente de respuesta de mensajes. 35
3.4.3.2 Fuente de sesión 38
3.4.3.3 Fuente de aplicación. 40
3.4.4 Según tipo de nodo 43
3.4.4.1 Nodos de proceso 43
3.4.4.2 Dispositivos de red 47
3.4.4.3 Grupo de computadores 49
3.4.5 Según tipo de enlace 51
3.4.5.1 Enlace Ethernet CSMA/CD 51
3.4.6 Parámetros de simulación 54
4. PRUEBAS 57
4.1 Metas técnicas a considerar 57
4.2 Problema 57
4.3 Aplicar la Metodología 57
4.4 Resultados para la sala tybaxa con 15 pc´s. 64
4.4.1 Utilización 64
4.4.2. Retardos 65
4.4.3. Conteo de mensajes por fuente 67
4.4.4. KBPS (kilo bytes por segundo) 68
4.4.5. PPS (paquetes por segundo ) 69
5. CONCLUSIONES 70
BIBLIOGRAFÍA 71
ANEXOS 72
TABLAS PAG
TABLA 1 : Personal encargado de la red de la Facultad de Ingeniería. 5
TABLA 1_1 : Funciones sobre la red. 6
TABLA 2: Servidores. 7
TABLA 3 Disco Duro. 8
TABLA 4: Clasificación de las aplicaciones de la red universitaria. 9
TABLA 5: Ubicación de las aplicaciones. 11
TABLA 6_1 Ubicación de los dispositivos de Red. (ALA NORTE) 13
TABLA 6_2: Ubicación de los dispositivos de Red. (ALA SUR) 14
TABLA 7: Parámetros de utilización en un switch. 16
TABLA 8: Tipos de enlaces utilizados en la red universitaria. 16
TABLA 9 Tráfico de Internet de la Sala TybaXA. 22
TABLA 10 Generación de trafico. 60
TABLA 11 Fuente de mensajes. 61
TABLA 12 Fuente de respuesta. 62
TABLA 13 Duración en tiempo real para simulaciones (1 sala) 62
TABLA 14 Duración en tiempo real para simulaciones (15 salas) 63
TABLA 15 Resultados de la utilización del enlace. 64
TABLA 16 Resultados de retardo promedio de mensajes. 65
TABLA 17 Resultados de retardo máximo de mensajes. 65
TABLA 18 Resultados de retardo promedio de paquetes. 66
TABLA 19 Resultados de retardo máximo de paquetes. 66
TABLA 20 Resultados de conteo de mensajes. 67
TABLA 21 Resultados de KBPS. 68
TABLA 22 Resultados de PPS. 69
GRAFICAS PAG
GRAFICA 1 Esquema general de red. (Facultad de Ingeniería) 17
GRAFICA 2 Esquema general de red. (Sala TybaXA) 59
GRAFICA 3 Esquema en COMNET III. (Sala TybaXA) 62
GRAFICA 4 Utilización del enlace. 65
GRAFICA 5 Retardo promedio de paquetes. 66
GRAFICA 6 Conteo de mensajes. 67
GRAFICA 7 KBPS. 68
GRAFICA 8 PPS. 69
1
1. INTRODUCCION
1.1 OBJETIVOS
1.1.1 Generales
1. Desarrollar una METODOLOGIA para la construcción de SIMULACIONES
de redes de datos universitarias en la herramienta disponible COMNET III.
2. Permitir que la METODOLOGÍA propuesta sea implementada en el diseño
de futuras redes, que tengan cierta similitud de parámetros con los
descritos en este proyecto.
3. Realizar un tipo de pautas para la caracterización de redes existentes que
permitan visualizar su comportamiento y examinar sus metas técnicas.
1.1.2 Específicos
1. Lograr obtener la información indicada, precisa y necesaria, que
permita ser introducida en la herramienta, para desarrollar una buena
simulación.
2. Lograr obtener los resultado específicos respecto a las metas técnicas que
se consideren trascendentales para las redes de datos universitarias.
3. Presentar un informe practico, claro y preciso sobre como seguir la
METODOLOGÍA propuesta, para que este disponible en el diseño y
simulación de futuras redes.
4. Implementar esta metodología en la red de la facultad de ingeniería para
observar los resultados de comportamiento y metas técnicas específicas.
2
1.2 MOTIVACIÓN
La simulación de redes universitarias carecen de ayudas metodológicas practicas
que permitan al estudiante afrontar el reto de implementar una red en COMNET.
Antes de tomar la determinación de realizar un proyecto de este tipo, debemos de
implementar una ayuda que permita facilitar la forma de cómo afrontamos un
problema de simulación de redes universitarias.
Por lo tanto decidí diseñar esta ayuda metodológica, para que la caracterización y
simulación de redes futuras, se pueda implementar para investigaciones posteriores.
3
1.3 ALCANCE
Desarrollar una metodología en COMNET III que permita ser implementada en el
diseño de futuras redes, que tengan cierta similitud de parámetros con los descritos
en el proyecto.
Presentar a los administradores de la red recomendaciones que puedan ser usadas
en la operación y dimensionamiento de este tipo de redes.
Monitorear usuarios específicos para caracterizar en términos estadísticos el tráfico
generado por éstos, con el fin de encontrar patrones que simplifiquen simulación de
la red.
Simular y caracterizar una red que cumpla con las especificaciones encontradas.
Realizar un análisis de sensibilidad a los parámetros utilizados, con sus respectivas
metas técnicas.
4
2. JUSTIFICACIÓN
1. Se quiere especificar una serie de pautas y pasos secuénciales para la
construcción de simulaciones, lo cual en lo consecuente llamaré
METODOLOGÍA.
2. Se realizo este proyecto, para indicar a estudiantes de redes, profesores,
ingenieros y demás personas interesadas en construir y desarrollar
simulaciones como deben interactuar con estas y como lograr obtener los
resultados específicos de metas técnicas que se ellos requieran.
5
3. METODOLOGÍA
3.1 INDAGAR QUIEN TIENE LA INFORMACIÓN.
Se debe ubicar el departamento, área o oficina indicada, que tenga a cargo laadministración de la red de datos. Consecuentemente debe completarse la siguientetabla con la información necesaria para cumplir el fin. La Tabla No. 1 nos muestra elpersonal encargado de la red de la Facultad de Ingeniería.
NOMBRE Teléfono E-mail
HorariodeAtención Cargo DPTO.
Funciones quetiene sobre laRED.
PedroFlorez Ext. 2973 peflorez@unian...
2:00 pm a6:00 pm
IngenieroAdminis. deRed DTI
Encargado deadministración dela red de datos dela Universidad delos Andes
Frey Leon Ext. 2979 [email protected]:00 a6:00 pm
IngenieroSoporte DTI
Ingeniero desoporte de la red
WilliamSanchez Ext. 2967 wisanche@unian...
2:00 a6:00 pm
Administradorde Red DTI Dirección
HernandoBarragan Ext. 2814 [email protected]...
8:00 am a6:00 pm Director MOX MOX Dirección
JuanDiegoJiménez Ext. 3893 jujimene@unian...
10:00 ama 12:00pm
Administradorde Sistemas Sistemas
Encargado de laadministración deservidores enSistemas
Luis Diaz Ext. 2928 [email protected]:00 am a6:00 pm
Ingeniero deSoporte MOX
Encargado de laadministración deservidores enIngenieria
Olga Roa Ext. 2919 [email protected]:00 am a3:00 pm
Ingeniero deSoporte MOX
Encargado de laadministración deservidores
TABLA No. 1
Luego de ingresar la información anterior se deben definir las funciones de todos losdepartamentos, áreas y oficinas que están involucradas en la administración de lared. Se debe llenar la siguiente tabla. En la Tabla A nos muestra un ejemplo de losdos departamentos encargados de la administración de la red.
6
3.1.1 FUNCION SOBRE LA RED.
Departamento: Debe tener el nombre del departamento, áreas y oficinas.
Función sobre la red: Es la actividad en la cual se vincula con la red, se debe incluir los servidores principales.
DPTO. Funcion sobre la RED
DTIAdministrador general de la red de datos de la Universidad delos Andes
Manejo de la infraestructura de RED (switches, cableado, RAGs,PATCH, etc)
Manejo de Servidor de Correo interno (LEELA), servidores debases de datos (SICUA)
MOX Administrador de Servidores de Ingenieria y salas de computoGestion de Aplicaciones. (MATLAB, ANSYS, ABAQUS,AUTOCAD, etc)
TABLA 1_1
7
3.2 DOCUMENTAR LA INFORMACIÓN SEGÚN CADA ELEMENTO DE RED.
3.2.1 SERVIDORES Y APLICACIONES
3.2.1.1 SERVIDORES
CANT. CAP. MEMORIA PLATA - NOMBRE REFERENCIA PROC. D.D. (GB) RAM (MB) UBICACION FORMA USUARIOS
SIE Origin 2000 SGI 2100 4 54 1024 CATALYST 2924 ORIX 550BOSA - TYR Digital Alpha Server 4/275 2 36 512 CATALYST 2924 OSF1 250MICA - THOR CLON Pentium 266 Mhz 1 8 256 PISO 6N OSF1 TODOS
UQUE CLON Pentium 266 Mhz 1 40 256 PISO 6N LINUX 150COLUMBUS CLON Pentium 400 Mhz 1 40 256 PISO 6Na LINUX 330TITAN SUN ENTERPRISE 250 2 9 256 SALAxc UNIX 20
SERTYBA1 DELL Pentium III-866Mhz 1 20 256 Piso 6NWin2000Profesional 360
SERTYBA2 DELL Pentium III-866Mhz 1 20 256 PISO 6NaWin2000Profesional 360
SERVFAGUA DELLPentium IV -1,7 Ghz 1 40 256 CATALYST 2924Win2000Profesional TODOS
SERVFAGUA2 DELL Pentium III-866Mhz 1 20 256 CATALYST 2924Win2000Profesional TODOS
SERTYBAXA DELLPentium IV -1,7 Ghz 40 256 SALAxcWin2000Profesional TODOS
SERTYMNE Premio Pent. MMx 166 Mhz 1 6 64 TymneWinNT 4,0Server TODOS
KETRA CLON Pentium 400 Mhz 1 6 64 MiniMOX LINUX 600SAUCE CLON Pent. dual 200 Mhz 1 6 128 MiniMOX LINUX 600ODIN CLON Pentium 400 Mhz 1 8 256 MiniMOX LINUX 600AGAMENON CLON Pent. dual 200 Mhz 1 8 256 MiniMOX LINUX 600XUE XEON Pentium III 2 40 1024 MiniMOX LINUX 600KEOPS DELL Pentium III-866Mhz 1 20 256 MiniMOX LINUX 600
TABLA 2La Tabla 2 que mostramos en la pagina anterior, describe las características
generales de los servidores conectados en la facultad de ingeniería. También se
utilizan siglas como pent. (pentium), todos (todos los estudiantes de la facultad de
ingeniería).
Nombre: Es el nombre que oficialmente tiene cada servidor.
8
Referencia: Es la característica general del modelo del servidor, generalmente
como es llamado por la compañía que lo creo. Si es un servidor
CLON colocar la especificación del procesador o el mayor que
tenga.
Cant. proc.: Numero de procesadores que tiene cada servidor. (cantidad de
procesadores).
Cap. D.D. Es la capacidad total que tiene el servidor. Es la sumatoria de
todas las capacidades de los Discos duros que posea el servidor.
Memoria RAM: Cantidad de memoria RAM que posea el servidor.
Ubicación: Según la estructura organizacional de la red debe tener un
dispositivo en el cual esta conectado directamente el servidor.
Plataforma: Plataforma en la cual opera el servidor.
Usuarios: Cantidad de usuarios los cuales acceden al servidor.
3.2.1.2 DISCO DURO
Se recomienda se realizar una búsqueda VIA WEB de la marca y referencia dadas
por el administrador de red, o encontrar un Disco Duro de las mismas características,
los parámetros de desempeño de un fabricante a otro no varían en gran magnitud.
VEL. DE CANT.CAP.TOT. MARCA REFERENCIA
TAM.SEC Xfer SEEK
NOM PROC. D.D. ( (MB) FABRICANTE INTERFACE (KB) (mic) (mic)
SIE 4 / 250 MHZ 3 54000 SEAGATE CHEETAH 36 ESSCSI ULTRA160 10500 7500 5200
XUE 2 / 700 MHZ 2 40000 SEAGATE CHEETAH 1K.6SCSI ULTRA320 10500 6800 4700
TABLA 3
NOM: Nombre del servidor.
VEL. DE PROC.: Es el número de procesadores que tiene el servidor y la velocidad
de los procesadores, generalmente tienen la misma velocidad.
CANT. D.D.: Cantidad de Discos Duros que posee el servidor.
9
MARCA: Es la marca de los discos duros, si posee diferentes marcas
escoger una marca común y reconocida.
REFERENCIA
FABRICANTE: Escribir la referencia que el fabricante le da este dispositivo, nos
sirve para diferenciarlo de otras marcas.
INTERFACE: Tipo de Disco Duro, y el modelo que opera este dispositivo.
TAM SEC.: El tamaño de los sectores (KiloBytes).
Xfer.: Rata de transferencia (microsegundos)
SEEK: Rata de tiempo en la cual se accede a un sector determinado.
(microsegundos)
3.2.1.3 APLICACIONES
La identificación de las aplicaciones de su cliente debe incluir tanto las aplicaciones
actuales y las nuevas aplicaciones. Debe Realizar una un listado de las aplicaciones
existentes; para ello podemos realizar la Siguiente Tabla:
Nombre de la Tipo de Es un nueva Aplicación Aplicación Aplicación (S/N) Comentarios
TABLA 4
Nombre de
Aplicación: Simplemente use un nombre que el Administrador de Red le da.
Esto pueda ser un nombre estándar, o un nombre que significa
algo, (sobre todo para un aplicación realizada al interior de la
facultad). Para las nuevas aplicaciones, el nombre podría ser un
nombre del código para un software en desarrollo.
Tipo de Aplicación: Se puede clasificar las aplicaciones de la siguiente manera:
10
Correo electrónico(Electronic mail) Transferencia de Archivos (File transfer)
Archivos de acceso compartido (File sharing/access),
Base de datos acceso/actualización, Groupware,
Desktop publishing, Web browsing,
juegos (Network game), Emulación de terminal
Diseminación informática (Push-based information dissemination),
Whiteboard electrónica, Terminal remota,
Calendario, Directorio en linea,
Medical imaging, Videoconferencia,
Aprendizaje a Distancia, Voz en una Intranet o en Internet,
Fax sobre la Intranet o Internet, Puntos de venta,
Ordenes de Venta, Comercio electrónico,
Reportes administrativos, modelos financieros,
rastreo de ventas, Recursos humanos,
Diseños asistidos por computador, Manufactura asistida por computador, control de
inventarios y envíos, control de procesos, Telemetría.
Otras:
Autenticación y autorización del usuario, Nombramiento del Host, Remote booting,
Configuración remota de descarga, Servicios de directorio, backup, distribución de
software y gerencia de red.
Comentarios: Agregue cualquier observación pertinente al diseño Por ejemplo,
incluya cualquier información que usted tiene sobre las
direcciones corporativas, como planes para dejar de usar una
aplicación en el futuro, o el desenvolvimiento específico.
A continuación se relaciona las aplicaciones con su respectivo servidor, y el número
de usuarios que acceden a esa aplicación. Si la comunidad es difícil de cuantificar,
11
se debe preguntar que cursos y numero de estudiantes podrían aplicar y ver en que
horarios acceden a la aplicación. Así nos damos cuenta de un ponderado o
aproximado de esta comunidad de usuarios.
Cabe anotar que las aplicaciones que describimos en la Tabla 5 de ejemplo son para
aplicación en RED, es decir no cuentan las que estén instaladas en forma individual
para cada punto de red.
APLICACIONES DE LA FACULTAD DE INGENIERIAUNIVERSIDAD DE LOS ANDES
NOMBRE DE Número deCODIGO LA APLICACIÓN NOMBRE DEL SERVIDOR Usuarios
Apli_1
Bentley EducationNetwork (Micro Station Jy MicroStation Modeler) SERTTYBA 620
Aplic_2 Autodesk AutoCAD 2002 SERVFAGUA2 550Apli_3 MatLab 6.1 SERTYBAXA 550
Aplic_4Autodesk MechanicalDesktop 3 SERTYBA1 340
Apli_5Autodesk LandDevelopment SERTYBA2 340
Aplic_6Autodesk ArchitecturalDesktop 3,3 Esp SERVFAGUA 280
Aplic_7 SAP2000 SERVFAGUA 180Apli_8 3DStudio VIZ - Autodesk SERVFAGUA 120Aplic_9 Autocad 13 SERTYMNE 50Aplic_10 Plaxis SERTYBA1 30Aplic_11 http XUE 350Aplic_12 MatLab SIE 550Aplic_13 ANSYS SIE 550Aplic_14 DIRECT SIE 120Aplic_15 ABAQUS SIE 150Aplic_16 COMNET BOSA - TYR 250Aplic_17 GAMS BOSA - TYR 180
TABLA 5
Codigo : Es un numero o referencia que podemos dar para identificarla
durante la simulación.
Nombre de la
12
Aplicación: Como se describió anteriormente es el nombre que tiene la
aplicación o el que le coloco el administrador de la misma o de la
RED.
Nombre del
Servidor: Es el nombre del servidor donde se encuentra instalada la aplicación.
Número de
Usuarios: Es la cantidad de usuarios que acceden a la aplicación, es
llamada también comunidad de usuarios.
13
3.2.2 SWITCHES, HUB, ENRUTADORES
Se debe realizar un recorrido por toda la facultad para describir la red física y su
respectiva ubicación que más adelante se colocará en un plano de red.
La facultad de Ingeniería de la Universidad de los Andes esta dividida en dos áreas
principales: Ala Norte (tabla 6_1) y Ala Sur(tabla 6_2) , las cuales se describen a
continuación.
ALA NORTE
DISPOS. OTRO_dis Modelo según marca En func. Dispon. Sin CONXFacultad de Catalyst 2948 G L3 48 port 28 0 20
Ingeniería Catalyst 2924 M-Xl 24 0 0Piso 6N catalyst 2900 XL 19 5 0Piso 6Na catalyst 2900 XL 12 4 8Piso 5N HUB 1 4 19Piso 4N catalyst 2950 16 7 1--------- Hub_4N Super Stack II PS hub 40 / 24port 6 0 18Piso 3N catalyst 2900 XL 16 8 0--------- Hub_3N Super Stack II PS hub 40 / 24port 11 7 6Piso 2N catalyst 2900 XL 24--------- Hub_2N Link Builder FMS II 24port 5 7 12Salaxa catalyst 2900 XL 23 1 0Salaxb catalyst 2900 XL 13 1 10Salaxc catalyst 2900 XL 4 7 12Salaxd catalyst 2900 XL 2 7 15Piso 1n catalyst 2900 XL 12 2 10Sala Inst catalyst 2900 XL 11 0 13Sala intel A catalyst 2900 XL 23 1 0--------- Hub_Intel A Super Stack II PS hub 40 / 24port 15 9 0Sala Intel B catalyst 2900 XL 20 4 0
Sub Totales 258 39 72TABLA 6_1
ALA SUR
14
DISPOS. OTRO_dis Modelo según marca En func. Dispon. Sin CONX
Inprise A catalyst 2950 21 3 0Inprise catalyst 2900 XL 19 3 2Lotus A catalyst 2900 XL 19 5 0Lotus catalyst 2900 XL 21 1 2Piso 5S catalyst 2900 XL 12 11 1--------- Hub_5S Link Builder FMS II 24port 6 3 15Piso 4S catalyst 2950 15 8 1--------- Hub_4S Super Stack II PS hub 40 / 12port 4 2 6Piso 3S catalyst 2900 XL 19 5 0--------- Hub_3S Super Stack II PS hub 40 / 24port 9 1 14Piso 2S catalyst 2950 12 12 0--------- Hub_2S Super Stack II PS hub 40 / 24port 6 2 16Tyba catalyst 2900 XL 22 2 0--------- Hub_tyba Super Stack II hub 10 / 24port 14 5 5Fagua catalyst 2900 XL 21 3 0Fagua A catalyst 2950 23 1 0FaguaB catalyst 2950 21 1 2Tymna catalyst 2900 XL 11 7 6--------- Hub_tymne Super Stack II hub 10 / 24port 23 0 1Uena catalyst 2900 XL 16 8 0--------- Super Stack II PS hub 40 / 12port 7 5 0MiniMOX catalyst 2900 XL 13 11 0 Hub_minimox Super Stack II PS hub 40 / 24port 5 5 14
Sub Totales 339 104 85
TABLA 6_2
Resumen de tablas 6_1 y 6_2
Puertos en funcionamiento: 597
Puertos Disponibles: 143
Puertos sin conexión: 157
DISPOS.: Nombre del dispositivo que tiene en el plano de RED, este
nombre debe conservarse para que al realizar la simulación no se
15
tengan consecuencias de desorganización y fácil comprensión
de los resultados para terceros.
OTRO_dis: Es otro dispositivo conectado al dispositivo principal de ese nivel,
generalmente es un HUB, o switches menores.
Modelo según
marca: Es la referencia del dispositivo es necesario describir al detalle el
modelo para que al realizar la simulación se facilite la
diferenciación de cada dispositivo.
En func.: En FUNCIONAMIENTO, significa que son todos los puertos que
están conectados a algún elemento o dispositivos (computadores,
servidores, hub, switches etc). Se diferencian porque tienen luz
verde.
Dispon: DISPONIBLES, son los puertos disponibles que están cableados
pero NO tienen ningún elemento o dispositivo conectado.
Sin conex.: SIN CONEXIÓN, son puertos que no están cableados.
Para el trabajo de la simulación es importante saber que puertos están en
funcionamiento ya que estos se van a reflejar directamente en nuestro objetivo. Sin
embargo los disponibles son prioritarios porque pueden entrar en funcionamiento en
cualquier momento, se deben tener en cuenta para la simulación ya que es el
crecimiento inmediato de la red.
16
PARAMETRO A UTILIZAR EN UN SWITCH
Recomienda se realizar una búsqueda VIA WEB por marca y modelo para encontrar
el BLACKPLANE del dispositivo (switching fabric). Esta variable se aplica
directamente en la herramienta de simulación ya que si esta no tiene caracterizado el
dispositivo es sus librerías hay que crearlo, y su característica principal es el switching
fabric).
MODELO BLACKPLANE Mbpscatalyst 2900 XL 3200catalyst 2950 8800Catalyst 2948 G L3 /48 port 24000
TABLA 7
3.2.3 TIPO DE ENLACES
Se requiere documentar que tipo de enlace se esta utilizando. Al observar el plano de
red se debe especificar el enlace, tipo de cable y si es full duplex.
TIPO DEL TIPO DE Es Full
ENLACE CABLE duplex
CSMA/CD 100base T SiCSMA/CD Ethernet Gigabit Si
TABLA 8
17
3.3 REALIZAR UN ESQUEMA GENERAL DE LA RED.
Los administradores de la red de la facultad de ingeniería, facilitaron este mapa o
esquema general, sin embargo fue necesario realizarle actualizaciones como
veremos más adelante en este trabajo.
GRAFICA 1
Podemos observar que la topología de red de la facultad de ingeniería es en
ESTRELLA, la cual esta centralizada en un switch de nivel 3 llamado CATALYST
2948-L3 este nombre se refiere al modelo y referencia de este dispositivo, sin
18
embargo seguiremos conservando el nombre que se le ha dado por los
administradores para este trabajo.
Aquí también podemos apreciar como esta dividida la facultad de ingeniería, Ala
Norte parte izquierda del esquema y Ala Sur parte Derecha del esquema.
Este esquema nos enumera la cantidad de PS´s que están conectados a cada
dispositivos (switch o hub) , esto nos ayudara mas adelante en las pruebas de
simulación.
Sin embargo este esquema de red debe ser corroborado y actualizado, lo cual es
necesario realizar un recorrido palmo a palmo por la facultad, se recomienda que
durante el recorrido no solo se actualice el esquema sino también realizar las tablas
6_1 y 6_2, realizando la ubicación física de los servidores conectados a la red(tabla
2).
3.4 LLEVAR LOS PARAMETROS SOBRE COMNET III
A continuación describiremos como los parámetros recolectados anteriormente se
introducen en herramienta de simulación, que para nuestro caso es COMNET III .
El tema describe, como se de cómo se construye una distribución, como podemos
construir comandos globales y locales, generadores de trafico (fuentes de mensaje,
fuente de sesión, fuentes de aplicación y fuentes de respuesta), construcción de
dispositivos según el tipo de nodo (switches, servidores, grupos de computadores) y
por ultimo construir según tipo de enlace.
19
3.4.1 CONSTRUCCION DE UNA DISTRIBUCION
3.4.1.1 Parametrizada
Una distribución parametrizada, es aquella distribución que se encuentra en los
estándares de la librería de la herramienta de simulación.
Entre las que podemos encontrar.
Beta, erlang, exponencial, fractal, gamma, geométrica, hiperexponencial, entera,
limitada, escalamiento lineal, logarítmica normal, combinación de dos distribuciones,
normal, pareto, poisson, triangular, uniforme y weibull.
La finalidad de este trabajo no es explicar cada una ya que las podemos encontrar en
el manual de la herramienta de simulación, sin embargo para tratar el tema se
escogió la DISTRIBUCIÓN EXPONENCIAL, la cual mostraremos a continuación:
Para construir una distribución parametrizada se deben realizar los siguientes pasos:
1. Al ubicarnos en el menú DEFINE / USER DISTRIBUTIONS, encontramos la
pantalla que se muestra, lo cual procedemos a presionar Add.
20
2. Luego procedemos a darle un nombre, se recomienda utilizar nombre que se
relacionen con dicha distribución. Posteriormente al escoger sample only , la
herramienta nos da todas las distribución que hay en el estándar más todas las
nuevas que creamos. Podemos apreciar que se escogió una distribución exponencial
con media (1) y un stream de (50), este ultimo es un número aleatorio para que la
herramienta comience a suministrar la muestra.
También podemos colocar una Expression , que puede ser alguna distribución
combinada.
3. Por ultimo utilizamos la opción view, para observar la gráfica de probabilidad de la
distribución que hemos creado (rojo). La herramienta nos muestra no solo la curva de
probabilidad sino también la gráfica de probabilidad acumulada(azul).
21
3.4.1.2 Tabulada.
Construir este tipo de distribuciones se realiza cuando tenemos una muestra de
trafico particular la cual no se puede simular con una distribución estándar
procedemos a construirla punto a punto.
Se tomo una muestra de tráfico en la sala de pc´s de eléctrica (TybaXA), durante 24
horas la cual nos dio como resultado la siguiente información:
El tamaño de mensaje, es el tamaño de del mensaje en el cual el protocolo de la
aplicación para navegar en Internet. Esta información se logro gracias a una
analizador protocolar colocado en un equipo de la sala TybaXA.
Después de recoger esta información se procede a organizarla, los tamaños de
mensajes se colocan de menor a mayor y su respectiva probabilidad de ocurrencia se
construye la probabilidad acumulada.
22
Tamaño Probabilidad Tamaño Probabilidad
de mensaje acumulada de mensaje acumulada1295 0,03 30420 0,5
2154 0,06 36514 0,52
6618 0,1 39625 0,55
8673 0,12 41829 0,69
9975 0,15 62230 0,72
14494 0,2 69609 0,74
14857 0,22 72317 0,76
16650 0,24 96015 0,78
17040 0,28 127800 0,79
17053 0,29 134370 0,82
18197 0,32 136681 0,84
21797 0,35 136681 0,86
25875 0,37 136681 0,94
28188 0,41 149812 0,96
30167 0,44 296816 0,98
30365 0,46 526065 1
TABLA 9
Luego de obtener esta información procedemos a realizar los siguientes pasos:
1. Al ubicarnos en el menú DEFINE / TABULAR DISTRIBUTIONS, encontramos la
pantalla que se muestra, lo cual procedemos a presionar Add.
23
2. Luego procedemos a darle un nombre, se recomienda utilizar nombre que se
relacionen con dicha distribución.
Para nuestro caso la llamaremos TABULACION_WEB.
3. Al colocar el nombre, escogemos que tipo de distribución se construirá, para
nuestro caso es cumulative probability,, sin embargo observamos que tenemos
otras dos opciones que son también muy útiles como son construir la probabilidad
(probability) en forma directa o según el peso o importancia que le demos a cada
campo del trafico. (Weight) , como estamos realizando una tabulación el tipo (type)
de distribución es discreto (discrete)
24
4. Procedemos a introducir los datos.
5. Por ultimo se realiza un view de la distribución que construimos y comparándola
con la que se construyo en excel (tabla 9). La ventaja de esta herramienta de
simulación es que al construir la probabilidad acumulada (azul) nos gráfica de
probabilidad (negro) de esta distribución.
3.4.2 CONSTRUCCIÓN DE COMANDOS
3.4.2.1 Globales
Un comando tanto global como local, nos ayudara a definir o estandarizar dentro de
nuestro proyecto fuentes de tráfico, ya sean fuentes de mensaje, sesiones, lectura de
archivos, mensaje de transporte etc (observar la pantalla inferior).
25
Esto es muy útil ya que las fuentes de mensaje se repiten cuando los usuarios de un
sala de computadores acceden a internet, el comportamiento del usuario es muy
similar, lo cual podemos generalizarlo y facilitar nuestra simulación.
En este trabajo se utilizaron varios comandos globales de los cuales solo explicare
uno de ellos, la fuente de respuesta la cual se usa cuando un servidor que recibe un
mensaje y este devuelve un mensaje de respuesta (answer message).
A continuación describo como se crea una fuente de respuesta:
1. Al ubicarnos en el menú DEFINE / GLOBAL COMMANDS, encontramos la
pantalla que se muestra, lo cual procedemos a presionar answer message. Y luego
copy,
Procedemos a colocar un nombre a nuestro comando en este caso RESPUESTA
WEB, en la misma pantalla la opción messages, al ser un comando de internet el
cual usa el protocolo TCP/IP tenemos que el calculo de para el tamaño del mensaje
siempre será el tamaño del mensaje en si, es decir:
Tamaño de mensaje = tamaño de los mensajes de la fuente de respuesta. (TMFR)
Formula de la herramienta: (A x TMFR ) + B
26
Para que se cumpla la relación descrita B = 0 y A = 1
2. Este comando lo debemos reflejar en las estadísticas o reportes que realiza la
herramienta, entonces para diferenciarlos utilizamos la palabra ECHO en
destinations.
1. De igual forma las opciones del texto en los reportes tenemos la opción copy
message name, para diferenciar de donde procede el mensaje.
27
Sin embargo podemos utilizar otras opciones las cuales se pueden practicar como es
la opción use original message la cual se utiliza para fuente de trafico o aplicaciones
al usar received message. Para mayor claridad consultar el manual de la
herramienta de simulación.
4. Al utilizar un protocolo conocido como es TCP/IP ya esta estandarizado en la
herramienta de simulación, se recomienda utilizar los parámetros descritos en la
pantalla inferior, basados en trabajos anteriores. Si se tiene un protocolo diferente, se
debe hacer una búsqueda exhaustiva de proyecto realizados en COMNET de los
parámetros a utilizar. Basándose en estos trabajos facilitan el tiempo de simulación y
ajustando a la realidad.
En cualquier simulación de una red son cientos de parámetros que se utilizan, lo cual
debemos tratar de estandarizar o generalizar todos los que se puedan sin perder la
lógica del parámetro sobre un tipo red especifica. Así tratamos de aminorar el tiempo
de investigación cuando las redes son similares entre si.
28
La opción comments se utiliza si se quiere tener algún comentario general sobre este
comando.
5. Por ultimo tecleamos OK nos acreado un comando y nos especifica de que tipo
es.
3.4.2.2 Locales.
Al igual que un comando global, los locales tienen las misma finalidad, pero se utilizan
para caracterizar una fuente de tráfico local, muy utilizadas por servidores para definir
como es el trafico de llegada a este dispositivo o elemento de red.
29
Al ser el servidor un elemento de red sobre un nodo en el diseño que se realiza en la
herramienta de simulación, debemos parametrizar no solo con las características
físicas del servidor sino las características de tráfico que llegan a él.
1. Sobre el nodo que estamos caracterizando, con anterioridad se le ha colocado un
nombre si no lo posee colocárselo, se recomienda colocar el nombre del servidor
sobre la red. En node properties (boton derecho) en software capability y
commands, procedemos a caracterizar el comando local utilizando la distribución
que creamos (tabla 9).
2. Igual que en los comandos globales procedemos a mostrar solo un opción en este
caso Read file , ya que es conveniente porque la distribución que creamos (tabla 9)
es un tráfico caracterizado de los usuarios de la sala TybaXa al navegar por internet.
Luego de procedemos a darle copy y done procedemos a ver la pantalla de los
parámetros del comando.
30
3. En esta pantalla le damos un nombre al comando PAGINA WEB, los parámetros
están generalizados para la distribución construida con anterioridad. Recomendamos
observar el manual para comprender las opciones de esta pantalla.
Cuando creamos un distribución de estas características tenemos.
App type: Other, ya que no utilizamos una estandar de la librería de
COMNET.
File to access: GENERAL STORAGE, el acceso al almacenamiento del
nodo se realiza en forma estándar para COMNET.
File modification method: Do not modify file, como estamos utilizando una
distribución particular, no se desea que varíe, sino que se
ejecute tal cual se creo.
Bytes read calculation: Probability distribution, en la tabla 9 describe el tamaño de
los mensajes en bytes por lo tanto se desea dejar igual.
Probability distribution: TABULACION_WEB, el nombre que le dimos a la
distribución.
31
4. Por ultimo procedemos a darle OK, y creamos el comando local según el tipo.
3.4.3 GENERADORES DE TRAFICO
En COMNET tiene diferentes formas de simular el tráfico generado por fuentes de
trafico. Las más sencillas son la construcción de fuente de mensaje, una fuente de
respuesta o una fuente de sesión.
Su finalidad es la misma cuando se crea un comando, sin embargo el nivel de
complejidad y comprensión para el analista disminuye en gran proporción.
Por lo tanto recomiendo, dominar esta parte de la herramienta de simulación, ya que
en realidad debería ser la primera. Sin embargo para un trabajo de simular una red se
tiene un tráfico que generalmente no se parece a ninguna distribución y el trabajo
estadístico tiende a complicarse, por lo tanto es muy útil dominar el tema de
comandos.
COMNET es una herramienta que describe un tráfico en forma de mensajes, lo cual
es muy importante que al tener un analizador de tráfico, sepamos diferenciar el
comienzo y final de un mensajes que esta compuesto por múltiples frames.
32
Por lo tanto para simular la red de la facultad de ingeniería, no solo es necesario tener
la herramienta de simulación sino también el analizador de tráfico.
3.4.3.1 Fuente de mensaje
En una fuente de mensajes hay que tener en cuenta dos cosas importantes para
simular, 1) el tiempo de envío de cada mensaje y 2) el tamaño de cada mensaje.
1) El tiempo de envío de cada mensaje: scheduling/arrival times , es
llamado asi por COMNET por que es el tiempo en el cual los mensajes
llegan al nodo que esta procesando ese trafico. Este tiempo puede ser
una constante, una distribución parametrizada o una tabulada.
2) El tamaño del mensaje: messages, es el tamaño del mensaje, el cual
describidos su tamaño que puede ser una constante, una distribución
parametrizada o una tabulada.
1. El siguiente ejemplo que describimos, tenemos una FUENTE DE MENSAJES
que envía cada 10 segundos un mensaje, el cual este tiempo Inter-arrivos se
comporta de forma de una distribución exponencial.
En el menú library/Bring into model/ message source/scheduling,
parametrizamos las características anteriores como lo describe la pantalla inferior.
33
2. Tenemos de igual manera que el tamaño de los mensajes se describen de forma
geométrica con una media de 5000 bytes.
En la distribución geométrica debemos tener en cuenta que hay un rango de offset lo
cual lo colocamos en 1.
En COMNET tenemos la facilidad de describir las unidades del tamaño del mensaje
(msg size units) en bytes o paquetes.
Para el calculo de tamaño del mensaje (msg size calc) COMNET dispone de dos
posibilidades utilizar un distribución estadística o un modelo lineal basado el cual el
mensajes desenvuelve el tráfico de la fuente:
Received message scheduling :
Tamaño de mensaje = Constante multiplicadora x Tamaño del mensaje recibido +
offset
3. El tipo de destinación Destinations / Destinations type el cual se utiliza para
describir el comportamiento de la llegada de los paquetes en el nodo que esta
procesando el mensaje que llega de la fuente de tráfico.
34
COMNET tiene seis diferentes tipos de destinación, recomendamos leer con el
manual de la herramienta de simulación para diferenciar cada uno de ellos. En
nuestro ejemplo describo a weighted list, se utiliza asignando una probabilidad para
el nodo según el peso o importancia que necesite el modelo para donde se dirija el
tráfico.
4. De igual forma las opciones del texto en los reportes tenemos la opción copy
message name, para diferenciar de donde procede el mensaje.
5. Al utilizar un protocolo conocido como es TCP/IP ya esta estandarizado en la
herramienta de simulación, se recomienda utilizar los parámetros descritos en la
pantalla inferior.
35
3.4.3.2 Fuente de respuesta.
Es un generador de mensajes que se utiliza para enviar mensajes de respuesta
cuando se esta recibiendo una petición.
Esta fuente es utilizada para modelar petición de acceso a bases de datos,
contestaciones de e-mail, o cualquier tipo de tráfico de mensajes que necesite ser
procesado por la recibo de un mensaje.
Los pasos para crear una fuente de respuesta son los siguientes:
1. En el menú de library/Bring into model/ response source/scheduling,
describimos el retardo de recibo de un mensaje, es decir el tiempo el cual necesita el
nodo para enviar una respuesta. Se puede modelar como una constante o una
distribución estadística.
36
Luego en edit received messages, escojemos cual es la fuente que nos hace la
petición. Aclaramos que REQ FTP es una fuente de mensajes que envía peticiones a
un servidor FTP.
2. En messages, al igual que una fuente de mensajes describimos las características
de los mensajes de respuesta, en este caso son mensajes de tipo FTP modelados
como una distribución normal con una media de 1.000.000 de bytes y una desviación
estandar. De 250.000 bytes.
37
3. Tanto en la opción destinations , text y packets se caracteriza con el mismo
principio de una fuente de mensajes.
38
3.4.3.3 Fuente de sesión
Este generador de mensajes los utilizamos para enviar sesiones de un nodo a otra,
es decir, primero un nodo organiza una sesión y luego envía el tráfico. Se utiliza para
modelar fuentes de mensaje que tienen un proceso de arribo establecido y gran
cantidad de mensajes pueden ser transmitidos con una sesión.
Crear sesión facilita el tiempo de simulación lo ideal esta es saber identificar cuando
se puede crear una sesión, por ejemplo si estamos sobre una maquina bajo UNÍS, y
deseamos operarla bajo windows, entonces la aplicación que realiza este trabajo abre
una sesión, significa que el tráfico entre esos nodos tendrá el mismo proceso de
arribo y podemos enviar gran cantidad de mensajes solo simulando el
comportamiento de uno.
1. En el menú de library/Bring into model/ message sourse/ session source, Al
igual que una fuente de mensaje la parametrizamos de igual forma, en la opción de
scheduling (se esta caracterizando un mensaje). Colocamos un nombre que
podamos apreciar que se trata de una sesión
2. En setup, especificamos dos cosas importantes: 1. setup packet (especifica el
número de bytes en una paquete de setup. 2. confirm packet (especifica el número de
bytes in el paquete de confirmación de la sesión.
39
3. Messages, describimos los parámetros de messages / session (número de
mensajes que serán transmitidos en una sesión, puede ser una constante o una
distribución estadística, Message IAT ( especifica tiempo de Inter-arribos de los
mensajes en una sesión, puede ser una constante o una distribución estadística.
4. Destinations, escojemos el tipo y havia donde va (edit destination list), (de igual
forma que una fuente de mensaje)
40
5. Tanto para destinations como para packets , se caracterizan de igual forma que
una fuente de mensajes.
3.4.3.4 Fuente de aplicación.
En COMNET las fuentes de aplicación son un proceso complejo el cual podemos usar
una fuentes de mensajes, respuesta y sesiones para crear un todo manejado por una
rutina de comandos (fuente de aplicación). En las fuentes de aplicación podemos usar
una combinación de lectura, escritura, procesos, transporte, respuestas y otrs
comandos setup de la herramienta.
41
Esta es una forma de programación secuencial en la cual describimos los pasos uno
a uno para caracterizar una fuente compleja generadora de tráfico.
En COMNET podemos crear diferentes aplicaciones en diferentes nodos, lo cual se
logra que interactúen las aplicaciones al mismo tiempo.
Sin embargo en este trabajo se utilizo una aplicación con dos comandos, de forma
sencilla. La cual solo realiza el comando de lectura y luego el comando respuesta.
1. En la opción sequense, se describe la secuencia de comandos que va a realizar la
aplicación hay que tener en cuenta que el comando debe estar creado previamente.
Luego procedemos a a presionar Add at end, y tenemos la pantalla de command
name detail, la cual escojemos el comando a utilizar en command name, y luego el
número de ejecuciones que tiene ese comando.
42
2. Por ultimo presionamos OK, y el la pantalla nos aparece la secuencia que
construimos.
3. Si queremos adicionar comandos repetimos el proceso desde el primer paso, pero
ahora con el comando llamado RESPUESTA WEB (tipo respuesta)
Lo que se realizo fue primero una lectura de una pagina WEB y se ejecuto la
respuesta. Es un ejemplo sencillo de cómo actúa un servidor de correo sobre una red.
43
3.4.4 SEGÚN TIPO DE NODO
COMNET, tenemos tres grupos para clasificar un nodo 1. nodos de proceso
(servidores), 2. nodos de dispositivos de red (switches, hub, enrutadores, etc) y 3.
nodo de grupo de computadores.
Estos nodos utilizan parámetros que son difíciles de predecir por alguna herramienta
de analizadora. En toda red, especialmente de una facultad universitaria existen
decenas de elementos para simular, la mayoría son servidores y dispositivos de red.
En el mercado hay gran variedad de opciones difíciles de parametrizar ya sea por ser
nuevas o muy viejas. Cada nodo es todo un estudio de análisis lo cual tardaríamos
mucho tiempo en lograr parametrizar adecuadamente cada uno, por lo tanto he
tratado de focalizarme en los parámetros más importantes.
Estoy basado en trabajos anteriores, y estudios acerca de simulación de redes, un
ejemplo de ello si encuentro dos servidores con las mismas especificaciones técnicas
iguales aunque marcas diferentes, recomiendo generalizar.
Sin embargo cuando un nodo es muy importante como un servidor central, de correo,
Se debe tratar de parametrizar lo máximo posible.
3.4.4.1 Nodo de proceso.
Este es el nodo más difícil de simular en COMNET, ya que cuenta con una gran
variedad de parámetros, sin embargo describiré los que consideré más importantes.
Un nodo de proceso, puede ser desde un servidor, un computador, una impresora
hasta un fax, generalmente se utiliza para modelar el sistema final, ya sea al origen o
44
destino para el tráfico de mensajes, ejecución de aplicaciones, puntos de switcheo en
la red.
1. En el menú library/bring into model/nodes/processing node, debemos presionar
add para crear nuestro nodo de proceso, sin embargo COMNET presenta un nodo de
proceso por defecto, lo cual facilita en casos de una simulación no presentar errores
por la falta de la parametrización de un nodo.
En la simulación de una red universitaria los nodos más importantes son los
servidores, que son los que procesan el trafico tanto de llegada como salida de la red.
2. En la simulación de una red universitaria los nodos más importantes son los
servidores, que son los que procesan el trafico tanto de llegada como salida de la red.
Por lo tanto este estudio se enfocara en las opciones de processor, storage, y files
1. En processor, hay tres parámetros fundamentales,
Number of processors :número de procesadores del servidor.
processing / cycle : Puede ser una constante o una distribución estadística, utilizada
para modelar la velocidad en la cual los comandos de procesamiento en una
aplicación ocurren en una simulación, este parámetro depende de la velocidad del
procesador y de cómo la aplicación se comporta en el servidor. Con una analizador
45
protocolar podemos ver el comportamiento de una aplicación sobre el servidor, y
calculamos el número de ciclos el cual dura en ejecutarse un proceso.
Time slice : En el caso de un computador o un servidor con un procesador este
tiempo tiende a cero, porque esta relacionado con la multitarea. Este parámetro
puede ser una constante o un distribución estadística. Sin embargo se recomienda
utilizar pequeños tiempos la cual es la mejor forma de aproximarse al ambiente de
multitarea.
2. storage, relaciona la capacidad de almacenamiento, más conocido como discos
duros, si se tiene varios discos duros se recomienda utilizar promedios para los
tiempos y sumar capacidades.
Los parámetros de Disk (capacidad total del almacenamiento del servidor), sector
(tamaño de los sectores), Xfer (tiempo requerido para leer un sector), y seek (tiempo
requerido para encontrar un archivo en el disco) , son fáciles de encontrar ya que el
fabricante los publica.
46
3. Files, nos presenta la lista de los archivos que pueden ser creados por los discos
duros al comenzar una simulación. Recomendamos utilizar GENERAL STORAGE, ya
que se dificulta el análisis modelar una completa estructura de archivos sobre el disco
duro.
4. Después de crear nuestro nodo de proceso procedemos a node properties ,
colocamos el nombre del nodo y el parámetro principal donde describimos las
características de los puntos 1,2 y 3
47
3.4.4.2 Dispositivos de red
COMNET cuenta con una amplia gama de dispositivos de red ya parametrizados, por
lo tanto si el dispositivo es muy antiguo y no se encuentra debemos tratar de simularlo
con alguno de características similares, o si en muy nuevo, podemos realizar una
busquedad por internet y buscar una librería más actualizada, o en ultimas utilizar el
parámetro más importante para la herramienta de simulación ( switch fabric = bus
rate).
1. En node type parameter sets , escogemos network device parameter,
selecionamos el indicado en la libreria (library selections)
48
2. Si el dispositivo no se encuentra buscar por medio del fabricante el parámetro de
switch fabric y procedemos a anotarlo en el campo de bus rate.
49
3. Luego recurrimos a node properties, y escogemos el nodo que acabamos de
crear.
3.4.4.3 Grupo de computadores.
Al igual que nodo de dispositivos de red, una red universitaria se focaliza en mayor
medida a su tráfico y no a las características de los computadores. Por lo tanto el
parámetro más importante es cuantos computadores hay en una sala de informática y
como se comporta cada uno de ellos.
1. En node type parameter sets , escogemos computer group parameter,
procedemos a presionar edit, el cual observamos DEFAULT por defecto y luego
adicionamos (add)
50
2. Le colocamos un nombre y el número de computadores que pueda tener una sala
de informática. Los demás parámetros se pueden dejar por defecto, ya que tenemos
un protocolo estandar como es TCP/IP.
3. Luego recurrimos a node properties, y escogemos el nodo que acabamos de
crear.
51
3.4.5 SEGÚN TIPO DE ENLACE
Los enlaces de una red universitarias están estandarizados y son generalizados por
lo tanto COMNET ya trae parametrizados diferentes tipos de enlace como son CSMA,
CSMA/CD, token ring, FDDI, CSMA/CA , etc.
En importante conocer que las estadísticas o reportes que nos muestra la
herramienta de simulación sobre un enlace no se especifica directamente, por lo tanto
debemos asumir un nodo de control en el cual se centraliza esta información.
3.4.5.1 Enlace ethernet CSMA/CD
En la red universitaria podemos observar que se utilizan el enlace CSMA/CD el cual
puede utilizar un cableado de 100baseT o un 10baseT.
En importante saber si el enlace que se utilice es full- duplex.
Veamos a continuación la creación de un enlace CSMA/CD.
1. En el menú library/bring into model/links, accedemos a la pantalla de link type
parameters set, y escogemos el tipo de enlace a utilizar.
52
2. Procedemos a escoger el tipo de cableado que se esta utilizando.
Al tener el enlace en la librería no es necesario configurar sus parámetros, en
nuestro caso la facultad de ingeniería de la universidad de los Andes sus enlaces son
full-duplex, por lo tanto seleccionamos esta opción.
3. Luego sobre el enlace (link properties), procedemos darle un nombre ,
seleccionamos en link type nuestro tipo de enlace y que parámetros vamos a utilizar.
53
4. Luego en la opción link specifics , seleccionamos el nodo de control donde se
reflejaran nuestras estadísticas.
54
3.4.6 PARÁMETROS DE SIMULACION
COMNET tiene diferentes parámetros para caracterizar una simulación, estos
parámetros según su elección puede aminorar o alargar el tiempo real de simulación
De igual forma los tiempo de simulación NO SON tiempos reales de simulación sin
embargo en este trabajo se trato de dar una idea de que tiempo puede ser REAL,
según las dimensiones de la red y cantidad de usuarios.
En COMNET podemos simular el tráfico y replicar la misma simulación, sin embargo
al realizar una replica el tiempo real de simulación es proporcional al número de
replicas, es decir a mayor uso de replicas mayor el tiempo de simulación. Cuando una
simulación tiene un tráfico pesado, NO se recomienda utilizar replicas, ya que la
herramienta de simulación desgasta en gran medida la maquina en la cual esta
funcionando, y más adelante podemos observar que podemos tardar días para una
simulación de una red universitaria a medida que aumentemos la carga de la red.
Warmup length : Es el tiempo que toma la red en establecer un correcto
funcionamiento, es decir si colocamos en funcionamiento por primera vez, seria el
tiempo necesario para que la red este disponible. En caso de una caída de una red,
seria el mismo espacio de tiempo que necesita para entrar en funcionamiento
nuevamente.
55
Number of replications: Cantidad de veces que se quiere replicar la simulación. En
este tipo de estudio siempre utilice una replica, ya que para simulaciones de periodos
cortos los resultados fueron iguales.
Replications legth: Es la cantidad de tiempo que dura la simulación, este tiempo
seria el tiempo real, sin embargo en la practica es menor o mayor dependiendo de la
carga que le demos a la red.
Las opciones de warmup every replications, utilizada para realizar un warmup para
cada replica, y reset systems every replications, se utiliza para sacar la red de
funcionamiento y colocarla a disponibilidad cada replica. Estas dos opciones aumenta
el tiempo de simulación.
En statistics, tenemos las siguientes opciones:
Confidence interval alpha: Es el intervalo en el cual queremos que las
estadísticas de los reportes de COMNET se muestren.
Export stats after run: Es la opción para que los archivos de estadísticas sean de
modo ASCII.
Include percentiles in export: Para incluir porcentajes en los reportes.
56
También recomendamos en el menú simulate/animate , ANULAR la opción de
animate packet flow , ya que esta opción aumenta en gran medida la simulación, se
puede utilizar para pequeñas simulaciones, con el sentido de ver el flujo de tráfico a
través de la red.
También podemos en el menú simulate/trace, observar graficas de los reportes (
trace to screen)que se desean, se recomienda sola para simulaciones pequeñas, ya
que COMNET utiliza bastante uso de memoria y dependiendo de la carga de la red,
puede bloquear el equipo que estemos utilizando y perder los datos de la simulación.
También se recomienda para simulaciones pesadas, NO exportar los reportes en
modelo excel, ya que estos archivos son muy pesados. Se recomienda utilizar realizar
las graficas en excel PERO manualmente cuando se tenga la información estadística.
57
4. PRUEBAS
4.1 Metas técnicas a considerar
Se requiere observar el comportamiento de las siguientes metas técnicas:
1. UTILIZACION
2. RETARDOS.
3. Conteo de mensajes por fuente.
4. KBPS (Kilo Bytes por segundo)
5. PPS (Paquetes por segundo )
4.2 Problema
En esta parte se quiere probar la METODOLOGÍA sobre un red universitaria, más
concretamente la sala TybaXA, para un flujo de 10 a 300 usuarios. Los cuales
realizan aplicaciones WEB, correo electrónico interno, aplicaciones FTP. Luego se
procederá a simular 15 (quince) sala TybaXa como un máximo de 15 pc´s por sala.
4. 3 Aplicar la METODOLOGÍA.
1. Indagar quien tiene la información.
Se realizo un estudio sobre el personal encargado de la red de datos de la facultad de
ingeniería, y se obtuvieron los datos mostrados con anterioridad.
Observar :
TABLA 1 : Personal encargado de la red de la Facultad de Ingeniería
TABLA 1_1 : Funciones sobre la red.
58
2. Documentar la información según cada elemento de red.
Debemos completar la información de las tablas a continuación. Esta información
depende de la colaboración que se preste de las personas que laboran sobre la red,
lo cual debemos aprovechar que un recorrido se completen las tablas relacionadas
entre si.
La información que se solicita en estas tablas, es básica e indispensable, no se debe
dejar campos vacíos.
Observar :
TABLA 2: Servidores
TABLA 3 Disco Duro
TABLA 4: Clasificación de las aplicaciones de la red universitaria.
TABLA 5: Ubicación de las aplicaciones (sobre cúal servidor están
instaladas?)
TABLA 6_1
Y TABLA 6_2: Ubicación de los dispositivos de Red.
TABLA 7: Parámetros de utilización en un switch.
TABLA 8: Tipos de enlaces utilizados en la red universitaria.
59
3. Realizar un esquema general de la red.
Se realizo un esquema general de la sala TybaXa, con los servidores y dispositivos
que son utilizados en la formulación del problema.
GRAFICA 2
60
4. Parámetros utilizados para la simulación.
TABLA DE GENERACIÓN DE TRAFICO(SEG)
USUARIOS WEB E-Mail FTP
1 300 600 240010 30 60 24020 15 30 12030 10 20 8050 6 12 4870 4,28571429 8,57142857 34,2857143100 3 6 24200 1,5 3 12300 1 2 8500 0,6 1,2 4,8700 0,42857143 0,85714286 3,42857143
1000 0,3 0,6 2,4
TABLA 10
La tabla 10 nos muestra el tiempo en segundo de cómo un usuarios genera un tráfico
WEB, un e-mail o FTP. Ejemplo: Para Un usuario esta generando una tráfico WEB
cada 300 segundo, enviando un e-mail cada 600 segundo y enviando una petición
FTP cada 2400 segundo.
Esta tabla se construyo por observación de la sala tybaXA en un día común, aunque
no es el tráfico exacto, nos sirve para realizar las pruebas que queremos.
Fuente de Mensajes
Nuestra media en arribo de mensajes será el resultado obtenido en la tabla 10 según
el número de usuarios que se presente.
De igual forma el tamaño de los mensajes es según la aplicación y según la fuente de
mensajes al ser el protocolo TCP/IP tenemos estandarizado el tamaño de los
mensajes.
61
FUENTE DE ARRIBO DE MENSAJES TAMAÑO DEL MENSAJEMENSAJE (SEG) (BYTES)
Tip. De Distrib. Media Tip. De distrib.. MediaREQ FTP EXPONENCIAL tabla 10 GEOMÉTRICA 20
E-Mail chequeo EXPONENCIAL tabla 10 CONSTANTE 60
E-Mail EXPONENCIAL tabla 10 GEOMÉTRICA 2000
Petición WEB EXPONENCIAL tabla 10 CONSTANTE 64
TABLA 11
Fuentes de Respuesta
Para realizar esta tabla utilizamos distribuciones normales ya que ésta se aproxima
muy bien al tipo de fuente de respuesta que utilizamos, y también nos basamos en
trabajos anteriores.
FUENTE DE RECIBO DE MENSAJES TAMAÑO DEL MENSAJE
RESPUESTA (SEG) (BYTES)
Distrib. Media Desv. Stand. Distrib. Media Desv. Stand.
E-Mail Resp NORMAL 0,20 0,05 NORMAL 100.000 25.000
FTP Resp EXPONENCIAL 0,2 No aplica NORMAL 1.000.000 250.000
TABLA 12
Fuente de Aplicación:
Respuesta WEB: Retardo de recibo de mensajes ninguno, contesta la fuente cada
vez que llega la Petición WEB, secuencia (tabla 9)
De comandos : 1. Lee la PAGINA WEB y luego ejecuta RESPUESTA WEB
62
Tipos de nodo y enlace
Observar (tabla
Diseño de la red en COMNET
Resultado de la construcción en COMNET III.
GRAFICA 3
Luego de realizar el diseño de la red prueba llamada tybaXA, a continuación se
mostraran los resultados obtenidos. Un resultado muy importante es saber cuanto
tiempo real se tardara las simulaciones en COMNET III a medida que variamos los
parámetros tanto para las fuentes de mensaje, fuentes de respuesta, cantidad de pc´s
en la sala y número de usuarios
TABLA 13
UNA (1) SALADURACION EN TIEMPO REAL PARA SIMULACIONES
CON UN WARMUP DE 30 MINUTOS Y 10 HORAS DE DURACIONUSUARIOS 1 PC´s 2 PC´s 5 PC´s 10 PC´s 15 PC´s
10 0 hor_03 min 0 hor_04 min 0 hor_13 min 0 hor_22 min 0 hor_35 min
20 0 hor_07 min 0 hor_09 min 0 hor_46 min 1 hor_16 min 1 hor_09 min
50 0 hor_15 min 0 hor_18 min 1 hor_14 min 3 hor_54 min 5 hor_27 min
100 0 hor_35 min 1 hor_12 min 2 hor_02 min 9 hor_03 min 14 hor_10 min
300 1 hor_54 min 3 hor_13 min 7 hor_30 min 25 hor_0 min 44 hor_42 min
63
La tabla 12 nos muestra el tiempo real de simulación para UNA SALA tybaXA, de
uno (1) a quince (15) pc´s y acceden de 10 usuarios a 300 (tabla 10). Las 10 horas de
duración es el parámetro de replications legth.
Podemos observar que para una sala TybaXA de 15 pc´s para 300 usuarios llegamos
a casi dos días enteros de simulación, lo cual será nuestro tope de número de
usuarios. Sin embargo , en la Facultad de ingeniería de la Universidad de Los Andes
podemos encontrar salas que tiene un comportamiento de 1000 usuarios.
Estas simulación son desgastan la maquina en donde se realiza la simulación, por lo
tanto se recomienda que al ejecutar las simulaciones, verificar que no haya ninguna
tarea pendiente para esa maquina.
Aclaro que esto tiempos obtenidos son sobre la maquina llamada TITAN, que posee
unas características según la tabla 2. Sin embargo los tiempos reales de simulación
tienden a disminuir proporcionalmente al mejorar el servidor donde se ejecute la
simulación.
Sin embargo una RED UNIVERSITARIA es más de una sala por lo tanto realice
pruebas hasta con 15 salas que tienen el mismo comportamiento de la sala TybaXa y
los tiempo reales de simulación tienden a ser semanas.
QUINCE (15) SALAS PARA 100 USUARIOSDURACION EN TIEMPO REAL PARA SIMULACIONES
CON UN WARMUP DE 30 MINUTOS Y 10 HORAS DE DURACION
Cant. De PC´s TIEMPO1 PC´s 1 dia_04 hor_21 min2 PC´s 2 dia_13 hor_45 min5 PC´s 3 dia_10 hor_52 min8 PC´s 6 dia_02 hor_31 min10 PC´s 7 dia_15 hor_51 min
TABLA 14
64
Según la cantidad de usuarios obtendremos una tabla como se muestra arriba, sin
embargo decidí solo realizar una de ellas cuando tenemos 100 usuarios y de 1 a 10
pc´s por sala y para 15 salas.
El tiempo de simulación es extremadamente largo por lo tanto la idea es tratar de
tener una buena aproximación de tráfico utilizando una distribución estadística
adecuada y lógica o la mejor utilizar un analizador protocolar y construir cada fuente
de tráfico.
4.4 RESULTADOS PARA LA SALA TYBAXA CON 15 PC´S.
4.4.1 UTILIZACIÓN
UTILIZACION DEL ENLACE Eth. UNIVERSIDAD Eth. Facultada de Eth. 1_100baseT Eth. 2_100baseT
USUARIOS Gigabit Ingeniería
10 0,006 0,0096 0,0065 0,0031
20 0,0024 0,0136 0,013 0,0064
50 0,006 0,0484 0,0326 0,0158
100 0,0174 0,1903 0,1284 0,0619
300 0,1035 0,2926 0,1939 0,0987
TABLA 15
65
UTILIZACION DEL ENLACE
0
0,05
0,1
0,15
0,2
0,25
0,3
0,35
10 20 50 100 300
USUARIOS
CA
NTI
DA
D (%
)
Eth. UNIVERSIDADGigabit
Eth. Facultada deIngeniería
Eth. 1_100baseT
Eth. 2_100baseT
GRAFICA 4
4.4.2 RETARDOS
RETARDO PROMEDIO DE IDA Y VUELTA DEMENSAJES (mS)
USUARIOS 10 20 50 100 300Peticion WEB: 200,236 200,236 200,236 200,236 200,236
E-Mail 264,287 266,502 264,847 264,145 266,671
E-Mail Chequeo 200,117 200,117 200,117 200,117 200,118
REQ FTP: 200,111 200,111 200,111 200,111 200,111
TABLA 16
RETARDO MAXIMO DE IDA Y VUELTA DE MENSAJES(mS)
USUARIOS 10 20 50 100 300Peticion WEB: 200,244 200,244 200,244 200,244 200,86E-Mail 401,71 402,572 403,007 403,007 403,016E-Mail Chequeo 200,134 200,117 200,128 200,117 200,782REQ FTP: 200,129 200,128 200,128 200,281 200,134
TABLA 17
66
RETARDO PROMEDIO DE IDA Y VUELTA DEPAQUETES (mS)
USUARIOS 10 20 50 100 300
Peticion WEB: 0,039 0,039 0,039 0,039 0,039E-Mail 0,121 0,122 0,121 0,12 0,124E-Mail Chequeo 0,02 0,02 0,02 0,02 0,01REQ FTP: 0,017 0,017 0,017 0,018 0,017
TABLA 18
RETARDO MAXIMO DE IDA Y VUELTA DE PAQUETES(mS)
USUARIOS 10 20 50 100 300Peticion WEB: 0,053 0,053 0,053 0,053 0,17E-Mail 0,551 0,551 0,587 0,587 0,63E-Mail Chequeo 0,034 0,026 0,026 0,026 0,375REQ FTP: 0,037 0,037 0,037 0,181 0,043
TABLA 19
RETARDO PROMEDIO DE PAQUETES
0
0,02
0,04
0,06
0,08
0,1
0,12
0,14
10 20 50 100 300
USUARIOS
CA
NT
IDA
D (m
SE
G) Peticion WEB:
E-Mail Chequeo
REQ FTP:
GRAFICA 5
67
4.4.3 CONTEO DE MENSAJES
CONTEO DE MENSAJES ENVIADOSE-Mail Peticion
Usuarios REQ FTP Chequeo E-Mail WEB
10 2255 8952 9006 18450
20 4206 16488 16689 33965
50 10525 40567 40830 83570
100 19252 75803 75803 156141
300 27800 109654 109086 225889TABLA 20
CONTEO DE MENSAJES
0
50000
100000
150000
200000
250000
10 20 50 100 300
USUARIOS
CA
NTI
DA
D
REQ FTP
E-Mail Cheq.
Peticion WEB
GRAFICA 6
68
4.4.4 Kilo Bytes por segundo (KBPS)
KILOBYTES / SEG
USUARIOS Eth. UNIVE_GIGABIT Eth. Facultadad Eth. 1_100baseT Eth. 2_100baseT
de Ingeniería
10 9 9 5 4
20 18 18 11 8
50 46 46 27 19
100 198 198 117 81
300 1174 1174 694 480
TABLA 21
GRAFICA 7
KILOBYTES / SEG
0
100
200
300
400
500
600
700
800
900
1000
1100
1200
1300
10 20 50 100 300
USUARIOS
CA
NTI
DA
D
Eth. UNIVE_GIGABIT
Eth. Facultadad deIngeniería
Eth. 1_100baseT
Eth. 2_100baseT
69
4.4.5 PAQUETES POR SEGUNDO (PPS)
PAQUETES/SEGUSUARIOS Eth. UNIVE_GIGABIT Eth. Facultadad Eth. 1_100baseT Eth. 2_100baseT
de Ingeniería
10 6,44 6,44 3,81 2,63
20 12,84 12,84 7,59 5,24
50 32,05 32,05 18,96 13,09
100 53,95 53,95 31,91 22,04
300 321,01 321,01 189,87 131,14
TABLA 22
PAQUETES / SEGUNDO
0,00
50,00
100,00
150,00
200,00
250,00
300,00
350,00
10 20 50 100 300
USUARIOS
CA
NTI
DA
D Eth. UNIVE_GIGABIT
Eth. Facultadad deIngeniería
Eth. 1_100baseT
Eth. 2_100baseT
GRAFICA 8
70
CONCLUSIONES
1. Se logro construir una METODOLOGIA, en forma clara y precisa, en la cual se
pueda entender de una manera sencilla el desarrollo de una simulación mediante la
aplicación de la herramienta disponible COMNET III.
2. Se denoto que para realizar un proceso de simulación es necesario documentar la
información acerca de los parámetros necesarios que la herramienta de simulación
requiera.
3. Se logro comprobar que existen un sin número de posibilidades para simular de
acuerdo con los parámetros establecidos, como son por comunidad de usuarios, PC,
y cantidad de salas.
4. Según la herramienta utilizada, cada parámetro puede generar una nueva
simulación, cual se recomienda antes de comenzar un trabajo, se debe tener claro
que parámetros se debe variar para evitar perdida de tiempo de simulación.
5. Todos los tiempos de simulación se hicieron mediante el despliegue gráfico, se
recomienda a los futuros usuarios de la METODOLOGIA , encontrar como ejecutar
los proceso mediante ejecución de comandos.
6. La verdadera simulación se procesa mediante el tráfico real de cada red. Tanto la
METODOLOGIA como la herramienta, soportan la importación de datos reales,
evitando realizar análisis de tráfico por medio de distribuciones de probabilidad para
las FUENTES.
7. Se detallo que los reportes generados por la herramienta de simulación, se
generan hasta el final de la ejecución por lo tanto se debe tener precaución para
evitar perder tiempo en la toma de resultados.
71
BIBLIOGRAFÍA
OPPRNHEIMER Priscilla, Top-Down Network Design , 1999
CISCO Systems, CCIE Fundamentals: Network Design and case studies,1999
McCABE James, Practical Computer Network analysis and Design,(Morgan Kaufmann Series in Networking), 1998
TANENBAUM Andrew S. Redes de Computadoras, 19997
Compuware Corporation, COMNET III Reference Guide, Release2.5.1, Volumen I y II, 2000
CACI , Detailed Guide for Modeling Network, 1999
