Mdulo1 Analisisdeprotocolostcp Ip 100519163553 Phpapp02

INICTEL
POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS
INTERCONECTIVIDAD DE REDES
OBJETIVO GENERAL: Describir los protocolos TCP/IP Enumerar y explicar los dispositivos de interconexin Definir el concepto de subneteo y direccionamiento IP Describir los protocolos de enrutamiento Describir los principales comandos usados en la configuracin de un router
SUMARIO 1. 2. 3. 4. 5. 6. Anlisis de protocolos TCP/IP Equipos de Interconexin Direccionamiento IP y Subneteo Enrutamiento y Protocolos Configuracin de Router Configuracin del Enrutamiento y conexin WAN
INTRODUCCIN: La interconectividad de redes es definida por IBM: comunicacin entre dos o ms redes. La interconectividad de redes es importante para compartir recursos y tener acceso a las base de datos compartidas en forma casi instantnea, adems de permitir al administrador de la red una administracin 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 interconexin. La primera parte se tratarn el conjunto de los protocolos TCP/IP y analiza los detalles de los protocolos individuales. Explica su implementacin y se concentra en los aspectos internos del software de protocolos. A continuacin se describirn los equipos de interconexin para finalmente centrarnos en el ruteador y las conexiones WAN.
DIVISIN DE TELEDUCACIN
INICTEL
MODULO 1 ANLISIS DE PROTOCOLOS TCP/IP

OBJETIVOS: Descripcin experimental de los protocolos que trabajan con TCP/IP Desarrollo del algoritmo de suma de comprobacin o Checksum Enumeracin de los principales comandos de generacin de trfico y diagnstico Descripcin bsica del software Ethereal
SUMARIO: 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 Anlisis experimental de los protocolos TCP/IP Anlisis de la Trama Ethernet Anlisis del protocolo ARP Anlisis del protocolo IP Anlisis del protocolo ICMP Anlisis del protocolo UDP Anlisis del protocolo TCP Algoritmo del checksum Comandos de generacin de trfico y diagnstico Analizador de protocolos Ethereal
INTRODUCCIN: La Internet es una red de redes basadas en tecnologas heterogneas que se enlazan en la Internet ofreciendo un conjunto homogneo de servicios. Mas an 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 informacin entre s. Dos o ms redes separadas estn conectadas para intercambiar datos o recursos forman una interred (internetwork). Enlazar LANs en una red requiere de equipos que realicen ese propsito. Estos dispositivos estn diseados para sobrellevar los obstculos para la interconexin sin interrumpir el funcionamiento de las redes. A estos dispositivos que realizan esa tarea se les llama equipos de Interconexin. La operacin tcnica de los protocolos en la que los datos son transmitidos a travs de la red se puede dividir en pasos discretos, sistemticos. 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.
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 ANLISIS DE PROTOCOLOS TCP/IP

1.1 ANALISIS EXPERIMENTAL DE LOS PROTOCOLOS TCP/IP Se hace un anlisis 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 MAC = 00-02-55-57-cf-88 A IP = 10.12.1.34 MAC = 00-09-6b-32-7d-44 B
Ethernet IP = 10.12.1.1 MAC = 00-d0-bb-cc-87-01
Red Red
Fig. 1.1 Red LAN experimentada Para generar trfico 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 opcin n indica la cantidad de paquete de datos de envo al host destino. 1.2 ANLISIS DE LA TRAMA ETHERNET: Del Host origen A hacia los Hosts de la red LAN (Solicitud de comunicacin con el Host B): Segn los paquetes capturados, la primera trama de envo es de tipo broadcast (Fig. 1.2) o difusin es realizada por un host origen A que quiere enviar informacin a un host destino B que se encuentra en la red pero no conoce la direccin MAC; por ello coloca el valor de FFFFFFFFFFFF (formato hexadecimal) en el campo de direccin destino con la intencin de ser escuchado por todos los hosts de la red y esperar la respuesta del host destino B con el que se quiere comunicar.
INICTEL
IP = 10.12.1.40 MAC = 00-02-55-57-cf-88 A

IP = 10.12.1.34 MAC = 00-09-6b-32-7d-44 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 direccin origen transporta su propia direccin 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
Direccin broadcast
00025557cf88
Direccin MAC origen
0806
Tipo de Protocolo
Datos (ARP solicitud)
relleno
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 direccin MAC.
IP = 10.12.1.40 MAC = 00-02-55-57-cf-88 A IP = 10.12.1.34 MAC = 00-09-6b-32-7d-44 B C
dirigido
Fig. 1.4 Respuesta del Host destino B a la peticin del Host origen A El campo direccin MAC destino contiene 00025557cf88 que corresponde a la direccin fsica del host A. El campo direccin MAC origen contiene 00096b327d44, que corresponde a la direccin fsica del host B, quien enva 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)
INICTEL
60 bytes 6 6 2 0806
Tipo de Protocolo 28 bytes 18 bytes
00025557cf88 00096b327d44
Direccin MAC destino Direccin MAC origen
Datos (ARP respuesta)
relleno
Fig. 1.5 Trama Ethernet del Host B al Host A 1.3 ANLISIS 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 comunicacin con la siguiente pregunta: Quin tiene la direccin fsica (MAC) del Host B?. Esta trama es recibida por todos los Hosts de la red, pero slo contesta el Host B. Como el protocolo ARP presenta un tamao de 28 bytes se agrega 18 bytes de relleno en el campo de datos para completar el mnimo de 46 bytes requerido para el transporte de la trama Ethernet (Fig. 1.6)
0
HARDWARETYPE TYPE HARDWARE
15 16
PROTOCOLTYPE TYPE PROTOCOL
31
00 00
01 01
PLEN (LongProt)
08 08 00 55
00 00 01 57 0c 00 00 22
HLEN (LongHw)
OPERATION
06 00
04 02 88 28 00 0c
SENDER HARDWARE (Direcc. Hw. del transmisor)
28 bytes
cf
SENDER IP (Direcc. IP del trans.)
SENDER IP (Direcc. IP del trans)
0a 00 00 01
TARGET HARDWARE (Direcc. Hw. del receptor)
01 00
TARGET IP (Direcc. IP del receptor.)
0a
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 direccin hardware del Host origen. 5
INICTEL
1.3.2
Plen: Toma el valor de 04, indica la versin de la direccin Internet (IP). Operation: Con valor de 0001, indica una solicitud ARP. Sender Hardware: Con valor 00025557cf88 indica la direccin fsica del origen. Sender IP: Con valor 0a0c0128 indica la direccin IP del destino. Target Hardware: Con valor 000000000000. No se conoce la direccin fsica del Host destino. Tarjet IP: Con valor 0a0c0122, indica la direccin IP del Host destino. 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 continuacin. (Fig. 1.7)
0
HARDWARETYPE TYPE HARDWARE
15 16
PROTOCOLTYPE TYPE PROTOCOL
31
00 00
01 01
PLEN (LongProt)
08 08 00
00 00 02 32 0c 02 88 28
HLEN (LongHw)
OPERATION
06 00
04 09 44 22 57 0c
SENDER HARDWARE (Direcc. Hw. del transmisor)
6b
SENDER IP (Direcc. IP del trans)
28 bytes
7d
SENDER IP (Direcc. IP del trans.)
0a 00 cf 01
TARGET HARDWARE (Direcc. Hw. del receptor)
01 55
TARGET IP (Direcc. IP del receptor.)
0a
Fig. 1.7 Formato ARP REPLY o RESPUESTA A continuacin la descripcin 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 direccin hardware del Host transmisor. Plen: Toma el valor de 04, indica la longitud de la direccin Internet (IP). Operation: Con valor de 0002, indica una respuesta ARP. Sender Hardware: Con valor 00096b327d44 indica la direccin fsica del transmisor. Sender IP: Con valor 0a0c0122 indica la direccin IP del transmisor. Target Hardware: Con valor 00025557cf88, indica la direccin fsica del Host destino. Tarjet IP: Con valor 0a0c0128, indica la direccin IP del Host destino. 6
INICTEL
Se finaliza la etapa en el instante que el Host B enva la direccin fsica (MAC) . Una vez que el Host A conoce la direccin fsica del Host B proceder a enviar los datos que sern analizados mas adelante. Para la consulta de la tabla de direcciones ARP o tambin 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 ANLISIS DEL PROTOCOLO IP: Despus de resolver la direccin fsica o MAC del host B, el host A enva los datos usando el protocolo IP, usando el paquete que se muestra en la Fig. 1.8
0
Ver
4
HLEN
8
Tipo Serv
16 19
Longitud total
31
4
Identificador
5 9e
00 0f
Protocolo
00
Indic Desplaz de frag.
3c 0 00 50 28 22
60 bytes
20 bytes
0 e6 01 01
TTL
Suma de chequeo
20
Direccin de origen
01 0c 0c 2 0800
Tipo de Protocolo
0a
Direccin de destino
0a 6 6
00096b327d44 00025557cf88
Direccin MAC destino Direccin MAC origen
Datos (cabecera IP+ datos IP)
Fig. 1.8 Datagrama IP encapsulado en la trama Ethernet Los campos de la Fig. 1.8 se describen a continuacin: VER: Toma el valor de 4, indica la versin del protocolo IP. HLEN: Toma el valor 5, indica la cabecera expresada en mltiplos de 32 bits. Tipo de servicio: Toma el valor de 00, que indica no existe ninguna prioridad de la datagrama.
INICTEL
1.4.1
Longitud total: Toma el valor 003c, que equivale a 60 bytes de longitud total. Identificador: Toma el valor de 9e0f, indica el nmero de secuencia de datagrama. Banderas: Con valor de 0 indica que no existe fragmentacin de datagrama. Desplazamiento de fragmentacin: Con valor de 0000, indica no existe desplazamiento, debido la no-existencia de la fragmentacin. 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 comprobacin de errores de la cabecera IP. Direccin origen: Con valor 0a0c0128, indica la direccin IP origen (host A). Direccin destino: Con valor 0a0c0122, indica la direccin IP del destino (host B). FRAGMENTACIN DE DATAGRAMAS: La fragmentacin 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
Fragmento 2 Fragmento 1 Ethernet MTU = 1500 bytes

Fig. 1.9 Fragmentacin en la red Ethernet Para el anlisis de fragmentacin se genera un trfico de tamao 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 Estadsticas de ping para 10.12.1.34: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mnimo = 4ms, mximo = 4ms, promedio = 4ms
Fig. 1.10 Envo de datos con el comando ping En la cabecera IP, el campo que se encarga de la fragmentacin es el campo indicador o bandera. Siguiendo con el ejemplo (Fig. 1.11), el bit Mas fragmentos toma el valor 1, del campo
INICTEL
banderas o indicadores, que indica que no es el ltimo datagrama (en nuestro caso es el fragmento 1)
Campo indicadores 3 bits 0 No fragmentar 1 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 No fragmentar 0 Mas fragmentos
Fig. 1.12 Campo Indicadores para el fragmento 2 El proceso de fragmentacin que ejecuta el Host origen A para transmitir la informacin al Host destino B en el nivel datagrama se puede apreciar en la Fig. 1.13
Datos Datagrama IP Header IP

20 1480 1500 bytes 14 Dato1500 1514 bytes 20
2008 2008
Datagrama IP Fragmentada 20 528 1500 bytes 14 Dato1500 1514 bytes
Trama Ethernet
Fig. 1.13 Fragmentacin a nivel datagrama 1.4.2 DESPLAZAMIENTO DE DATAGRAMAS: 9
INICTEL
El desplazamiento de paquetes indica la posicin de cada fragmento dentro del paquete original para luego ubicar la misma posicin en el momento de reensamblar el paquete en el Host destino B. Este desplazamiento tambin 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 informacin (el conteo es a partir de 0 y termina en 1479); el segundo segmento tiene el valor de desplazamiento 1480 y la informacin tiene la cantidad de 528 bytes (el conteo es a partir de 1480 y finaliza en 2007), si se tuviera un fragmento ms, este empezara en 2008 y se sumaria la cantidad de informacin; la idea es slo indicar el valor de desplazamiento y en el Host destino se reensamblar y tomar la posicin que le corresponde.
Header IP
20 Datos 1 1 480 bytes Datos 2 528 bytes
Fragmento 1 Desplazamiento 0
Fragmento 1 Desplazamiento 1480
Fig. 1.14 Desplazamiento 1.5 ANALISIS DEL PROTOCOLO ICMP: En esta seccin 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
Tipo Tipo
8
Cdigo Cdigo
16
23
31
Identificador
08 08 02
00 00 00
Sumade deverificacin verificacin Suma Nmero de secuencia
3c 3c 0f
5e 5e 00
Dato ICMP (32 bytes) 4 0a0c0122

Direccin IP destino
4 0a0c0128
Direccin IP origen
1 01
Protocolo
40 bytes
ICMP
Datos IP
Fig. 1.15 ICMP Eco encapsulado en Datagrama IP Los campos expuestos en la Fig. 1.15 tienen el significado:
10
INICTEL
Tipo: Toma el valor 08, identifica el tipo de mensaje de solicitud de eco. Cdigo: Toma el valor de 00, indica no existe ms informacin 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 identificacin del mensaje ICMP eco. Numero de secuencia: Toma el valor 0f00, indica el nmero 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 enva por defecto un tamao 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
Tipo Tipo
8
Cdigo Cdigo
16
23
31
Identificador
00 00 02
00 00 00
Sumade deverificacin verificacin Suma Nmero de secuencia
44 44 0f
5c 5c 00
Dato ICMP (32 bytes) 4 0a0c0128

Direccin IP destino
4 0a0c0122
Direccin IP origen
1 01
Protocolo
40 bytes
ICMP
Datos IP
Fig. 1.16 ICMP Respuesta de eco encapsulado en Datagrama IP Los campos de la Fig. 1.16 se detallan a continuacin: Tipo: Toma el valor 00, identifica el tipo de mensaje de respuesta de eco. Cdigo: Toma el valor de 00, indica no existe ms informacin 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 identificacin del mensaje ICMP de respuesta de eco. Igual al campo anterior (solicitud de eco).
11
INICTEL
Numero de secuencia: Toma el valor 0f00, indica el nmero 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 enva por defecto un tamao 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 enva cuando descarta un datagrama al finalizar su tiempo de vida. Los Hosts lo enva 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.
B router Ethernet
ICMP
Red Red
Fig. 1.17 Mensaje de tiempo excedido Para el anlisis del mensaje de tiempo excedido se genera un trfico 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 trnsito. Estadsticas de ping para 10.12.2.30: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mnimo = 0ms, mximo = 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. Cdigo: Toma el valor de 00, indica no existe ms informacin 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.
12
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 envo de datagrama
0
Tipo Tipo
8
Cdigo Cdigo
16
23
31
11 11 00
00 00 00
Sumade deverificacin verificacin Suma
9f 9f
a3 a3 00
00
Cabecera IP + 8 bytes de la datagrama anterior
4 0a0c0128
Direccin IP destino
4 0a0c0101
Direccin IP origen router
1 01
Protocolo
36 bytes
ICMP
Datos IP
Fig. 1.19 ICMP-tiempo excedido encapsulado en datagrama IP 1.6 ANALISIS DEL PROTOCOLO UDP Para el anlisis del protocolo UDP se genera un trfico de resolucin de nombres (DNS) La Fig. 1.20 muestra este anlisis.
Emisor
IP origen = 10.12.1.40 Puerto origen = 1085
Mensaje en la red
Receptor
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 nmero de puerto de la mquina origen (host A), quien hace la peticin de resolucin de nombres. Puerto UDP de destino: Toma el valor de 0035, indica el nmero de puerto de la mquina 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).
13
INICTEL
Suma de verificacin UDP: Toma el valor de f525, representa la Suma de comprobacin de errores del mensaje. Ms adelante se calcula este campo. Datos: Contiene los datos que se envan las aplicaciones. En este caso al protocolo DNS. El tamao del dato es de 32 bytes
16
23
31
PuertoUDP UDPde deorigen origen Puerto
04 04 00 00
3d 3d
PuertoUDP UDPde dedestino destino Puerto
00 00
35 35 25 25
Longitudde demensaje mensajeUDP UDP Longitud
28 f5 28 f5 Dato UDP (32 bytes)
4 200.138.105.37
Direccin IP destino
4 10.12.1.40
Direccin IP origen
1 17
Protocolo
40 bytes
UDP
Datos IP
Fig. 1.21 Mensaje UDP encapsulado en datagrama IP 1.7 ANLISIS DEL PROTOCOLO TCP: Para el anlisis 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 ANLISIS DEL ESTABLECIMIENTO DE UNA CONEXIN TCP: Se generan tres mensajes antes de enviar los datos los cuales se denominan mensajes de establecimiento de conexin TCP o handshake (saludo) y se puede apreciar en la Fig. 1.23 El Host origen inicia el establecimiento de conexin al enviar el mensaje con el bit SYN activado. Este mensaje es recibido por el Host destino, y devuelve la correspondiente confirmacin (ACK), si desea abrir la conexin activa el bit SYN del segmento e informa de su primer nmero de secuencia. Por su parte, el Host origen recibe los mensajes que le ha enviado y enva su confirmacin (ACK). Finalmente, el Host destino recibe el segmento ACK y se inicia la comunicacin.
14
INICTEL
IP origen = 10.12.1.40 Puerto origen = 1081 Envo de SYN

Seq = 592319
IP destino = 10.12.1.38 Puerto origen = 80
Recepcin del seg. SYN

Seq = 360125634
Envo de SYN y ACK
Recepcin de SYN + segmento ACK Envo de ACK

Seq = 592320 Ack = 360125635
Ack = 592320
Recepcin del seg. ACK
Fig. 1.23 Establecimiento de conexin TCP El anlisis TCP del primer segmento (segmento SYN) en el establecimiento de una conexin 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 mquina destino (servidor Web)
0 3 9 16 23 31
Puertofuente fuente Puerto
Nmero de secuencia Nmero de secuencia
04 04
39 39 09 09 00 00
CodeBits CodeBits
Puertodestino destino Puerto
00 00
50 50 bf bf 00 00 00 00 00 00 b4 b4 02 02
Nmero de acuse de recibo Nmero de acuse de recibo HLEN HLEN
00 00
09 09
Ventana Ventana
00 00
Reservado Reservado
00 00 20 20
Sumade deverificacin verificacin Suma Opciones (variable) Opciones (variable)
70 70 3e 3e
02 02 69 69
Punterode deurgencia urgencia Puntero
00 00
02 02 01 01
04 04 01 01 1 06
05 05 04 04
28 bytes
4 10.12.1.38
Direccin IP destino
4 10.12.1.40
Direccin IP origen
TCP
Datos IP
Protocolo
Fig. 1.24 Formato TCP del Segmento SYNC encapsulado en datagrama IP Nmero de secuencia: Toma el valor de 000909bf, indica el nmero de secuencia del segmento.
15
INICTEL
Nmero de acuse de recibo: De 32 bits, indica el nmero de secuencia del siguiente byte que se espera recibir. Con este campo se indica al otro extremo de la conexin que los bytes anteriores se han recibido correctamente.
HLEN, Reservado y cdigo de bits. Se explica en la Fig. 1.25
70
02
U A P R S R C S S Y G K H T N F I N
0 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0
Longitud de cabecera TCP
Reservado para el futuro
Cdigo de Bits
Fig. 1.25 HLEN, Reservado y Cdigo de bits o o o El Campo Longitud de Cabecera toma el 0111 (valor 7 en decimal), que corresponde a un segmento con datos opcionales (28 bytes) El campo Reservado, toma el valor de 000000 en bits, reservados para un posible uso futuro. El Bits de cdigo o indicadores, toma el valor de 000010, segun el grfico anterior tiene activado el bit SYN en 1 y determina el propsito y contenido del segmento. Se utiliza al crear una conexin para indicar al otro extremo cual va a ser el primer nmero de secuencia con el que va a comenzar a transmitir. Ventana. Toma el valor 2000, nmero de bytes que el emisor del segmento est dispuesto a aceptar por parte del destino. Suma de verificacin. Toma el valor 3e69 suma de comprobacin de errores del segmento actual. Puntero de urgencia. Toma el valor de 0000, este valor indica datos de envo no urgentes. Opciones (variable) si est presente nicamente se define una opcin; el tamao mximo de segmento que ser aceptado. Relleno. No existe Datos. No existe por ser un segmento de sealizacin. El segundo segmento (segmento SYN y ACK) en el establecimiento de una conexin TCP se observa en la Fig. 1.26
16
INICTEL

0 3 9 16 23 31
Nmerode desecuencia secuencia Nmero
00 00 15 15 00 00
50 50 77 77 09 09
04 04
39 39 c2 c2 c0 c0 d0 d0 00 00 b4 b4 02 02
Nmero de acuse de recibo Nmero de acuse de recibo HLEN HLEN Reservado Reservado
14 14 09 09 16 16 00 00
Sumade deverificacin verificacin Suma Opciones (variable) Opciones (variable)
70 70
12 12 4f 4f 04 04 01 01
CodeBits Ventana Ventana CodeBits
1d 1d
02 02 01 01
05 05 04 04
28 bytes
4 10.12.1.40
Direccin IP destino
4 10.12.1.38
Direccin IP origen
1 06
Protocolo
TCP
Datos IP
Fig. 1.26 Formato TCP del Segmento SYNC y ACK encapsulado en datagrama IP El tercer segmento (segmento ACK) en el establecimiento de una conexin TCP se aprecia en la Fig. 1.27
16
23
31
Nmerode desecuencia secuencia Nmero
04 04
39 39 09 09
00 00
50 50 c0 c0 c3 c3 38 38 00 00
Nmerode deacuse acusede derecibo recibo Nmero HLEN HLEN
00 00
09 09 14 14 22 22 00 00
15 15
Reservado Reservado
77 77 10 10
50 50 3e 3e
CodeBits Ventana Ventana CodeBits
ab ab
4 10.12.1.38
Direccin IP destino
4 10.12.1.40
Direccin IP origen
1 06
Protocolo
28 bytes
TCP
Datos IP
Fig. 1.27 Formato TCP del Segmento ACK encapsulado en datagrama IP
17
INICTEL
1.8 ALGORITMO DE CHECKSUM: 1.8.1 DETECCIN DE ERRORES: En ocasiones, los paquetes de datos al moverse de un nodo a otro pueden alterarse generando errores en la informacin que transportan. Este tipo de errores deben evitarse para que la informacin que transporte la red sea confiable. Sin esta confiabilidad los usuarios no utilizaran las redes. La idea bsica detrs de los esquemas de deteccin de errores en redes es adicionar informacin 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 deteccin de errores que podemos imaginar es la transmisin completa de dos copias del mismo paquete. Si las dos copias son idnticas cuando lleguen al receptor, es muy probable que la informacin 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 deteccin de errores es deficiente: se requieren n bits de correccin de errores para un mensaje de n bits y adems, si por alguna razn, los errores ocurren en el mismo lugar en los dos paquetes, no sern detectados. Afortunadamente se pueden hacer cosas mejores. En general, se puede proporcionar una capacidad de deteccin de errores ms fuerte enviando slo k bits redundantes en un mensaje de nbits, donde k << n (k mucho ms pequeo que n). Por ejemplo, el frame de Ethernet puede llevar hasta 12000 bits (1500 bytes) y utiliza slo 32 bits redundantes para detectar errores (usa un cdigo de redundancia cclica conocido como CRC-32). Los bits adicionados al mensaje son redundantes pues no adicionan nueva informacin 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 enva 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 accin apropiada (descartar el paquete y esperar su retransmisin 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 especficos, cuando el algoritmo para crear el cdigo se basa en la adicin, reciben el nombre de checksums. Infortunadamente, la palabra checksum se usa de manera incorrecta, queriendo nombrar con ella cualquier cdigo de deteccin 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.
18
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 clculo 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 sern procesados (el mensaje) son acomodados como una secuencia de enteros de 16 bits. Estos enteros se suman utilizando aritmtica 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 aritmtica complemento a uno, un entero negativo -x se representa como el complemento de x; es decir, cada bit de x es invertido. Cuando los nmeros se adicionan, si se obtiene un acarreo (carry) en el bit ms significativo, se debe incrementar el resultado. Por ejemplo, sumemos -5 y -3 en aritmtica complemento a uno con enteros de 4 bits. En este caso +5 se representara con 0101 y -5 con 1010; +3 se representara con 0011 y -3 con 1100. Al sumar 1010 y 1100, ignorando el acarreo (carry) que queda en el bit ms significativo, tendremos como resultado 0110. En la aritmtica complemento a uno, cuando una operacin genera un acarreo (carry) en el bit ms significativo, se debe incrementar el resultado; es decir que 0110 se convierte en 0111, que es la representacin 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 aritmtica complemento a uno), el chequeo es correcto. Como un ejemplo sencillo del clculo del checksum supongamos que tenemos tres "palabras" de 16 bits
0110011001100110 0101010101010101 0000111100001111 DIVISIN DE TELEDUCACIN
19
INICTEL
La suma de las dos primeras palabras sera:

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 sera
0011010100110101. Que vendra 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 clculos del checksum. En IP el checksum se calcula slo 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 clculo similar que en UDP. El RFC1071, Computing the Internet Checksum, discute mtodos 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 cdigo de deteccin de errores, pero esta no es una tcnica fuerte de deteccin 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 razn por la cual un algoritmo como ste es utilizado, aunque tenga una proteccin dbil contra errores, es simple: este algoritmo es fcil 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). Adems la experiencia observada en ARPANET sugiri que un checksum era adecuado: este checksum es la ltima lnea de defensa en los protocolos de TCP/IP pues la gran mayora de errores son descubiertos por algoritmos de deteccin de errores ms fuertes, tales como los CRCs utilizados en la capa de enlace (capa 2 del modelo OSI). 1.8.3 DETECCIN DE ERRORES VS CORRECCIN DE ERRORES: A primera vista uno puede suponer que corregir errores es mucho mejor que slo detectarlos, ya que evitara tener que reenviar el paquete completo que, entre otras cosas, aumenta el uso de
20
INICTEL
ancho de banda y produce un tiempo de latencia mientras se retransmite el mensaje. Sin embargo, la correccin de errores tiene su lado malo: requiere un mayor nmero de bits redundantes para que sea tan fuerte (es decir capaz de corregir el mismo rango de errores) como un cdigo que slo detecta errores. De esta forma, mientras la deteccin de errores requiere que ms bits sean enviados cuando algn error ocurre, la correccin de errores requiere enviar ms bits todas las veces. Como resultado, la correccin de errores es til en dos condiciones: 1. Cuando los errores son demasiado probables. Por ejemplo, en ambientes inalmbricos. 2. Cuando el costo de retransmisin es demasiado alto. Por ejemplo, el tiempo de latencia involucrado en la retransmisin de un paquete sobre un enlace de satlite. El uso de cdigos de correccin de errores es llamado, en redes, FEC (forward error correction) porque la correccin de errores es manejada de antemano, con informacin extra, en lugar de esperar a que los errores sucedan y manejarlos con retransmisin. 1.8.4 CALCULO DEL CAMPO CHECKSUM EN EL HEADER DEL DATAGRAMA IP La informacin 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 clculo 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
21
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
16 19 Longitud total
31
Ver HLEN Tipo Serv.

20 bytes
Identificador TTL
Direccin de origen Direccin 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
Ver
4
HLEN
8
Tipo Serv
16 19
Longitud total
31
4
Identificador
5 9e
00 0f
Protocolo
00
3c 0 00 50 28 22 50 00 64 68 6C 70 74 61 65 69 Cabecera IP
20 bytes
0 e6 01 01
TTL
Suma de chequeo
20
Direccin de origen
01 0c 0c 00 00 62 66 6A 6E 72 76 63 67
0a
Direccin de destino
0a
Datos IP
08 02 61 65 69 6D 71 75 62 66
40 0B 63 67 6B 6F 73 77 64 68
40 bytes
Fig. 1.31 Datagrama IP (Cabecera + Datos) Realizando el clculo 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).
22
Cabecera
Datos IP
Protocolo Suma de chequeo
INICTEL
POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS Hexadecimal 4500 003c 9509 0000 2001 0000 0a0c 0128 0a0c 0122 110A8 Binario 0100010100000000 0000000000111100 1001010100001001 0000000000000000 0010000000000001 0000000000000000 0000101000001100 0000000100101000 0000101000001100 0000000100100010 10001000010101000
El 1 subrayado indica el carry de la operacin. El resultado de la suma se realiza la siguiente operacin: 10A8 1 10A9 1000010101000 1 0001000010101001
Para clculo final del checksum debemos calcular el complemento a uno del resultado obtenido. 10A9 EF56 1110111101010110 1110111101010110
El resultado mostrado en amarillo es el valor del checksum que se comprueba en la Fig. 1.30 y ah termina la verificacin. 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 informacin mostrada en la Fig. 1.32 protocolos. es la captura de paquetes de la cabecera UDP utilizando un analizador de
Fig. 1.32 Cabecera UDP

23
INICTEL
La seudo-cabecera UDP de 12 bytes con los datos de la Fig. 1.33 se muestran en la Fig. 1.32
16
31
Direccin de origen
0a
Direccin de destino
0c 8a
Protocolo
01 69
Longitud del mensaje UDP
28 25 28
ce
Cero
00
11
00
Fig. 1.33 seudo-cabecera UDP La informacin de la seudo cabecera (Fig. 1.33) se reacomoda para el clculo de checksum de la siguiente forma: Hexadecimal 0a0c 0128 ce8a 6925 0011 0028 1431C Se suma el carry 431C 1 431D 0100001100011100 1 0100001100011101 Binario 0000101000001100 0000000100101000 1100111010001010 0110100100100101 0000000000010001 0000000000101000 10100001100011100
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
08 bytes
16
23
31
PuertoUDP UDPde deorigen origen Puerto
04 04 00 00 00 00 00 03 03 03 02 00
3d 3d 28 28 01 01 00 77 75 65 70 01
PuertoUDP UDPde dedestino destino Puerto
00 00 f5 f5
35 35 25 25 00 00 00 77 70 75 00 01
Longitudde demensaje mensajeUDP UDP Longitud Datos UDP
Cabecera UDP
01 00 00 77 74 64 65 00
32 bytes
Datos UDP
Fig. 1.34 Segmento UDP (Cabecera + Datos)
24
INICTEL
Suma con aritmtica complemento a uno de la cabecera UDP y colocando a cero el campo checksum (F525H al valor 0000): Hexadecimal 043d 0035 0028 0000 049a Binario 0000010000111101 0000000000110101 0000000000101000 0000000000000000 0000010010011010
Suma con aritmtica complemento a uno de los datos transportados por UDP mostrados en la Fig. 1.34 Hexadecimal 0001 0100 0001 0000 0000 0000 0377 7777 0375 7470 0365 6475 0270 6500 0001 0001 1C321 Se suma el carry: C321 1 C322 1100001100100001 1 1100001100100010 Binario 0000000000000001 0000000100000000 0000000000000001 0000000000000000 0000000000000000 0000000000000000 0000001101110111 0111011101110111 0000001101110101 0111010001110000 0000001101100101 0110010001110101 0000001001110000 0110010100000000 0000000000000001 0000000000000001 11100001100100001
Luego, se genera una suma de los resultados obtenidos con la seudo-cabecera, la cabecera UDP y los datos. Hexadecimal 431D 049a C322 10AD9 Se suma el carry
Binario 0100001100011101 0000010010011010 1100001100100010 10000101011011001
25
INICTEL
POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS 0AD9 1 ADA 1100001100100001 1 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 GENERACIN DE TRFICO Y DIAGNSTICO: 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 slo si se ha instalado el protocolo TCP/IP. ping [-t] [-a] [-n cantidad] [-l tamao] [-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: 1.9.2 -t : Solicita eco al host hasta ser interrumpido. Para ver estadsticas 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 tamao: Tamao del bfer de envos. -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. COMANDO TRACERT: Esta herramienta de diagnstico determina el camino tomado hacia un destino enviando paquetes de eco del Protocolo de mensajes de control de Internet (ICMP)con valores variables de
26
INICTEL
Perodo de vida (TTL) para el destino. Cada enrutador de la ruta de acceso debe decrementar el Perodo de vida de un paquete al menos en 1 para reenviarlo, de forma que el Perodo de vida sea un nmero de "hops". Cuando el Perodo 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 enva el primer paquete de eco con un perodo de vida de 1 y lo incrementa en una unidad en cada transmisin posterior hasta que el destino responda o se alcance el perodo de vida mximo. 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 notificacin los paquetes con valores de perodo de vida caducados, por lo que son invisibles para tracert. tracert [-d] [-h saltosMximos] [-j listaDeEquipos] [-w tiempoDeEspera] nombreDeDestino Opciones: 1.9.3 -d: Especifica que las direcciones no se deben resolver hacia nombres de hosts. -h saltos Mximos: Especifica el nmero mximo 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 nmero de milisegundos especificado por tiempoDeEspera en cada respuesta . Nombre De Destino: Nombre del host de destino. COMANDO ARP: Muestra y modifica las tablas de traduccin de direcciones fsicas de IP a Ethernet o a Token Ring que utiliza el protocolo de resolucin de direcciones (ARP, Ardes Resolution Protocol). Este comando slo 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, slo se mostrarn las direcciones IP y fsicas del equipo especificado. Cuando ARP se utiliza en ms de una interfaz de red, entonces se muestran entradas para cada tabla ARP. -g: Igual que -a. dir_inet: Especifica una direccin IP en notacin decimal con puntos. -N dir_if: Muestra las entradas de ARP para la interfaz de red especificada mediante dir_if. 27
INICTEL
dir_if: Especifica, si est presente, la direccin IP de la interfaz cuya tabla de traduccin 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 direccin IP dir_ineta la direccin fsica dir_eth. La direccin fsica se especifica como 6 bytes hexadecimales separados por guiones. La direccin IP se especifica mediante la notacin decimal con puntos. Esta entrada es permanente, es decir, no se quitar automticamente de la cach cuando termine el tiempo de espera.
1.10
dir_eth: Especifica una direccin fsica. ANALIZADOR DE PROTOCOLOS ETHEREAL: Ethereal es una aplicacin que ofrece una interfaz sencilla de utilizar y permite visualizar los
contenidos de las cabeceras de los protocolos involucrados en una comunicacin en una forma muy cmoda. 1.10.1 INTERFAZ Y MENS: Ethereal funciona en modo grfico y est programado con la librera de controles GTK. La ventana principal de la aplicacin se divide en tres partes de visualizacin y una zona inferior de trabajo con filtros. (Fig. 1.35)
2 3 A B C D
Fig. 1.35 Interfaz Ethereal En la primera parte (Fig. 1.35 seccin 1) se muestra la informacin ms relevante de los paquetes capturados, como, por ejemplo, las direcciones IP y puertos involucrados en la comunicacin. Seleccionando un paquete en esta seccin podemos obtener informacin detallada sobre l en las otras dos secciones de la pantalla que comentaremos a continuacin. DIVISIN DE TELEDUCACIN INTERCONECTIVIDAD DE REDES 28
INICTEL
En la parte central de la ventana (Fig. 1.35 seccin 2) se muestra, utilizando controles treeview, cada uno de los campos de cada una de las cabeceras de los protocolos que ha utilizado el paquete para moverse de una mquina a la otra. As, si hemos capturado una serie de paquetes de, por ejemplo, una conexin 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 seccin 3) muestra un volcado hexadecimal del contenido del paquete. Seleccionando cualquier campo en la parte central de la ventana se mostrarn en negrita los datos correspondientes del volcado hexadecimal, los datos reales que estn viajando por la red. En la barra inferior (siempre en la Fig. 1.35), aparecen cuatro componentes muy interesantes a la hora de hacer anlisis de capturas: Creacin 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 aplicacin contiene lo siguiente: File: Men con los tems para abrir, guardar ficheros de captura. Permite imprimir y salir de la aplicacin. Edit: Men para encontrar tramas concretas, ir a una trama y marcar tramas. Tambin tiene las opciones de preferencias, de captura y visualizacin de filtros y protocolos. Capture: Inicia o detiene la captura de paquetes. Display: Permite cambiar las opciones de visualizacin, correspondencia y coloreado de marcos. Tools: Este men contiene los pluggins instalados, seguimiento de un paquete TCP (interesante funcin), sumario de los paquetes capturados y la visualizacin de las estadsticas de protocolos empelados. Help: Ayuda de la aplicacin y acerca de.
1.10.2 CAPTURA DE PAQUETES: La captura de paquetes se realiza por medio de la opcin de men capture -> start. Al seleccionar la opcin aparecer la caja de dilogo con las preferencias para la captura de los paquetes como se observa en la Fig. 1.37
29
INICTEL
1 2 3 6 7 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 sesin, en algunos sistemas es equivalente a las conexiones de red de las que se dispone (PPP, Red, etc) si al seleccionar una opcin no se capturan datos, se debe a que no se ha seleccionado el interfaz correcto. 2. Cuenta (count): Es el nmero de paquetes que deseamos que se capturen. En el caso de dejarse a 0, se capturarn todos los paquetes hasta que se detenga manualmente la sesin (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 ms 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 mxima de bytes de cada trama que deseamos sean capturados. 6. Captura de datos: En caso de seleccionarse esta opcin, se capturarn todos los datos posibles que sean alcanzables por el host monitor. Si no se selecciona1, slo se capturarn los paquetes que entren o salgan al host monitor. 7. Actualizacin de la lista en tiempo real: Actualiza la ventana de paquetes capturados a la vez que stos son capturados. Esta opcin 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 resolucin de nombres MAC: Este botn 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 resolucin del nombre de la red: Este botn permite que controlar si Ethereal traduce o la direcciones IP a nombres del dominio del DNS. Haciendo clic en este botn, la lista de
4 5
30
INICTEL
paquetes capturados tendr informacin ms til, pero provocar las correspondientes peticiones de operaciones de bsqueda, que pueden influir en la captura. 11. Permitir la resolucin de nombres de transporte: Este botn permite controlar si Ethereal traduce o no los nmeros de puerto del protocolo. Terminada la configuracin de la ventana con las opciones que requerimos, al presionar el botn OK; comenzar la captura de paquetes, si se presiona CANCEL, no se capturar ningn paquete y se regresar al estado anterior. Durante la captura, aparecer la caja de dilogo que muestra la evolucin de la captura de datos (Fig. 1.38)
Fig. 1.38 Evolucin de la captura 1.10.3 VISUALIZACIN DE LOS RESULTADOS: Una vez realizada la captura de los datos, toda la secuencia de estos paquetes aparecer en los marcos de visualizacin. Ethereal proporciona una serie de herramientas que facilitan esta visualizacin. La forma ms directa de visualizar los resultados consiste en hacer clic en el paquete del que se desee obtener ms informacin, dentro de la zona 1 (ver Fig. 1.39) de la ventana. Esta zona muestra los paquetes que han sido capturados. La ventana se divide en filas (una por paquete) y columnas que muestran la correspondiente informacin acerca de los paquetes. Por defecto las columnas que aparecen son las mostradas en la Fig. 1.39
(1) Nmero de paquete; (2) Informacin temporal de la captura del paquete (fecha, hora, etc.); (3) Direccin fuente; (4) Direccin destino; (5) Protocolo empleado por el paquete; (6) Informacin adicional.
Fig. 1.39 Distribucin de las columnas de Ethereal La informacin de estas columnas varia de acuerdo a las opciones del men que elijamos a travs del men Edit -> Preferences. Se pueden aadir o quitar columnas con informacin adicional o variar el orden en que stas se muestran.
31
INICTEL
Una vez se ha seleccionado un paquete en una fila, la informacin de ste aparece en la ventana inferior dentro de la zona 2 (ver figura 1.40). All aparece con los campos que ste tiene y, por medio de un control tree-view, la informacin de stos puede ser visualizada de forma organizada. En el panel 2 de la Fig. 1.40 se tiene la estructura del mensaje; al seleccionar un tem de este panel, se visualizar su contenido en el panel 3 (Fig. 1.40) dentro del contenido del paquete completo como una zona sombreada. Se puede extender o contraer toda la informacin del marco 2 por medio de las opciones de men Display -> Collapse All y Display -> Expand All, respectivamente. Si se desea visualizar un paquete por separado, para un mejor anlisis del mismo, o compararlo con otro, se puede seleccionar y por medio de la opcin de men Display ->Show packet in New Window. El paquete seleccionado aparecer en una nueva ventana. Tambin se puede acceder a este men por medio del men contextual que aparece al hacer clic con el botn derecho en el paquete seleccionado.
3
Fig. 1.40 Ventanas de informacin. Otras herramientas tiles a la hora de trabajar con los paquetes visualizados son las de buscar o ir hacia un paquete con un nmero concreto. Esto se hace por medio de los mens Edit->Find frame, y Edit->Go to Frame. Tambin se puede marcar un paquete por medio de la opcin de men Edit-> Mark Frame (para retirar el marcado o seleccin, se debe seleccionar el paquete marcado y volver a seleccionar la opcin de men Edit -> Mark Frame) 1.10.4 DEFINICIN DE FILTROS DE LECTURA: Ethereal permite filtrar la informacin acerca de los paquetes capturados, tanto en el momento de la captura de los mismos como en la visualizacin. Ethereal utiliza la misma sintaxis para la
32
INICTEL
definicin de filtros que la orden de Unix tcpdump. La descripcin que se ofrece a continuacin no es ms que una adaptacin de la informacin que aparece en la pgina man de tcpdump. Un filtro de captura consiste en un conjunto de expresiones primitivas conectadas mediante los operadores lgicos and/or y opcionalmente precedidos por not: [not] primitiva [and|or [not] primitiva ...] tcp port 23 and host 10.0.0.5 Captura trfico telnet (puerto 23) desde y hacia el host 10.0.0.5. tcp port 23 and not host 10.0.0.5 Captura trfico telnet no dirigido ni generado por el host 10.0.0.5. Una primitiva es una de las expresiones siguientes: [src|dst] host <host> Permite filtrar el trfico generado (src) o recibido (dst) por un <host>, indicando su direccin IP o su nombre. Si no se especifica ni src ni dst, se seleccionan todos los paquetes cuya direccin origen o destino coincide con la del computador especificado. ether [src|dst] host <ehost> Permite filtrar basndose en la direccin fsica (Ethernet). Como antes, se puede indicar src o dst para capturar slo el trfico saliente o entrante. gateway host <host> Permite filtrar paquetes que usan al <host> como un gateway (router). Es decir, paquetes cuya direccin fsica (origen o destino) es la del host, pero las direcciones IP (origen o destino) no corresponden al host. [src|dst] net <net> [{mask <mask>}|{len <len>}] Permite seleccionar paquetes basndose en las direcciones de red. Adicionalmente, se puede especificar un mscara de red o el prefijo CIDR cuando sea diferente al de la propia mquina desde donde se realiza la captura. [tcp|udp] [src|dst] port <port> Permite un filtrado basado en los puertos TCP y/o UDP. Las opciones [tcp|udp] [src|dst] permiten restringir el filtrado slo a los paquetes de un protocolo (TCP o UDP), o slo a los que utilizan el puerto como origen o como destino. less|greater <length> Selecciona paquetes cuya longitud sea menor o igual (less) o mayor o igual (greater) que un valor dado <length>. ip|ether proto <protocol> Selecciona paquetes del protocolo especificado, bien al nivel Ethernet o al nivel IP. ether|ip broadcast|multicast 33
INTERCONECTIVIDAD DE REDES DIVISIN DE TELEDUCACIN
INICTEL
Permite filtrar difusiones (broadcast) o multidifusiones (multicast) Ethernet o IP. <expr> relop <expr> Esta primitiva permite crear filtros complejos que seleccionan bytes o rangos de bytes en los paquetes. La primitiva se evala a True si se cumple la relacin. relop es una de las siguientes: >, <, >=, <=, =, !=, y expr is una expresin aritmtica compuesta por constantes enteras (expresadas en la sintaxis estndar de C), los operadores binarios [+, -, *, /, &, |], un operador de longitud, y funciones para acceder a los datos de un paquete. Para acceder a datos en el interior de un paquete se utiliza la sintaxis siguiente:proto [ expr : size ]. Proto es uno de los siguientes ether, fddi, ip, arp, rarp, tcp, udp, or icmp. El offset en bytes referido al protocolo especificado, viene dado por expr. size es opcional e indica el nmero de bytes del campo de inters; puede ser 1, 2 4, el defecto es 1. El operador de longitud, indicado por la palabra len, da la longitud del paquete. Por ejemplo: ether[0] & 1 != 0 captura todo el trfico multicast ip[0] & 0xf != 5 captura todos los paquetes IP con opciones ip[6:2] & 0x1fff = 0 captura slo datagramas no fragmentados y el primer fragmento de un datagrama. Esta comprobacin se aplica implcitamente a todas las operaciones tcp y udp indexadas. Por ejemplo, tcp[0] siempre significa el primer byte de la cabecera TCP, y no el primer byte de un fragmento tcp distinto del primero. 1.10.5 EJEMPLOS: Para capturar todos los paquetes que llegan o salen sundown: host sundown Para capturar el trfico entre helios y, o bien, hot, o ace: host helios and ( hot or ace ) Para capturar todos los paquetes IP entre ace y cualquier host excepto helios: ip host ace and not helios Para capturar todo el trfico entre el localhost y hosts en Berkeley: net ucb-ether Para capturar todo el trfico ftp a travs del router snup: gateway snup and (port ftp or ftpdata) Para capturar los paquetes de establecimiento y cierre de cada conexin TCP (los paquetes SYN y FIN): tcp[13] & 3 != 0 Para capturar datagramas IP mayores de 576 bytes: ip[2:2] > 576 Para capturar los datagramas IP de difusin o multidestino que no han sido enviados mediante una difusin o direccin multidestino Ethernet: ether[0] & 1 = 0 and ip[16] >= 224 Para capturar todos los paquetes ICMP, excepto las peticiones y respuestas de eco: icmp[0] != 8 and icmp[0] != 0
34
INICTEL
ENLACES DE INTERES: SOFTWARE ETHEREAL http://www.ethereal.com/download.html MANUAL ETHEREAL http://www.lab.dit.upm.es/~labrst/config/config-ethereal.htm TRAMA ETHERNET http://www.dei.isep.ipp.pt/~andre/documentos/ethernet.html FUNCIONAMIENTO ICMP http://www.argo.es/~jcea/proyecto/icmp.htm RFC 768 http://www.rfc-es.org/rfc/rfc0768-es.txt RFC 1071 http://www.ietf.org/rfc/rfc1071.txt?number=1071 DESCARGA RFC INGLES: http://www.ietf.org/rfc.html NUMERACIN BINARIA, HEXADECIMAL http://www.monografias.com/trabajos14/sistdigital/sistdigital.shtml
35

Mdulo1 Analisisdeprotocolostcp Ip 100519163553 Phpapp02

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Mdulo1 Analisisdeprotocolostcp Ip 100519163553 Phpapp02

Загружено:

Авторское право:

Доступные форматы

INICTEL

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

MODULO 1 ANLISIS DE PROTOCOLOS TCP/IP

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

DESARROLLO DEL MODULO 1 ANLISIS DE PROTOCOLOS TCP/IP

Ethernet IP = 10.12.1.1 MAC = 00-d0-bb-cc-87-01

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

60 bytes 6 6 2 28 bytes 18 bytes

Datos (ARP solicitud)

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

Datos (ARP respuesta)

SENDER HARDWARE (Direcc. Hw. del transmisor)

SENDER IP (Direcc. IP del trans)

TARGET HARDWARE (Direcc. Hw. del receptor)

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

SENDER HARDWARE (Direcc. Hw. del transmisor)

TARGET HARDWARE (Direcc. Hw. del receptor)

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

Datos (cabecera IP+ datos IP)

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

Dato 2008 bytes

Fragmento 2 Fragmento 1 Ethernet MTU = 1500 bytes

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

Datos Datagrama IP Header IP

Datagrama IP Fragmentada 20 528 1500 bytes 14 Dato1500 1514 bytes

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

Fragmento 1 Desplazamiento 1480

Sumade deverificacin verificacin Suma Nmero de secuencia

Dato ICMP (32 bytes) 4 0a0c0122

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

Sumade deverificacin verificacin Suma Nmero de secuencia

Dato ICMP (32 bytes) 4 0a0c0128

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

Sumade deverificacin verificacin Suma

Cabecera IP + 8 bytes de la datagrama anterior

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

PuertoUDP UDPde deorigen origen Puerto

PuertoUDP UDPde dedestino destino Puerto

Longitudde demensaje mensajeUDP UDP Longitud

28 f5 28 f5 Dato UDP (32 bytes)

Sumade deverificacin verificacin Suma

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

IP origen = 10.12.1.40 Puerto origen = 1081 Envo de SYN

IP destino = 10.12.1.38 Puerto origen = 80

Recepcin del seg. SYN

Envo de SYN y ACK

Recepcin de SYN + segmento ACK Envo de ACK

Recepcin del seg. ACK

Puertofuente fuente Puerto

Nmero de secuencia Nmero de secuencia

Puertodestino destino Puerto

Nmero de acuse de recibo Nmero de acuse de recibo HLEN HLEN

Sumade deverificacin verificacin Suma Opciones (variable) Opciones (variable)

Punterode deurgencia urgencia Puntero

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

HLEN, Reservado y cdigo de bits. Se explica en la Fig. 1.25

Longitud de cabecera TCP

Reservado para el futuro

POSTGRADO A DISTANCIA: REDES DE COMUNICACIN DE DATOS

Puertofuente fuente Puerto

Nmerode desecuencia secuencia Nmero

Puertodestino destino Puerto