Análisis de Protocolos

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

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.

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.


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)


INICTEL

60 bytes
6 6 2 28 bytes 18 bytes

00025557cf88 00096b327d44 0806 Datos (ARP respuesta) relleno
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.


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.


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)
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.


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


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:


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:


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
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
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.
• 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).


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.
• 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.


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
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
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).

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
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
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.


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
00
00 09
09 09
09 bf
bf
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 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
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.


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


INICTEL

0 3 9 16 23 31

Puerto fuente
Puerto destino
00
00 50
50 04
04 39
39
15
15 77
77 14
14 c2
c2
00
00 09
09 09
09 c0
c0
HLEN
HLEN Reservado
Reservado CodeBits Ventana
CodeBits Ventana
70
70 12
12 16
16 d0
d0
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
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 destino
04
04 39
39 00
00 50
50
00
00 09
09 09
09 c0
c0
15
15 77
77 14
14 c3
c3
HLEN
HLEN Reservado
Reservado CodeBits Ventana
CodeBits Ventana
50
50 10
10 22
22 38
38
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
destino origen

Fig. 1.27 Formato TCP del Segmento ACK encapsulado en datagrama IP


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.


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


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


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

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
20 bytes

Cabecera
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
9e 0f 0 0 00
20 bytes

Cabecera IP
20 01 e6 50
0a 0c 01 28
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).


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


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

0a 0c 01 28
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
Cabecera UDP
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)


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”


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


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.


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.

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


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


INICTEL

paquetes capturados tendrá información más útil, pero provocará las correspondientes peticiones
de operaciones de búsqueda, que pueden influir en la captura.
11. Permitir la resolución de nombres de transporte: Este botón permite controlar si Ethereal
traduce o no los números de puerto del protocolo.
Terminada la configuración de la ventana con las opciones que requerimos, al presionar el botón
OK; comenzará la captura de paquetes, si se presiona CANCEL, no se capturará ningún paquete y
se regresará al estado anterior.
Durante la captura, aparecerá la caja de diálogo que muestra la evolución de la captura de datos
(Fig. 1.38)

Fig. 1.38 Evolución de la captura

1.10.3 VISUALIZACIÓN DE LOS RESULTADOS:
Una vez realizada la captura de los datos, toda la secuencia de estos paquetes aparecerá en los
marcos de visualización. Ethereal proporciona una serie de herramientas que facilitan esta
visualización.
La forma más directa de visualizar los resultados consiste en hacer clic en el paquete del que se
desee obtener más información, 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 información acerca de los paquetes. Por defecto las columnas que
aparecen son las mostradas en la Fig. 1.39

1 2 3 4 5 6
(1) Número de paquete; (2) Información temporal de la captura del paquete (fecha, hora, etc.); (3) Dirección fuente; (4)
Dirección destino; (5) Protocolo empleado por el paquete; (6) Información adicional.
Fig. 1.39 Distribución de las columnas de Ethereal

La información de estas columnas varia de acuerdo a las opciones del menú que elijamos a
través del menú Edit -> Preferences. Se pueden añadir o quitar columnas con información adicional
o variar el orden en que éstas se muestran.


INICTEL

Una vez se ha seleccionado un paquete en una fila, la información 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 información 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 información 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 análisis del mismo, o compararlo
con otro, se puede seleccionar y por medio de la opción de menú Display ->Show packet in New
Window. El paquete seleccionado aparecerá en una nueva ventana. También se puede acceder a
este menú por medio del menú contextual que aparece al hacer clic con el botón derecho en el
paquete seleccionado.

2

3
Fig. 1.40 Ventanas de información.

Otras herramientas útiles a la hora de trabajar con los paquetes visualizados son las de buscar o
ir hacia un paquete con un número concreto. Esto se hace por medio de los menús Edit->Find frame,
y Edit->Go to Frame. También se puede marcar un paquete por medio de la opción de menú Edit->
Mark Frame (para retirar el marcado o seleccién, se debe seleccionar el paquete marcado y volver a
seleccionar la opción de menú Edit -> Mark Frame)

1.10.4 DEFINICIÓN DE FILTROS DE LECTURA:
Ethereal permite filtrar la información acerca de los paquetes capturados, tanto en el momento
de la captura de los mismos como en la visualización. Ethereal utiliza la misma sintaxis para la


INICTEL

definición de filtros que la orden de Unix tcpdump. La descripción que se ofrece a continuación no es
más que una adaptación de la información que aparece en la página man de tcpdump.
Un filtro de captura consiste en un conjunto de expresiones primitivas conectadas mediante los
operadores lógicos and/or y opcionalmente precedidos por not:
[not] primitiva [and|or [not] primitiva ...]
• tcp port 23 and host 10.0.0.5
Captura tráfico telnet (puerto 23) desde y hacia el host 10.0.0.5.
• tcp port 23 and not host 10.0.0.5
Captura tráfico 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 tráfico generado (src) o recibido (dst) por un <host>, indicando su dirección
IP o su nombre. Si no se especifica ni src ni dst, se seleccionan todos los paquetes cuya
dirección origen o destino coincide con la del computador especificado.
• ether [src|dst] host <ehost>
Permite filtrar basándose en la dirección física (Ethernet). Como antes, se puede indicar src o
dst para capturar sólo el tráfico saliente o entrante.
• gateway host <host>
Permite filtrar paquetes que usan al <host> como un gateway (router). Es decir, paquetes
cuya dirección física (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 basándose en las direcciones de red. Adicionalmente, se
puede especificar un máscara de red o el prefijo CIDR cuando sea diferente al de la propia
máquina 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 sólo a los paquetes de un protocolo (TCP o UDP), o sólo 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

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 evalúa a True si se cumple la relación. relop es una de las
siguientes: >, <, >=, <=, =, !=, y expr is una expresión aritmética compuesta por constantes
enteras (expresadas en la sintaxis estándar 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 número de bytes del
campo de interés; 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 tráfico multicast
ip[0] & 0xf != 5 captura todos los paquetes IP con opciones
ip[6:2] & 0x1fff = 0 captura sólo datagramas no fragmentados y el primer fragmento de un
datagrama.
Esta comprobación se aplica implícitamente 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 tráfico 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 tráfico entre el localhost y hosts en Berkeley: net ucb-ether
• Para capturar todo el tráfico ftp a través del router snup: gateway snup and (port ftp or ftp-
data)
• Para capturar los paquetes de establecimiento y cierre de cada conexión 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 difusión o multidestino que no han sido enviados
mediante una difusión o dirección 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

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
• NUMERACIÓN BINARIA, HEXADECIMAL
http://www.monografias.com/trabajos14/sistdigital/sistdigital.shtml


Análisis de Protocolos

Más contenido relacionado

La actualidad más candente (20)

Similar a Análisis de Protocolos (20)

Más de Jorge Arroyo (20)

Último (20)

Análisis de Protocolos