Analisis de protocolos tcp ip

3,754 views

Published on

Analisis de protocolos tcp ip

Published in: Technology, Business
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,754
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Analisis de protocolos tcp ip

  1. 1. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL INTERCONECTIVIDAD DE REDES OBJETIVO GENERAL: • Describir los protocolos TCP/IP • Enumerar y explicar los dispositivos de interconexión • Definir el concepto de subneteo y direccionamiento IP • Describir los protocolos de enrutamiento • Describir los principales comandos usados en la configuración de un router SUMARIO 1. Análisis de protocolos TCP/IP 2. Equipos de Interconexión 3. Direccionamiento IP y Subneteo 4. Enrutamiento y Protocolos 5. Configuración de Router 6. Configuración del Enrutamiento y conexión WAN INTRODUCCIÓN: La interconectividad de redes es definida por IBM: “comunicación entre dos o más redes”. La interconectividad de redes es importante para compartir recursos y tener acceso a las base de datos compartidas en forma casi instantánea, además de permitir al administrador de la red una administración de la misma en forma centralizada. Si una empresa trabaja con una red, ésta reducirá sus costos de presupuesto en tiempo y en dinero. Las redes se conectan mediante equipos de telecomunicaciones conocidos como equipos de interconexión. La primera parte se tratarán el conjunto de los protocolos TCP/IP y analiza los detalles de los protocolos individuales. Explica su implementación y se concentra en los aspectos internos del software de protocolos. A continuación se describirán los equipos de interconexión para finalmente centrarnos en el ruteador y las conexiones WAN. DIVISIÓN DE TELEDUCACIÓN 1 INTERCONECTIVIDAD DE REDES
  2. 2. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL MODULO 1 ANÁLISIS DE PROTOCOLOS TCP/IP OBJETIVOS: • Descripción experimental de los protocolos que trabajan con TCP/IP • Desarrollo del algoritmo de suma de comprobación o Checksum • Enumeración de los principales comandos de generación de tráfico y diagnóstico • Descripción básica del software Ethereal SUMARIO: 1.1 Análisis experimental de los protocolos TCP/IP 1.2 Análisis de la Trama Ethernet 1.3 Análisis del protocolo ARP 1.4 Análisis del protocolo IP 1.5 Análisis del protocolo ICMP 1.6 Análisis del protocolo UDP 1.7 Análisis del protocolo TCP 1.8 Algoritmo del checksum 1.9 Comandos de generación de tráfico y diagnóstico 1.10 Analizador de protocolos Ethereal INTRODUCCIÓN: La Internet es una red de redes basadas en tecnologías heterogéneas que se enlazan en la Internet ofreciendo un conjunto homogéneo de servicios. Mas aún en la Internet se encuentran ordenadores muy diversos con sistemas operativos diferentes, desde ordenadores de sobremesa PC o Macintosh hasta grandes sistemas IBM o Digital. Los protocolos de la familia TCP/IP son los que hacen posible que todos estos sistemas compartan información entre sí. Dos o más redes separadas están conectadas para intercambiar datos o recursos forman una interred (internetwork). Enlazar LANs en una red requiere de equipos que realicen ese propósito. Estos dispositivos están diseñados para sobrellevar los obstáculos para la interconexión sin interrumpir el funcionamiento de las redes. A estos dispositivos que realizan esa tarea se les llama equipos de Interconexión. La operación técnica de los protocolos en la que los datos son transmitidos a través de la red se puede dividir en pasos discretos, sistemáticos. A cada paso se realizan ciertas acciones que no se pueden realizar en otro paso. Cada paso incluye sus propias reglas y procedimientos, o protocolo. DIVISIÓN DE TELEDUCACIÓN 2 INTERCONECTIVIDAD DE REDES
  3. 3. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL Los pasos del protocolo se tienen que llevar a cabo en un orden apropiado y que sea el mismo en cada uno de los equipos de la red. En el equipo origen, estos pasos se tienen que llevar a cabo de arriba hacia abajo. En el equipo de destino, estos pasos se tienen que llevar a cabo de abajo hacia arriba. DESARROLLO DEL MODULO 1 – ANÁLISIS DE PROTOCOLOS TCP/IP 1.1 ANALISIS EXPERIMENTAL DE LOS PROTOCOLOS TCP/IP Se hace un análisis en forma experimental de los protocolos del modelo TCP/IP, así como su formato de protocolos utilizando el analizador de protocolos Ethereal. Este programa se caracteriza por tener ventanas en la cual se visualiza con detalle todos los campos de los datagramas capturados de la red. Las experiencias se realizan en una red LAN, como se ilustra en la Fig. 1.1 IP = 10.12.1.40 IP = 10.12.1.34 MAC = 00-02-55-57-cf-88 MAC = 00-09-6b-32-7d-44 A B Red Red Ethernet IP = 10.12.1.1 MAC = 00-d0-bb-cc-87-01 Fig. 1.1 Red LAN experimentada Para generar tráfico mediante el comando ping se usa una consola de comandos de DOS y se captura los siguientes protocolos: Ethernet, ARP, IP, ICMP. El comando ping se ejecuta de la siguiente manera: >ping –n 1 10.12.1.34 Donde la opción n indica la cantidad de paquete de datos de envío al host destino. 1.2 ANÁLISIS DE LA TRAMA ETHERNET: • Del Host origen A hacia los Hosts de la red LAN (Solicitud de comunicación con el Host B): Según los paquetes capturados, la primera trama de envío es de tipo broadcast (Fig. 1.2) o difusión es realizada por un host origen A que quiere enviar información a un host destino B que se encuentra en la red pero no conoce la dirección MAC; por ello coloca el valor de FFFFFFFFFFFF (formato hexadecimal) en el campo de dirección destino con la intención de ser escuchado por todos los hosts de la red y esperar la respuesta del host destino B con el que se quiere comunicar. DIVISIÓN DE TELEDUCACIÓN 3 INTERCONECTIVIDAD DE REDES
  4. 4. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL IP = 10.12.1.40 IP = 10.12.1.34 MAC = 00-02-55-57-cf-88 MAC = 00-09-6b-32-7d-44 A B C broadcast Fig. 1.2 Trama broadcast En la trama Ethernet generada por el host origen (Fig. 1.3) podemos apreciar que el campo dirección origen transporta su propia dirección MAC. El campo tipo de protocolo toma como valor 0806 (formato hexadecimal) el cual indica el protocolo ARP. El campo de datos transporta el formato ARP y bytes de relleno. 60 bytes 6 6 2 28 bytes 18 bytes FFFFFFFFFFFF 00025557cf88 0806 Datos (ARP solicitud) relleno Dirección Dirección Tipo de broadcast MAC origen Protocolo Fig. 1.3 Trama Ethernet enviada por el host origen A • Del Host destino B al Host origen A: La trama Ethernet del Host B hacia el Host A es dirigida punto a punto(Fig. 1.4) conteniendo la dirección MAC. IP = 10.12.1.40 IP = 10.12.1.34 MAC = 00-02-55-57-cf-88 MAC = 00-09-6b-32-7d-44 A B C dirigido Fig. 1.4 Respuesta del Host destino B a la petición del Host origen A El campo dirección MAC destino contiene 00025557cf88 que corresponde a la dirección física del host A. El campo dirección MAC origen contiene 00096b327d44, que corresponde a la dirección física del host B, quien envía la trama. El campo tipo de protocolo presenta un valor de 0806 correspondiente al protocolo ARP. El campo de datos transporta el formato ARP y bytes de relleno (Fig. 1.5) DIVISIÓN DE TELEDUCACIÓN 4 INTERCONECTIVIDAD DE REDES
  5. 5. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL 60 bytes 6 6 2 28 bytes 18 bytes 00025557cf88 00096b327d44 0806 Datos (ARP respuesta) relleno Dirección Dirección Tipo de MAC destino MAC origen Protocolo Fig. 1.5 Trama Ethernet del Host B al Host A 1.3 ANÁLISIS DEL PROTOCOLO ARP: Se analiza el formato de ARP Request o Solicitud y ARP Response o Respuesta transportado sobre la trama Ethernet. 1.3.1 ARP REQUEST O SOLICITUD: La trama Ethernet de tipo broadcast transporta en el campo de datos del protocolo ARP la solicitud de comunicación con la siguiente pregunta: ¿Quién tiene la dirección física (MAC) del Host B?. Esta trama es recibida por todos los Hosts de la red, pero sólo contesta el Host B. Como el protocolo ARP presenta un tamaño de 28 bytes se agrega 18 bytes de relleno en el campo de datos para completar el mínimo de 46 bytes requerido para el transporte de la trama Ethernet (Fig. 1.6) 0 8 15 16 31 HARDWARE TYPE HARDWARE TYPE PROTOCOL TYPE PROTOCOL TYPE 00 00 01 01 08 08 00 00 HLEN (LongHw) PLEN (LongProt) OPERATION 06 04 00 01 SENDER HARDWARE (Direcc. Hw. del transmisor) 00 02 55 57 SENDER IP (Direcc. IP del trans) 28 bytes cf 88 0a 0c SENDER IP (Direcc. IP del trans.) TARGET HARDWARE (Direcc. Hw. del receptor) 01 28 00 00 00 00 00 00 TARGET IP (Direcc. IP del receptor.) 0a 0c 01 22 Fig. 1.6 Formato ARP REQUEST o SOLICITUD Se describen los campos mencionados en la Fig. 1.6: • Hardware Type: Toma el valor de 0001, indica el tipo de hardware es Ethernet. • Protocol Type: Toma el valor 0800, indica que el protocolo es IP. • Hlen: Toma el valor de 06, indica la longitud de la dirección hardware del Host origen. DIVISIÓN DE TELEDUCACIÓN 5 INTERCONECTIVIDAD DE REDES
  6. 6. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL • Plen: Toma el valor de 04, indica la versión de la dirección Internet (IP). • Operation: Con valor de 0001, indica una solicitud ARP. • Sender Hardware: Con valor 00025557cf88 indica la dirección física del origen. • Sender IP: Con valor 0a0c0128 indica la dirección IP del destino. • Target Hardware: Con valor 000000000000. No se conoce la dirección física del Host destino. • Tarjet IP: Con valor 0a0c0122, indica la dirección IP del Host destino. 1.3.2 ARP REPLY O RESPUESTA El protocolo de respuesta ARP es transportado en una trama dirigida Ethernet, como respuesta a una solicitud enviado por el Host origen o transmisor A. El formato del protocolo se ilustra a continuación. (Fig. 1.7) 0 8 15 16 31 HARDWARE TYPE HARDWARE TYPE PROTOCOL TYPE PROTOCOL TYPE 00 00 01 01 08 08 00 00 HLEN (LongHw) PLEN (LongProt) OPERATION 06 04 00 02 SENDER HARDWARE (Direcc. Hw. del transmisor) 00 09 6b 32 SENDER IP (Direcc. IP del trans) 28 bytes 7d 44 0a 0c SENDER IP (Direcc. IP del trans.) TARGET HARDWARE (Direcc. Hw. del receptor) 01 22 00 02 55 57 cf 88 TARGET IP (Direcc. IP del receptor.) 0a 0c 01 28 Fig. 1.7 Formato ARP REPLY o RESPUESTA A continuación la descripción de los campos mostrados en la Fig. 1.7 • Hardware Type: Toma el valor de 0001, que indica el tipo de hardware es Ethernet. • Protocol Type: Toma el valor 0800, indica el tipo de protocolo es IP. • Hlen: Toma el valor de 06, indica la longitud de la dirección hardware del Host transmisor. • Plen: Toma el valor de 04, indica la longitud de la dirección Internet (IP). • Operation: Con valor de 0002, indica una respuesta ARP. • Sender Hardware: Con valor 00096b327d44 indica la dirección física del transmisor. • Sender IP: Con valor 0a0c0122 indica la dirección IP del transmisor. • Target Hardware: Con valor 00025557cf88, indica la dirección física del Host destino. • Tarjet IP: Con valor 0a0c0128, indica la dirección IP del Host destino. DIVISIÓN DE TELEDUCACIÓN 6 INTERCONECTIVIDAD DE REDES
  7. 7. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL Se finaliza la etapa en el instante que el Host B envía la dirección física (MAC) . Una vez que el Host A conoce la dirección física del Host B procederá a enviar los datos que serán analizados mas adelante. Para la consulta de la tabla de direcciones ARP o también llamado caché ARP se procede de la siguiente manera: >arp –a Es oportuno mencionar que los valores almacenados en la tabla son temporales aproximadamente de un minuto. 1.4 ANÁLISIS DEL PROTOCOLO IP: Después de resolver la dirección física o MAC del host B, el host A envía los datos usando el protocolo IP, usando el paquete que se muestra en la Fig. 1.8 0 4 8 16 19 31 Ver HLEN Tipo Serv Longitud total 4 5 00 00 3c Identificador Indic Desplaz de frag. 9e 0f 0 0 00 20 bytes TTL Protocolo Suma de chequeo 20 01 e6 50 Dirección de origen 0a 0c 01 28 Dirección de destino 0a 0c 01 22 6 6 2 60 bytes 00096b327d44 00025557cf88 0800 Datos (cabecera IP+ datos IP) Dirección Dirección Tipo de MAC destino MAC origen Protocolo Fig. 1.8 Datagrama IP encapsulado en la trama Ethernet Los campos de la Fig. 1.8 se describen a continuación: • VER: Toma el valor de 4, indica la versión del protocolo IP. • HLEN: Toma el valor 5, indica la cabecera expresada en múltiplos de 32 bits. • Tipo de servicio: Toma el valor de 00, que indica no existe ninguna prioridad de la datagrama. DIVISIÓN DE TELEDUCACIÓN 7 INTERCONECTIVIDAD DE REDES
  8. 8. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL • Longitud total: Toma el valor 003c, que equivale a 60 bytes de longitud total. • Identificador: Toma el valor de 9e0f, indica el número de secuencia de datagrama. • Banderas: Con valor de 0 indica que no existe fragmentación de datagrama. • Desplazamiento de fragmentación: Con valor de 0000, indica no existe desplazamiento, debido la no-existencia de la fragmentación. • TTL: Toma el valor 20, indica el tiempo de vida de la datagrama. • Protocolo: Con valor 01, indica el protocolo utilizado en el campo de datos IP es ICMP. • Suma de Chequeo: Toma el valor e650, indica la suma de comprobación de errores de la cabecera IP. • Dirección origen: Con valor 0a0c0128, indica la dirección IP origen (host A). • Dirección destino: Con valor 0a0c0122, indica la dirección IP del destino (host B). 1.4.1 FRAGMENTACIÓN DE DATAGRAMAS: La fragmentación es trabajo del Host origen / transmisor o los nodos intermedios y lo hace cuando el datagrama es mayor que el MTU. El MTU de una red Ethernet es 1500 bytes. (Fig. 1.9) Dato 2008 bytes A B C Fragmento 2 Fragmento 1 Ethernet MTU = 1500 bytes Fig. 1.9 Fragmentación en la red Ethernet Para el análisis de fragmentación se genera un tráfico de tamaño de 2000 bytes que se enviará desde el host origen A hacia el host destino B, mediante el comando ping. El resultado del comando ping se muestra en la Fig. 1.10 C:WINDOWS>ping -n 1 -l 2000 10.12.1.34 Haciendo ping a 10.12.1.34 con 2000 bytes de datos: Respuesta desde 10.12.1.34: bytes = 2000 tiempo = 4ms TDV = 128 Estadísticas de ping para 10.12.1.34: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 4ms, máximo = 4ms, promedio = 4ms Fig. 1.10 Envío de datos con el comando ping En la cabecera IP, el campo que se encarga de la fragmentación es el campo indicador o bandera. Siguiendo con el ejemplo (Fig. 1.11), el bit Mas fragmentos toma el valor 1, del campo DIVISIÓN DE TELEDUCACIÓN 8 INTERCONECTIVIDAD DE REDES
  9. 9. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL banderas o indicadores, que indica que no es el último datagrama (en nuestro caso es el fragmento 1) Campo indicadores 3 bits 0 1 No fragmentar Mas fragmentos Fig. 1.11 Campo Indicadores para el fragmento 1 Para el fragmento 2, el bit de Mas fragmento toma el valor 0 indicando que es el último datagrama (Fig. 1.12) Campo indicadores 3 bits 0 0 No fragmentar Mas fragmentos Fig. 1.12 Campo Indicadores para el fragmento 2 El proceso de fragmentación que ejecuta el Host origen A para transmitir la información al Host destino B en el nivel datagrama se puede apreciar en la Fig. 1.13 Datos 2008 Datagrama IP 20 2008 Header Datagrama IP Fragmentada IP 20 1480 20 528 1500 bytes 1500 bytes 14 Dato1500 14 Dato1500 1514 bytes 1514 bytes Trama Ethernet Fig. 1.13 Fragmentación a nivel datagrama 1.4.2 DESPLAZAMIENTO DE DATAGRAMAS: DIVISIÓN DE TELEDUCACIÓN 9 INTERCONECTIVIDAD DE REDES
  10. 10. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL El desplazamiento de paquetes indica la posición de cada fragmento dentro del paquete original para luego ubicar la misma posición en el momento de reensamblar el paquete en el Host destino B. Este desplazamiento también se le denomina offset. En la Fig. 1.14 tenemos un ejemplo de desplazamiento: El primer fragmento tiene el valor 0 de desplazamiento con 1480 bytes de información (el conteo es a partir de 0 y termina en 1479); el segundo segmento tiene el valor de desplazamiento 1480 y la información tiene la cantidad de 528 bytes (el conteo es a partir de 1480 y finaliza en 2007), si se tuviera un fragmento más, este empezaría en 2008 y se sumaria la cantidad de información; la idea es sólo indicar el valor de desplazamiento y en el Host destino se reensamblará y tomará la posición que le corresponde. Header IP Datos 1 Datos 2 20 1 480 bytes 528 bytes Fragmento 1 Fragmento 1 Desplazamiento 0 Desplazamiento 1480 Fig. 1.14 Desplazamiento 1.5 ANALISIS DEL PROTOCOLO ICMP: En esta sección se explicará los mensajes ICMP 1.5.1 DE HOST ORIGEN A HACIA HOST DESTINO B (mensaje ICMP de solicitud de eco): El datagrama IP transporta en el campo de datos el protocolo ICMP de tipo eco. Es oportuno enfatizar que el comando ping genera mensajes ICMP de tipo eco y nos permite verificar la conectividad entre dos Host (en nuestro caso la conectividad entre el Host A y Host B) Si el Host B esta activo responde con otro mensaje con eco reply o respuesta. El mensaje de eco se muestra en la Fig. 1.15 0 8 16 23 31 Tipo Tipo Código Código Suma de verificación Suma de verificación 08 08 00 00 3c 3c 5e 5e Identificador Número de secuencia 02 00 0f 00 Dato ICMP (32 bytes) 4 4 1 40 bytes 0a0c0122 0a0c0128 01 ICMP Dirección IP Dirección IP Protocolo Datos IP destino origen Fig. 1.15 ICMP – Eco encapsulado en Datagrama IP Los campos expuestos en la Fig. 1.15 tienen el significado: DIVISIÓN DE TELEDUCACIÓN 10 INTERCONECTIVIDAD DE REDES
  11. 11. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL • Tipo: Toma el valor 08, identifica el tipo de mensaje de solicitud de eco. • Código: Toma el valor de 00, indica no existe más información sobre el tipo de mensaje. • Suma de chequeo de errores: Toma el valor 3c5e, indica el chequeo de errores sobre todo el mensaje ICMP. • Identificador: Toma el valor 0200, indica la identificación del mensaje ICMP eco. • Numero de secuencia: Toma el valor 0f00, indica el número de secuencia de envió. Junto con el campo anterior (identificador) permite al emisor asociar las respuestas con las peticiones. • Datos: Transporta datos de 32 bytes. Este valor es modificable. En el sistema operativo Windows mediante el comando ping se envía por defecto un tamaño de 32 bytes. 1.5.2 DE HOST B HACIA HOST A (mensaje ICMP de respuesta de eco) En la Fig. 1.16 se ilustra el formato del mensaje ICMP de eco respuesta, el cual es enviado por el Host B. De igual manera se transporta sobre el protocolo IP y este sobre la trama Ethernet. Algunos campos difieren con respecto al formato de mensaje ICMP de solicitud de eco mostrado en la Fig. 1.16 0 8 16 23 31 Tipo Tipo Código Código Suma de verificación Suma de verificación 00 00 00 00 44 44 5c 5c Identificador Número de secuencia 02 00 0f 00 Dato ICMP (32 bytes) 4 4 1 40 bytes 0a0c0128 0a0c0122 01 ICMP Dirección IP Dirección IP Protocolo Datos IP destino origen Fig. 1.16 ICMP – Respuesta de eco encapsulado en Datagrama IP Los campos de la Fig. 1.16 se detallan a continuación: • Tipo: Toma el valor 00, identifica el tipo de mensaje de respuesta de eco. • Código: Toma el valor de 00, indica no existe más información sobre el tipo de mensaje. • Suma de chequeo de errores: Toma el valor 445c, indica el chequeo de errores sobre todo el mensaje ICMP. • Identificador: Toma el valor 0200, indica la identificación del mensaje ICMP de respuesta de eco. Igual al campo anterior (solicitud de eco). DIVISIÓN DE TELEDUCACIÓN 11 INTERCONECTIVIDAD DE REDES
  12. 12. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL • Numero de secuencia: Toma el valor 0f00, indica el número de secuencia de envió. Junto con el campo anterior (identificador) permite al emisor asociar las respuestas con las peticiones. • Datos: Transporta datos de 32 bytes. Este valor es modificable. En el sistema operativo Windows mediante el comando ping se envía por defecto un tamaño de 32 bytes 1.5.3 MENSAJE DE TIEMPO EXCEDIDO: Los mensajes de tiempo excedido pueden ser enviados por los Hosts y los Routers hacia la fuente original. El Router lo envía cuando descarta un datagrama al finalizar su tiempo de vida. Los Hosts lo envía cuando ocurre un timeout mientras se esperan todos los fragmentos del datagrama. En la Fig. 1.17 se muestra un mensaje enviado por un router. A B router Ethernet Red Red ICMP Fig. 1.17 Mensaje de tiempo excedido Para el análisis del mensaje de tiempo excedido se genera un tráfico del Host A hacia el Host de otra red, mediante el comando ping. El resultado del comando ping se ofrece en la Fig. 1.18 C:WINDOWS>ping -n 1 -i 1 10.12.2.30 Haciendo ping a 10.12.2.30 con 32 bytes de datos: Respuesta desde 10.12.1.1: El tiempo de vida caducó en tránsito. Estadísticas de ping para 10.12.2.30: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 0ms, máximo = 0ms, promedio = 0ms Fig. 1.18 Mensaje de tiempo excedido con el comando Ping Los campos del mensaje ICMP con sus respectivos valores se observa en la Fig. 1.19 • Tipo: Toma el valor 11, identifica el tipo de mensaje de tiempo excedido. • Código: Toma el valor de 00, indica no existe más información sobre el tipo de mensaje. • Suma de chequeo de errores: Toma el valor 9f43, indica el chequeo de errores sobre todo el mensaje ICMP. • Identificador: Este campo no existe y toma el valor 0000. • Numero de secuencia: Este campo no existe y toma el valor 0000. DIVISIÓN DE TELEDUCACIÓN 12 INTERCONECTIVIDAD DE REDES
  13. 13. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL • Datos: En el tipo de mensaje ICMP de tiempo excedido, los datos son la cabecera IP y los 8 bytes (64 bits) de la datagrama anterior. En nuestro caso la datagrama que envió el Hosts A hacia el host de otra red. Es por ello se puede saber porque se originó el error durante el envío de datagrama 0 8 16 23 31 Tipo Tipo Código Código Suma de verificación Suma de verificación 11 11 00 00 9f 9f a3 a3 00 00 00 00 Cabecera IP + 8 bytes de la datagrama anterior 4 4 1 36 bytes 0a0c0128 0a0c0101 01 ICMP Dirección IP Dirección IP Protocolo Datos IP destino origen router Fig. 1.19 ICMP-tiempo excedido encapsulado en datagrama IP 1.6 ANALISIS DEL PROTOCOLO UDP Para el análisis del protocolo UDP se genera un tráfico de resolución de nombres (DNS) La Fig. 1.20 muestra este análisis. Emisor Mensaje en Receptor la red IP origen = 10.12.1.40 Puerto origen = 1085 IP destino = 206.138.105.37 Puerto destino = 53 Fig. 1.20 Segmento UDP enviado por el Emisor Los campos del segmento UDP se muestran en la Fig. 1.21: • Puerto UDP de origen: Toma el valor de 043d, indica el número de puerto de la máquina origen (host A), quien hace la petición de resolución de nombres. • Puerto UDP de destino: Toma el valor de 0035, indica el número de puerto de la máquina destino. En decimal equivale al puerto 53 del servicio DNS. • Longitud del mensaje UDP: Toma el valor de 0028, especifica la longitud total del mensaje UDP (cabecera mas datos). DIVISIÓN DE TELEDUCACIÓN 13 INTERCONECTIVIDAD DE REDES
  14. 14. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL • Suma de verificación UDP: Toma el valor de f525, representa la Suma de comprobación de errores del mensaje. Más adelante se calcula este campo. • Datos: Contiene los datos que se envían las aplicaciones. En este caso al protocolo DNS. El tamaño del dato es de 32 bytes 0 8 16 23 31 Puerto UDP de origen Puerto UDP de origen Puerto UDP de destino Puerto UDP de destino 04 04 3d 3d 00 00 35 35 Longitud de mensaje UDP Longitud de mensaje UDP Suma de verificación Suma de verificación 00 00 28 28 f5 f5 25 25 Dato UDP (32 bytes) 4 4 1 40 bytes 200.138.105.37 10.12.1.40 17 UDP Dirección IP Dirección IP Protocolo Datos IP destino origen Fig. 1.21 Mensaje UDP encapsulado en datagrama IP 1.7 ANÁLISIS DEL PROTOCOLO TCP: Para el análisis del protocolo TCP, se genera un trafico http a un servidor Web por medio del navegador web (Fig. 1.22) Fig. 1.22 Navegador Web 1.7.1 ANÁLISIS DEL ESTABLECIMIENTO DE UNA CONEXIÓN TCP: Se generan tres mensajes antes de enviar los datos los cuales se denominan mensajes de establecimiento de conexión TCP o handshake (saludo) y se puede apreciar en la Fig. 1.23 El Host origen inicia el establecimiento de conexión al enviar el mensaje con el bit SYN activado. Este mensaje es recibido por el Host destino, y devuelve la correspondiente confirmación (ACK), si desea abrir la conexión activa el bit SYN del segmento e informa de su primer número de secuencia. Por su parte, el Host origen recibe los mensajes que le ha enviado y envía su confirmación (ACK). Finalmente, el Host destino recibe el segmento ACK y se inicia la comunicación. DIVISIÓN DE TELEDUCACIÓN 14 INTERCONECTIVIDAD DE REDES
  15. 15. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL IP origen = 10.12.1.40 IP destino = 10.12.1.38 Puerto origen = 1081 Puerto origen = 80 Seq = 592319 Envío de SYN Recepción del seg. SYN Seq = 360125634 Envío de SYN y ACK Recepción de SYN + Ack = 592320 segmento ACK Seq = 592320 Envío de ACK Ack = 360125635 Recepción del seg. ACK Fig. 1.23 Establecimiento de conexión TCP El análisis TCP del primer segmento (segmento SYN) en el establecimiento de una conexión TCP en la Fig. 1.24: • Puerto fuente: Toma el valor de 0439. Que pertenece al puerto de la maquina del transmisor. • Puerto destino: Toma el valor de 0050 (80 en decimal). Indica el puerto de la máquina destino (servidor Web) 0 3 9 16 23 31 Puerto fuente Puerto fuente Puerto destino Puerto destino 04 04 39 39 00 00 50 50 Número de secuencia Número de secuencia 00 00 09 09 09 09 bf bf Número de acuse de recibo Número de acuse de recibo 00 00 00 00 00 00 00 00 HLEN HLEN Reservado Reservado CodeBits CodeBits Ventana Ventana 70 70 02 02 20 20 00 00 Suma de verificación Suma de verificación Puntero de urgencia Puntero de urgencia 3e 3e 69 69 00 00 00 00 Opciones (variable) Opciones (variable) 02 02 04 04 05 05 b4 b4 01 01 01 01 04 04 02 02 4 4 1 28 bytes 10.12.1.38 10.12.1.40 06 TCP Dirección IP Dirección IP Protocolo Datos IP destino origen Fig. 1.24 Formato TCP del Segmento SYNC encapsulado en datagrama IP • Número de secuencia: Toma el valor de 000909bf, indica el número de secuencia del segmento. DIVISIÓN DE TELEDUCACIÓN 15 INTERCONECTIVIDAD DE REDES
  16. 16. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL • Número de acuse de recibo: De 32 bits, indica el número de secuencia del siguiente byte que se espera recibir. Con este campo se indica al otro extremo de la conexión que los bytes anteriores se han recibido correctamente. • HLEN, Reservado y código de bits. Se explica en la Fig. 1.25 70 02 0 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0 U A P R S F Código Longitud de Reservado R C S S Y I de Bits cabecera TCP para el futuro G K H T N N Fig. 1.25 HLEN, Reservado y Código de bits o El Campo Longitud de Cabecera toma el 0111 (valor 7 en decimal), que corresponde a un segmento con datos opcionales (28 bytes) o El campo Reservado, toma el valor de 000000 en bits, reservados para un posible uso futuro. o El Bits de código o indicadores, toma el valor de 000010, segun el gráfico anterior tiene activado el bit SYN en 1 y determina el propósito y contenido del segmento. Se utiliza al crear una conexión para indicar al otro extremo cual va a ser el primer número de secuencia con el que va a comenzar a transmitir. • Ventana. Toma el valor 2000, número de bytes que el emisor del segmento está dispuesto a aceptar por parte del destino. • Suma de verificación. Toma el valor 3e69 suma de comprobación de errores del segmento actual. • Puntero de urgencia. Toma el valor de 0000, este valor indica datos de envío no urgentes. • Opciones (variable) si está presente únicamente se define una opción; el tamaño máximo de segmento que será aceptado. • Relleno. No existe • Datos. No existe por ser un segmento de señalización. El segundo segmento (segmento SYN y ACK) en el establecimiento de una conexión TCP se observa en la Fig. 1.26 DIVISIÓN DE TELEDUCACIÓN 16 INTERCONECTIVIDAD DE REDES
  17. 17. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL 0 3 9 16 23 31 Puerto fuente Puerto fuente Puerto destino Puerto destino 00 00 50 50 04 04 39 39 Número de secuencia Número de secuencia 15 15 77 77 14 14 c2 c2 Número de acuse de recibo Número de acuse de recibo 00 00 09 09 09 09 c0 c0 HLEN HLEN Reservado Reservado CodeBits Ventana CodeBits Ventana 70 70 12 12 16 16 d0 d0 Suma de verificación Suma de verificación Puntero de urgencia Puntero de urgencia 1d 1d 4f 4f 00 00 00 00 Opciones (variable) Opciones (variable) 02 02 04 04 05 05 b4 b4 01 01 01 01 04 04 02 02 4 4 1 28 bytes 10.12.1.40 10.12.1.38 06 TCP Dirección IP Dirección IP Protocolo Datos IP destino origen Fig. 1.26 Formato TCP del Segmento SYNC y ACK encapsulado en datagrama IP El tercer segmento (segmento ACK) en el establecimiento de una conexión TCP se aprecia en la Fig. 1.27 0 3 9 16 23 31 Puerto fuente Puerto fuente Puerto destino Puerto destino 04 04 39 39 00 00 50 50 Número de secuencia Número de secuencia 00 00 09 09 09 09 c0 c0 Número de acuse de recibo Número de acuse de recibo 15 15 77 77 14 14 c3 c3 HLEN HLEN Reservado Reservado CodeBits Ventana CodeBits Ventana 50 50 10 10 22 22 38 38 Suma de verificación Suma de verificación Puntero de urgencia Puntero de urgencia 3e 3e ab ab 00 00 00 00 4 4 1 28 bytes 10.12.1.38 10.12.1.40 06 TCP Dirección IP Dirección IP Protocolo Datos IP destino origen Fig. 1.27 Formato TCP del Segmento ACK encapsulado en datagrama IP DIVISIÓN DE TELEDUCACIÓN 17 INTERCONECTIVIDAD DE REDES
  18. 18. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL 1.8 ALGORITMO DE CHECKSUM: 1.8.1 DETECCIÓN DE ERRORES: En ocasiones, los paquetes de datos al moverse de un nodo a otro pueden alterarse generando errores en la información que transportan. Este tipo de errores deben evitarse para que la información que transporte la red sea confiable. Sin esta confiabilidad los usuarios no utilizarían las redes. La idea básica detrás de los esquemas de detección de errores en redes es adicionar información redundante al paquete, de tal forma que permita determinar si un error ha sido introducido mientras se llevaba de un nodo a otro. Un esquema de detección de errores que podemos imaginar es la transmisión completa de dos copias del mismo paquete. Si las dos copias son idénticas cuando lleguen al receptor, es muy probable que la información esté correcta. Si no son iguales, un error fue introducido en una de las copias (o en ambas) y deben ser descartadas. Este esquema de detección de errores es deficiente: se requieren n bits de corrección de errores para un mensaje de n bits y además, si por alguna razón, los errores ocurren en el mismo lugar en los dos paquetes, no serán detectados. Afortunadamente se pueden hacer cosas mejores. En general, se puede proporcionar una capacidad de detección de errores más fuerte enviando sólo k bits redundantes en un mensaje de n- bits, donde k << n (k mucho más pequeño que n). Por ejemplo, el frame de Ethernet puede llevar hasta 12000 bits (1500 bytes) y utiliza sólo 32 bits redundantes para detectar errores (usa un código de redundancia cíclica conocido como CRC-32). Los bits adicionados al mensaje son redundantes pues no adicionan nueva información al mensaje sino que se calculan directamente del mensaje original utilizando un algoritmo bien definido. El nodo que transmite y el que recibe deben conocer exactamente el algoritmo utilizado. El transmisor del mensaje aplica el algoritmo al mensaje que desea enviar para generar los bits redundantes y envía el mensaje y los bits extras. Cuando el receptor aplica el mismo algoritmo al mensaje recibido, el resultado debe ser (en ausencia de errores) el mismo enviado por el transmisor. Al concordar los dos resultados, el receptor sabe, con una alta probabilidad, que no hubo errores durante el movimiento del paquete. En caso de no concordar, el receptor debe tomar la acción apropiada (descartar el paquete y esperar su retransmisión o, si le es posible, corregir los errores). En general, los bits adicionados a un mensaje para detectar errores se llaman error-detecting codes. En ciertos casos específicos, cuando el algoritmo para crear el código se basa en la adición, reciben el nombre de checksums. Infortunadamente, la palabra checksum se usa de manera incorrecta, queriendo nombrar con ella cualquier código de detección de errores, incluyendo aquellos que no son sumas, como los CRCs. El checksum de Internet recibe el nombre correcto, pues es un chequeo de errores que utiliza un algoritmo de suma. DIVISIÓN DE TELEDUCACIÓN 18 INTERCONECTIVIDAD DE REDES
  19. 19. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL 1.8.2 ALGORITMO DE CHECKSUM La idea en la que se basa la suma de chequeo de Internet es muy sencilla: se suman todas las palabras de 16 bits que conforman el mensaje y se transmite, junto con el mensaje, el resultado de dicha suma (este resultado recibe el nombre de checksum). Al llegar el mensaje a su destino, el receptor realiza el mismo cálculo sobre los datos recibidos y compara el resultado con el checksum recibido. Si cualquiera de los datos transmitidos, incluyendo el mismo checksum, esta corrupto, el resultado no concordará y el receptor sabrá que ha ocurrido un error. El checksum se realiza de la siguiente manera: los datos que serán procesados (el mensaje) son acomodados como una secuencia de enteros de 16 bits. Estos enteros se suman utilizando aritmética complemento a uno para 16 bits y, para generar el checksum, se toma el complemento a uno para 16 bits del resultado. (Fig. 1.28) En aritmética complemento a uno, un entero negativo -x se representa como el complemento de x; es decir, cada bit de x es invertido. Cuando los números se adicionan, si se obtiene un acarreo (carry) en el bit más significativo, se debe incrementar el resultado. Por ejemplo, sumemos -5 y -3 en aritmética complemento a uno con enteros de 4 bits. En este caso +5 se representaría con 0101 y -5 con 1010; +3 se representaría con 0011 y -3 con 1100. Al sumar 1010 y 1100, ignorando el acarreo (carry) que queda en el bit más significativo, tendremos como resultado 0110. En la aritmética complemento a uno, cuando una operación genera un acarreo (carry) en el bit más significativo, se debe incrementar el resultado; es decir que 0110 se convierte en 0111, que es la representación complemento a uno de -8 (obtenido de invertir los bits 1000). Fig. 1.28 Algoritmo del Checksum El uso del algoritmo de checksum de Internet en los headers de los protocolos se puede resumir en tres pasos simples. 1. Los octetos adyacentes que se deben verificar con al suma de chequeo deben ser acomodados para formar enteros de 16 bits, luego se calcula la suma complemento a uno de estos enteros (de 16 bits) 2. Para generar el checksum, el campo de checksum del header del PDU que será transmitido es puesto en cero, luego la suma complemento a uno es calculada sobre los octetos correspondientes y el complemento a uno de esta suma se coloca en el campo de checksum. 3. Para revisar el checksum, la suma es calculada sobre los mismo octetos, incluyendo el campo de checksum. Si el resultado es 16 bits con valor 1 (-0 en aritmética complemento a uno), el chequeo es correcto. Como un ejemplo sencillo del cálculo del checksum supongamos que tenemos tres "palabras" de 16 bits 0110011001100110 0101010101010101 0000111100001111 DIVISIÓN DE TELEDUCACIÓN 19 INTERCONECTIVIDAD DE REDES
  20. 20. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL La suma de las dos primeras palabras sería: 0110011001100110 0101010101010101 1011101110111011 Adicionando ahora la tercera "palabra" al resultado anterior tenemos 1011101110111011 0000111100001111 1100101011001010 La suma complemento a uno se obtiene convirtiendo todos los ceros en unos y todos los unos en ceros. De esta forma la suma complemento a uno de 1100101011001010 sería 0011010100110101. Que vendría a ser el checksum. Al llegar al receptor las cuatro palabras de 16 bits, incluyendo el checksum son sumados y el resultado debe ser 1111111111111111. Si uno de los bits es cero, un error ha sido detectado. Dependiendo del protocolo, se deben seleccionar ciertos campos de los headers para realizar los cálculos del checksum. En IP el checksum se calcula sólo sobre los octetos que componen el header del datagrama (RFC791), en UDP (RFC768) se calcula sobre un seudo-header , el header UDP y los datos que transporta UDP y en TCP (RFC793) se hace un cálculo similar que en UDP. El RFC1071, Computing the Internet Checksum, discute métodos para calcular de manera eficiente el checksum de Internet que se utiliza en los protocolos IP, UDP y TCP. Al utilizar este checksum, se agregan 16 bits al mensaje original como código de detección de errores, pero esta no es una técnica fuerte de detección de errores. ¿por qué? Por ejemplo, si una pareja de bits individuales, uno de los cuales incrementa una palabra de 16 bits, de las que conforman el mensaje, en cierta cantidad y el otro bit decrementa otra palabra de 16 bits en la misma cantidad, al realizar la suma de chequeo no será detectado el error. La razón por la cual un algoritmo como éste es utilizado, aunque tenga una protección débil contra errores, es simple: este algoritmo es fácil de implementar en software (el algoritmo de CRC utilizado en los protocolos de la capa de enlace, como Ethernet y Token Ring se implementan en el hardware de las tarjetas de red). Además la experiencia observada en ARPANET sugirió que un checksum era adecuado: este checksum es la última línea de defensa en los protocolos de TCP/IP pues la gran mayoría de errores son descubiertos por algoritmos de detección de errores más fuertes, tales como los CRCs utilizados en la capa de enlace (capa 2 del modelo OSI). 1.8.3 DETECCIÓN DE ERRORES VS CORRECCIÓN DE ERRORES: A primera vista uno puede suponer que corregir errores es mucho mejor que sólo detectarlos, ya que evitaría tener que reenviar el paquete completo que, entre otras cosas, aumenta el uso de DIVISIÓN DE TELEDUCACIÓN 20 INTERCONECTIVIDAD DE REDES
  21. 21. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL ancho de banda y produce un tiempo de latencia mientras se retransmite el mensaje. Sin embargo, la corrección de errores tiene su lado malo: requiere un mayor número de bits redundantes para que sea tan fuerte (es decir capaz de corregir el mismo rango de errores) como un código que sólo detecta errores. De esta forma, mientras la detección de errores requiere que más bits sean enviados cuando algún error ocurre, la corrección de errores requiere enviar más bits todas las veces. Como resultado, la corrección de errores es útil en dos condiciones: 1. Cuando los errores son demasiado probables. Por ejemplo, en ambientes inalámbricos. 2. Cuando el costo de retransmisión es demasiado alto. Por ejemplo, el tiempo de latencia involucrado en la retransmisión de un paquete sobre un enlace de satélite. El uso de códigos de corrección de errores es llamado, en redes, FEC (forward error correction) porque la corrección de errores es manejada de antemano, con información extra, en lugar de esperar a que los errores sucedan y manejarlos con retransmisión. 1.8.4 CALCULO DEL CAMPO CHECKSUM EN EL HEADER DEL DATAGRAMA IP La información mostrada en la Fig. 1.29 es la captura de paquetes de la cabecera IP de un analizador de protocolos. Fig. 1.29 Captura de paquetes IP con el analizador de Protocolos Antes de realizar el cálculo del CheckSum, se rellena el campo CheckSum de la cabecera del protocolo IP capturado con el analizador de protocolo con el valor cero. Los octetos o los bytes de los campos adyacentes (solo los campos de la cabecera IP, mas no los datos) deben ser DIVISIÓN DE TELEDUCACIÓN 21 INTERCONECTIVIDAD DE REDES
  22. 22. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL acomodados para formar enteros de 16 bits, luego se calcula la suma complemento a uno de estos enteros (de 16 bits). El formato del protocolo IP se ilustra en la Fig. 1.30 0 4 8 16 19 31 Ver HLEN Tipo Serv. Longitud total Identificador Indic Desplaz de frag. 20 bytes TTL Protocolo Suma de chequeo Cabecera Dirección de origen Dirección de destino 40 bytes max Opciones-relleno Carga útil Fig. 1.30 Protocolo IP Los datos marcados con negro (solo corresponde a la cabecera IP) en la Fig. 1.29 son reemplazados en la Fig. 1.30 cada dato en su campo correspondiente ( Fig. 1.31) 0 4 8 16 19 31 Ver HLEN Tipo Serv Longitud total 4 5 00 00 3c Identificador Indic Desplaz de frag. 9e 0f 0 0 00 20 bytes TTL Protocolo Suma de chequeo Cabecera IP 20 01 e6 50 Dirección de origen 0a 0c 01 28 Dirección de destino 0a 0c 01 22 Datos IP 08 00 40 50 02 00 0B 00 61 62 63 64 40 bytes 65 66 67 68 69 6A 6B 6C Datos IP 6D 6E 6F 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 Fig. 1.31 Datagrama IP (Cabecera + Datos) Realizando el cálculo con los bytes u octetos de los campos adyacentes de la datagrama acomodados en palabras de 16 bits (estos valores son obtenidos del analizador de protocolos mostrados anteriormente). DIVISIÓN DE TELEDUCACIÓN 22 INTERCONECTIVIDAD DE REDES
  23. 23. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL Hexadecimal Binario 4500 0100010100000000 003c 0000000000111100 9509 1001010100001001 0000 0000000000000000 2001 0010000000000001 0000 0000000000000000 0a0c 0000101000001100 0128 0000000100101000 0a0c 0000101000001100 0122 0000000100100010 110A8 10001000010101000 El “1” subrayado indica el carry de la operación. El resultado de la suma se realiza la siguiente operación: 10A8 1000010101000 1 1 10A9 0001000010101001 Para cálculo final del checksum debemos calcular el complemento a uno del resultado obtenido. 10A9 1110111101010110 EF56 1110111101010110 El resultado mostrado en amarillo es el valor del checksum que se comprueba en la Fig. 1.30 y ahí termina la verificación. 1.8.5 CALCULO DEL CAMPO CHECKSUM EN LA CABECERA UDP: El checksum para UDP se calcula con los bytes que componen una seudo-cabecera, la cabecera UDP y los datos (completando con ceros al final si es necesario). La información mostrada en la Fig. 1.32 es la captura de paquetes de la cabecera UDP utilizando un analizador de protocolos. Fig. 1.32 Cabecera UDP DIVISIÓN DE TELEDUCACIÓN 23 INTERCONECTIVIDAD DE REDES
  24. 24. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL La seudo-cabecera UDP de 12 bytes con los datos de la Fig. 1.33 se muestran en la Fig. 1.32 0 8 16 31 Dirección de origen 0a 0c 01 28 Dirección de destino ce 8a 69 25 Cero Protocolo Longitud del mensaje UDP 00 11 00 28 Fig. 1.33 seudo-cabecera UDP La información de la seudo cabecera (Fig. 1.33) se reacomoda para el cálculo de checksum de la siguiente forma: Hexadecimal Binario 0a0c 0000101000001100 0128 0000000100101000 ce8a 1100111010001010 6925 0110100100100101 0011 0000000000010001 0028 0000000000101000 1431C 10100001100011100 Se suma el “carry” 431C 0100001100011100 1 1 431D 0100001100011101 Los datos marcados con negro en la Fig. 1.32 (corresponde solo a la cabecera UDP) son reemplazados en su formato del segmento UDP (cabecera UDP + Datos UDP), cada dato en su campo correspondiente (Fig. 1.34) 0 8 16 23 31 Puerto UDP de origen Puerto UDP de origen Puerto UDP de destino Puerto UDP de destino 08 bytes 04 04 3d 3d 00 00 35 35 Longitud de mensaje UDP Suma de verificación Cabecera UDP Longitud de mensaje UDP Suma de verificación 00 00 28 28 f5 f5 25 25 Datos UDP 00 01 01 00 00 01 00 00 32 bytes 00 00 00 00 03 77 77 77 Datos UDP 03 75 74 70 03 65 64 75 02 70 65 00 00 01 00 01 Fig. 1.34 Segmento UDP (Cabecera + Datos) DIVISIÓN DE TELEDUCACIÓN 24 INTERCONECTIVIDAD DE REDES
  25. 25. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL Suma con aritmética complemento a uno de la cabecera UDP y colocando a cero el campo checksum (F525H al valor 0000): Hexadecimal Binario 043d 0000010000111101 0035 0000000000110101 0028 0000000000101000 0000 0000000000000000 049a 0000010010011010 Suma con aritmética complemento a uno de los datos transportados por UDP mostrados en la Fig. 1.34 Hexadecimal Binario 0001 0000000000000001 0100 0000000100000000 0001 0000000000000001 0000 0000000000000000 0000 0000000000000000 0000 0000000000000000 0377 0000001101110111 7777 0111011101110111 0375 0000001101110101 7470 0111010001110000 0365 0000001101100101 6475 0110010001110101 0270 0000001001110000 6500 0110010100000000 0001 0000000000000001 0001 0000000000000001 1C321 11100001100100001 Se suma el “carry”: C321 1100001100100001 1 1 C322 1100001100100010 Luego, se genera una suma de los resultados obtenidos con la seudo-cabecera, la cabecera UDP y los datos. Hexadecimal Binario 431D 0100001100011101 049a 0000010010011010 C322 1100001100100010 10AD9 10000101011011001 Se suma el “carry” DIVISIÓN DE TELEDUCACIÓN 25 INTERCONECTIVIDAD DE REDES
  26. 26. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL 0AD9 1100001100100001 1 1 ADA 0000101011011010 Finalmente, se genera un complemento a 1 del valor obtenido (0000101011011010) el cual es 1111010100100101. Este resultado en valor hexadecimal es F525, el valor del checksum (verificar en la Fig. 1.32) 1.9 COMANDOS DE GENERACIÓN DE TRÁFICO Y DIAGNÓSTICO: Se estudiará el comando ping, el comando tracert y el comando ARP 1.9.1 COMANDO PING: Comprueba el estado de las conexiones establecidas con uno o varios hosts remotos. Este comando está disponible sólo si se ha instalado el protocolo TCP/IP. ping [-t] [-a] [-n cantidad] [-l tamaño] [-f] [-i TTL] [-v TOS] [-r cantidad] [-s cantidad] [[-j lista de host] | [-k lista de host]][-w Tiempo de espera agotado] lista de destino Opciones: • -t : Solicita eco al host hasta ser interrumpido. Para ver estadísticas y continuar: presione Ctrl-Inter. Para interrumpir: presione Ctrl-C. • -a: Resuelve direcciones a nombres de host. • -n cantidad: Cantidad de solicitudes de eco a enviar. • -l tamaño: Tamaño del búfer de envíos. • -f: No fragmentar el paquete. • -i TTL: Tiempo de vida. • -v TOS: Tipo de servicio. • -r Cantidad: Registrar la ruta para esta cantidad de saltos. • -s Cantidad: Registrar horarios para esta cantidad de saltos. • -j lista de Hosts: Ruta origen variable en la lista de host. • -k lista de Hosts: Ruta origen estricta en la lista de host. • -w tiempo: Tiempo de espera agotado de respuesta en milisegundos. 1.9.2 COMANDO TRACERT: Esta herramienta de diagnóstico determina el camino tomado hacia un destino enviando paquetes de eco del Protocolo de mensajes de control de Internet (ICMP)con valores variables de DIVISIÓN DE TELEDUCACIÓN 26 INTERCONECTIVIDAD DE REDES
  27. 27. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL Período de vida (TTL) para el destino. Cada enrutador de la ruta de acceso debe decrementar el Período de vida de un paquete al menos en 1 para reenviarlo, de forma que el Período de vida sea un número de "hops". Cuando el Período de vida de un paquete llegue a 0, se supondrá que el enrutador debe devolver al sistema de origen un mensaje de tiempo excedido de ICMP. Para determinar la ruta, tracert envía el primer paquete de eco con un período de vida de 1 y lo incrementa en una unidad en cada transmisión posterior hasta que el destino responda o se alcance el período de vida máximo. La ruta se determina examinando los mensajes de tiempo excedido de ICMP enviados de vuelta por los enrutadores intermedios. Sin embargo, algunos enrutadores omiten sin notificación los paquetes con valores de período de vida caducados, por lo que son invisibles para tracert. tracert [-d] [-h saltosMáximos] [-j listaDeEquipos] [-w tiempoDeEspera] nombreDeDestino Opciones: • -d: Especifica que las direcciones no se deben resolver hacia nombres de hosts. • -h saltos Máximos: Especifica el número máximo de hops que se deben buscar para el destino. • -j lista De Equipos: Especifica la ruta de origen no estricta a lo largo de la listaDeEquipos. • -w tiempo De Espera: Espera el número de milisegundos especificado por tiempoDeEspera en cada respuesta . • Nombre De Destino: Nombre del host de destino. 1.9.3 COMANDO ARP: Muestra y modifica las tablas de traducción de direcciones físicas de IP a Ethernet o a Token Ring que utiliza el protocolo de resolución de direcciones (ARP, Ardes Resolution Protocol). Este comando sólo está disponible si se ha instalado el protocolo TCP/IP arp -a [dir_inet] [-N [dir_if]] arp -d dir_inet [dir_if] arp -s dir_inet dir_eth [dir_if] Opciones: • -a: Muestra las entradas actuales de ARP mediante una consulta de TCP/IP. Si se especifica dir_inet, sólo se mostrarán las direcciones IP y físicas del equipo especificado. Cuando ARP se utiliza en más de una interfaz de red, entonces se muestran entradas para cada tabla ARP. • -g: Igual que -a. • dir_inet: Especifica una dirección IP en notación decimal con puntos. • -N dir_if: Muestra las entradas de ARP para la interfaz de red especificada mediante dir_if. DIVISIÓN DE TELEDUCACIÓN 27 INTERCONECTIVIDAD DE REDES
  28. 28. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL • dir_if: Especifica, si está presente, la dirección IP de la interfaz cuya tabla de traducción de direcciones debe modificarse. Si no está presente, se usará la primera interfaz aplicable. • -d: Elimina la entrada especificada mediante dir_inet. • -s: Agrega una entrada a la caché de ARP para asociar la dirección IP dir_ineta la dirección física dir_eth. La dirección física se especifica como 6 bytes hexadecimales separados por guiones. La dirección IP se especifica mediante la notación decimal con puntos. Esta entrada es permanente, es decir, no se quitará automáticamente de la caché cuando termine el tiempo de espera. • dir_eth: Especifica una dirección física. 1.10 ANALIZADOR DE PROTOCOLOS ETHEREAL: Ethereal es una aplicación que ofrece una interfaz sencilla de utilizar y permite visualizar los contenidos de las cabeceras de los protocolos involucrados en una comunicación en una forma muy cómoda. 1.10.1 INTERFAZ Y MENÚS: Ethereal funciona en modo gráfico y está programado con la librería de controles GTK. La ventana principal de la aplicación se divide en tres partes de visualización y una zona inferior de trabajo con filtros. (Fig. 1.35) 1 2 3 A B C D Fig. 1.35 Interfaz Ethereal En la primera parte (Fig. 1.35 sección 1) se muestra la información más relevante de los paquetes capturados, como, por ejemplo, las direcciones IP y puertos involucrados en la comunicación. Seleccionando un paquete en esta sección podemos obtener información detallada sobre él en las otras dos secciones de la pantalla que comentaremos a continuación. DIVISIÓN DE TELEDUCACIÓN 28 INTERCONECTIVIDAD DE REDES
  29. 29. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL En la parte central de la ventana (Fig. 1.35 sección 2) se muestra, utilizando controles tree- view, cada uno de los campos de cada una de las cabeceras de los protocolos que ha utilizado el paquete para moverse de una máquina a la otra. Así, si hemos capturado una serie de paquetes de, por ejemplo, una conexión telnet, podremos ver las cabeceras del protocolo TCP, del IP y de los que tengamos debajo de ellos (trama Ethernet, por ejemplo, en una red Ethernet). La tercera parte de la ventana (Fig. 1.35 sección 3) muestra un volcado hexadecimal del contenido del paquete. Seleccionando cualquier campo en la parte central de la ventana se mostrarán en negrita los datos correspondientes del volcado hexadecimal, los datos reales que están viajando por la red. En la barra inferior (siempre en la Fig. 1.35), aparecen cuatro componentes muy interesantes a la hora de hacer análisis de capturas: Creación de filtros (A), filtro actual (B), borrar filtro (C) y mensajes adicionales (D) Todas las opciones que pueden ser empleadas, son accesibles por medio de la barra de menú. (Fig. 1.36) Fig. 1.36 Menú Ethereal La aplicación contiene lo siguiente: • File: Menú con los ítems para abrir, guardar ficheros de captura. Permite imprimir y salir de la aplicación. • Edit: Menú para encontrar tramas concretas, ir a una trama y marcar tramas. También tiene las opciones de preferencias, de captura y visualización de filtros y protocolos. • Capture: Inicia o detiene la captura de paquetes. • Display: Permite cambiar las opciones de visualización, correspondencia y coloreado de marcos. • Tools: Este menú contiene los pluggins instalados, seguimiento de un paquete TCP (interesante función), sumario de los paquetes capturados y la visualización de las estadísticas de protocolos empelados. • Help: Ayuda de la aplicación y “acerca de”. 1.10.2 CAPTURA DE PAQUETES: La captura de paquetes se realiza por medio de la opción de menú capture -> start. Al seleccionar la opción aparecerá la caja de diálogo con las preferencias para la captura de los paquetes como se observa en la Fig. 1.37 DIVISIÓN DE TELEDUCACIÓN 29 INTERCONECTIVIDAD DE REDES
  30. 30. POSTGRADO A DISTANCIA: REDES DE COMUNICACIÓN DE DATOS INICTEL 1 2 3 6 4 7 5 8 9 10 11 Fig. 1.37 Ventana de preferencias de la captura Las opciones que permite esta ventana son las siguientes: 1. Interface: Es el interface de captura que se va a emplear para la sesión, en algunos sistemas es equivalente a las conexiones de red de las que se dispone (PPP, Red, etc…) si al seleccionar una opción no se capturan datos, se debe a que no se ha seleccionado el interfaz correcto. 2. Cuenta (count): Es el número de paquetes que deseamos que se capturen. En el caso de dejarse a 0, se capturarán todos los paquetes hasta que se detenga manualmente la sesión (o se sature el sistema). 3. Filtro (Filter): Determina el filtro que deseamos que se aplique a la captura. La sintaxis de los filtros se verá más adelante. 4. Archivo (File): En caso de que se desee que la captura sea volcada hacia un archivo, se puede seleccionar por medio de este cuadro de texto. 5. Longitud: Marca la cantidad máxima de bytes de cada trama que deseamos sean capturados. 6. Captura de datos: En caso de seleccionarse esta opción, se capturarán todos los datos posibles que sean alcanzables por el host monitor. Si no se selecciona1, sólo se capturarán los paquetes que entren o salgan al host monitor. 7. Actualización de la lista en tiempo real: Actualiza la ventana de paquetes capturados a la vez que éstos son capturados. Esta opción tiene el problema de cargar en exceso el sistema. 8. Desplazamiento de la lista de paquetes capturados: Permite que la ventana con el contenido de los paquetes capturados, se actualice en tiempo real. 9. Permitir resolución de nombres MAC: Este botón permite controlar si Ethereal traduce o no los primeros tres octetos de las direcciones MAC al nombre del fabricante a quien ese prefijo ha sido asignado por el IETF. 10. Permite resolución del nombre de la red: Este botón permite que controlar si Ethereal traduce o la direcciones IP a nombres del dominio del DNS. Haciendo clic en este botón, la lista de DIVISIÓN DE TELEDUCACIÓN 30 INTERCONECTIVIDAD DE REDES

×