Estudio de tráfico con plataforma de ruteo estático y...
186
Facultad de Ingeniería Escuela de Ingeniería de Sistemas ESTUDIO DE TRÁFICO CON PLATAFORMAS DE RUTEO ESTÁTICO Y RUTEO DINÁMICO, PARA DETERMINAR PUNTOS CRÍTICOS DE SATURACIÓN EN LA RED Valerio G. Piselli P. Tutor: Teodoro Lobo Caracas, julio 2001
Transcript of Estudio de tráfico con plataforma de ruteo estático y...
Facultad de Ingeniería
Escuela de Ingeniería de Sistemas
ESTUDIO DE TRÁFICO CON PLATAFORMAS DE RUTEO
ESTÁTICO Y RUTEO DINÁMICO, PARA DETERMINAR
PUNTOS CRÍTICOS DE SATURACIÓN EN LA RED
Valerio G. Piselli P.
Tutor: Teodoro Lobo
Caracas, julio 2001
DERECHO DE AUTOR
Cedo a la Universidad Metropolitana el derecho de reproducir y difundir el presente
trabajo, con las únicas limitaciones que establece la legislación vigente en materia de
derecho de autor.
En la ciudad de Caracas, a los 11 días del mes de Julio de año 2001.
Autor. Valerio Piselli
APROBACIÓN
Considero que el Trabajo Final titulado
ESTUDIO DE TRÁFICO CON PLATAFORMAS DE RUTEO ESTÁTICO Y RUTEO
DINÁMICO, PARA DETERMINAR PUNTOS CRÍTICOS DE SATURACIÓN EN LA
RED
Elaborado por el ciudadano
Valerio G. Piselli P.
Para optar al título de
ING. DE SISTEMAS
Reúne los requisitos exigidos por la Escuela de Ingeniería de Sistemas de la Universidad
Metropolitana, y tiene méritos suficientes como para ser sometido a la presentación y
evaluación exhaustiva por parte del jurado examinador que se designe.
En la ciudad de Caracas, a los 11 días del mes de Julio del año 2001.
Tutor: Teodoro Lobo.
ACTA DE VEREDICTO
Nosotros, los abajo firmantes constituidos como jurado examinador y reunidos en Caracas,
el día , con el propósito de evaluar el Trabajo Final titulado
ESTUDIO DE TRÁFICO CON PLATAFORMAS DE RUTEO ESTÁTICO Y RUTEO
DINÁMICO, PARA DETERMINAR PUNTOS CRÍTICOS DE SATURACIÓN EN LA
RED
Presentado por el ciudadano
Valerio G. Piselli P.
Para optar al título de
ING. DE SISTEMAS:
Emitimos el siguiente veredicto:
Reprobado Aprobado Notable Sobresaliente
Observaciones
Ricardo Strusberg Bonell Martínez Teodoro Lobo
AGRADECIMIENTOS
A mis padres, por su apoyo incondicional, no sólo durante la realización de este proyecto,
sino durante todos mis años de estudio, sin sus estímulos jamás hubiese podido llegar
adonde estoy.
A mi hermana, por estar siempre en los momentos en los que la necesito y por hacerme
parte de ese mundo de fantasía y realidad en el que vivimos, siempre podré contar con una
gran amiga, gracias Patty.
A José Ramón Godoy Narváez, por sus grandes consejos desde el momento en que
iniciamos este proyecto y que por cosas del destino no pudimos terminarlo juntos. Estoy
seguro que este trabajo es un logro para ambos, gracias por no abandonarme y haber
contribuido con tus buenas ideas. Esto es por los dos!!!
A Rodrigo Velásquez, por interesarse e involucrarse en el desarrollo de este proyecto y
por su contribución en la elaboración de las pruebas. Gracias por permitirme contar
contigo en los momentos crítico y darme ánimos para seguir adelante.
A Martha Moya, por sus buenos consejos para elaborar el tomo y por apoyarme en los
momentos difíciles para no perder la calma. Gracias Martita.
A mi tutor Teodoro Lobo , por enseñarme que en la vida los mejores logros son aquellos en
los que se lucha por obtenerlos sin importar las adversidades y por abrirme las puertas para
lograr este sueño tan anhelado.
A la Universidad Metropolitana, por brindarme la oportunidad de demostrar el esfuerzo
y creatividad adquiridos durante mis años de estudio en esta institución.
A aquellas personas que de una u otra forma me estimularon y apoyaron para seguir
adelante.
A todos ellos mi eterna gratitud.
TABLA DE CONTENIDO
LISTA DE TABLA Y FIGURAS....................................................................... iv
RESUMEN.......................................................................................................... v
ABSTRACT........................................................................................................ vi
INTRODUCCIÓN............................................................................................... 1
P R I M E R A P A R T E
ASPECTOS BÁSICOS PRELIMINARES DEL PROYECTO........................ 4
1.1 PLANTEAMIENTO DEL PROBLEMA.......................................... 5
1.2 OBJETIVOS...................................................................................... 7
1.2.1 OBJETIVOS GENERALES............................................... 7
1.2.2 OBJETIVOS ESPECÍFICOS.............................................. 7
S E G U N D A P A R T E
M A R C O T E Ó R I C O............................................................................... 8
2.1 TCP/IP................................................................................................ 9
2.1.1 Modelo de Referencia TCP/IP............................................. 10
2.1.2 Descripción general del uso de TCP/IP............................... 13
2.1.3 PROTOCOLO TCP............................................................. 20
2.1.4 PROTOCOLO IPv4..………………………………....…... 21
2.1.5 PROTOCOLO ICMP.………..............................…............ 35
2.2 ETHERNET / IEEE 802.3......................................................…........ 36
2.2.1 COMPARACIÓN ETHERNET / IEEE 802.3.................... 37
2.2.2 FORMATO DE LOS PAQUETES ETHERNET Y
IEEE 802.3................................................................................... 38
2.3 CONCEPTOS ESCENCIALES......................................................... 40
2.3.1 COMPONENTES DE ROUTING (RUTEO)..................... 46
2.3.2 ALGORITMOS DE RUTEO.............................................. 51
2.4 ROUTING INFORMATION PROTOCOL (RIP)…………………. 62
2.4.1 FORMATO DE LA TABLA DE ROUTING..................... 62
2.4.2 FORMATO DE LOS PAQUETES:
IMPLEMENTACIÓN IP............................................................. 64
2.4.3 ESPECIFICACIONES DE ESTABILIDAD...................... 67
2.5 RIP VERSION 2................................................................................ 71
2.5.1 FORMATO DE PAQUETES EN RIP2.............................. 72
2.6 SNIFFING.......................................................................................... 75
2.6.1 FUNCIONAMIENTO DE UN SNIFFER........................... 76
2.6.2 COMPONENTES DE UN SNIFFER.................................. 77
2.6.3 ANÁLISIS DE PROTOCOLOS.......................................... 78
2.6.4 PACKET.DLL API……………………………………….. 82
TERCERA PARTE
MARCO METODOLÓGICO.............................................................................. 83
3.1 TIPO DE INVESTIGACIÓN............................................................. 84
3.2 DISEÑO DE LA INVESTIGACIÓN................................................. 84
3.2.1 DISEÑO DE LA RED......................................................... 86
3.2.2 MÓDULO DE CAPTURA.................................................. 88
3.2.3 DISEÑO DEL SISTEMA NMIRE...................................... 92
3.2.4 DISEÑO DE LAS PRUEBAS............................................. 95
CUARTA PARTE
ANÁLISIS Y RESULTADOS............................................................................. 112
4.1 ANÁLISIS DE LAS PRUEBAS........................................................ 113
4.1.2 ESTUDIO DEL TRÁFICO QUE VIAJA POR LA RED Y
EL GENERADO POR EL PROTOCOLO RIP BAJO
CONDICIONES CONTROLADAS............................................ 113
4.1.3 ESTUDIO DE LAS DOS VERSIONES DEL
PROTOCOLO RIP ...................................................................... 113
4.1.4 RENDIMIENTO DEL SISTEMA NMIRE......................... 118
4.2 LIMITACIONES................................................................................ 122
QUINTA PARTE
CONCLUSIONES Y RECOMENDACIONES.................................................. 123
5.1 CONCLUSIONES............................................................................. 124
5.2 RECOMENDACIONES.................................................................... 127
REFERENCIAS BIBLIOGRÁFICAS................................................................. 128
APÉNDICE A
NMIRE - DIAGRAMA DE FLUJO DE DATOS................................................ 132
DESCRIPCIÓN DE PROCESOS............................................................. 143
SISTEMA NMIRE.................................................................................... 143
MÓDULO DE CAPTURA....................................................................... 150
APÉNDICE B
DIAGRAMA DE ENTIDAD – REALACIÓN.................................................... 155
ANEXO A
MANUAL DE USUARIO.................................................................................... 160
DESCRIPCIÓN DE LAS PANTALLAS DEL SISTEMA...................... 161
ABRIR SESIÓN........................................................................... 163
ABRIR CAPTURA...................................................................... 163
VER CAPTURA Y VER GRÁFICO........................................... 164
GENERADOR DE TRÁFICO..................................................... 166
CAPTURAR EL TRÁFICO......................................................... 166
EQUIPOS...................................................................................... 167
CONSULTA................................................................................. 168
COMPARAR SESIONES............................................................ 169
COMPARAR PROTOCOLOS..................................................... 170
OPCIONES DEL SISTEMA........................................................ 171
LISTA DE TABLA Y FIGURAS
TABLAS
1. Protocolos más comunes de TCP/IP, 11
2. Tabla de Routing, 62
3. Descripción detallada de un paquete capturado con un sniffer, 80
4. Ping 4096 RIPv1, 101
5. Ping 4096 RIPv2, 102
6. Ping 8192 RIPv1, 105
7. Ping 8192 RIPv2, 106
8. Ping 16384 RIPv1, 109
9. Ping 16384 RIPv2, 110
10. Tráfico Generado por RIP, 114
FIGURAS
1. Modelo de Referencia OSI y los protocolos de TCP/IP correspondientes, 10
2. Capas de los protocolos TCP/IP, 14
3. Modelo de Referencia OSI y las capas del Modelo de Referencia TCP/IP
correspondiente, 17
4. Formato de paquete IP, 21
5. Formato de direccionamiento clase A, B, C y D para rede IP, 26
6. Dirección de Subred, 32
7. Ejemplo de una máscara de red para una dirección clase A, 34
8. Formato de los Paquetes Ethernet y IEEE 802.3, 38
9. Tabla de Ruta Destino / próximo hop, 47
10. Proceso de Switching, 49
11. Bucle Infinito, 53
12. Formato de Paquetes RIP, 64
13. HOP-COUNT LIMIT, 67
14. SPLIT HORIZONS, 69
15. Formato de Paquetes RIPv2, 72
16. Ejemplo de un paquete capturado por un sniffer, 79
17. Escenario de funcionamiento, 86
18. Funcionamiento del módulo de captura, 89
19. Paquetes Recibidos Ping 4096, 103
20. Paquetes Perdidos Ping 4096, 103
21. Tamaño de la data Ping 4096, 104
22. Cantidad de paquetes Broadcast Ping 4096, 104
23. Paquetes Recibidos Ping 8192, 107
24. Paquetes Perdidos Ping 8192, 107
25. Tamaño de la data Ping 8192, 108
26. Cantidad de paquetes Broadcast Ping 8192, 108
27. Paquetes Recibidos Ping 16384, 111
28. Paquetes Perdidos Ping 16384, 111
29. Tamaño de la data Ping 16384, 112
30. Cantidad de paquetes Broadcast Ping 16384, 112
31. Paquetes Unicast y Broadcast en Tráfico de RIP, 115
32. Tabla de Ruta RIPv1, 116
33. Tabla de Ruta RIPv2, 116
34. Diagrama entidad – relación, 156
35. Pantalla Principal del Sistema NMIRE, 162
36. Abrir Sesión, 163
37. Abrir Captura, 164
38. Ver Captura, 165
39. Ver Gráfico, 165
40. Generador de Tráfico, 166
41. Ventana de captura, 167
42. Equipos, 168
43. Consulta 168
44. Ventana de Comparar Sesiones, 169
45. Botones de la ventana de Comparar Sesiones, 170
46. Comparación de Protocolos, 171
47. Opciones del Sistema, 171
RESUMEN
ESTUDIO DE TRÁFICO CON PLATAFORMAS DE RUTEO ESTÁTICO Y RUTEO
DINÁMICO, PARA DETERMINAR PUNTOS CRÍTICOS DE SATURACIÓN EN LA
RED
Autor: Valerio G. Piselli P.
Tutor: Teodoro Lobo.
Caracas, Julio 2001.
Este proyecto consistió en la elaboración de un sistema, denominado NMIRE, que permite
capturar el tráfico de paquetes que viaja por una red, para así establecer comparaciones
entre una serie de variables que determinan el desempeño de la misma. Además se realizó
una comparación entre las dos versiones del protocolo RIP para determinar cual se adapta
mejor como protocolo de enrutamiento en un escenario determinado. La finalidad de este
trabajo es la de ayudar a los administradores de red a descubrir problemas relacionados con
los tiempos de servicio y con el tráfico que se genera en una red.
ABSTRACT
ESTUDIO DE TRÁFICO CON PLATAFORMAS DE RUTEO ESTÁTICO Y RUTEO
DINÁMICO, PARA DETERMINAR PUNTOS CRÍTICOS DE SATURACIÓN EN LA
RED
Author: Valerio G. Piselli P.
Tutor: Teodoro Lobo.
Caracas, July 2001.
This project consist in the elaboration of a system, call NMIRE, that allows the capture of
packets that travel in computer networks, and in this way to establish comparison between a
set of variables that determines its performance. Besides, it was made a comparison
between the two versions of the RIP protocol to determine which one is better as a routing
protocol in a specific stage. The finality of this work is to he lp networks administrators to
find problems with services times and traffic generation in networks.
1
INTRODUCCIÓN
En una red de computadoras se envía una gran cantidad de información. Esta
información es generalmente dividida en varias partes, para después ser unida
nuevamente por la máquina que la recibe. Cada una de estas partes es denominada
paquete. De esta forma en la red circulan una gran cantidad de paquetes en el
momento de un envío.
El flujo de paquetes que viaja en la red en un momento específico, se conoce como
tráfico. Cuando muchas máquinas trasmiten paquetes en una red simultáneamente, el
rendimiento de la red disminuye. A medida que el tráfico aumenta los tiempos de
servicio para entregar estos paquetes también lo hacen, y pueden llegar inclusive a
perderse paquetes por el congestionamiento que se genera a raíz del tráfico.
De esta manera, este proyecto ayuda a los administradores de red en búsqueda de
soluciones a este problemas. Esto lo logra mediante la elaboración de un sistema,
llamado NMIRE, que permite establecer comparaciones entre variables que están
directamente relacionadas con el desempeño de la red; además de estudiar ambas
versiones del protocolo RIP para determinar la eficiencia del Router, el cual es un
elemento clave dentro de la red, ya que es el encargado de distribuir los paquetes a
sus respectivos destinos. Para ello tiene como objetivo principal realizar el estudio,
2
en una red piloto LAN para determinar el funcionamiento del sistema y de la red bajo
una gran cantidad de tráfico.
En este sentido, el estudio realizado se estructura dentro de una investigación
comparativa, con diseño experimental.
El marco teórico de la investigación se fundamenta en cómo obtener los paquetes de
la red para poder analizar el funcionamiento de la misma y de cómo funcionan las dos
versiones del protocolo RIP. Para ello se hace refe rencia al protocolo TCP/IP, se
explica detalladamente su modelo de referencia, se habla del protocolo ICMP usado
en la generación del tráfico de las pruebas de la investigación, se establecen
comparaciones entre una red Ethernet y una red IEEE 802.3. Del mismo modo se dan
conceptos esenciales relacionados con los componentes de routing y una lista de los
términos básicos de la investigación, así como una explicación detallada del
protocolo RIP y sus versiones. Por último se hace referencia a Sniffing,
funcionamiento, componentes y análisis de protocolos.
El marco experimental consistió en el estudio del protocolo RIP como protocolo de
enrutamiento y la realización de pruebas utilizando el sistema NMIRE para verificar
las variables que determinan el tráfico de la red. Por último en la cuarta parte del
trabajo se destacan las conclusiones, recomendaciones, referencias bibliográficas y
3
apéndices; en estos se presentan los diagramas de flujo del sistema NMIRE como el
diagrama de entidad - relación de la base de datos y una explicación de cada proceso
y de cada entidad. En los anexos encontramos el manual de usuario del sistema,
donde se explica el funcionamiento de cada pantalla del mismo.
4
P R I M E R A P A R T E
ASPECTOS BÁSICOS PRELIMINARES DEL PROYECTO
“La ciencia es una de las pocas realidades que se pueden legar a las generaciones venideras. Los hombres de cada período histórico asimilan los resultados científicos de las generaciones anteriores, desenvuelven y amplían algunos aspectos nuevos”
RENE DESCARTES
5
1.1 PLANTEAMIENTO DEL PROBLEMA La presencia de una gran cantidad de paquetes dentro de una red, genera
inmediatamente una caída en el rendimiento. Cuando la cantidad de paquetes
descargados en la red por los hosts está dentro de su capacidad, todos se entregan
(excepto aquellos involucrados en errores de transmisión) y la cantidad entregada es
proporcional al número enviado. Sin embargo, a medida que aumenta el tráfico, los
routers ya no pueden manejarlo y comienzan a perder paquetes. Esto tiende a
empeorar las cosas. A muy alto tráfico, el desempeño decae por completo, y casi no
hay entrega de paquetes. El tráfico puede ocurrir por varias razones. Sí
repentinamente comienzan a llegar cadenas de paquetes por tres o cuatros líneas de
entrada 1 y todos necesitan la misma línea de salida, se generará una cola. Sí no hay
suficiente memoria para contenerlos a todos, se perderán paquetes. Si los routers son
lentos para llevar a cabo las tareas de administración requeridas (actualización de
tablas, manejo de mensajes, etc.), pueden alargarse las colas, aún cuando haya un
exceso de capacidad de línea. De la misma manera, las líneas de poco ancho de
banda también pueden causar congestionamientos. La modernización de las líneas
sin cambiar los procesadores, o viceversa, generalmente ayuda un poco, pero con
frecuencia simplemente desplaza en cuello de botella.
1 Una línea de entrada es una conexión entrante en un nodo de la red. Este nodo puede ser una computadora (host), un router, etc.
6
De aquí que los administradores de redes siempre estén en búsqueda de nuevas
alternativas para identificar estos problemas relacionados directamente con el tráfico.
Los sistemas actuales de monitoreo de red, entregan los datos mas no una primera
línea de soporte al administrador de la red, la cual va asociada a la solución del
problema.
El problema está en cómo entregar esa primera línea de soporte que permita tomar las
decisiones de manera puntual y consciente dentro de la red LAN.
7
1.2 OBJETIVOS
1.2.1 OBJETIVOS GENERALES:
?? Desarrollar una celda de prueba que nos permita determinar los puntos críticos
de saturación en una red.
?? Establecer comparaciones entre la utilización de tablas de enrutamiento
manuales y tablas de enrutamiento dinámicas.
1.2.2 OBJETIVOS ESPECÍFICOS:
?? Generar una red piloto de estudio en LAN que permita analizar el tráfico de la
red.
?? Generar un modelo que permita analizar las estadísticas de tráfico y generar
criterios globales y locales con respecto a la red piloto bajo protocolos
ruteables.
?? Generar un sistema que entregue al administrador de la red dichas pautas para
tomar óptimas decisiones en la corrección de problemas.
8
S E G U N D A P A R T E
M A R C O T E Ó R I C O
“Las redes de computadoras pueden prestar un gran número de servicios, tanto para compañías como para individuos. Para las compañías, las redes de computadoras personales que usan servidores compartidos ofrecen con frecuencia flexibilidad y una buena relación precio / rendimiento. Para los individuos, las redes ofrecen acceso a una variedad de recursos de información y distracción.”
ANDREW S. TANENBAUM
9
2.1 TCP/IP
TCP/IP más que un protocolo es un conjunto de protocolos. Se ha convertido en el
estándar de intercomunicación de redes de área extensa y es el único protocolo de
enlace y transporte permitido en Internet.
La idea general de conectar una red con ordenadores diferentes partió de las
investigaciones llevadas a cabo en la Defense Advanced Research Projects Agency
(DARPA). En el ámbito de esta investigación, DARPA desarrollo el conjunto de
protocolos TCP/IP para establecer comunicaciones entre redes e implantó una red que
recibió el nombre de ARPANET, que más tarde se convirtió en Internet. El conjunto
de protocolos TCP/IP define los formatos y normas utilizados en la transmisión y
recepción de información con independencia de cualquier tipo de hardware
determinado u organización de red. A pesar de los protocolos se desarrollaron para la
Internet, TCP/IP se ha convertido en el estándar de hecho ya que muchas
organizaciones públicas y privadas lo utilizan para su conectividad.
El éxito inicial de TCP/IP fue debido a su inclusión en las diferentes variedades del
sistema operativo UNIX y fue impulsado porque su implantación resulta más cómoda
y económica que los protocolos equivalentes. TCP/IP emplea un modelo de
enrutamiento basado en "datagramas" (paquetes) en lugar de circuitos virtuales.
TCP/IP brinda a los arquitectos de sistemas e ingenieros de comunicaciones una
independencia del hardware utilizado.
10
2.1.1 Modelo de Referencia TCP/IP En líneas generales, el conjunto de protocolos TCP/IP se corresponde con el modelo
de comunicaciones de red definido por la International Organization for
Standardization (ISO). Este modelo se denomina modelo de referencia Interconexión
de sistemas abiertos (OSI). El modelo OSI describe un sistema de redes ideal que
permite establecer una comunicación entre procesos de capas distintas y fáciles de
identificar. En el host, las capas prestan servicios a capas superiores y reciben
servicios de capas inferiores. La Figura 1 muestra las siete capas del modelo de
referencia OSI y su correspondencia general con las capas del conjunto de protocolos
TCP/IP.
Figura 1. Modelo de referencia OSI y los protocolos de TCP/IP
correspondientes.
11
El sistema para determinar capas permite a los programadores concentrar sus
esfuerzos en las funciones de una capa determinada. No es necesario que creen todo
los mecanismos para enviar información a lo largo de la red. Sólo tienen que saber los
servicios que el software debe proporcionar a la capa superior, los servicios que las
capas inferiores pueden proporcionar al software y qué protocolos del conjunto
proporcionan estos servicios.
En la tabla 1 se enumeran los protocolos más comunes del conjunto de protocolos
TCP/IP, los servicios que proporcionan.
Tabla 1 Protocolos más comunes de TCP/IP
Protocolos TCP/IP Servicio
Protocolo Internet (IP) Proporciona servicios para la entrega de paquetes (encaminamiento) entre nodos.
Protocolo de control de mensaje Internet (ICMP)
Regula la transmisión de mensajes de error y control entre los host y las gateways.
Protocolo de resolución de direcciones (ARP)
Asigna direcciones Internet a direcciones físicas.
Protocolo de resolución de direcciones invertidas (RARP)
Asigna direcciones físicas a direcciones Internet.
Protocolo de control de transmisión (TCP)
Proporciona servicios de envío de flujos fiables entre los clientes.
Protocolo de datagrama de usuario (UDP)
Proporciona servicio de entrega de datagramas no fiable entre clientes.
Protocolo de transferencia de archivos (FTP)
Proporciona servicios de nivel de aplicación para la transferencia de archivos.
TELNET Proporciona un método de emulación de terminal.
12
Protocolo de información de encaminamiento (RIP)
Permite el intercambio de información de encamina-miento de vectores de distancia entre routers.
Protocolo Abrir la vía más corta primero (OSPF)
Permite el intercambio de información de encamina-miento de estado del enlace entre routers.
Protocolo Gateway externo (EGP)
Permite el intercambio de información de encamina-miento entre routers externos.
13
2.1.2 Descripción general del uso de TCP/IP Las aplicaciones que se desarrollan con TCP/IP, normalmente, usan varios protocolos
del conjunto. La suma de las capas del conjunto de protocolos se conoce también
como el stack de protocolo. Las aplicaciones definidas por el usuario se comunican
con la capa superior del conjunto de protocolos. La capa de nivel superior del
protocolo del computador de origen traspasa la información a las capas inferiores del
stack, y de allí a la red física la cual envía información al ordenador de destino. Las
capas inferiores del stack de protocolo del ordenador de destino transfieren la
información a las capas superiores y posteriormente a la aplicación de destino.
Cada capa del conjunto de protocolos TCP/IP tiene varias funciones; estas funciones
son independientes de las otras capas. No obstante, cada capa espera recibir
determinados servicios de la capa inferior y cada capa proporciona ciertos servicios a
la capa superior.
La Figura 2 muestra las diferentes capas del conjunto TCP/IP. Cada capa del stack de
protocolo del ordenador de origen se comunica con la misma capa del ordenador de
destino. Las capas que se encuentran al mismo nivel en el ordenador de origen y de
destino son pares. Asimismo, la aplicación del ordenador de origen y la del de destino
también son pares. Desde el punto de vista del usuario o programador, la
transferencia de paquetes se efectúa directamente de una capa a otra.
14
Figura 2. Capas de los protocolos TCP/IP. El proceso que utiliza una aplicación para transferir el contenido de un archivo es el
siguiente:
?? La capa de la aplicación envía un flujo de bytes a la capa de transporte del
ordenador de origen.
?? La capa de transporte divide el flujo en segmentos TCP, asigna un encabezado
con un número de secuencia al segmento en cuestión y transmite este
segmento a la capa de Internet (IP). Se calcula la suma de comprobación.
15
?? La capa de IP crea un paquete con parte de los datos que contiene el segmento
TCP. La capa de IP añade al paquete un encabezado que indica las direcciones
IP de origen y de destino. Esta capa también determina la dirección física del
ordenador de destino o los ordenadores que actúan como intermediarios hasta
el host de destino. Entonces, envía el paquete y la dirección física a la capa de
enlace de datos. Se vuelve a calcular la suma de comprobación.
?? La capa de enlace de datos transmite el paquete IP en la sección de datos de
una trama de enlace de datos al ordenador de destino. Si el ordenador de
destino actúa como intermediario, el paso 3 volverá a repetirse hasta que se
alcance el destino final.
?? Cuando se alcanza el ordenador de destino, la capa de enlace de datos descarta
el encabezado del enlace y envía el paquete IP a la capa de IP.
?? La capa de IP verifica el encabezado del paquete. Si la suma de comprobación
del encabezado no coincide con la calculada por dicha capa, el paquete se
ignora.
?? Si las sumas coinciden, la capa IP descarta el encabezado y envía el segmento
TCP a la capa TCP correspondiente. Esta capa comprueba el número de
secuencia para determinar si el segmento, es el segmento correcto de la
secuencia.
?? La capa TCP calcula una suma de comprobación para los datos y el
encabezado TCP. Si la suma no coincide con la suma transmitida con el
16
encabezado, la capa TCP descarta el segmento. Si la suma coincide y el
segmento está en la secuencia correcta, la capa TCP envía un reconocimiento
al ordenador de destino.
?? La capa TCP descarta el encabezado TCP y transfiere los bytes del segmento
que acaba de recibir a la aplicación.
?? La aplicación que se encuentra en el ordenador de destino recibe un flujo de
bytes como si estuviera conectado directamente a la aplicación del ordenador
de origen.
2.1.2.1 CAPA DE INTERRED Esta capa es el eje que mantiene unida toda la arquitectura. La misión de esta capa es
permitir que los nodos inyecten paquetes en cualquier red y los hagan viajar de forma
independiente a su destino (que podría estar en una red diferente). Los paquetes
pueden llegar incluso en un orden diferente a aquel en que se enviaron, en cuyo caso
corresponde a las capas superiores volver a ordenarlas, si se desea la entrega
ordenada. La Figura 3 muestra una comparación entre el modelo de referencia OSI y
el modelo de referencia TCP/IP.
17
O S I TCP/IP
7 APLICACIÓN APLICACIÓN
6 PRESENTACIÓN
5 SESIÓN
4 TRANSPORTE TRANSPORTE
3 RED INTERRED
2 ENLACE DE DATOS
1 FÍSICA HOST A RED
Figura 3. Modelo de referencia OSI y las capas del Modelo TCP/IP
correspondientes.
La capa de interred define un formato de paquete y protocolo oficial llamado IP
(Internet protocolo, protocolo de interred). El trabajo de la capa de interred es
entregar los paquetes IP a donde se supone que deben ir. Aquí la consideración más
importante es claramente el ruteo de los paquetes , y también evitar la congestión. Por
lo anterior es razonable decir que la capa de interred TCP/IP es muy parecida en
funcionalidad a la capa de red de OSI.
2.1.2.2 CAPA DE TRANSPORTE Esta capa se diseñó para permitir que las entidades pares en los nodos de origen y
destino lleven a cabo una conversación lo mismo que en la capa de transporte OSI.
Aquí se definieron dos protocolos de extremo a extremo. El primero, TCP
18
(TRANSMISSION CONTROL PROTOCOL, protocolo de control de transmisión) es
un protocolo confiable orientado a la conexión que permita que una corriente de bytes
originada en una máquina se entregue sin errores en cualquier otra máquina de la
interred. Este protocolo fragmenta la corriente entrante de bytes en mensaje s
discretos y pasa cada uno a la capa de interred. En el destino, el proceso TCP
receptor reensambla los mensajes recibidos para formar la corriente de salida. El
TCP también se encarga del control de flujo para asegurar que un emisor rápido no
pueda abrumar a un receptor lento con más mensajes de los que pueda manejar.
El segundo protocolo de esta capa es el UDP (USER DATAGRAM PROTOCOL), es
un protocolo sin conexión, no confiable, para aplicaciones que no necesitan la
asignación de secuencias ni el control de flujo del TCP y que desean utilizar los suyos
propios. Este protocolo también se usa ampliamente para consultas de petición y
respuesta de una sola ocasión, del tipo cliente-servidor, y en aplicaciones en las que la
entrega pronta es más importante que la entrega precisa, como las transmisiones de
voz o de vídeo.
2.1.2.3 CAPA DE APLICACIÓN
El modelo TCP/IP no tiene capas de sesión ni de presentación. No se pensó que
fueran necesarias, así que no se incluyeron. La experiencia con el modelo OSI ha
comprobado que esta visión fue correcta: se utiliza muy poco en la mayor parte de las
aplicaciones.
19
Encima de la capa de transporte está la capa de aplicación, que contiene todos los
protocolos de alto nivel. Entre los protocolos más antiguos están el de terminal
virtual TELNET, el de transferencia de archivos FTP y el de correo electrónico
SMTP. El protocolo de terminal virtual permite que un usuario en una máquina
distante trabaje ahí. El protocolo de transferencia de archivos ofrece un mecanismo
para mover datos de una máquina a otra en forma eficiente. El correo electrónico fue
en sus orígenes sólo una clase de transferencia de archivos, pero más adelante se
desarrolló para él un protocolo especializado; con los años, se le han añadido otros
protocolos, como el servicio de nombres de dominio DNS para relacionar los
nombres de los nodos con sus direcciones de la red; NNTP, el protocolo que se usa
para transferir artículos noticiosos; HTTP, el protocolo que se usa para recuperar
páginas en la WORLD WILD WEB y muchos otros.
20
2.1.3 PROTOCOLO TCP
El protocolo TCP (Protocolo de Control de Transmisión) define la manera en que la
información será dividida en paquetes y enviada a través de Internet. Para tener una
idea de este protocolo, podríamos imaginar que queremos regalar un libro, el cual
dividimos separándolo en capítulos, y utilizamos para su transporte diferentes
medios, como por ejemplo, autobuses, la oficina postal y mensajería privada. Está
claro que los capítulos llegarán a su destino en diferentes momentos y en distinto
orden, y la persona que lo reciba tendrá que revisar los números de los capítulos y
recomponer el libro en el orden correcto.
21
2.1.4 PROTOCOLO IPv4 El protocolo IP es el protocolo primario de la capa de interred2. Además para el ruteo
de paquetes en una red, IP provee fragmentación y reensamblaje de datagramas y
reporte de errores. En conjunto con TCP, IP representa el corazón de los Protocolos
de Internet. El formato de los paquetes Ip se muestra en la Figura 4:
? ----------------------------------------------- 32 bits -----------------------------------------------?
Versión IHL Type-of-service Total length
Identification Flags Fragment offset
Time-to-live Protocol Header checksum
Source address
Destination address
Options (+ padding)
Data (variable)
Figura 4. Formato de Paquete IP.
2 Ver modelo de referencia TCP/IP, corresponde a la capa de red en el modelo de referencia OSI.
22
Los campos del paquete IP son los siguientes:
?? Versión – Indica la versión de IP que se está usando.
?? IP header length (IHL) – Indica el tamaño del cabecero del datagrama en una
palabra de 32 bits.
?? Type-of-Service – Especifica cómo un protocolo de capa superior desearía
manejar el datagrama. Aquí se pueden especificar distintos niveles de
importancia al datagrama.
?? Total Length – Tamaño total del datagrama, incluyendo el cabecero y el
cuerpo en bytes.
?? Identification – Tiene un entero que especifica el número del datagrama. Este
campo es usado para unir los fragmentos de datagramas.
?? Flags – Es un campo de 3 bits, de los cuales los dos primeros son usados para
controlar la fragmentación. Un bit especifica si el paquete puede ser
fragmentado, y el segundo bit, especifica si el paquete es el último de una
serie de fragmentos de un paquete.
?? Time-to-live – Mantiene un contador que regularmente decrementa hasta cero,
y en ese caso el datagrama se desecha. Esto previene que los paquetes entren
en loops infinitos.
?? Protocol – Indica un protocolo de capa superior que recibirá los paquetes
entrantes después que el proceso de IP termine.
23
?? Header checksum – Ayuda a verificar la integridad del cabecero IP.
?? Source address – Especifica el nodo que envió el paquete.
?? Destination address - Especifica el nodo que recibirá el paquete.
?? Options – Permite a IP tener varias opciones, entre las cuales se encuentran la
seguridad.
?? Data – Contiene la información de capa superior.
2.1.4.1 DIRECCIONAMIENTO
El protocolo IP establece un sistema de direcciones que identifica a cada host de
forma única. Todos los equipos y dispositivos de comunicaciones en una red TCP/IP
han de tener una dirección IP única para poder establecerse la comunicación.
Cada vez que se envía un paquete a la red ésta determina el camino que seguirá hasta
su destino. La dirección IP es un número de 4 bytes (32bits) que se representa como
4 enteros entre 0 y 255.
Cada dirección IP de 4 bytes se divide en dos partes:
?? Una porción de la red, que identifica la red.
?? Una porción del Host, que identifica el nodo.
24
Las direcciones IP se dividen en tres clases según los dos bits más importantes de los
cuatro primeros bytes. Esto se hace para que los route rs puedan extraer la porción de
la red de la dirección de manera eficiente.
A pesar de la clase de dirección, todos los nodos de una red única comparten la
misma porción de la red; cada nodo tiene una porción única.
Un ejemplo de una dirección IP de un host sería 194.224.78.16.
Para facilitar el encaminamiento de los datagramas, las direcciones de IP se agrupan
en redes. Una red es un grupo de direcciones IP que tienen en común una parte de su
dirección. La dirección IP anterior hace referencia al host número 16 de la red
194.224.78.0
En este caso la dirección IP de la red sería 194.224.78.0.
Por convenio la dirección de una red se obtiene a partir de los bits que tiene en común
todas las direcciones de ella, con los demás bits puestos a cero. Dado que cada
dirección IP se compone de 4 números enteros entre 0 y 255, la red comprende todas
las direcciones desde 194.224.78.1 hasta 194.224.78.254. El número 0 se reserva para
el número de la red y el número 255 es la dirección de difusión de la red, cualquier
datagrama enviado a la dirección de difusión será recibido y procesado por todos los
hosts de la red.
El direccionamiento IP soporta cinco tipos diferentes de clases. Los bits que se
encuentran a la izquierda de la dirección determinan el tipo de clase.
25
?? Clase A – Estas direcciones son destinadas principalmente para uso en pocas
redes de gran tamaño, esto se debe a que utilizan únicamente 7 bits, de los 32
disponibles, para identificar a la red.
?? Clase B – Permiten 14 bits para identificar a la red y 16 bits para el campo de
los nodos. Estas direcciones ofrecen gran correlación entre la cantidad de
redes y la cantidad de nodos en cada red.
?? Clase C – Las redes tienen 22 bits que las identifican. Estas direcciones
permiten únicamente 8 bits para identificar a los nodos.
?? Clase D – Este direccionamiento está reservado para grupos multicast3. En
las clase d los cuatro primeros bits de la dirección están definidos de la
siguiente manera: 1, 1, 1 y 0; en ese mismo orden.
?? Clase E – Estas direcciones también están definidas por IP pero están
reservadas para uso futuro. En estas direcciones los cuatro primeros bits están
definidos por 1.
3 Para mayor información ver el documento oficial RFC 1112.
26
La Figura 5 muestra los formatos de direccionamiento clase A, B y C para redes IP.
0
Clase A
Red
Host
1 0 Clase B
Red
Host
1 1 0 Clase C
Red
Host
Figura 5. Formato de direccionamiento clase A, B y C para redes IP. 2.1.4.1.1 Direcciones de Clase A Una dirección IP de la clase A consiste en una porción de la red de un byte seguido
por una porción del Host de 3 bytes. El bit de mayor orden del byte de la porción de
red se define siempre a 0. Por lo tanto se dispondrán de un total de 126 redes de la
Clase A (1 a 126) y con más de 16 millones de nodos por red, (las redes entre 0 y 127
están reservadas)
Por ejemplo, n = dirección de red y h = dirección de host
Clase A 0nnnnnnn.hhhhhhhh.hhhhhhhh.hhhhhhhh
27
2.1.4.1.2 Direcciones de Clase B Una dirección IP de la clase B consiste en una porción de la red de dos bytes seguido
por una porción del Host de 2 bytes. Los dos bits de orden superior de la porción de
red se definen siempre a 10. Por lo tanto se dispondrán de aproximadamente 16.000
redes de la Clase B (desde 128.x a 191.x) y con más de 65.000 nodos por red.
Por ejemplo, n = dirección de red y h = dirección de host
Clase A 10nnnnnn.nnnnnnnn.hhhhhhhh.hhhhhhhh
2.1.4.1.3 Direcciones de Clase C Una dirección IP de la clase C consiste en una porción de la red de tres bytes seguido
por una porción del Host de 1 bytes. Los tres bits de orden superior de la porción de
red se definen siempre a 110. Por lo tanto se dispondrán de aproximadamente 2
millones de redes de la Clase C (desde 192.x.x a 223.x.x) y con 254 nodos por red.
Por ejemplo, n = dirección de red y h = dirección de host
Clase A 10nnnnnn.nnnnnnnn.nnnnnnnn.hhhhhhhh
Existen empresas y grupos de usuarios cuyas necesidades no llegan a los 254 hosts.
Para atender las necesidades de estos grupos mas reducidos se crean subredes que
segmentan las clases A, B o C.
28
Dirección Red Máscara 1er Host Ultimo Host
194.224.78.0 255.255.255.0 194.224.78.1 194.224.78.254
194.224.78.128 255.255.255.128 194.224.78.129 194.224.78.254
194.224.78.240 255.255.255.254 194.224.78.241 194.224.78.242
2.1.4.1.4 Direcciones IP Reservadas Las reglas de direccionamiento IP reservan los siguientes tipos de direcciones IP para
propósitos especiales:
?? Direcciones de la red - Estas son las direcciones IP en las que la porción del
Host está definida por ceros. Por ejemplo la dirección 129.47.0.0 es la
dirección o numero de red correspondiente a una red Clase B.
?? Direcciones de difusión general - Son direcciones en las que la porción del
Host está definida en todos (255). Un paquete con una dirección de difusión
general se destina a todos los nodos de la red. Por norma general, ningún nodo
tiene asignado una porción del Host formada sólo por unos.
?? Direcciones de retorno de bucle - La dirección de la red 127.0.0.0, y todas las
direcciones del Host en la red, por ejemplo, 127.0.0.1, son reservadas.
?? Direcciones reservadas - Son direcciones en las que la porción de red está
formada por ceros o todos (255).
29
2.1.4.1.5 Creación de subredes Una red Internet (en una dirección de la red Internet única) puede dividirse en una o
más redes más pequeñas. En la parte inferior están listadas algunas de las razones
para dividir la red:
?? Usar varios medios - Puede ser imposible, inconveniente o demasiado caro
conectar todos los nodos en un medio de la red única cuando estos nodos
están demasiado lejos o conectados a un medio diferente.
?? Reducir la congestión - El tráfico entre nodos en una red única usa un ancho
de banda de la red. Como resultado, se requieren más anchos de banda cuando
el usuario tiene más nodos. La división de los nodos en varias redes reduce el
número de nodos de la red. Si los nodos de una red de tamaño pequeño se
comunican principalmente con otros nodos de la misma red, el nivel de
congestión se reduce.
?? Reducir el uso del CPU - La reducción del uso de CPU los nodos conectados
es similar a la reducción de la congestión. Más nodos en la red causan más
difusiones generales en la red. Incluso si una difusión general no se envía a un
nodo en particular, cada nodo de una red debe reaccionar ante la misma antes
de decidir si debe aceptar o descartarse.
?? Aislar una red - La división de una red de mayor tamaño en redes más
pequeñas, limita el impacto de uno de los problemas de la red sobre otra.
Entre estos problemas se pueden incluir el error de hardware de la red, como
30
una interconexión Ethernet abierta, o errores de software, como una operación
de emisión confusa.
?? Mejorar el nivel de seguridad - En un medio de red de difusión general como
es Ethernet, cada nodo de una red tiene acceso a todos los paquetes enviados a
la misma. Si se permite sólo un tráfico de red sensitivo en una red, otros
monitores de red pueden evitar el acceso a éste tipo de tráfico.
?? Hacer uso eficiente del espacio de la dirección IP - Si está asignando un
número de red Clase A o B y tiene varias redes físicas pequeñas, puede dividir
el espacio de dirección IP en varias subredes IP y asignarles redes físicas
individuales. Con el uso de este método, no necesita conseguir más números
de redes IP por cada red física.
2.1.4.1.6 Máscaras y direcciones de subredes Cada subred funciona como si fuera una red independiente. Para redes remotas, sin
embargo, las subredes aparecen colectivamente como redes discretas y únicas. Esto
significa que la red local sólo necesita una dirección de red IP y estas redes remotas
no necesitan poner atención en la ubicación de un nodo en una subred particular.
La comunicación entre un nodo en una subred local y un nodo en una subred
diferente es parecida a la comunicación entre nodos de dos redes diferentes. Para un
usuario, el encaminamiento entre subredes es transparente. Internamente, el software
IP reconoce cualquier dirección IP que esté destinada a una subred y envía estos
paquetes al router de la misma.
31
Al igual que en la comunicación entre redes, la información del encaminamiento para
la comunicación de la subred entre subredes se mantiene en la tabla de
encaminamiento (por IP) para cada nodo o router. Sin embargo, en el caso de las
subredes, dicha información está formada por la dirección de la red y la dirección de
la subred.
Cuando una red se distribuye en varias subredes, la porción del Host de la dirección
IP se divide en dos partes, al igual que la dirección IP se divide en dos partes (4 bytes
en total). La porción de la dirección del Host especifica la subred de la red IP y el
nodo de dicha subred.
Por ejemplo, si una red tiene la porción de la dirección de la red Clase B 129.47, el
resto de dicha dirección se puede dividir en direcciones de subred y del Host. Esta
división está controlada por la red local a fin de obtener una mayor flexibilidad en el
funcionamiento de la red a nivel local. Por ejemplo, la dirección de subred puede
contener cuatro bits de los dos bytes restantes. Esto permite 15 subredes, cada una
con 4094 nodos. En otro ejemplo, la dirección de la subred puede contener ocho bits,
lo que permite usar 254 subredes (una dirección de subred de todos los unos no es
válida), cada una con 254 nodos.
Una máscara de subredes indica cómo se divide la porción del Host de una dirección
IP en direcciones de subredes y porciones de dirección del Host local. La máscara de
la red está representada por un número de 32 bits en el que las porciones de dirección
de red y subred están formadas por una dirección IP completa y todas las del Host por
32
ceros. Por ejemplo, con una porción de la dirección de la red IP de Clase B de 129.47
y una dirección de la subred de 4 bits, la máscara de subred constará de 20 unos y 12
ceros. En resumen, una máscara de subred amplía la porción de la dirección de la red
de una dirección IP local.
Por ejemplo, en una red clase B con una dirección IP 128.10.0.0 (los ceros en el
campo del host representan la red completa). En lugar de cambiar todas las
direcciones a otra dirección, el administrador puede subdividir la red utilizando
subredes. Esto se logra tomando bits del campo de host y usándolos para representar
la subred, como se muestra en la Figura 6:
Dirección Clase B: antes de hacer la subred
Clase B 1 0
Red Host
Dirección Clase B: después de hacer la subred
Clase B 1 0
Red Subred Host
Figura 6. Dirección de una subred.
Si el administrador de la red decide usar 8 bits para representar a la subred, el tercer
octeto de una dirección IP clase B, tendrá la subred. Por ejemplo, la dirección
33
128.10.1.0 hace referencia a la red 128.10, subred 1; la dirección 128.10.2.0 hace
referencia a la red 128.10, subred 2; y así sucesivamente.
El número de bits prestados para la dirección de subred es variable. Para especificar
cuantos bits son usados, debemos hacer referencia a la mascara de red. La s mascaras
de red utilizan las mismas técnicas de representación y formato que las direcciones
IP. Las mascaras de red tienen un 1 en todos los bits exceptuando aquellos que
representan a los host. Por ejemplo, la mascara de red que especifica 8 bits de subred
para una dirección clase A 34.0.0.0 es 255.255.0.0. La mascara de red que especifica
16 bits para una dirección clase A 34.0.0.0 es 255.255.255.0. Ambas subredes se
muestran en la Figura 7 :
Dirección
Clase A 0 0 1 0 0 0 1 0 < 0 > < 0 > < 0 > 34.0.0.0
Mascara:
8 bits de
Subred
< 1 > < 1 > < 0 > < 0 > 255.255.0.0
34
Dirección
Clase A 0 0 1 0 0 0 1 0 < 0 > < 0 > < 0 > 34.0.0.0
Mascara:
16 bits de
Subred
< 1 > < 1 > < 1 > < 0 > 255.255.255.0
Figura 7. Ejemplo de una máscara de red para una dirección clase A.
35
2.1.5 PROTOCOLO ICMP
El protocolo ICMP realiza varias tareas dentro de una red de IP. La razón principal
por la que fue creado, era para reportar fallas en las rutas del router. Además, ICMP
provee los siguientes mensajes:
?? Echo y Reply - para realizar pruebas del alcance a cada nodo de la red.
?? Redirect - para estimular eficientemente el ruteo.
?? Time exceeded – para informar cuando un datagrama ha excedido el tiempo de
vida permitido para existir dentro de la red.
?? Router advertisement y router solicitation – para determinar las direcciones
de otros routers conectados a otras subredes.
Recientemente se ha agregado una característica más a ICMP, la cual permite a que
nuevos nodos descubrir la máscara de subred que se está usando en la red.
36
2.2 ETHERNET / IEEE 802.3 El término Ethernet se refiere a una implementación de LAN que se incluye dentro de
tres categorías:
?? Ethernet e IEEE 802.3 – Especificación de LAN que opera a 10 Mbps con
cable coaxial o con cable de pares trenzados.
?? 100-Mbps Ethernet – Una simple especificación de LAN, también conocida
como FAST ETHERNET, que opera a 100 Mbps con un cable de pares
trenzados.
?? 1000-Mbps Ethernet – Otra especificación simple de LAN, también conocida
como GIGABIT ETHERNET, que opera a 1000 Mbps (1 Gbps) sobre una
fibra óptica o un cable de pares trenzados.
Ethernet ha sobrevivido como una tecnología de medios esencial, esto es debido a su
tremenda flexibilidad y su relativa simplicidad para entender e implementar.
37
2.2.1 COMPARACIÓN ETHERNET / IEEE 802.3
Ambos tienen especificaciones similares. Los dos utilizan una red LAN con
CSMA/CD. Las estaciones de trabajo en una LAN CSMA/CD pueden acceder a la
red en cualquier momento. Antes de enviar la data, las estaciones CSMA/CD
“escuchan” a la red para ver si está trabajando. Si lo está, la estación deseando
transmitir, espera. Si la red no está siendo usada, la estación transmite. Cuando dos
estaciones transmiten al mismo tiempo, ocurren las colisiones. En este caso, los dos
paquetes enviados por las estaciones se pierden, y deberán ser enviados nuevamente
más tarde. Existen algoritmos llamados BACKOFF los cuales determinan cuando
estas estaciones deberán transmitir. Las estaciones CSMA/CD pueden detectar las
colisiones, por este motivo, pueden conocer el momento en el cual pueden volver a
transmitir.
Tanto Ethernet como IEEE 802.3 son redes de broadcast. En otras palabras, todas las
estaciones pueden ver todos los paquetes. Todas las estaciones deben examinar los
paquetes recibidos para determinar si la estación es el destino. Si es así, el paquete es
pasado a un protocolo de capa superior para su apropiado procesamiento.
38
2.2.2 FORMATO DE LOS PAQUETES ETHERNET Y IEEE 802.3 La Figura 8 muestra los formatos de los paquetes Ethernet y IEEE 802.3. Cada
campo está medido en bytes.
Ethernet. 8 6 6 2 46-1500 4
Preámbulo Dirección de Destino
Dirección de Origen Tipo Data FCS
IEEE 802.3 7 1 6 6 2 46-1500 4
Preámbulo S O F
Dirección de Destino
Dirección de Origen Tamaño
Encabezado 802.2 y Data
FCS
Figura 8. Formato de los Paquetes Ethernet y IEEE 802.3 SOF = START-OF-FRAME DELIMITER (Delimitador del Comienzo del Paquete).
FCS = FRAME CHECK SEQUENCE (secuencia de chequeo del paquete).
?? Preámbulo – El patrón alternativo de unos y cero le indica a la estación que
recibe el paquete, que el paquete está llegando (Ethernet o IEEE 802.3). El
paquete de Ethernet incluye un byte adicional que es el equivalente del SOF
en el IEEE 802.3.
?? SOF – El delimitador de IEEE 802.3, termina con dos bits 1, los cuales sirven
para sincronizar la recepción de paquetes de todas las estaciones en la LAN.
39
?? Dirección de Destino y de Origen – La dirección de origen es siempre unicast
(un solo nodo), mientras que la dirección de destino puede ser unicast,
multicast (un grupo de nodos), o broadcast (todos los nodos).
?? Tipo (Ethernet) – especifica el protocolo de capa superior que debe recibir el
paquete luego que el proceso de Ethernet esté completo.
?? Tamaño (IEEE 802.3) – especifica el tamaño, en bytes, de la data que sigue a
este campo.
?? Data (Ethernet) – Luego que el proceso en la capa física (capa 1 en OSI) y la
capa de enlace de datos (capa 2 en OSI) está completa, la data es enviada al
protocolo especificado en el campo anterior. Al menos 46 bytes se necesitan
en este campo, para que el paquete sea considerado como válido.
?? Data (IEEE 802.3) – El protocolo que debe encargarse del paquete luego de la
capa 1 y la capa 2, es definido dentro de la data del paquete.
?? FCS – Este es un número que es calculado por la estación que envía el
paquete y que luego es calculado nuevamente por la estación que lo recibe,
todo esto sirve para verificar la integridad del paquete.
40
2.3 CONCEPTOS ESCENCIALES PAQUETE: un paquete es un mensaje corto, el cual es enviado de una máquina a
otra. Todo lo que se trasmite por una red es subdividido en unidades más pequeñas
para poder enviarlo por partes. Estas unidades más pequeñas son conocidas como
paquetes.
HOST: es una máquina (o computadora) destinada a ejecutar programas de usuario
(es decir, de aplicación).
ROUTER: se encarga de realizar el trabajo para establecer las conexiones externas y
convertir el protocolo IP a protocolos de WAN y LAN. Los paquetes de datos
transmitidos hacia Internet, desde un visualizador de una PC, pasarán a través de
numerosos routers a lo largo del camino, cada uno de los cuales toma la decisión de
hacia donde dirigir el paquete. Los routers toman sus decisiones basándose en tablas
de datos y reglas, por medio de filtros, así que, por ejemplo, solo datos de una cierta
dirección pueden pasar a través del router.
RUTEO DE TCP/IP: el ruteo de IP es el proceso de mandar paquetes de una red a
otra a través de routers. En la terminología de IP al router se le refiere como un
gateway. La ruta que utiliza un router para entregar el paquete es definida como tabla
de routing.
41
La tabla de routing, contiene entradas con las direcciones IP de las interfaces de los
routers de otras redes. Por default un router puede rutear paquetes a redes que tengan
la interface configurada.
Cuando un host intenta la comunicación con un host en una red diferente, IP utiliza la
dirección del default gateway del host para entregar el paquete al router.
En el router, la tabla de ruteo es consultada para una ruta de esa red. Si la ruta no se
encuentra, el paquete es mandado a la dirección del gateway, sino es configurado.
Cuando el router es encontrado, el paquete es mandado a la red y después entregado
al host de destino. Si el router no se encuentra, un mensaje de error es mandado al
host fuente.
RUTEO DINÁMICO: el ruteo dinámico es una función de protocolos inter-
ruteados, como el RIP y el OSPF. Los protocolos de ruteo periódicamente
intercambian rutas para conocer redes a través de routers dinámicos. Si una ruta
cambia, otros routers son automáticamente informados del cambio.
RUTEO ESTÁTICO: el ruteo estático es una función de IP. Los routers estáticos
requieren que las tablas de ruteo sean construidas y actualizadas manualmente, por lo
42
tanto, los cambios no son propagados aunque los routers estáticos se comuniquen con
routers dinámicos.
RED LAN: las redes de área local, generalmente llamadas LAN (LOCAL AREA
NETWORKS), son redes de propiedad privada dentro de un solo edificio o campus de
hasta unos cuantos kilómetros de extensión. Se usan ampliamente para conectar
computadoras personales y estaciones de trabajo en oficinas de compañías y fábricas
con objeto de compartir recursos (por ejemplo, impresoras) e intercambiar
información. Las LAN se distinguen de otro tipo de redes por tres características:
?? Su tamaño,
?? Su tecnología de transmisión,
?? Su topología.
Las LAN están restringidas en tamaño, lo cual significa que el tiempo de transmisión
del peor caso está limitado y se conoce de antemano. Conocer este límite hace
posible usar ciertos tipos de diseños que de otra manera no serían prácticos, y también
simplifica la administración de la red.
SISTEMAS AUTÓNOMOS: es un conjunto de routers que trabajan en el mismo
grupo administrativo.
43
CSMA/CD: (Carrier Sense Multiple Access/Collision Detect). Un conjunto de
reglas, las cuales determinan cómo los dispositivos de una red deben responder
cuando existen dos entidades tratando de usar los canales de transmisión al mismo
tiempo (llamado colisión). El estándar Ethernet utiliza CSMA/CD. Este estándar
permite a los dispositivos detectar cuando ocurre una colisión, uno de los dispositivos
espera un tiempo aleatorio y luego intenta enviar el paquete nuevamente. Si vuelve a
ocurrir una colisión, el dispositivo debe esperar el doble del tiempo para volver a
enviar el paquete. Esto es conocido como BACK OFF exponencial.
IP: (Internet Protocol). Cada host y router de Internet tiene una dirección IP, que
codifica su número de red y número de host. La combinación es única: no hay dos
máquinas que tengan la misma dirección de IP. Todas las direcciones de IP son de 32
bits de longitud y se usan en los campos de dirección de origen y de destino de los
paquetes IP.
UNICAST: especifica una dirección de un simple nodo de la red.
MULTICAST: transmisión ONE-TO-MANY (uno para muchos). El RFC 1112
describe IP Multicast como: "la transmisión de un paquete IP a un grupo de host, un
conjunto de ceros o más hosts identificados por una simple dirección de IP. Un
paquete multicast es enviado a todos los miembros de un grupo de hosts con las
44
mismas especificaciones de un paquete Ip de unicast. La permanencia de un grupo de
hosts es dinámica; es decir, un host puede entrar y salir de un grupo en cualquier
momento”.
BROADCAST: transmisión ONE-TO-ALL (uno a todos), donde el transmisor envía
el mensaje a todos los nodos de la red, aunque ninguno lo haya solicitado.
MAC ADDRESS (Dirección de Hardware): Media Access Control. como en una
red cada máquina comparte el mismo cable de Ethernet, cada una debe tener un único
identificador. Este identificador se compone por un número hexadecimal de doce
dígitos para cada hardware de una red (Ej. tarjetas de red).
La dirección MAC es un número de 48 bits. Los primeros 24 bits corresponden al
vendedor del dispositivo, los siguientes 24 bits es un serial asignado por el vendedor.
Esto garantiza que ningún dispositivo tenga la misma dirección MAC (a menos que el
vendedor se equivoque). Direcciones repetidas causarían un problema muy grande,
de esta forma el valor único de cada dispositivo es muy importante. Este número de
24 bits es conocido como OUI (Organizationally Unique Identifier). Sin embargo, el
OUI es en realidad un número de 22 bits, los otros dos bits son usados con otros
propósitos. Un bit indica si la dirección es de broadcast o multicast, el otro bit indica
45
si la dirección ha sido reasignada con algún propósito en especial del administrador
de la red local.
Para saber la dirección MAC de una computadora se debe ejecutar el comando
winipcfg.exe desde una computadora Win9x, sí estamos en una computadora que usa
WinNT se debe ejecutar el comando ipconfig.exe / all.
46
2.3.1 COMPONENTES DE ROUTING (RUTEO) El ruteo es el proceso de llevar información a través de una red desde un origen a un
destino. En el camino por lo menos un nodo intermedio es normalmente encontrado.
El ruteo comprende dos actividades básicas: Determinación del camino óptimo y el
transporte de grupos de información (llamados paquetes) a través de una red. El
transporte de los paquetes, también conocido como switching, es relativamente
sencillo, mientras que determinar el camino óptimo resulta ser una labor complicada.
2.3.1.1 DETERMINACIÓN DEL CAMINO Los routers para determinar el camino óptimo a un nodo, utilizan una medida
estándar conocida como métrica, por ejemplo, el tamaño o longitud del camino. Para
facilitar el proceso, existen algoritmos de ruteo que se encargan de inicializar y
mantener tablas de ruta, las cuales contienen información de todos los caminos de un
router. Esta información varia según el algoritmo que se utilice.
Un ejemplo típico de la información que puede tener esta tabla de rutas, es el Destino
/ próximo hop asociado, el cual le dice al router que un destino en particular puede ser
alcanzado óptimamente, enviando el paquete a un router específico “próximo hop” en
la vía del destino final. Cuando un router recibe un paquete, verifica la dirección de
47
destino e intenta asociarla con un próximo hop. La Figura 9 muestra un ejemplo de
una tabla de ruta de Destino / próximo hop.
Red Enviar a:
27 Nodo A
57 Nodo B
17 Nodo C
24 Nodo A
52 Nodo A
16 Nodo B
26 Nodo A
.
.
.
.
.
.
Figura 9. Tabla de Ruta Destino /próximo hop.
Las tablas de ruta pueden contener más información, tales como tiempos de
transmisión, etc. Cada router se comunica con los otros (y mantienen sus tablas de
ruta) mediante el envío de una variedad de mensajes. Los mensajes de actualización
son uno de ellos. Los mensajes de actualización generalmente consisten en toda o
una porción de la tabla de ruta. Un router, analizando los mensajes de todos los
demás, puede construir una imagen detallada de la topología de la red. Una vez que
48
la topología de la red es entendida, los routers pueden determinar el camino óptimo a
un destino.
2.3.1.2 SWITCHING Los algoritmos de switching son relativamente fáciles y son utilizados por la mayoría
de los protocolos de ruteo. En la mayoría de los casos, un host determina que debe
enviar un paquete a otro host. Habiendo obtenido la dirección del router de alguna
forma, el host de origen envía el paquete específicamente a la dirección física del
router (Media Access Control [MAC]-layer), pero con la dirección (capa de red) de
protocolo del host de destino.
Examinando la dirección de destino del pa quete, el router determina si puede o no
reenviar el paquete a otro hop. Si el router no sabe como enviar el paquete,
normalmente lo elimina. Si el router conoce como enviarlo, entonces cambia la
dirección física de destino a la dirección del próximo hop y luego reenvía el paquete.
El próximo hop puede o no ser el hop de destino. Si no lo es, el próximo hop es
normalmente otro router, el cual ejecuta el mismo proceso de switching. Mientras el
paquete viaja por la red, su dirección física de destino cambia constantemente,
mientras que la dirección de protocolo permanece constante. Este proceso es
ilustrado en la Figura 10 :
49
Figura 10. Proceso de Switching.
Lo anterior describe el switching entre un origen y un destino o sistema final. La
Organización Internacional de Estándares (ISO – International Organization for
Standardization), ha desarrollado una terminología jerárquica la cual es útil para
describir este proceso. Usando esta terminología, los componentes de una red que no
poseen la habilidad de retransmitir paquetes a través de una subred, son llamados
A: Nodo de Destino (Dirección de protocolo). Router 1 (Dirección física).
A: Nodo de Destino (Dirección de protocolo). Router 2 (Dirección física).
A: Nodo de Destino (Dirección de protocolo). Router 3 (Dirección física).
A: Nodo de Destino (Dirección de protocolo). Nodo de Destino (Dirección física).
Router 2
Router 1
Router 3
PC
PC
50
Sistemas Finales (Ess – End Systems), mientras que los componentes que sí poseen
esta habilidad, son llamados Sistemas Intermedios (ISs – Intermediate Systems).
Los ISs están divididos en aquellos que pueden comunicarse sin el uso de dominios
de routing (Intradomain ISs) y en los que se pueden comunicar con o sin dominios de
routing. Un dominio de routing es generalmente considerado por ser una porción de
una red que se encuentra bajo una autoridad administrativa, regulada por una serie de
directivas. Los dominios de routing son llamados también Sistemas Autónomos
(Autonomous Systems). Con ciertos protocolos, los dominios de routing pueden ser
divididos en áreas de routing, pero los protocolos de Intradomain routing seguirían
siendo usados para switching con o sin y entre áreas.
51
2.3.2 ALGORITMOS DE RUTEO
Los algoritmos de ruteo pueden ser divididos según ciertas características. Primero,
el objetivo particular del diseñador de l algoritmo afecta el funcionamiento del
protocolo de ruteo resultante. Segundo, hay varios tipos de algoritmos de ruteo.
Cada algoritmo tiene un impacto diferente en la red y en los routers. Finalmente,
Estos algoritmos usan una variedad de métricas que afectan el cálculo de la ruta
óptima. La siguiente sección analiza estos atributos.
2.3.2.1 OBJETIVOS DE DISEÑO
Los algoritmos de ruteo generalmente poseen uno o más de los siguientes objetivos
de diseño:
?? Optimalidad.
?? Simplicidad y baja carga.
?? Estabilidad.
?? Rápida convergencia.
?? Flexibilidad.
52
Optimalidad – Se refiere a la habilidad de los algoritmos de seleccionar la “mejor”
ruta. La mejor ruta depende de la métrica usada para hacer los cálculos. Por ejemplo,
una algoritmo de ruta podría usar número de hops, pero otro podría usar retrazo por
tamaño lo cual genera una carga mayor en los cálculos. Naturalmente, los protocolos
de ruteo deben especificar estrictamente sus métricas para los cálculos.
Simplicidad – Los algoritmos de ruteo están diseñados para ser tan simples como sea
posible. En otras palabras, estos algoritmos deben funcionar eficientemente, con el
mínimo de software y de carga por utilización. La eficiencia es particularmente
importante cuando la implementación del software del algoritmo de ruteo debe correr
en una computadora con recursos limitados.
Estabilidad – Los algoritmos deben ser robustos. En otras palabras, deben ser
capaces de actuar correctamente ante cualquier eventualidad que pueda suceder, bien
sea problemas de hardware, alta carga de sistema e implementaciones incorrectas.
Debido a que los routers son colocados en puntos de unión dentro de una red, pueden
generar problemas considerables cuando fallan. Los mejores algoritmos son aquellos
que han pasado por este tipo de pruebas y han probado que son estables bajo una
variedad de condiciones de red.
53
Rápida Convergencia – la convergencia es el aspecto de mayor consideración para
todos los routers para determinar la mejor ruta. Cuando un evento en una red causa
una caída en una ruta o una ruta se hace disponible, cada router debe enviar mensajes
de actualización. Estos mensajes permiten a las redes recalcular sus rutas óptimas,
causando eventualmente que todos los routers coincidan con sus tablas de ruta. Si el
algoritmo de Routing es lento, esto generaría posibles bucles infinitos y problemas en
la red.
La Figura 11 muestra un bucle infinito. En este caso, un paquete llega al router 1 en
el tiempo 1. La tabla de ruta del router 1 ya ha sido actualizada e indica que el mejor
camino hacia el nodo “X” es utilizando como próximo hop al router 2. De esta forma
el paquete es reenviado del router 1 al router 2. Como el router 2 no ha sido
actualizado y además tiene como destino hacia el nodo “X” al router 1, el paquete va
a ser reenviado de vuelta al router 1. El paquete va a seguir en este proceso entre los
dos routers hasta que el router 2 reciba su actualización o hasta que el paquete sea
reenviado hasta un límite de veces permitido.
Figura 11. Bucle Infinito.
Destino: X Enviado a: R2
Destino: X Enviado a: R1
Paquete hacia el nodo X Router 2 Router 1
54
Flexibilidad – Estos algoritmos deben ser también flexibles. En otras palabras,
deben ser capaces de adaptarse rápidamente a una variedad de circunstancias en la
red. Por ejemplo, cuando se cae un segmento de red. Muchos algoritmos, cuando
reconocen este problema, rápidamente recalculan la mejor ruta para todos los routers
que utilizan ese segmento de red. Además pueden ser programados para adaptarse a
cambios en el ancho de banda, demora de servicio, y otras variables.
2.3.2.2 TIPOS Los algoritmos de routing pueden ser clasificados en distintos tipos. Por ejemplo, los
algoritmos pueden ser:
?? Estáticos o dinámicos.
?? Single-Path o Multi-Path.
?? Flat o Hierarchical.
?? Host-Intelligent o Router-Intelligent.
?? Intradomain o Interdomain.
?? Link State o Distance Vector.
Estáticos o Dinámicos – Los algoritmos de routing estáticos son difícilmente
considerados algoritmos como tal. El administrador de la red debe establecer, antes
de empezar el routing, las tablas de ruta. Estas tablas no varían a menos que el
55
administrador las cambie por sí mismo. Los algoritmos que utilizan rutas estáticas
son diseñados y utilizados para trabajar en ambientes donde el tráfico de la red es
predecible y el diseño de la red es sencillo.
Debido a que el ruteo estático no puede reaccionar ante cambios en la red, son
generalmente considerados imprácticos para el tamaño de las redes de hoy, las cuales
cambian continuamente. La mayoría de los algoritmos de routing usados a partir de
la década de lo 90s son dinámicos.
Los algoritmos de ruteo dinámicos se ajustan, en tiempo real, a circunstancias de
cambio dentro de la red. Si un mensaje indica que un cambio en la red ha ocurrido, el
software de routing recalcula las rutas y manda nuevos mensajes de actualización.
Estos mensajes permiten a la red, estimular a los routers a volver a arrancar sus
algoritmos y cambiar sus tablas acordemente.
Single-Path o Multi-Path – Algunos protocolos sofisticados de routing soportan
muchos caminos hacia un destino (multi-path). Estos algoritmos permiten el manejo
de tráfico sobre muchas líneas; los algoritmos single-path no lo permite. Las ventajas
de los algoritmos multi-path son obvias; permiten proveer sustancialmente mejor
enrutamiento y seguridad.
56
Flat o Hierarchical (planos o jerárquicos) – Algunos algoritmos de routing operan
en un espacio plano, mientras otros utilizan jerarquías de routing. En un sistema de
routing plano, todos los routers son pares punto a punto uno de los otros. En un
sistema de routing jerárquico, algunos routers forman algo semejante a una espina
dorsal. Los paquetes que no pertenecen a un router de la espina dorsal, viajan hacia
un router que si pertenezca, y de ahí son enviados, a través de la espina dorsal, a el
área general del destino.
Los sistemas de routing generalmente destinan grupos lógicos de nodos llamados
dominios, sistemas autónomos, o áreas. En sistemas jerárquicos, algunos routers del
dominio pueden comunicarse con routers de otros dominios, mientras que otros sólo
pueden comunicarse con los de su mismo dominio. En redes muy largas, pueden
existir niveles jerárquicos adicionales.
La ventaja principal de el routing jerárquico es que imita la organización de la
mayoría de las compañías y de esta forma soporta sus tráficos muy bien. La mayoría
de las comunicaciones en una red ocurren en un mismo grupo pequeño de la
compañía (dominio). Los routers internos del dominio sólo necesitan saber acerca de
los routers de su mismo dominio, y de esta forma sus algoritmos de routing pueden
ser simplificados. Dependiendo del algoritmo de routing usado, el tráfico generado
por las actualizaciones puede ser drásticamente reducido.
57
Host-Intelligent o Router-Intelligent – Algunos algoritmos de routing asumen que
el nodo de origen es el que va a determinar la ruta entera de l paquete. Esto es
comúnmente conocido como Routing de origen. En sistemas de routing de origen,
los routers actúan simplemente como dispositivos de recibir y enviar paquetes.
Otros algoritmos asumen que los host no conocen nada acerca de rutas. En est os
algoritmos, los routers determinan el camino, basados en sus propios cálculos. En el
primer modelo los host tienen la inteligencia de routing (host-intelligent). En el
segundo modelo los routers son los que la tienen (router-intelligent).
La diferenc ia principal entre host-intelligent y router-intelligent, es que uno obtiene el
mejor camino más a menudo pero genera más tráfico (en el caso del host) y el otro no
consigue con la misma frecuencia el mejor camino pero genera menos tráfico (en el
caso de router).
Intradomain o Interdomain – Algunos algoritmos de routing trabajan sólo en su
mismo dominio; y otros pueden hacerlo en cualquiera. La naturaleza de estos dos
tipos de algoritmos es diferente. De esta forma, se entiende, que un algoritmo que
func ione entre dominios (Intradomain) no será necesariamente el óptimo para trabajar
en un solo dominio (Interdomain).
58
Link State o Distance Vector – Los algoritmos Link State (también conocidos como
algoritmos shortest path first) envían información hacia todos los nodos de la
estructura de red. Sin embargo, cada router envía sólo la porción de la tabla de ruta
que describe el estado de sus propias conexiones. Los algoritmos de Distance Vector
(también conocido como algoritmos Bellman-Ford) llaman a cada router para enviar
toda o una parte de su tabla de ruta, pero sólo a sus vecinos. En esencia, los
algoritmos Link State envían pequeñas actualizaciones a todas partes, mientras los
algoritmos de Distance Vector envían mensajes de actualización más grades pero sólo
a sus vecinos.
Debido a que cubren más rápido toda la red, los algoritmos de Link State son menos
propensos a caer en bucles infinitos. Por otro lado, también requieren más poder de
CPU y memoria que los algoritmos de Distance Vector. De esta manera los Link
State son más costosos para implementar y mantener. Aunque apartando estas
diferencias, se puede decir que ambos funcionan muy bien para la mayoría de las
circunstancias.
2.3.2.3 MÉTRICAS
Las tablas de routing contienen información usada por el software de switching para
seleccionar la mejor ruta. Los algoritmos de routing utilizan diferentes métricas para
59
determinar estas rutas. Todas estas métricas pueden ser usadas de manera individual
o en conjunto según sea el objetivo del diseñador. Las siguientes métricas son las
más usadas:
?? Longitud del Camino.
?? Confiabilidad.
?? Demora.
?? Ancho de Banda.
?? Carga.
?? Costo de la comunicación.
Longitud del Camino – Esta es la métrica usada con mayor frecuencia. Algunos
protocolos de routing permiten al administrador de la red asignar arbitrariamente un
costo a cada conexión de la red. En este caso, la longitud de la red será la suma de
cada costo asociado con cada ruta recorrida. Otros protocolos definen un hop count
(contador de hops), una métrica que especifica el número de routers por los cuales
debe pasar un paquete para llegar a su destino.
Confiabilidad – En este contexto, se refiere a la confiabilidad (usualmente descrita
en términos de la rata de bit-error) para cada conexión de la red. Algunas conexiones
pueden caerse con mayor frecuencia que otras. Una vez caídas, algunas conexiones
60
pueden ser reparadas con mayor rapidez que otras. Cualquier factor de confiabilidad
puede ser tomado para asignar la rata de confianza. La rata de confianza son
usualmente asignadas a cada conexión por el administrados de la red. Generalmente
son números arbitrarios.
Demora – Se refiere al tiempo requerido para mover paquetes desde el origen al
destino a través de la red. Esta demora depende de muchos factores, incluyendo el
ancho de banda de conexiones internas, y la distancia física que debe ser recorrida.
Debido a que es un conglomerado de muchas variables importantes, la demora es una
métrica muy común y útil.
Ancho de Banda – Se refiere a la capacidad de tráfico de una conexión. En teoría es
preferible usar una conexión de Ethernet a 10 Mbps que usar una línea de 64 Kbps.
Si embargo se puede decir que esto no es siempre así, si tenemos un ruta muy rápida
pero que se encuentra muy ocupada, el tiempo actual para enviar un paquete hasta el
destino va a ser muy grande si se usa esa ruta.
Carga – Es el nivel de carga que posee un recurso de red (un router por ejemplo). La
carga puede ser calculada de diversas maneras, incluyendo utilización de CPU y
paquetes procesados por unidad de tiempo.
61
Costo de la comunicación – Esta es una métrica importante. Muchas empresas no se
preocupan tanto por el desempeño sino por los gastos operacionales. Aunque la
demora en la línea sea mayor, enviarán paquetes por sus propias líneas en lugar de
usar líneas públicas las cuales puedan costar dinero adicional para usarlas por un
período de tiempo.
62
2.4 ROUTING INFORMATION PROTOCOL (RIP) El ROUTING INFORMATION PROTOCOL (RIP) es un protocolo de ruteo
diseñando para XEROX PARC UNIVERSAL PROTOCOL (donde fue llamado
GWINFO) y usado en el XEROX NETWORK SYSTEMS (XNS) PROTOCOL SUITE.
2.4.1 FORMATO DE LA TABLA DE ROUTING
Cada entrada en una tabla de ruteo de RIP provee una gran cantidad de información,
incluyendo la dirección de destino, el próximo hop en la vía del destino, y una
métrica. La métrica indica la distancia en número de hops hacia el destino. Se puede
incluir mucha más información en la tabla, incluyendo varios tipos de tiempos
asociados con el ruteo. La Tabla 2 muestra una tabla de routing.
Tabla 2 Tabla de Routing.
Destino Próximo HOP Distancia Tiempos FLAGS
RED A ROUTER 1 3 T1, T2, T3 X, Y
RED B ROUTER 2 5 T1, T2, T3 X, Y
REB C ROUTER 1 2 T1, T2, T3 X, Y . . .
.
.
.
.
.
.
.
.
.
.
.
.
63
RIP mantiene únicamente la mejor ruta hacia un destino. Cuando se obtiene nueva
información acerca de una ruta mejor, esta información reemplaza las rutas
anteriores. Cambios en la topología de una red, pueden provocar cambios en las
rutas. Cuando esto ocurre, se crean mensajes de actualización en la red. Por ejemplo,
un router A detecta una falla de un enlace o de otro router B, el router A vuelve a
calcular sus rutas y envía un mensaje de actualización a la red. Cada router recibe la
actualización y realiza los cambios pertinentes a sus tablas y a su vez propaga el
mensaje.
64
2.4.2 FORMATO DE LOS PAQUETES: IMPLEMENTACIÓN IP La Figura 12 muestra le formato del paquete IP. El tamaño de cada campo está
medido en bytes.
1 1 2 2 2 4 4 4 4
A B C D C E C C F
Figura 12. Formato de Paquetes RIP
A - Comando (petición o respuesta).
B - Número de versión.
C - Cero.
D - ADDRESS FAMILY IDENTIFIER.
E - Dirección.
F - Métrica.
Los campos de un paquete de RIP, son los siguientes:
?? Comando – Indica que el paquete es una petición o una respuesta. El
comando de petición pide a otro sistema, que envíe toda o parte de su tabla de
ruteo. Los destinos para los cuales una respuesta es solicitada, son listados
luego en el paquete. El comando de respuesta representa una la contestación
a una petición, o más frecuentemente, un mensaje no solicitado de
actualización frecuente. En el paquete de respuesta, el sistema incluye toda o
65
parte de su tabla de ruteo. Los mensajes de actualizaciones regulares incluyen
la tabla de ruteo completa.
?? Número de Versión – Especifica el número de versión del RIP.
?? ADDRESS FAMILY IDENTIFDIER – Precedido de una cadena de 16 bits de
ceros, especifica el ADDRESS FAMILY particular que se está usando. En la
Internet (una larga, red internacional que conecta instituciones de
investigación, instituciones gubernamentales, universidades, empresas
privadas), este ADDRESS FAMILY es generalmente IP (valor = 2), pero
otros tipos de redes pueden ser representadas.
?? Dirección – Sigue otra cadena de 16 bits de ceros. En una intranet de RIP,
este campo contiene generalmente una dirección IP.
?? Métrica – Siguiendo dos cadenas más de 32 bits cada una, especifica el HOP
COUNT (cantidad de hops ). El HOP COUNT indica la cantidad de hops que
deben ser recorridos para llegar a la dirección de destino.
Con un máximo de 25 ocurrencias del campo ADDRESS FAMILY IDENTIFIER
hasta el campo de MÉTRICA son permitidos en un paquete típico de IP RIP. En
otras palabras, hasta 25 destinos pueden ser listados en paquete simple de RIP.
Múltiples paquetes de RIP son usados para cubrir información de largas tablas de
ruteo.
66
Como otros protocolos de ruteo, RIP usa ciertos tiempos para regular su performance.
El RIP ROUTING UPDATE TIMER (tiempo de actualización de ruteo) es
generalmente de 30 segundos, asegurando que cada router enviará una copia
completa de su tabla de ruteo a cada uno de sus vecinos cada 30 segundos. El ROUTE
INVALID TIMER (tiempo inválido de router) determina cuanto tiempo debe pasar sin
que un router escuche a otro para considerarlo inválido. Cuando un router es
marcado como inválido, los vecinos son notificados de este hecho. Esta notificación
debe ocurrir antes de que termine el ROUTE FLUSH TIMER (tiempo de nivelación
de router). Cuando el ROUTE FLUSH TIMER expira, el router es removido de la
tabla de ruteo. Normalmente los valores de estos tiempos son, 90 segundos para el
ROUTER INVALID TIMER y 270 segundos para el ROUTE FLUSH TIMER.
67
2.4.3 ESPECIFICACIONES DE ESTABILIDAD RIP especifica una serie de características diseñadas para hacer su operación más
estable en vías de un rápido cambio de la topología de la red. Estas incluyen HOP -
COUNT LIMIT, HOLD DOWNS, SPLIT HORIZONS y POISON REVERSE
UPDATE.
2.4.3.1 HOP-COUNT LIMIT RIP permite un máximo de 15 hops para llegar al destino. Cualquier destino mayor
de 15 hops de distancia es marcado como inalcanzable. Esta característica limita
enormemente la implementación de RIP en una red muy grande, pero evita un
problema llamado COUNT TO INFINITY, el cual causa un ciclo sin fin en la red.
Figura 13. HOP-COUNT LIMIT.
En la Figura 13, considere que pasaría sí la conexión del ROUTER 1 (R1) a la RED
A fallara. R1 examina su información y nota que el ROUTER 2 (R2) tiene una
conexión a la RED A mediante un hop. Mientras el R1 sabe que está conectado al
R2, este supondría que puede llegar a la RED A mediante dos hops a partir del R2, y
por tal razón comenzar a enviar todo el tráfico a la RED A mediante el enlace que
ROUTER 1
ROUTER 2
RED A
68
tiene hacia el R2. Esto crea un ciclo de ruteo. Cuando R2 nota que R1 puede ahora
llegar a la RED A mediante dos hops, este cambiará su propia tabla de ruteo para
mostrar que puede llegar a la RED A mediante tres hops. Este problema, y el ciclo de
ruteo, continuará indefinidamente, o mientras alguna condición externa intervenga.
Esa condición externa en RIP es el HOP-COUNT MAXIMUM. Cuando la cuenta de
hops llegue a 15, el router lo marcará como inalcanzable. Según pase el tiempo, el
router será eliminado de la tabla.
2.4.3.2 HOLD-DOWNS HOLD-DOWNS son usados para prevenir mensajes inapropiados de actualización de
un router que se ha caído. Cuando un router se cae, los vecinos lo detectan. Estos
routers vuelven a calcular las rutas y envían mensajes de actualización para informar
a sus vecinos los cambios en las rutas. Esta actividad empieza una ola de
actualizaciones que se filtran a través de la red.
Estas actualizaciones no llegan instantáneamente a cada entidad de la red. Por esta
razón es posible que una entidad que no ha sido todavía informada de un fallo de la
red, pueda enviar sus mensajes habituales de actualización (indicando que el router
que se ha caído, sigue estando activo) a otra entidad que ya ha sido informada del
fallo de la red. En este caso, la última entidad tiene ahora información de ruteo
incorrecta.
69
HOLD-DOWNS informa a un router que mantenga cualquier cambio que pueda
afectar un router que ha sido removido de la tabla recientemente, un período de
tiempo. El período de un HOLD-DOWN es calculado para ser mayor que el tiempo
necesario para actualizar completamente a la red de una cambio. HOLD-DOWNS
previenen los problemas de COUNT-TO-INFINITY.
2.4.3.3 SPLIT HORIZONS SPLIT HORIZONS deriva del hecho que nunca es útil enviar información de regreso
por la ruta de donde vino.
Red A Red B
Figura 14. SPLIT HORIZONS.
Router 1 (R1) inicialmente indica que tiene una ruta hacia la Red A. No hay razón
para el Router 2 (R2), incluir esta ruta en su mensaje de actualización de regreso al
R1, debido a que R1 está más cerca de la Red A. La regla de SPLIT HORIZONS
indica al R2 que debe eliminar esta ruta de cualquier mensaje de actualización que
envíe al R1.
ROUTER 1
ROUTER 2
70
Esta regla evita que dos nodos entren en un ciclo de actualización. Por ejemplo,
considere el caso cuando la conexión entre R1 y la Red A se cae. Sin SPLIT
HORIZONS, R2 continua informando a R1 que puede llegar a la Red A mediante R1.
Sí R1 no tuviera suficiente inteligencia, podría elegir la ruta alternativa que presenta
R2 para llegar a la Red A, causando así un ciclo. Mientras HOLD DOWNS provee
una solución a este problema, SPLIT HORIZONS aporta mayor estabilidad al
algoritmo.
2.4.3.4 POISON REVERSE UPDATES Así mismo como SPLIT HORIZONS previene ciclos entre dos nodos adyacentes,
POISON REVERSE UPDATES son creados con la intención de brindar una
protección de ciclos entre largas cadenas de nodos. La idea es que generalmente
crecimientos en la métrica, indica un ciclo de ruteo. POISON REVERSE UPDATES
especifica que la ruta debe ser eliminada y colocada en HOLD DOWN.
71
2.5 RIP VERSION 2 RIP 2 es una extensión de ROUTING INFORMATION PROTOCOL (RIP), como
fue definido anteriormente. Su propósito es expandir la cantidad de información útil
dentro de un paquete RIP y además brindar algunos elementos de seguridad.
La justificación de mantener el viejo RIP en un mundo de nuevos y fuertes protocolos
de ruteo, es principalmente su rápida distribución y sus bajos requerimientos en
ancho de banda, en configuración y ma ntenimiento de tiempo. Adicionalmente, RIP
es muy fácil de implementar. Bajo la suposición de que RIP estará en servicio por
algunos años más, se consideró necesario incrementar la funcionalidad de este
protocolo. Recientemente, RIP 2 se ha convertido en la versión estándar de RIP,
mientras que el original ha pasado a la historia.
RIP versión 2 soporta los mismos algoritmos básicos de la versión 1, y además
incorpora nuevas características. Estas características son las siguientes:
?? Route Tags (Etiquetas de ruta).
?? Máscaras de Red.
?? Dirección del Próximo Hop.
?? Autenticación.
?? Multicasting.
72
2.5.1 FORMATO DE PAQUETES EN RIP2 El formato de un paquete en RIP 2 se puede ver en la Figura 15.
? ----------------------------------------------------- 32 bits -----------------------------------------------------?
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Comando (1)
Versión (1)
Routing Domain
Address Family Identifier (2) Route Tag (2)
Ip Address (4)
Máscara de red (4)
Próximo Hop (4)
Métrica (4)
Figura 15. Formato de Paquetes RIPv2. El Comando, ADDRESS FAMILY IDENTIFIER (AFI), IP ADDRESS, y Métrica,
tienen el mismo significado que en RIP 1. El campo de la versión especifica el
número 2 para los datagramas de RIP que usan autenticación o llevan información
para cualquiera de los nuevos campos definidos.
73
En RIP 2 hay un mecanismo de autenticación opcional. Cuando está en uso, esta
opción toma una entrada completa del paquete, y deja espacio para un máximo de 24
entradas en el resto del paquete. El tipo de autenticación más extenso, es una
contraseña de tipo 2.
El campo de ROUTING DOMAIN permite algún tipo de trabajo entre el ruteo del
dominio de la misma infraestructura física. Mientras que lógicamente se ignoran
unos con otros. Esto permite implementar diferentes tipos de políticas. Hay un valor
por defecto para este campo el cual es ‘0’.
El ROUTE TAG (RT) existe como un soporte para EGP. Este campo lleva números
de Sistemas Autónomos para EGP y BGP. Los sistemas de RIP que reciben entradas
RIP que contienen el campo RT distinto de cero, deben re advertir el valor.
La Máscara de Subred contiene la máscara que es aplicada a la dirección IP. Si este
campo es cero, implica que no existe una Subred.
Próximo Hop es la siguiente dirección IP del hop el cual va ha recibir el paquete
antes de llegar a su destino. El propósito de este campo es de evitar que el paquete
sea enviado a más destinos de los necesarios. En particular es muy útil cuando RIP
no está siendo utilizado por todos los router de la red.
74
MULTI-CASTING es una característica opcional dentro de RIP 2, usando una
dirección IP 224.0.0.9. Esta característica reduce cargas innecesarias en esos host
que no están conectados a RIP 2. La dirección IP multicast es usada para periódicos
broadcast. En orden de mantener compatibilidad, el uso de multicast es
configurable. Además, RIP 2 es completamente compatible con RIP 1. Sus
aplicaciones soportan emulación de RIP 1, compatibilidad RIP 1, o RIP 2 completo.
75
2.6 SNIFFING
Un sniffer o un packet sniffer (Paquete de sniffer), es un dispositivo (o un programa)
que se conecta a una red para poder ver el tráfico de paquetes que pasa por la misma.
Es muy parecido a los dispositivos que usa el FBI u otras organizaciones para
escuchar conversaciones telefónicas, los programas de sniffing permiten escuchar
conversaciones entre una o varias computadoras.
Sin embargo, estas conversaciones consisten aparentemente en información binaria
aleatoria. De esta manera, este tipo de programa vienen también con una
característica conocida como “análisis del protocolo” (protocol análisis), el cual
permite decodificar el tráfico de la computadora y de esta manera darle algún sentido.
Este tipo de programa es usado principalmente de dos maneras distintas. Por un lado
están los paquetes comerciales de sniffer, usados principalmente como ayuda para el
mantenimiento de redes; y por otro lado por están los sniffers usados para irrumpir en
computadoras y de esta manera obtener información confidencial de la misma.
Los usos típicos de un sniffer son los siguientes:
76
?? Obtención en texto-claro de contraseñas y nombres de usuario de la red. Esta
característica es usada principalmente por hackers y crackers de manera de
poder entrar en los sistemas.
?? Leer información que está pasando por el tráfico de la red.
?? Análisis para descubrir problemas en la red, como por ejemplo el porqué la
computadora A no se puede comunicar con la B.
?? Descubrir cuellos de botella, que impiden el flujo adecuado del tráfico.
?? Detección de intrusos y de esta manera poder descubrir a hackers y crackers
en el sistema.
?? Crear registros que no puedan ser borrados por ninguna persona.
2.6.1 FUNCIONAMIENTO DE UN SNIFFER Las redes Ethernet fueron construidas con un principio fundamental: todos los
dispositivos en una red comparten el mismo “cable”. Esto implica que todas las
computadoras son capaces de ver el tráfico del cable al cual están conectadas.
De esta manera, el hardware de Ethernet (adaptadores de red entre otros) es
construido con un filtro que ignora los paquetes que no le pertenecen. Esto lo logra
77
comparando la dirección MAC4 del paquete y comparándola con la de la propia
máquina – sí no son iguales el paquete es descartado -.
Un programa de sniffer cancela estos filtros poniendo al hardware de Ethernet en
“modo promiscuo”. De esta forma una máquina A puede ver el tráfico entre B y C
siempre y cuando estén en el mismo cable.
2.6.2 COMPONENTES DE UN SNIFFER
?? El hardware – la mayoría de los productos funcionan desde cualquier
adaptador de red estándar. Existe hardware especial que permite ver inclusive
problemas como errores CRC, problemas de voltaje, problemas de cable,
errores de negociación y muchos más.
?? Driver de Captura – esta es la parte más importante. Captura el tráfico de
red desde el cable, filtra el paquete para un tráfico particular que se desee,
luego almacena la captura en un buffer.
?? Buffer – una vez realizada la captura, los paquetes son colocados en el buffer.
Existen varios modos de captura: capturar paquetes hasta que el buffer esté
completamente lleno, o usar el buffer como un “round robin” donde la data
nueva reemplaza a la anterior.
4 Ver conceptos esenciales
78
?? Análisis en tiempo real – existe la posibilidad de analizar los paquetes a
medida que van siendo capturados. Esta posibilidad permite ver un número
reducido de opciones y sirve principalmente para diagnosticar intrusos en la
red. Se puede hacer un análisis más detallado de la captura y ver el contenido
de la misma una vez que se ha finalizado la captura. Esta característica es
conocida como Decodificación.
?? Decodificación o Análisis de Protocolos– despliega el contenido de la
captura con un texto descriptivo y de esta forma cualquier analista podrá saber
lo que está sucediendo en la red.
?? Edición y trasmisión de paquetes – algunos productos contienen
características de edición de paquetes para luego retransmitirlo en la red.
2.6.3 ANÁLISIS DE PROTOCOLOS
El análisis de protocolos es el proceso de capturar paquetes del tráfico de la red
(usando programas de sniffing) y ver más de cerca la información que contienen para
de esta forma determinar lo que está ocurriendo.
Los datos en una red son trasmitidos en paquetes, esto significa que la información
fue subdividida en múltiples paquetes y enviada de esta forma, luego es tarea del
dispositivo que la reciba volverla a unir. Por ejemplo, un documento que se envíe por
79
la red que ocupe 45,000 bytes, asumiendo que un paquete ocupa por lo general un
valor máximo de 1,500 bytes, tendría que ser dividido en aproximadamente 30
paquetes para poder ser trasmitido.
La Figura 16 muestra un ejemplo de un paquete.
0000 00 02 55 e4 30 12 00 10 4b 64 42 82 08 00 45 00 ..U.0...KdB...E. 0010 00 3c 32 03 00 00 1f 01 46 a0 8c 05 06 0a 8c 05 .<2.....F....... 0020 05 0a 08 00 f3 5a 01 00 59 01 61 62 63 64 65 66 .....Z..Y.abcdef 0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 ghijklmnopqrstuv 0040 77 61 62 63 64 65 66 67 68 69 wabcdefghi Figura 16. Ejemplo de un paquete capturado por un sniffer.
Esta es la representación hexadecimal de un paquete de red, antes de ser
decodificado. El paquete tiene tres columnas:
1. El número de cada línea.
2. La representación hexadecimal de la data.
3. Y su representación equivalente en formato ASCII.
Este paquete contiene 14 bytes que representan el cabecero de Ethernet (en color
amarillo), 20 bytes que representan el cabecero IP (en color azul), 8 bytes que
representan el cabecero ICMP (en color verde) y el resto representa la data del
paquete (en color magenta).
80
El paquete mostrado anteriormente es un ping realizado desde la máquina con
dirección IP: 140.5.6.10 (8c 05 06 0a) con dirección MAC: 00 10 4b 64 42 82, a la
dirección IP: 140.5.5.10 (8c 05 05 0a) con dirección MAC: 00 02 55 e4 30 12;
utilizando el protocolo ICMP (01) del tipo Echo (08).
La Tabla 3 muestra una descripción más detallada de los campos más importantes
del paquete mostrado:
Tabla 3. Descripción Detallada de un paquete capturado con un sniffer.
Protocolo Descripción Representación
Ethernet Dirección de destino 00 02 55 e4 30 12
Ethernet Dirección de salida 00 10 4b 64 42 82
Ethernet Tamaño del Paquete 74 bytes
Ethernet Tipo de Ethernet 0x0800 (IP)
IP Versión 4 (0x4)
IP Tamaño del cabecero 20 bytes
IP Tamaño Total 0x003c
IP Identificación 0x3203
IP Tiempo de Vida 60 (0x1f)
IP Protocolo 01 ICMP
IP Checksum 0x46a0
81
IP IP de Salida 140.5.6.10 (8c 05 06 0a)
IP IP de Destino 140.5.5.10 (8c 05 05 0a)
ICMP Tipo del Paquete Echo (0x0800)
ICMP Checksum 0xf35a
ICMP Identificador 0x0100
ICMP Número de Secuencia 0x5901
ICMP Data Todos los bytes restantes.
Esta es la manera en que un decodificador de protocolos debe actuar. Extrae cada
uno de los campos fuera del paquete e intenta explicar el significado de cada número.
Algunos campos son tan pequeños como un simple bit, otros ocupan varios bytes.
El análisis de protocolos es un arte realmente difícil, y requiere mucho conocimiento
acerca de protocolos para poder realizarlo bien. Sin embargo, la recompensa es que
muchísima información puede obtenerse fácilmente de los protocolos. Esta
información es muy útil para administradores de red tratando de resolver problemas,
o para hackers que están intentando entrar en alguna computadora5.
5 Para más información correspondiente a los número de cada protocolo, tipos de ethernet, consulte el RFC 1700.
82
2.6.4 PACKET.DLL API
Packet.dll es un librería dinámica (DLL) que permite comunicar un driver de
captura con el nivel de aplicación del usuario (programa de usuario). Este DLL
implementa una serie de funciones que hacen la comunicación con el driver más
sencilla. Esto evita el usar llamadas al sistema o IOCTLs en programas de usuario.
Además, provee funciones para manejar adaptadores de red, leer y escribir paquetes
desde la red, especificar el buffer y los filtros del driver, y mucho más. Hay dos
versiones de PACKET.DLL: la primera funciona para Win95/98/ME, la segunda para
WinNT/2000. Las dos versiones exportan la misma interfaz de programación,
haciendo más fácil escribir aplicaciones de captura independientes del sistema.
Usando PACKET.DLL API, la misma aplicación puede correr en cualquier sistema
Windows sin tener que hacer ninguna modificación6.
6 Para mayor información, verifica la bibliografía. Packet.dll API: Programmer’s Manual.
83
TERCERA PARTE
MARCO METODOLÓGICO
“Las observaciones experimentales se hacen bajo condiciones predeterminadas y planificadas. Los experimentos deben estar bajo constante control y las condiciones controladas o manipuladas al deseo del investigador.”
CAMPBELL & STANLEY
84
3.1 TIPO DE INVESTIGACIÓN
El tipo de investigación realizada es una investigación comparativa de diseño
experimental, la cual nos permite establecer diferencias y semejanzas entre dos (2) o
más grupos; compara una variable en dos grupos diferentes, sin establecer
correlaciones o causalidad entre ellas bajo condiciones rigurosamente controladas,
para descubrir cómo o por qué causa se produce una situación o acontecimiento
particular.
3.2 DISEÑO DE LA INVESTIGACIÓN
Como primer paso para la realización de este trabajo, se diseñó un sistema que
permitiera entregar al usuario (administrador de la red) datos asertivos sobre el estado
de la red. Este sistema evalúa el rendimiento y la cantidad de paquetes que viajan por
la misma en un momento especificado.
Para ello fue necesario la elaboración de un módulo de captura de paquetes, este
modulo se realizó utilizando las librerías PACKET.DLL especificadas anteriormente.
Estas librerías permiten almacenar en un buffer los paquetes que viajan por el
adaptador de red del equipo. Este módulo fue realizado en Visual C++ y compilado
para utilizarlo como un archivo ejecutable. Este archivo ejecutable llamado
85
Capture.exe genera un archivo de captura con todos los paquetes capturados en el
buffer de la aplicación y con estadísticas de esta captura.
Luego este archivo es utilizado en un sistema de análisis de paquetes y medición de
tráfico en la red, llamado NMIRE. Este sistema permite analizar la captura realizada
con en el módulo captura, además de guardar la misma en la base de datos
Traffic.mdb. Además muestra los datos obtenidos en pantalla, las estadísticas de la
captura, permite guardar las sesiones de captura y compararlas, y generación de
gráficos. Este sistema fue utilizado en las pruebas de este proyecto.
Para la realización de estas pruebas, fue necesario la instalación de una red
experimental LAN, en la cual se hizo el estudio de las dos versiones del protocolo
RIP y además se evaluó el funcionamiento del sistema.
86
3.2.1 DISEÑO DE LA RED
La red experimental instalada para la realización de las pruebas fue una red muy
básica, la cual estaba conformada por tres computadores. Uno de ellos actúa como
Router y los otros dos como clientes conectados al Router. Esto facilita la evaluación
del sistema y del rendimiento del protocolo RIP. Los equipos utilizados para estas
pruebas fueron los siguientes:
1. Router - Computador Pentium III 800Mhz, 256Mb de memoria RAM, con
Windows NT y Service Pack 6.
2. Cliente 1 y Cliente 2 – Computador Pentium II 600Mhz, 128Mb de memoria
RAM, con Windows 98.
3. Cuatro Tarjetas de Red (Dos para el Router y una para cada Cliente).
4. Dos cables CROSS OVER para realizar la conexión entre los equipos.
La Figura 17 muestra la instalación de la red utilizada.
Figura 17. Escenario de Funcionamiento.
Servidor NT
140.5.5.1 / 140.5.6.1
Router
R 1
Cliente 2 140.5.6.10 255.255.255.0 Gateway: 140.5.6.1
Cliente 1 140.5.5.10 255.255.255.0 Gateway: 140.5.5.1
2
87
Los clientes 1 y 2 son computadores con Windows 98, los cuales fueron usados para
generar el tráfico en la red. El router tiene instalado el sistema operativo Windows
NT y en él está colocado el sistema de monitoreo de red NMIRE desarrollado en este
proyecto.
Como se puede ver por las direcciones asignadas a cada máquina, la red instalada
posee dos segmentos: 140.5.5.0 y 140.5.6.0. Cada una de estas direcciones está
asignada a una tarjeta de red del router, y cada una de ellas a su respectivo cliente de
la red.
Para activar el funcionamiento del protocolo RIP versión 1, se activo el servicio de
Windows NT RIP for IP protocol. Luego para activar el funcionamiento del
protocolo RIP versión 2, se desinstaló RIP versión 1, y se instaló el archivo de
actualización del sistema operativo Routing and Remote Access Service. Toda la red
funciona bajo un mismo dominio de Windows NT.
88
3.2.2 MÓDULO DE CAPTURA
Para capturar los paquetes transferidos por la red, el módulo de captura necesita
interactuar directamente con el hardware de la red. Por esta razón el sistema
operativo debe ofrecer un conjunto de primitivas de captura para comunicarse y
recibir data directamente desde el adaptador de red. La meta de estas primitivas es
básicamente capturar los paquetes de la red (ocultando la interacción con el adaptador
de la red), y trasferirlos al programa. Esto es algo muy dependiente del sistema y de
esta manera cambia mucho según el sistema operativo que se esté utilizando. La
sección de captura de paquetes del kernel debe ser rápida y eficiente ya que tiene que
ser capaz de realizar las capturas en redes LAN de alta velocidad con tráfico pesado,
limitando la perdida de paquetes y usando una cantidad reducida de recursos del
sistema.
En el nivel de usuario, la aplicación de captura recibe los paquetes del sistema,
interpretándolos y procesándolos, y de esta manera generando una salida
comprensible y productiva a la vez. Una característica importante es que permite
incrementar el numero de protocolos de una manera simple.
El módulo de captura realizado es sólo la parte más alta de todo el proceso de captura
el cual se compone del nivel del kernel y otro que corre en el nivel de usuario. Estas
89
dos partes tienen propósitos distintos y son independientes de cada uno. La Figura
18 muestra más detalladamente el funcionamiento de este módulo.
Figura 18. Funcionamiento del módulo de captura.
En la parte más baja está el adaptador de red. Este es usado para capturar los
paquetes que circulan en la red. El adaptador debe estar corriendo “en modo
promiscuo” el cual obliga a aceptar todos los paquetes en lugar de aceptar solo los
que le corresponden.
Capture.exe
Libpcap Aplicación
Nivel de Usuario
Packet.dll Librería Dinámica
Driver de Captura.
Conjunto de otros
protocolos
Nivel del Kernel
Adaptador de red
paquetes
90
El Driver de Captura es el módulo de nivel más bajo del conjunto de captura. Es la
parte que trabaja en el nivel de kernel e interactúa con el adaptador de red para
obtener los paquetes. Provee al adaptador un conjunto de funciones para leer y
escribir información desde la red a la capa de enlace de datos7.
Packet.dll trabaja en el nivel de usuario, pero está separado de la aplicación de
captura (la cual se llama Capture.exe8). Esta librería dinámica separa a la aplicación
de captura del driver permitiendo una interfaz de captura independiente del sistema.
De esta forma Capture.exe puede ser utilizado en cualquier versión de Windows sin
necesidad de ser recompilado.
La librería pcap, o libpcap9, es una librería estática que es usada por la parte de
captura de la aplicación. Es usada para importar las funciones de Packet.dll, y provee
un alto nivel y una poderosa interfaz de captura. Se debe destacar que esta librería
estática es parte del programa Capture.exe y por lo tanto esta compilada con el
mismo.
El programa Capture.exe, se encarga de abrir el adaptador de red del cual se quiere
realizar la captura – como vimos anteriormente, esto lo logra con las librerías 7 Ver modelo de referencia OSI, equivalente a la capa de interred en el modelo TCP/IP. 8 Como veremos más adelante el sistema de monitoreo final, utiliza dos instancias de este módulo, por lo cual se ha compilado dos veces – Capture1, y Capture2 -. 9 Para ejecutar el módulo de captura debe instalar primero estas librerías, para ello instale las librerías WinPcap. Ver Bibliografía WinPcap.
91
estáticas libpcap, las cuales se comunican directamente con la librería dinámica
Packet.dll -. Una vez abierto el adaptador de red, el programa envía una señal de
comienzo al Driver de captura, para que se guarden todos los paquetes que pasan por
el adaptador en el buffer del driver. De aquí Packet.dll permite tomar estos paquetes
y colocarlos en el buffer de la aplicación. Una vez ahí, Capture.exe guarda esta
información en texto claro10 en un archivo llamado Captura.txt. Esto sigue en un
ciclo de captura hasta que se envía una señal al programa para que detenga la captura.
Para ello Capture.exe, detiene la captura del driver y cierra el adaptador, copia al final
del archivo generado (Captura.txt) el tamaño de la data capturada (medida en bytes),
la cantidad de paquetes que se recibieron en el proceso de captura y la cantidad de
paquetes perdidos. Este archivo es analizado posteriormente por el sistema NMIRE.
10 Ver sección 2.6.3 Análisis de Protocolo para ver el ejemplo del formato y representación de un paquete.
92
3.2.3 DISEÑO DEL SISTEMA NMIRE
El sistema NMIRE permite analizar el tráfico que se genera en la red, lleva
estadísticas de su desempeño, compara sesiones de captura y genera gráficos para una
mayor comprensión de lo que está ocurriendo en la red11.
En primera lugar, el sistema captura el tráfico de la red; esto lo logra ejecutando el
módulo de captura explicado anteriormente, mediante el archivo ejecutable
Capture.exe. Debido a que la red piloto de este proyecto consta de una computadora
que funciona como Router – en la cual se instaló el sistema NMIRE – y que además
en este router existen dos tarjetas de red para comunicar los dos segmentos, fue
necesario compilar dos instancias del programa de captura (una para cada tarjeta de
red) y así capturar el tráfico generado por cada cliente que pase por el router. Estas
dos instancias del programa se llaman Capture1.exe (para el Cliente1) y Capture2.exe
(para el Cliente2).
Estos dos programas de captura son ejecutados por un tiempo preestablecido en el
sistema. Una vez finalizado este tiempo, NMIRE toma los dos archivos generados en
la captura (Captura1.txt y Captura2.txt) y guarda la información de la captura, de los
paquetes y de la sesión de captura dentro de la base de datos traffic.mdb.
11 Para mayor información consulte el Apéndice A NM IRE - Manual del Sistema.
93
En este punto el usuario puede ver los resultados obtenidos por pantalla. Las
variables que verifica el sistema NMIRE para hacer el estudio del tráfico son las
siguientes:
1. Total de paquetes capturados.
2. Total de paquetes perdidos.
3. Total de la data capturada (medida en bytes).
4. Total de paquetes unicast.
5. Total de paquetes multicast.
6. Total de paquetes broadcast.
7. Porcentaje total de utilización de la red.
Los resultados de estas variables durante el proceso de captura, se muestran tanto
para el router como para los dos clientes de la red piloto. Además de esto el usuario
puede ver estos resultados mediante gráficos que facilitan su comprensión como
también puede ver un análisis de protocolo de los paquetes que fueron capturados 12.
Otra característica importante del sistema NMIRE, es que permite comparar sesiones
realizadas con anterioridad, esto fue de gran importancia en este proyecto ya que se 12 Para mayor información acerca del análisis de protocolos consulta la sección 2.6.3 Análisis de Protocolos.
94
pudieron establecer comparaciones entre las capturadas realizadas utilizando el
protocolo RIP versión 1 y las capturas utilizando el protocolo RIP versión 2.
Por último el sistema incluye una utilidad para verificar la accesibilidad de un host en
la red llamada Traffic Agent Generator. Para ello utiliza el comando ping para
verificar las rutas entre el servidor y alguna máquina de la red. Permite tomar los
nombres de los equipos y almacenarlos en la base de datos para futuras
verificaciones. Cuando se realiza la verificación, el programa envía una cantidad de
pings predefinida y devuelve el resultado de los ping (en caso de ser satisfactorios
devuelve el tiempo promedio del ping, en caso contrario devuelve el error generado).
95
3.2.4 DISEÑO DE LAS PRUEBAS
Las pruebas realizadas para cumplir con los objetivos fueron las siguientes.
1. Estudio de tráfico que viaja por la red y el generado por el protocolo RIP
bajo condiciones controladas. Para realizar esta prueba, se utilizó el
comando PING13 para generar tráfico desde cada cliente, y el sistema NMIRE
en el servidor para captar este tráfico.
Esta prueba fue realizada primero utilizando el protocolo RIP versión 1 en el
servidor y luego utilizando el protocolo RIP versión 2 para poder realizar
comparaciones.
El tráfico generado fue dividido en varias etapas o sesiones (este es el nombre
que reciben dentro del sistema NMIRE). Estas sesiones fueron utilizando
pings de 4096 bytes, 8192 bytes y 16384 bytes respectivamente. Todas las
pruebas tuvieron una duración de 5 minutos.
a. Ping desde cada cliente al otro – se envió un ping continuo desde el
cliente 1 al cliente 2 y viceversa.
b. Ping desde cada cliente hasta su interfaz de red - se envió un ping
continuo desde el cliente 1 (140.5.5.10) a la tarjeta 1 del servidor
13 Consulte los apéndices para mayor información sobre el comando PING.
96
(140.5.5.1) y desde el cliente 2 (140.5.6.10) a la tarjeta 2 del servidor
(140.5.6.1).
c. Envío de un archivo al router con tráfico de fondo – se realizaron tres
sesiones para cada tamaño de ping, enviando un archivo de 5Mb, un
archivo de 10Mb y un archivo de 15Mb al servidor respectivamente.
Los pings utilizados como tráfico de fondo fueron realizados desde
cada cliente al otro.
2. Estudio de las dos versiones del protocolo RIP. Para ello se hicieron dos
pruebas una para cada versión de RIP.
a. Estudio del tráfico generado por RIP - aquí se realizó una prueba
similar a las anteriores pero sin el tráf ico de fondo. Simplemente se
corrió el programa de captura pero no se realizó ningún ping en los
clientes. Esto con la finalidad de medir el tráfico que genera el
protocolo RIP. Esta prueba también tuvo una duración de 5 minutos.
b. Comparación de las tablas de ruta generadas – para cada protocolo se
analizaron las tablas de rutas generadas por el router, con el fin de
analizar sus entradas.
3. Pruebas de rendimiento del Sistema NMIRE. Estas pruebas miden el
rendimiento del sistema. Fueron realizadas a lo largo de la creación del
Sistema, durante las pruebas de desempeño y funcionalidad, durante el estudio
de tráfico y durante el análisis del tráfico.
97
En total se realizaron 17 pruebas para cada versión del protocolo RIP (además de la
prueba de rendimiento del sistema), las cuales fueron las siguientes:
1. Ping 4096 bytes desde cada cliente al otro.
2. Ping 4096 bytes desde cada cliente a su interfaz de red.
3. Ping 4096 bytes desde cada cliente al otro enviando un archivo de 5Mb al
servidor.
4. Ping 4096 bytes desde cada cliente al otro enviando un archivo de 10Mb
al servidor.
5. Ping 4096 bytes desde cada cliente al otro enviando un archivo de 15Mb
al servidor.
6. Ping 8192 bytes desde cada cliente al otro.
7. Ping 8192 bytes desde cada cliente a su interfaz de red.
8. Ping 8192 bytes desde cada cliente al otro enviando un archivo de 5Mb al
servidor.
9. Ping 8192 bytes desde cada cliente al otro enviando un archivo de 10Mb
al servidor.
10. Ping 8192 bytes desde cada cliente al otro enviando un archivo de 15Mb
al servidor.
11. Ping 16384 bytes desde cada cliente al otro.
12. Ping 16384 bytes desde cada cliente a su interfaz de red.
98
13. Ping 16384 bytes desde cada cliente al otro enviando un archivo de 5Mb
al servidor.
14. Ping 16384 bytes desde cada cliente al otro enviando un archivo de 10Mb
al servidor.
15. Ping 16384 bytes desde cada cliente al otro enviando un archivo de 15Mb
al servidor.
16. Captura sin tráfico adicional.
17. Verificación de las entradas en la tabla de ruta generada por RIP.
99
CUARTA PARTE
ANÁLISIS Y RESULTADOS
“En la actualidad el análisis de los datos se lleva a cabo por computadora. Ya que nadie lo hace de forma manual, especialmente si hay un volumen de datos considerable. Por otra parte, prácticamente en todas las instituciones de educación superior, centros de investigación, empresas y sindicatos disponen de sistemas de cómputo para archivar y analizar datos.”
ROBERTO HERNÁNDEZ SAMPIERI
100
4.1 ANÁLISIS DE LAS PRUEBAS
A continuación se hace referencia a los resultados obtenidos luego de realizar las
pruebas mencionadas anteriormente.
4.1.2 ESTUDIO DEL TRÁFICO QUE VIAJA POR LA RED Y EL GENERADO POR EL PROTOCOLO RIP BAJO CONDICIONES CONTROLADAS
En esta etapa se registraron los datos obtenidos en la captura de los paquetes
mediante el sistema NMIRE14. Se realizaron las pruebas del envío de tráfico en la red
mediante el comando Ping. Se estudió el desempeño de la red bajo pings de 4096,
8192, 16384 bytes realizados de cliente a cliente, de cada cliente al router (a la
interfaz de red de su segmento de red), de cliente a cliente enviando archivos de
distintos tamaños al router, 5Mb, 10Mb y 15Mb respectivamente.
Los datos mostrados son el tiempo promedio del ping, paquetes recibidos, paquetes
perdidos, tamaño de la captura, total de paquetes unicast, total de paquetes multicast,
total de paquetes broadcast y el porcentaje de uso de la red, que es un valor calculado
(entre el promedio de la cantidad de bytes por segundos capturados y el ancho de
banda del segmento de red).
14 Para mayor información acerca del uso de NMIRE, consulte el Apéndice A.
101
4.1.2.1 PING 4096 BYTES
Tabla 4 Ping 4096 RIPv1
Cliente1 - RIPv1 Cliente 2 Router Archivo 5Mb Archivo 10Mb Archivo 15Mb
Tiempo Promedio Ping 3 1 2 2 2
Paquetes Recibidos 3619 1984 9183 14925 20211
Paquetes Perdidos 0 0 3736 8678 13589
Tamaño de la Captura 5049133 2760815 6854665 7748603 8136300
Total Unicast 3601 1968 5431 6226 6605
Total Multicast 0 0 0 0 0
Total Broadcast 18 16 16 21 17
% Uso de la Red 0,8 0,44 1,09 1,23 1,29
Cliente2 - RIPv1 Cliente 1 Router Archivo 5Mb Archivo 10Mb Archivo 15Mb
Tiempo Promedio Ping 1 1 5 3 3
Paquetes Recibidos 3618 1978 9183 15141 20618
Paquetes Perdidos 0 0 4132 9364 14411
Tamaño de la Captura 5049133 2752403 6464612 7300509 7716528
Total Unicast 3601 1962 5035 5756 6191
Total Multicast 0 0 0 0 0
Total Broadcast 17 16 15 21 16
% Uso de la Red 0,8 0,44 1,03 1,16 1,23
102
Tabla 5 Ping 4096 RIPv2
Cliente1 - RIPv2 Cliente 2 Router Archivo 5Mb Archivo 10Mb Archivo 15Mb
Tiempo Promedio Ping 2 1 1 1 1
Paquetes Recibidos 3932 1958 7494 12986 18273
Paquetes Perdidos 0 0 3896 8620 13533
Tamaño de la Captura 5502946 2734399 4387480 4187279 5517192
Total Unicast 3929 1950 3596 3378 4740
Total Multicast 0 0 0 0 0
Total Broadcast 3 2 2 1 0
% Uso de la Red 0,87 0,43 0,7 0,67 0,88
Cliente2 - RIPv2 Cliente 1 Router Archivo 5Mb Archivo 10Mb Archivo 15Mb
Tiempo Promedio Ping 2 1 1 1 1
Paquetes Recibidos 3932 1938 7528 13030 18499
Paquetes Perdidos 0 0 4082 8272 13259
Tamaño de la Captura 5502946 2710692 4215400 5509370 5952184
Total Unicast 3929 1934 3444 4757 5239
Total Multicast 0 0 0 0 0
Total Broadcast 3 4 2 1 1
% Uso de la Red 0,87 0,43 0,67 0,88 0,95
103
Figura 19. Paquetes Recibidos Ping 4096
Figura 20. Paquetes Perdidos Ping 4096
Como se puede ver en las Figuras 19, 20 y 21, en esta prueba ( ping 4096), aunque el
protocolo RIPv1 se encuentra un poco por encima del protocolo RIPv2 en lo que se
refiere a tamaño de la captura de datos, no existe mucha diferencia entre los paquetes
Paquetes Recibidos Ping 4096
0
5000
10000
15000
20000
25000
Cliente Router Archivo5Mb
Archivo10Mb
Archivo15Mb
PaquetesRecibidosCliente1 RIPv1
PaquetesRecibidosCliente2 RIPv1
PaquetesRecibidosCliente1 RIPv2
PaquetesRecibidosCliente2 RIPv2
Paquetes Perdidos Ping 4096
0
2000
4000
6000
8000
10000
12000
14000
16000
Cliente Router Archivo5Mb
Archivo10Mb
Archivo15Mb
PaquetesPerdidosCliente1 RIPv1
PaquetesPerdidosCliente2 RIPv1
PaquetesPerdidosCliente1 RIPv2
PaquetesPerdidosCliente2 RIPv2
104
enviados y los paquetes perdidos entre cada uno. Presentan un comportamiento
aparentemente lineal a medida que se aumenta el tráfico. En cambio, en la Figura 22
se muestra una gran diferencia en la cantidad de broadcast generado por cada
protocolo.
Figura 21. Tamaño de la Data Ping 4096.
Cantidad Broadcast Ping 4096
0
5
10
15
20
25
Cliente Router Archivo5Mb
Archivo10Mb
Archivo15Mb
CantidadBroadcastCliente1 RIPv1CantidadBroadcastCliente2 RIPv1
CantidadBroadcastCliente1 RIPv2CantidadBroadcastCliente2 RIPv2
Figura 22. Cantidad de Paquetes Broadcast Ping 4096
Tamaño Captura Ping 4096
0
1000000
2000000
3000000
4000000
5000000
6000000
7000000
8000000
9000000
Cliente Router Archivo5Mb
Archivo10Mb
Archivo15Mb
Tamaño CapturaCliente1 RIPv1
Tamaño CapturaCliente2 RIPv1
Tamaño CapturaCliente1 RIPv2
Tamaño CapturaCliente2 RIPv2
105
4.1.2.2 PING 8192 BYTES
Tabla 6 Ping 8192 RIPv1
Cliente1 - RIPv1 Cliente 2 Router Archivo 5Mb Archivo 10Mb Archivo 15Mb
Tiempo Promedio Ping 6 3 4 3 4
Paquetes Recibidos 7854 3929 18170 19003 24150
Paquetes Perdidos 0 0 7912 8763 13028
Tamaño de la Captura 10977780 5450752 12039923 13316179 14104276
Total Unicast 7836 3910 9253 10223 11100
Total Multicast 0 0 0 0 0
Total Broadcast 18 19 15 17 22
% Uso de la Red 1,74 0,87 1,91 2,12 2,24
Cliente2 - RIPv1 Cliente 1 Router Archivo 5Mb Archivo 10Mb Archivo 15Mb
Tiempo Promedio Ping 5 2 3 4 4
Paquetes Recibidos 7819 3929 18349 19129 24511
Paquetes Perdidos 0 0 9496 9022 14729
Tamaño de la Captura 10927556 5433944 11639935 13171513 12798618
Total Unicast 7801 3898 8836 10090 9748
Total Multicast 0 0 0 0 0
Total Broadcast 18 19 17 17 22
% Uso de la Red 1,74 0,86 1,85 2,09 2,03
106
Tabla 7 Ping 8192 RIPv2
Cliente1 - RIPv2 Cliente 2 Router Archivo 5Mb Archivo 10Mb Archivo 15Mb
Tiempo Promedio Ping 3 3 2 2 4
Paquetes Recibidos 7436 3893 9271 14880 20060
Paquetes Perdidos 0 0 3056 9448 14260
Tamaño de la Captura 10405650 5447227 6672991 6962871 7181209
Total Unicast 7433 3890 5246 5431 5797
Total Multicast 0 0 0 0 0
Total Broadcast 3 3 4 1 3
% Uso de la Red 1,65 0,87 1,06 1,11 1,14
Cliente2 - RIPv2 Cliente 1 Router Archivo 5Mb Archivo 10Mb Archivo 15Mb
Tiempo Promedio Ping 3 3 3 2 3
Paquetes Recibidos 7412 3947 9315 14986 20143
Paquetes Perdidos 0 0 4152 7413 12986
Tamaño de la Captura 10372034 5499081 6635102 8146626 8555636
Total Unicast 7409 3944 5160 6587 7155
Total Multicast 0 0 0 0 0
Total Broadcast 3 3 3 0 2
% Uso de la Red 1,65 0,87 1,05 1,29 1,36
107
Figura 23. Paquetes Recibidos Ping 8192
Figura 24. Paquetes Perdidos Ping 8192
En esta prueba (ping 8192), se aprecia un mayor tamaño en la data enviada usando el
protocolo RIPv1. La cantidad de paquetes enviada también aumentó en el protocolo
RIPv1, aunque en los paquetes perdidos no se aprecia ninguna diferencia
significativa. En la Figura 26 se muestra los resultados de los broadcast realizados
Paquetes Recibidos Ping 8192
0
5000
10000
15000
20000
25000
30000
Cliente Router Archivo5Mb
Archivo10Mb
Archivo15Mb
PaquetesRecibidosCliente1 RIPv1
PaquetesRecibidosCliente2 RIPv1
PaquetesRecibidosCliente1 RIPv2
PaquetesRecibidosCliente2 RIPv2
Paquetes Perdidos Ping 8192
0
2000
4000
6000
8000
10000
12000
14000
16000
Cliente Router Archivo5Mb
Archivo10Mb
Archivo15Mb
PaquetesPerdidosCliente1 RIPv1
PaquetesPerdidosCliente2 RIPv1
PaquetesPerdidosCliente1 RIPv2
PaquetesPerdidosCliente2 RIPv2
108
en esta prueba. Los dos protocolo presentaron un leve aumento en el envío de
broadcast en las pruebas de transferencia de archivos, pero ninguno muy significativo
con respecto a la prueba anterior.
Tamaño Captura Ping 8192
0
2000000
4000000
6000000
8000000
10000000
12000000
14000000
16000000
Cliente Router Archivo5Mb
Archivo10Mb
Archivo15Mb
Tamaño CapturaCliente1 RIPv1
Tamaño CapturaCliente2 RIPv1
Tamaño CapturaCliente1 RIPv2
Tamaño CapturaCliente2 RIPv2
Figura 25. Tamaño de la Data Ping 8192
Cantidad Broadcast Ping 8192
0
5
10
15
20
25
Cliente Router Archivo5Mb
Archivo10Mb
Archivo15Mb
CantidadBroadcastCliente1 RIPv1
CantidadBroadcastCliente2 RIPv1CantidadBroadcastCliente1 RIPv2CantidadBroadcastCliente2 RIPv2
Figura 26. Cantidad de Paquetes Broadcast Ping 8192
109
4.1.2.3 PING 16384 BYTES
Tabla 8 Ping 16384 RIPv1
Cliente1 - RIPv1 Cliente 2 Router Archivo 5Mb Archivo 10Mb Archivo 15Mb
Tiempo Promedio Ping 8 4 15 36 33
Paquetes Recibidos 15751 7815 21507 25477 32125
Paquetes Perdidos 0 0 3816 9429 13829
Tamaño de la Captura 21980646 10906192 24001073 21754385 24408442
Total Unicast 15723 7793 17669 16032 18276
Total Multicast 0 0 0 0 0
Total Broadcast 28 22 22 16 20
% Uso de la Red 3,49 1,73 3,81 3,46 3,88
Cliente2 - RIPv1 Cliente 1 Router Archivo 5Mb Archivo 10Mb Archivo 15Mb
Tiempo Promedio Ping 24 4 23 36 17
Paquetes Recibidos 15752 7779 21488 25620 32548
Paquetes Perdidos 0 0 4214 9464 14970
Tamaño de la Captura 21980804 10855743 23561025 21824742 23696053
Total Unicast 15725 7758 17252 16139 17532
Total Multicast 0 0 0 0 0
Total Broadcast 27 21 22 17 22
% Uso de la Red 3,49 1,73 3,74 3,47 3,77
110
Tabla 9 Ping 16384 RIPv2
Cliente1 - RIPv2 Cliente 2 Router Archivo 5Mb Archivo 10Mb Archivo 15Mb
Tiempo Promedio Ping 6 5 6 5 7
Paquetes Recibidos 14401 7447 12748 18121 24160
Paquetes Perdidos 0 0 4271 9356 14428
Tamaño de la Captura 20160249 10417248 11331247 11567976 12741800
Total Unicast 14400 7445 8477 8764 9730
Total Multicast 0 0 0 0 0
Total Broadcast 1 2 0 1 2
% Uso de la Red 3,2 1,66 1,8 1,84 2,03
Cliente2 - RIPv2 Cliente 1 Router Archivo 5Mb Archivo 10Mb Archivo 15Mb
Tiempo Promedio Ping 6 4 10 4 5
Paquetes Recibidos 14353 7367 12485 18076 24334
Paquetes Perdidos 0 0 3978 8526 13740
Tamaño de la Captura 20093049 10284458 11197696 12209245 13551915
Total Unicast 14352 7364 8506 9525 10593
Total Multicast 0 0 0 0 0
Total Broadcast 1 3 1 1 1
% Uso de la Red 3,19 1,63 1,78 1,94 2,15
111
Figura 27. Paquetes Recibidos Ping 16384
Figura 28. Paquetes Perdidos Ping 16384
En esta prueba (ping 16384) se evidenció en mayor medida el incremento del tamaño
de la data enviada por el protocolo RIPv1, mientras el protocolo RIPv2 mantuvo su
comportamiento lineal. En cuanto a los paquetes recibidos por cada protocolo, el
comportamiento fue muy parecido al de la prueba anterior; RIPv1 siguió estando por
encima de su contraparte, aunque su crecimiento fue lineal para los dos casos. En los
paquetes perdidos ambos protocolos parecen haberse comportado de igual manera, a
Paquetes Recibidos Ping 16384
0
5000
10000
15000
20000
25000
30000
35000
Cliente Router Archivo5Mb
Archivo10Mb
Archivo15Mb
PaquetesRecibidosCliente1 RIPv1
PaquetesRecibidosCliente2 RIPv1
PaquetesRecibidosCliente1 RIPv2
PaquetesRecibidosCliente2 RIPv2
Paquetes Perdidos Ping 16384
0
2000
4000
6000
8000
10000
12000
14000
16000
Cliente Router Archivo5Mb
Archivo10Mb
Archivo15Mb
PaquetesPerdidosCliente1 RIPv1
PaquetesPerdidosCliente2 RIPv1
PaquetesPerdidosCliente1 RIPv2
PaquetesPerdidosCliente2 RIPv2
112
medida que se aumentó el tráfico en la red, la cantidad de paquetes perdidos fue
subiendo de igual manera para cada protocolo. El broadcast no cambió en esta
prueba
Tamaño Captura Ping 16384
0
5000000
10000000
15000000
20000000
25000000
30000000
Cliente Router Archivo5Mb
Archivo10Mb
Archivo15Mb
Tamaño CapturaCliente1 RIPv1
Tamaño CapturaCliente2 RIPv1
Tamaño CapturaCliente1 RIPv2
Tamaño CapturaCliente2 RIPv2
Figura 29. Tamaño de la Data Ping 16384
Cantidad Broadcast Ping 16384
0
5
10
15
20
25
Cliente Router Archivo5Mb
Archivo10Mb
Archivo15Mb
CantidadBroadcastCliente1 RIPv1
CantidadBroadcastCliente2 RIPv1CantidadBroadcastCliente1 RIPv2CantidadBroadcastCliente2 RIPv2
Figura 30. Cantidad de Paquetes Broadcast Ping 16384
113
4.1.3 ESTUDIO DE LAS DOS VERSIONES DEL PROTOCOLO RIP
Esta prueba consistió en verificar el tráfico que genera RIP en sus dos versiones.
Para ello se realizaron dos pruebas, una para RIPv1 y otra para RIPv2, parecidas a las
realizadas anteriormente pero sin la utilización de tráfico adicional en la red (ping o
envío de archivos). Los datos capturados fueron obtenidos mediante el sistema
NMIRE.
114
4.1.3.1 TRÁFICO GENERADO POR RIP
TABLA 10 Tráfico Generado por RIP
Router - RIPv1 140.5.5.1 140.5.6.1
Paquetes Recibidos 23 24
Paquetes Perdidos 0 0
Tamaño de la Captura 2517 2725
Total Unicast 3 4
Total Multicast 0 0
Total Broadcast 20 20
% Uso de la Red 0 0
Router - RIPv2 140.5.5.1 140.5.6.1
Paquetes Recibidos 8 10
Paquetes Perdidos 0 0
Tamaño de la Captura 715 829
Total Unicast 6 8
Total Multicast 0 0
Total Broadcast 2 2
% Uso de la Red 0 0
115
Paquetes Unicast
0
5
10
15
20
25
Router - RIPv1 Router - RIPv2
PaquetesUnicast Cliente1
PaquetesUnicast Cliente2
PaquetesBroadcastcliente1
PaquetesBroadcastCliente2
Figura 31. Paquetes Unicast y Broadcast en Tráfico de RIP
En la Figura 31 se puede apreciar fácilmente que hubo un incremento en los paquetes
unicast generados con el protocolo RIPv2, mientras que el broadcast bajó
considerablemente del valor que tenía con el protocolo RIPv1. Para ilustrar mejor
este hecho, podemos notar que el envío de paquetes unicast aumentó en un 50% al
pasar al protocolo RIPv2, mientras que el broadcast disminuyó en un 90%.
116
4.1.3.2 EVALUACIÓN DE LAS TABLAS DE RUTA DE RIP
Las tablas de rutas obtenidas con el comando ROUTE PRINT (en una consola de
MS-DOS) para RIPv1 y RIPv2 se pueden ver en la Figura 32 y la Figura 33.
Figura 32. Tabla de Ruta de RIPv1
Figura 33. Tabla de Ruta de RIPv2
117
Como se puede apreciar, el protocolo RIPv2 (en este tipo de red), coloca dos entradas
más en la tabla de ruta, las cuales corresponden a la dirección de broadcast de la red
del segundo cliente, y a la dirección de broadcast del segmento de red de esta misma
red.
118
4.1.4 RENDIMIENTO DEL SISTEMA NMIRE
Estas pruebas fueron realizadas a lo largo del desarrollo del sistema, así como en la
captura y análisis del tráfico de la red. “La prueba de rendimiento está diseñada para
probar el rendimiento del software en tiempo de ejecución dentro del contexto de un
sistema integrado. La prueba de rendimiento se da durante todos los pasos del
proceso de la prueba” (Pressman, 1998, p. 339-340).
El sistema presenta un comportamiento muy estable además de ser muy fácil de usar.
Presenta muchas características importantes, tales como la comparación de sesiones y
la comparación de protocolos (la cual fue muy útil en este proyecto ya que permite
comparar el comportamiento del protocolo RIPv1 con el protocolo RIPv2), así como
también el análisis del protocolo de los paquetes de la captura.
El rendimiento en este caso fue medido mediante dos criterios: tiempo de
procesamiento del sistema y funcionalidad del mismo.
Durante el proceso de captura el sistema nunca presentó problemas de desempeño, es
importante destacar que durante esta etapa el usuario no puede trabajar en otra
aplicación ya que se debe dar el uso exclusivo a la captura. Esto es así por dos
razones: la primera es que se tomó en consideración que la pérdida de paquetes en el
119
envío de datos, se debe generalmente a demoras por congestionamiento (lo cual debe
estimar el administrador de la red, utilizando NMIRE) o por un router lento el cual
retrace el flujo de los paquetes. Y segundo porque el sistema debe tener la atención
del programa de captura para poder detenerlo en el tiempo establecido. Pudiera ser
que el usuario interfiriera en este llamado del sistema al programa de captura,
utilizando alguna aplicación que consuma mucho tiempo en CPU y muchos recursos
del sistema, y de esta forma el programa de captura seguiría tomando paquetes hasta
que alguien lo detuviera manualmente, lo cual tampoco sería muy adecuado ya que
quedaría la memoria del computador con el buffer de la captura y de otras estructuras
utilizadas en el momento de captura.
Luego de realizada la captura y de haberse generado los archivos respectivos, el
sistema NMIRE abre esta captura teniendo la posibilidad de almacenar la sesión de
captura en la base de datos para referencias futuras. Los tiempo para leer estos
archivos se ve retardado en gran medida por el tamaño del archivo de captura. El
programa debe identificar cada línea y almacenarla en la base de datos antes de poder
mostrar la información. Este tiempo aumenta a medida que la captura sea más larga.
El análisis para ver la información de los paquetes sufre algo parecido a la lectura de
la captura. El tiempo de análisis está directamente relacionado con la cantidad de
paquetes de la captura. Otro dato importante es que después de haber analizado los
paquetes, el sistema deja esta informac ión en memoria. Esto es así ya que el usuario
120
no debería esperar otra vez el análisis sí lo que desea es volver a ver la información
que ya se analizó. Esto se refleja especialmente cuando se desea analizar los paquetes
de una captura distinta o cuando se cierra el sistema, en cuyo caso se debe primero
liberar de memoria este análisis antes de poder proseguir. Esto también genera una
demora relacionada con la cantidad de paquetes existentes en el análisis. Sin
embargo al evaluar la funcionalidad, la manera en que se presenta los datos permite
un fácil entendimiento de lo que se está mostrando, característica muy importante en
este tipo de sistemas.
En cuanto a la recuperación de sesiones anteriores, el sistema presenta un
comportamiento muy eficiente, ya que la lectura de estos datos es casi inmediata y
otorga la misma funcionalidad que tiene el sistema cuando está abriendo una nueva
captura. De manera que el usuario ya esté familiarizado con la interfaz.
La generación de gráficos por pantalla es un at ributo muy importante del sistema.
Permite realizar comparaciones importantes en el desempeño del tráfico de sesiones
diferentes, como también se pueden ver gráficos relacionados con la captura mostrada
en pantalla. El tiempo de estas comparaciones es muy reducido y está limitado
únicamente por la velocidad en que el usuario haga clic en el botón de comparación.
121
En resumen el sistema presenta un rendimiento muy elevado, limitado en algunas
oportunidades por el tiempo de lectura de capturas muy grandes; pero en general el
comportamiento es muy bueno si se compara con la cantidad de información que
muestra el sistema al usuario, en este caso al administrador de la red.
122
4.2 LIMITACIONES
Como limitación metodológica, no se captó ningún tipo de paquetes multicast en las
pruebas. Esto no es debido a un error en el sistema, sino a que por el tipo de red
empleada, una red muy básica de sólo tres computadoras, el router no tenía necesidad
de enviar paquetes de este tipo para actualizar las rutas; para ello emplea mensajes
unicast directamente (ya que solamente necesitaba comunicarse con una sola máquina
para cada segmento de red, y no a un grupo de máquinas).
Como otra limitación, en un principio se tenía planeado utilizar en la captura de
paquetes, una herramienta de Microsoft llamada Network Monitor (incluida dentro de
las herramientas administrativas de Windows NT), sin embargo para poderse incluir
en este proyecto, debía utilizarse un ambiente de programación desarrollado para el
Network Monitor incluido en la plataforma SDK (Software Development Kit –
Paquete de Desarrollo de Software). Para ello era necesario emplear mucho más
tiempo para el desarrollo del módulo de captura, que el empleado en realidad.
Además que requería de un gasto adicional para la adquisición de dicho ambiente de
desarrollo 15. De esta manera, se buscaron otras alternativas para solventar estos
inconvenientes, y se concluyó que la vía más óptima era utilizar las librerías de
captura Packet.dll.
15 Esta plataforma de desarrollo SDK viene incluida dentro del System Managment Server Beta 3, el cual es parte del Microsoft BackOffice Resource Kit 4.5. Para mayor información diríjase a www.microsoft.com
123
QUINTA PARTE
CONCLUSIONES Y RECOMENDACIONES
“Conocemos una cosa de manera absoluta, cuando sabemos cuál es la causa que la produce y el motivo por el cual no puede ser de otro modo; esto es saber por demostración; por eso, la ciencia se reduce a la demostración”
ARISTÓTELES
124
5.1 CONCLUSIONES
Se cumplió con el objetivo de desarrollar una celda de prueba que nos permita
determinar puntos críticos de saturación en una red. El sistema NMIRE determina
cuando un equipo está generando tráfico excesivo en la red, además se evidenció que
permite establecer comparaciones entre el tráfico de varios protocolo, en este caso
RIPv1 y RIPv2.
A través del Sistema NMIRE se demostró que cuando el tráfico es ligero en la red, la
cantidad de paquetes y el tamaño de la data que viaja es prácticamente la misma para
las dos versiones de RIP. Sin embargo, a medida que el tráfico aumenta, el tamaño
de la data y la cantidad de paquetes que viajan por la red, utilizando el protocolo
RIPv1, aumentan considerablemente en comparación con RIPv2. La cantidad de
paquetes descartados se mantienen prácticamente igual para las dos versiones
Los tiempos promedios del ping (utilizado por cada cliente para generar tráfico)
aumenta de la misma manera para las dos versiones de RIP; aunque este crecimiento
no se puede tomar como lineal sino como algo disperso.
Además el sistema NMIRE ayudó a cumplir con el objetivo de establecer
comparaciones entre las tablas de enrutamiento de las dos versiones del protocolo
125
RIP. Los niveles de tráfico generados por el protocolo RIPv1 fueron más elevados
que con RIPv2, sin embargo la tablas de ruta generadas por cada uno indican que para
este tipo de red (una red muy básica de solamente tres computadoras), RIPv1
mantiene menor cantidad de información, lo que se traduce en un me jor desempeño a
nivel de comprobación de rutas y actualizaciones periódicas.
Además el sistema NMIRE demostró que RIPv1 genera más broadcast que RIPv2;
sin embargo, la cantidad de paquetes unicast (en este tipo de red16) generada por el
protocolo RIPv1, es menor que en RIPv2. La disminución del broadcast utilizando
RIPv2 es de aproximadamente 90%, mientras que el aumento en el nivel de unicast es
de 50%.
Por último no se encontraron diferencias en las pruebas a la hora de llevar las tablas
de enrutamiento en forma estática o en forma dinámica. Ya que una vez creadas las
tablas utilizando el protocolo RIP, no hace falta modificarlas sí se trabajaran
manualmente. Sólo habría diferencias sí una de las rutas fallara, lo cual no es parte
de esta investigación
16 Ver Limitaciones.
126
Es importante destacar que el sistema no fue realizado con la única intención de
usarlo en este proyecto, sino se estima que sea una herramienta útil para los
administradores de red para determinar criterios globales de tráfico de red.
127
5.2 RECOMENDACIONES
Se recomienda, para las personas que deseen continuar este proyecto, las siguientes
consideraciones:
?? Ampliar el sistema NMIRE para poder utilizarse en cualquier tipo de red.
Para ello se pueden realizar estudios del comportamiento del sistema bajo
cambios en la topología de la red.
?? Ya que el sistema NMIRE en el momento del análisis de la captura, lleva
solamente estadísticas de dos equipos, además del router, sería muy útil
adaptarlo para que permitiera guardar todos los equipos que intervienen en
el envío de paquetes y así realizar estadísticas en este sentido.
?? El módulo de análisis de paquetes, en estos momentos, está configurado
para captar únicamente paquetes que contengan en el campo de identificación
del tipo de red, redes del tipo IEEE802.3, Internet IP (Ipv4) y ARP. De esta
manera se pueden desarrollar módulos extras incorporables al sistema para
monitorear diferentes tipos de protocolo. Para ello se deben tomar en
consideración el tipo de paquetes que genera el protocolo que se desea
adaptar, así como los campos del paquete asociados a ese protocolo.
128
REFERENCIAS BIBLIOGRÁFICAS
Tanenbaum, Andrew S. (1997). Redes de Computadora. México: Prentice–Hall
Hispanoamérica.
Comer, Douglas E. (1991). Internetworking With TCP/IP. Englewood Cliffs, NJ:
Prentice–Hall.
Rose, Marchall T. (1991). The Simple Book: An Introduction to Management of
TCP/IP – Based Internets. Englewood Cliffs, NJ: Prentice-Hall.
Wokingham, K Washburn. (1993). TCP/IP: Running a Successful Network.
England: Addison Wesley.
Hernández, S. (2000). Evaluación de plataformas de redes LAN (local area
networks) con enrutamiento bajo protocolo RIP (routing information protocol)
versiones 1 y 2. Proyecto Industrial, Ingeniería de Sistemas, Universidad
Metropolitana.
129
Pressman, Roger S. (1998). Ingeniería de Software. Un Enfoque Práctico (4ta. Ed.).
Madrid: McGraw Hill.
Hernández S, R., Fernández C, C. y Baptista L, P. (1998). Metodología de la
Investigación (2da. Ed.) México: McGraw Hill.
RFC 1058 Routing Information Protocol (1988), [en línea]. Disponible en:
http://www.cis.ohio -state.edu/cgi-bin/rfc/rfc1058.html [julio, 2001].
RFC 1387 RIP Versión 2 Protocol Analysis (1993), [en línea]. Disponible en:
http://www.cis.ohio -state.edu/cgi-bin/rfc/rfc1387.html [julio, 2001].
RFC 1700 Assigned Numbers (1994), [en línea]. Disponible en:
http://www.cis.ohio -state.edu/cgi-bin/rfc/rfc1700.html [julio, 2001].
RFC 1722 RIP Versión 2 Protocol Applicability Statement (1994), [en línea].
Disponible en: http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1722.html [julio, 2001].
RFC 1723 RIP Versión 2 Carrying Additional Information (1994), [en línea].
Disponible en: http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1723.html [julio, 2001].
130
Microsoft Corp. (2000). Implementing IP Routing , [en línea]. Disponible en:
http://www.microsoft.com/technet/network/implip.asp [julio 2001].
Microsoft Corp. (2000). Administering Routing and Remote Access Service , , [en
línea]. Disponible en:
http://www.microsoft.com/technet/winnt/winntas/manua ls/rras40/rrasch03.asp
[julio 2001].
WinPcap (2001). Windows Packet Capture Library, [en línea]. Disponible en:
http://netgroup-serv.polito.it/winpcap/default.htm [julio 2001].
Packet.dll API: Programmer’s Manual (2001). Windows Packet Capture Library
Docs , [en línea]. Disponible en:
http://netgroup-serv.polito.it/winpcap/ docs/dll.htm [julio 2001].
Fernández Menéndez Cazorla, (2001). Introducción a las Redes [en línea]. España.
Disponible en: http://anas.worldonline.es/fer-mc.r/redes/tema01.htm [julio 2001].
131
Ethernet Codes Master Page, (1998) [en línea]. Disponible en:
http://www.cavebear.com/cavebear/ethernet [julio 2001].
Linnet Solution TCP/UDP Port Numbers, (2001) [en línea]. Disponible en:
http://www.ec11.dial.pipex.com/port-num.htm [julio 2001].
Newsletter Library, (1997). RIPv1 vs RIPv2 [en línea]. Disponible en:
http://www.pmg/otw_nwsl/97_w_rip.htm [julio 2001].
TCP/IP, Index, (1996) [en línea]. Disponible en:
http://www.ictp.trieste.it/~radionet/nuc1996/ref/tcpip/append.htm [julio 2001].
132
APÉNDICE A
NMIRE – DIAGRAMA DE FLUJO DE DATOS
133
A continuación se presenta el diagrama de flujo de datos, aquí se encuentra la
información de los procesos del sistema y de los flujos de datos del mismo, luego de
manera esquematizada se presenta una descripción de cada uno de ellos.
134
Ilustración 1 - Nivel 0 NMIRE
1SOLICITARCAPTIRA
3ABRIR
CAPTURA
4MOSTRAR
DATOS
6VER
CAPTURA
5GENERARGRÁFICO
7COMPARARSESIONES
USUARIO
TRAFFIC.MDB
8CONFIGURARPROGRAMA
Pedir Captura
MODULO DECAPTURA
Comando paraejecutar captura
en la tarjeta 1 Comando paraejecutar capturaen la tarjeta 2
2DETENERCAPTURA
Señal de Comienzode Captura
Comando paradetener captura 1 y 2
Archivo deCaptura 1
Archivo deCaptura 2
USUARIO
Tiempode Captura
Nombre de la Sesión
Datos de la Captura
Datos de la Captura(y Sesión)
Configuración
Datos deConfiguración
Variables
VerificarVariables
Datos de laCaptura por
Pantalla
Gráfico porPantalla
USUARIO
Código dela Captura
Paquetes
Sesionesa Comparar
Comparaciónde Sesiones
Información delos Paquetes
VerPaquetes
PaquetesY Sesiones
Created with Visio
135
Ilustración 2 - NMIRE - DETENER CAPTURA
TRAFFIC.MDB
2.2 (*)COMPROBAR
TIEMPO
MODULO DECAPTURA
Tiempo deEjecución
2.3FINALIZARPROCESO
2.1INICIALIZAR
RELOJ
1SOLICITARCAPTURA
Tiempode Captura
DetenerReloj
Pedir Tiempo
TiempoCulminado
Comando paraFinalizar Captura
1 y 2
Señal deComienzo
2.2 COMPROBAR TIEMPO:
Compara el tiempo de Ejecución del Reloj, con el tiempode captura guardado en la base de datos. Sí el tiempo deejecución es mayor o igual al tiempo de captura, entoncesse envía la señal "Tiempo Culminado" al proceso 2.3"FINALIZAR PROCESO".Esto es:
if Tiempo_Eje >= Tiempo_Cap Then <<Enviar Señal de Culminación>> else <<Seguir Comprobando Tiempo>>end if
Created with Visio
136
Ilustración 3 - NMIRE - ABRIR CAPTURA
3.1 (*)INICIALIZARVARIABLES
USUARIO
TRAFFIC.MDB
MODULO DECAPTURA
Variables
Nombre dela Sesión
Nombre dela Sesión
Nombre dela Sesión
Archivo 1 y 2de captura
Archivo 1 y 2de captura
Captura
Paquetes
Nuevos valoresde las Variables
Datos dela Captura
3.2TOMARSESIÓN
3.4GUARDAR
CAPTURA YPAQUETES
3.3 (**)ABRIR
CAPTURA1 Y 2
4MOSTRARVARIABLES
(*) 3.1 INICIALIZAR VARIABLES
1.Coloca los valores de las variablesque monitorea el sistema en el valor 0. (Broadcast,Unicast, Multicast, % Uso de la Red, PaquetesRecibidos, Paquetes Perdidos, Tamaño de la DataCapturada).
2.Toma los nuevos valores de lasvariables antes mencionadas y las actualiza.
3. Entrega estos valores al proceso 4"MOSTRAR VARIABLES".
(**) 3.3 ABRIR CAPTURA
Este proceso se realiza dos veces, primero para elarchivo de captura 1 (generado por el tráfico en laprimera tarjeta de red) y luego el archivo de captura2 (generado a su vez por el tráfico en la segundatarjeta de red).
Created with Visio
137
Ilustración 4 - NMIRE - ABRIR CAPTURA - GUARDAR CAPTURA Y PAQUETES
TRAFFIC.MDB
Nuevos valoresde las Variables
3.4.2IDENTIFICARDATA DE LA
LÍNEA
3.1INICIALIZARVARIABLES
3.3ABRIR
CAPTURA1 Y 2
3.4.3ACTUALIZARVARIABLES
3.4.1LEER POR
LÍNEA
Archivo 1 y 2de captura Línea
LíneaIdentificada
CapturaPaquetes
Created with Visio
138
Ilustración 5 - NMIRE - VER CAPTURA
6.1TOMAR
PAQUETES
TRAFFIC.MDB
4MOSTRAR
DATOSUSUARIO
Código dela Captura
Paquetes
Información delos Paquetes
VerPaquetes
6.4IDENTIFICAR
ELPROTOCOLO
6.6MOSTRARPAQUETES
ANALIZADOS
6.3IDENTIFICARTIPO DE RED
6.5DECODIFICARLOS CAMPOS
6.2ANALIZAR
CAMPOS DELPAQUETE
Paquetes dela Captura
Campos deEthernet
Tipo deEthernet
Campos deProtocolo
Protocolo Campos delPaquete
PaqueteDecodificado
PaqueteAnalizado
Created with Visio
139
Ilustración 6 - NMIRE - COMPARAR SESIONES
7.1TOMAR
VALORES DELA B/D
USUARIO
TRAFFIC.MDB
Sesionesa Comparar
Comparaciónde Sesiones
PaquetesY Sesiones
7.2GRAFICARVALORES
Valores delas Sesiones
Created with Visio
140
Ilustración 7 - Módulo de Captura
NMIRE
1EJECUTARPROGRAMA
DE CAPTURA
2REALIZARCAPTURA
3BUSCARADAP. DE
RED
4TOMAR
PAQUETE
5IMPRIMIR
TAMAÑO DELPAQUETE EN
PANTALLA
6DETENERCAPTURA
Comando paraEjecutar capturaen la tarjeta 1 y 2
Número delAdaptador
Lista deAdaptadores
Archivode
Captura
PaqueteCapturado
Continuar Ciclode Captura
Comando paradetener captura
1 y 2
Archivo deCaptura
Archivode Captura
Datos delPaquete
Cerrar Archivo
Detener Ciclode Captura
Tamaño delPaquete
GuardarEstadísticas
Created with Visio
141
Ilustración 8 - MODCAP - REALIZAR CAPTURA
3BUSCARADAP. DE
RED
2.8CERRARCAPTURA
Número delAdaptador
Parar Ciclo
Lista deAdaptadores
Archivode
Captura
Buffer delDriver
Continuar Ciclode Captura
Detener Ciclode Captura
GuardarEstadísticas
1EJECUTARPROGRAMA
DECAPTURA
6DETENERCAPTURA
4TOMAR
PAQUETE
2.6INICIALIZARESTRUCTURA
DELPAQUETE
2.7INICIAR
CAPTURA
2.5ASIGNAR
BUFFER DELDRIVER
2.4ABRIR
ADAPTADOR
2.3ASIGNAR
BUFFER DELA APLIC.
2.2CONFIGURAR
CAPTURA
2.1VERIFICAR
ADAPTADOR
Identificadordel Adaptador
Buffer dela Aplicación
Número deAdaptador
Buffer delDriver
Estructuradel Paquete
Paquete
Adaptador
Created with Visio
142
Ilustración 9 - MODCAP - REALIZAR CAPTURA - CERRAR CAPTURA
2.8.3CERRAR
ADAPTADOR
Parar Ciclo
Archivode
Captura
Detener Ciclode Captura
GuardarEstadísticas
6DETENERCAPTURA
2.8.1OBTENER
ESTADÍSTICASDE LA
CAPTURA
2.8.2LIBERAR
PAQUETE YBUFFER
Detener Ciclode Captura
Detener Ciclode Captura
2.7INICIAR
CAPTURA
Created with Visio
143
DESCRIPCIÓN DE PROCESOS
SISTEMA NMIRE 1 SOLICITAR CAPTURA Este proceso sirve para iniciar el proceso de captura en la red. Envía una señal de comienzo al módulo de captura y otra para inicializar el reloj. Entradas Origen Salidas Destino
Pedir Captura Usuario Señal de Comienzo de captura.
2 Detener Captura
Comando para ejecutar captura 1 y 2
Módulo de Captura
2 DETENER CAPTURA Este proceso es el encargado de llevar el tiempo en que se está ejecutando la captura. Cuando este tiempo finaliza envía una señal de fin de captura al módulo de captura. Entradas Origen Salidas Destino
Señal de Comienzo de captura. 1 Solicitar Captura
Comando para detener captura 1 y 2
Módulo de Captura
Tiempo de Captura Base de Datos 3 ABRIR CAPTURA Abre el archivo de captura generado por el Módulo de Captura. Lee los valores del archivo y los guarda en la base de datos. Además guarda el nombre de la sesión de captura y actualiza los valores de las variables que utiliza el sistema para determinar el tráfico (tamaño de la data capturada, broadcast, unicast, multicast, paquetes recibidos, paquetes perdidos, porcentaje de uso de la red). Entradas Origen Salidas Destino Archivo de Captura 1 y 2 Módulo de Captura Datos de la
Captura y Sesión Base de Datos
Nombre de la Sesión Usuario Datos de la
Captura 4 Mostrar Datos
144
4 MOSTRAR DATOS Se encarga de mostrar las variables de la captura realizada. Entradas Origen Salidas Destino Datos de la Captura
3 Abrir Captura Código de la Captura
6 Ver Captura
Verificar Variables 5 Generar Gráfico Datos de la Captura por Pantalla
Usuario
Variables Generar Gráfico 5 GENERAR GRÁFICO Se encarga de mostrar un gráfico por pantalla de los valores de las variables para una mejor comprensión. Entradas Origen Salidas Destino
Variables 4 Mostrar Datos Verificar Variables 4 Mostrar Datos
Gráfico por Pantalla
Usuario
6 VER CAPTURA Este proceso realiza el análisis de protocolo de los paquetes para mostrarlos por pantalla. Entradas Origen Salidas Destino Código de la Captura 4 Mostrar Datos Información de los
paquetes Usuario
Paquetes Base de Datos
Ver Paquetes Usuario 7 COMPARAR SESIONES Este proceso se encarga de comparar sesiones guardas con anterioridad en el sistema. Entradas Origen Salidas Destino Paquetes y Sesiones Base de Datos Comparación de
Sesiones Usuario
Sesiones a Comparar Usuario
145
8 CONFIGURAR PROGRAMA Este proceso se encarga de configurar diferentes opciones del sistema incluyendo el tiempo de captura. Entradas Origen Salidas Destino
Configuración Usuario Datos de la Configuración
Base de Datos
2.1 INICIALIZAR RELOJ Coloca el reloj en cero, y lo pone en marcha. Entradas Origen Salidas Destino
Señal de Comienzo 1 Solicitar Captura Tiempo de Ejecución
2.2 Comprobar tiempo
Pedir Tiempo 2.2 Comprobar tiempo
Detener Reloj 2.3 Finalizar Proceso
2.2 COMPROBAR TIEMPO Se encarga de verificar que el tiempo de ejecución no sea mayor al tiempo de captura guardado en la base de datos. Entradas Origen Salidas Destino Tiempo de Ejecución
2.1 Inicializar Reloj Tiempo Culminado 2.3 Finalizar
Proceso
Tiempo de Captura Base de Datos Pedir Tiempo 2.1 Inicializar Reloj
2.3 FINALIZAR PROCESO Se encarga de detener el reloj y de enviar una señal de fin de captura al módulo de captura. Entradas Origen Salidas Destino
Tiempo Culminado 2.2 Comprobar Tiempo Detener Reloj 2.1 Inicializar
Reloj
Comando para Detener Captura 1 y 2
Módulo de Captura
146
3.1 INICIALIZAR VARIABLES Coloca los valores de las variables que utiliza el sistema en el valor correcto. Entradas Origen Salidas Destino Nuevos valores de las Variables
3.4 Guardar Captura y Paquetes
Variables 3.3 Abrir Captura 1 y 2
Datos de la Captura
4 Mostrar Variables
3.2 TOMAR SESIÓN Se encarga de guardar el nombre de la sesión en la base de datos. Entradas Origen Salidas Destino Nombre de la sesión Usuario Nombre de la
sesión Base de Datos
Nombre de la sesión
3.3 Abrir Captura
3.3 ABRIR CAPTURA Se encarga de abrir la captura realizada por el Módulo de captura.
Entradas Origen Salidas Destino
Variables 3.1 Inicializar Variables
Archivo 1 y 2 de captura
3.4 Guardar Captura y Paquetes
Nombre de la Sesión 3.2 Tomar Sesión
Archivo 1 y 2 de captura
Módulo de Captura
3.4 GUARDAR CAPTURA Y PAQUETES Guarda los datos de la captura y de los paquetes en la base de datos. Entradas Origen Salidas Destino Archivo1 y 2 de Captura
3.3 Abrir Captura 1 y 2
Nuevos Valores de las Variables
3.1 Inicializar Variables
Captura Base de Datos
Paquetes Base de Datos
147
3.4.1 LEER POR LÍNEA Lee línea por línea el archivo capturado y entrega esta línea para su identificación. Entradas Origen Salidas Destino Archivo 1 y 2 de Captura
3.3 Abrir Captura Línea 3.4.2 Identificar data de la línea
3.4.2 IDENTIFICAR DATA DE LA LÍNEA Identifica los valores de la línea y entrega estos resultados al siguiente proceso. Entradas Origen Salidas Destino
Línea 3.4.1 Leer por Línea
Línea Identificada 3.4.3 Actualizar Variables
3.4.3 ACTUALIZAR VARIABLES Cambia los valores de las variables del sistema y guarda la información de las líneas identificadas (como captura y paquetes) en la base de datos. Entradas Origen Salidas Destino
Línea Identificada 3.4.2 Identificar data de la línea
Nuevos Valores de las Variables
3.1 Inicializar Variables
Paquetes Base de Datos
Captura Base de Datos 6.1 TOMAR PAQUETES Toma los paquetes que quiere analizar el usuario de la base datos utilizando el código de la captura. Entradas Origen Salidas Destino Código de la captura
4 Mostrar Datos Paquetes de la Captura
6.2 Analizar Campo del Paquete
Ver Paquetes Usuario
Paquetes Base de Datos
148
6.2 ANALIZAR CAMPOS DEL PAQUETE Analiza los campos del paquete para decidir su tipo. Entradas Origen Salidas Destino Paquetes de la captura
6.1 Tomar Paquetes
Campos de Ethernet
6.3 Identificar Tipo de Red
Tipo de Ethernet 6.3 Identificar Tipo de Red
Campos de Protocolo
6.4 Identificar el Protocolo
Protocolo 6.4 Identificar el Protocolo
Campos del Paquete
6.5 Decodificar los Campos
Paquete Decodificado
6.5 Decodificar los Campos Paquete Analizado
6.6 Mostrar Paquetes Analizados
6.3 IDENTIFICAR TIPO DE RED Identifica el tipo de Ethernet del Paquete (por ejemplo ARP, IP, Appletalk, etc). Entradas Origen Salidas Destino Campos de Ethernet
6.2 Analizar Paquetes
Tipo de Ethernet 6.2 Analizar Paquetes
6.4 IDENTIFICAR EL PROTOCOLO Identifica el tipo de protocolo asociado al tipo de red del paquete (por ejemplo en el caso de que el tipo de red sea IP alguno de los protocolos pueden ser: TCP, ICMP, IP, UDP, etc). Entradas Origen Salidas Destino Campos de Protocolo
6.2 Analizar Paquetes
Protocolo 6.2 Analizar Paquetes
6.5 DECODIFICAR LOS CAMPOS Toma los campos del paquete y determina la información que viene el mismo. Entradas Origen Salidas Destino Campos del Paquete
6.2 Analizar Paquetes
Paquete Decodificado
6.2 Analizar Paquetes
6.6 MOSTRAR PAQUETES ANALIZADOS Toma cada paquete analizado y lo despliega por pantalla.
Entradas Origen Salidas Destino
Paquete Analizado 6.2 Analizar Paquetes
Información de los Paquetes Usuario
149
7.1 TOMAR VALORES DE LA BASE DE DATOS Recupera los valores de los paquetes que desea el usuario comparar de la base datos. Entradas Origen Salidas Destino Sesiones a comparar Usuario Valores de las
Sesiones 7.2 Graficar Valores
Paquetes y Sesiones
Base de Datos
7.2 GRAFICAR VALORES Toma los valores de las sesiones y los despliega por pantalla.
Entradas Origen Salidas Destino Valores de las Sesiones
7.1 Tomar valores de la B / D
Comparación de Sesiones Usuario
150
MÓDULO DE CAPTURA 1 EJECUTAR PROGRAMA DE CAPTURA Inicializa los programas de las dos instancias de captura (capture1.exe y capture2.exe) Entradas Origen Salidas Destino Comando para ejecutar captura en la tarjeta 1 y 2
NMIRE Número del Adaptador 2 Realizar Captura
2 REALIZAR CAPTURA Inicia la captura en el Driver de Captura Entradas Origen Salidas Destino
Número del adaptador
1 Ejecutar Programa de Captura
Buffer del Driver 4 Tomar Paquete
Lista de Adaptadores
3 Buscar Adap. de Red
Guardar Estadísticas
Archivo de Captura
Continuar Ciclo de Captura 4 Tomar Paquete
Detener Ciclo de Captura 6 Detener Captura
3 BUSCAR ADAP. DE RED Busca los adaptadores de Red del sistema. Entradas Origen Salidas Destino
Lista de Adaptadores 2 Realizar Captura
4 TOMAR PAQUETE Toma los paquetes del buffer del driver y los guarda en el archivo de captura. Entradas Origen Salidas Destino
Buffer del Driver 2 Realizar Captura Continuar Ciclo de Captura
2 Realizar Captura
Tamaño del Paquete
5 Imprimir Tamaño del Paquete
Datos del Paquete Archivo de Captura
151
5 IMPRIMIR TAMAÑO DEL PAQUETE Imprime el tamaño del paquete por pantalla a medida que se van capturando. Entradas Origen Salidas Destino Tamaño del paquete 4 Tomar Paquete
6 DETENER CAPTURA Detiene el proceso de captura. Entradas Origen Salidas Destino Comando para detener captura NMIRE Detener Ciclo de
Captura 2 Realizar Captura
Cerrar Archivo Archivo de Captura
Archivo de Captura
Archivo de Captura
Archivo de Captura
Archivo de Captura
2.1 VERIFICAR ADAPTADOR Verifica que el adaptador esté presente en el sistema. Entradas Origen Salidas Destino
Número del Adaptador
1 Ejecutar Programa de Captura
Identificador del Adaptador
2.2 Configurar Captura
Lista de Adaptadores
3 Buscar Adap. De Red
152
2.2 CONFIGURAR CAPTURA Establece los valores de configuración del programa (buffer del driver, buffer de la aplicación, estructura del paquete). Entradas Origen Salidas Destino Identificador del Adaptador
2.1 Verificar Adaptador
Buffer de la Aplicación
2.3 Asignar Buffer de la Aplicación
Número del Adaptador
2.4 Abrir Adaptador
Buffer del Driver 2.5 Asignar Buffer del Driver
Estructura del Paquete
2.6 Inicializar Estructura del Paquete
2.3 ASIGNAR BUFFER DE LA APLICACIÓN Asigna el valor del buffer. Esto es el tamaño en bytes de la estructura de memoria que contendrá los paquetes que vienen del driver mientras son guardados en el archivo de captura. Entradas Origen Salidas Destino Buffer de la Aplicación
2.2 Configurar Captura
2.4 ABRIR ADAPTADOR Abre el adaptador especificado para leer los paquetes que pasan por él. Además coloca el adaptador en modo promiscuo, de esta forma se tomarán todos los paquetes que lleguen a la tarjeta de red. Entradas Origen Salidas Destino Número del adaptador
2.2 Configurar Captura
2.5 ASIGNAR BUFFER DEL DRIVER Asigna el valor del buffer. Esto es el tamaño en bytes de la estructura de memoria que contendrá los paquetes que vienen del adaptador de red. Entradas Origen Salidas Destino
Buffer del Driver 2.2 Configurar Captura
153
2.6 INICIALIZAR ESTRUCTURA DEL PAQUETE Crea la estructura en memoria del paquete, de esta manera los paquetes se reciben por esta estructura. Entradas Origen Salidas Destino Estructura del Paquete
2.2 Configurar Captura
Paquete 2.7 Iniciar Captura
2.7 INICIAR CAPTURA Toma los paquetes del adaptador de red y los guarda en el buffer del Driver. Entradas Origen Salidas Destino
Adaptador 2.4 Abrir Adaptador
Buffer del Driver 4 Tomar Paquete
Paquete 2.6 Inicializar Estructura del Paquete
Continuar Ciclo de Captura
4 Tomar Paquete
Parar Ciclo 2.8 Cerrar Captura 2.8 CERRAR CAPTURA Se encarga de detener el ciclo de captura. Entradas Origen Salidas Destino Detener Ciclo de Captura
6 Detener Captura Parar Ciclo 2.7 Iniciar Captura
Guardar Estadísticas
Archivo de Captura
2.8.1 OBTENER ESTADÍSTICAS DE LA CAPTURA Obtiene las estadísticas de la captura. La biblioteca dinámica Packet.dll contiene una instrucción para esto, por lo tanto no es necesario crear una estruc tura para guardar esta información. Entradas Origen Salidas Destino Detener Ciclo de Captura 6 Detener Captura Guardar
Estadísticas Archivo de Captura
154
2.8.2 LIBERAR PAQUETE Y BUFFER Cierra las estructuras de paquetes y ambos buffer, y las quita de memoria.
Entradas Origen Salidas Destino Detener Ciclo de Captura 6 Detener Captura
2.8.3 CERRAR ADAPTADOR Cierra el adaptador de red. Entradas Origen Salidas Destino Detener Ciclo de Captura 6 Detener Captura Parar Ciclo 2.7 Iniciar Captura
155
APÉNDICE B
DIAGRAMA DE ENTIDAD – REALACIÓN
156
La Figura 34 muestra el diagrama de entidad – relación de la base de datos del
sistema NMIRE, aquí se almacena la información de la captura y los paquetes.
Además están las tablas de Equipos, Sesiones y la de configuración del sistema.
Figura 34. Diagrama Entidad – Relación
A continuación se presenta una descripción de las tablas de la base de datos del
sistema traffic.mdb.
CAPTURE
IdCaptura Fecha PaqRec PaqPer DataLen CaptureLen Tarjeta Sesion Unicast Multicast Broadcast TiempoCap
PAQUETE
Hora Tamaño IdCaptura Data
EQUIPO
IP Nombre Descripción
SESIÓN
NombreSesion
TAConfiguracion
Buffer Repeticiones Tiempo
1
N
157
CAPTURE
Guarda la información de las capturas.
Campo Descripción
IdCaptura Campo Clave de la tabla.
Fecha Fecha en la cual se hizo la captura.
PaqRec Cantidad de Paquetes Recibidos en la captura.
PaqPer Cantidad de Paquetes Perdidos durante la captura.
DataLen Tamaño de la Data capturada. (medida en bytes).
CaptureLen Tamaño de la Captura (medida en bytes).
Tarjeta Tarjeta de red de la cual proviene la captura.
Sesion Nombre de la Sesión de Captara.
Unicast Cantidad de paquetes unicast de la captura.
Multicast Cantidad de paquetes multicast de la captura.
Broadcast Cantidad de paquetes broadcast de la captura.
TiempoCap Tiempo que duró la captura.
158
PAQUETE
Almacena la información de los paquetes capturados.
Campo Descripción
Hora Hora en que se recibió el paquete.
Tamaño Tamaño del paquete (medido en bytes).
IdCaptura Clave de la Captura asociada al paquete.
Data Data del Paquete.
SESION
Guarda los nombres de las Sesiones realizadas.
Campo Descripción
NombreSesion Nombre de la sesión.
159
EQUIPO
Almacena la información de los equipos.
Campo Descripción
Ip Dirección Ip del equipo.
Nombre Nombre del equipo.
Descripcion Descripción del equipo.
TAConfiguracion
Opciones de configuración del programa.
Campo Descripción
Buffer Tamaño de la data en bytes utilizada por el módulo de
generación de tráfico del sistema.
Repeticiones Número de repeticiones del ping utilizado en el módulo de
generación de tráfico del sistema.
Tiempo Tiempo en segundos en que se debe realizar la captura.
160
ANEXO A
MANUAL DE USUARIO
161
DESCRIPCIÓN DE LAS PANTALLAS DEL SISTEMA
La pantalla principal muestra la información de captura esencial del sistema. A mano
izquierda se encuentran tres cuadros: el primero representa los datos del router y los
otros dos los datos de los clientes. A mano derecha están otros datos asociados a los
cuadros de la izquierda. Esta información es la siguiente:
?? Paquetes Recibidos (para el router), paquetes enviados (para los clientes)
?? Paquetes Perdidos
?? Tamaño de la Data Capturada.
?? Total Unicast.
?? Total Multicast.
?? Total Broadcast.
?? % Tráfico Procesado.
Además encontramos un menú donde están todas las opciones del sistema. La
Figura 35 muestra la pantalla principal.
162
Figura 35. Pantalla Principal del Sistema NMIRE
163
ABRIR SESIÓN
Para abrir una sesión de captura , debe ir al menú archivo de l menú principal y
seleccionar la opción “Abrir Sesión...”, se presenta una ventana con todas las sesiones
guardadas en la base de datos. Seleccione la sesión que desee abrir y haga clic en
Aceptar. La Figura 36 muestra la ventana de abrir sesión.
Figura 36. Abrir Sesión
ABRIR CAPTURA
Con esta opción se puede abrir una captura recién hecha, el programa pregunta si se
desea guardar la sesión de captura. En ese caso indique el nombre de la sesión y haga
clic en Aceptar, en caso contrario indique que no desea guardar la captura y espere a
que el programa muestre los datos por pantalla de la captura. La Figura 37
164
Figura 37. Abrir Captura.
Luego de abrir la captura, se pede acceder al menú ver de la pantalla principal. En
este menú hay dos opciones: ver captura y ver gráfico.
VER CAPTURA Y VER GRÁFICO
Esta opción sirve para ver los paquetes contenidos en la captura realizada. A su vez
analiza su contenido y lo expone de una manera organizada para un mayor
entendimiento. La Figura 38 muestra los paquetes de una captura.
165
Figura 38. Ver Captura
Además es posible ver un gráfico indicando la cantidad de paquetes unicast, multicast
y broadcast que fueron capturados. Para ello seleccione la opción Ver / Gráfico de la
pantalla principal. La Figura 39 muestra un gráfico de una captura.
Figura 39. Ver Gráfico
166
GENERADOR DE TRÁFICO
El sistema NMIRE tiene una utilidad para generar tráfico desde el servidor a la red
llamada Traffic Agent Generator. Esta utilidad es muy útil para verificar la
accesibilidad a otros equipos dentro de la red. Permite enviar una cantidad de pings
preestablecida a una dirección ip y devuelve el tiempo promedio del mismo, en caso
de no encontrar el equipo, devuelve el error generado. La Figura 40 muestra la
utilidad Traffic Agent Generator.
Figura 40. Generador de tráfico
CAPTURAR EL TRÁFICO
Para capturar el tráfico de la red, el sistema tiene una utilidad llamada Taffic Monitor,
la cual ejecuta los dos programas de captura Capture1.exe y Capture2.exe (cada uno
167
para la captura de cada tarjeta de red). Esta captura se efectúa durante un tiempo
predeterminado (ver opciones del sistema) y durante este proceso no se podrá realizar
ninguna otra función en la computadora. Esto es así para evitar que se pierdan
paquetes por cargas adicionales en el servidor. La Figura 41 muestra una ventana de
captura.
Figura 41. Ventana de captura.
EQUIPOS
Se pueden ingresar nuevos equipos en la base de datos para ser usados posteriormente
con Traffic Agent Generator, también podemos borrar equipos ingresados
anteriormente o simplemente consultar los ya existentes. Para acceder a esta opción
elija la opción Equipos en el menú Herramientas de la ventana principal. La Figura
42 muestra esta ventana.
168
Figura 42. Equipos
CONSULTA
Para consultar las capturas realizadas anteriormente por sesiones o por fecha, se
puede hacer mediante la opción Consulta en el menú Herramientas de la ventana
principal. La Figura 43 muestra la ventana de consulta.
Figura 43. Consulta
169
COMPARAR SESIONES
Esta opción es muy útil, permite comparar mediante un gráfico, dos o más sesiones
creadas anteriormente en el sistema. Para acceder a esta opción diríjase a la opción
Comparar Sesiones del menú Herramientas de la ventana principal. Una vez abierto
el programa debe verse como la Figura 44.
Figura 44. Ventana de Comparar Sesiones
Una vez abierto el programa, debe colocar en la lista de la derecha todas aquellas
sesiones que desee comparar. Para ello seleccione una sesión en la lista de la
izquierda y haga clic en el botón con el signo “?” para llevarla a la lista deseada. De
igual manera si desea borrar una sesión de la lista de la derecha, haga clic en ella y
170
luego en el botón con el signo “?” para devolverla a la lista original. Si desea
colocar todas las sesiones en la lista de la derecha, puede hacerlo haciendo clic en el
botón con el signo “>>”. Si desea borrar todas las sesiones de la lista de la derecha,
utilice el botón “<<” para regresarlas a la lista original. Luego podrán comparar las
sesiones según el criterio que quiera verificar. Para ello haga clic en alguno de los
botones que aparecen en la parte superior de la pantalla. La Figura 45 muestra todas
las opciones de esta ventana.
Figura 45. Botones de la ventana Comparar Sesiones
COMPARAR PROTOCOLOS
Esta opción permite comparar varias sesiones creadas con algún protocolo de ruteo
particular con otras creadas con otro protocolo. También puede ser utilizada para
comparar simplemente una serie de sesiones con otra serie. Al igual que en
Comparar Sesiones, disponemos de una lista con todas las sesiones creadas en el
sistema anteriormente, ubicada en el centro. Para realizar la comparación, debe
colocar las sesiones en las lista de la izquierda y de la derecha utilizando los botones
con los símbolos “?” y “?”. Es importante destacar que debe introducir igual
cantidad de sesiones en la lista de la izquierda como en la de la derecha. Para
171
comparar utilice una de las opciones de los botones que están en la parte superior de
la ventana. La Figura 46 muestra un ejemplo de una comparación de protocolos.
Figura 46. Comparación de Protocolos.
OPCIONES DEL SISTEMA
El sistema presenta algunas opciones de configuración. Ellas permite establecer el
tamaño del buffer de datos a enviar y el número de repeticiones del ping utilizando
Traffic Agent Generator, y además el tiempo de captura utilizado por Traffic Monitor.
La Figura 47 muestra esta ventana de opciones.
172
Figura 47. Opciones del Sistema.
