ejercicios 1 al 20 - cuaderno de bitacora de eidansoft | … · · 2010-11-26-i ttl tiempo de...

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP

Página 1 del ejercicio1.doc

Ejercicio 1: En nuestro PC hemos abierto una ventana MS-DOS y hemos ejecutado los siguientes comandos: C:\WINDOWS>ipconfig Configuración IP de Windows 98 0 Ethernet adaptador : Dirección IP . . . . . . . . . . . . . : 172.26.0.2 Máscara de subred . . . . . . . . . . : 255.255.0.0 Puerta de enlace predeterminada . . . : 172.26.0.1 C:\WINDOWS>ping Uso: 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. C:\WINDOWS>ping -n 1 -l 15 172.26.0.3 Haciendo ping a 172.26.0.3 con 15 bytes de datos: Respuesta desde 172.26.0.3: bytes=15 tiempo=1ms TDV=128 Estadísticas de ping para 172.26.0.3: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: Mínimo = 1ms, máximo = 1ms, promedio = 1ms C:\WINDOWS> ¿Qué tipo de tarjeta de red tenemos instalada? Ethernet ¿Cuál es la IP de nuestro PC? Nuestra dirección IP es la 172.26.0.2 ¿A que clase de red pertenece nuestra IP? A una red de clase B, pues en binario nuestra IP empieza por “10” ¿Se ha hecho “subnetting” en nuestra red? No, pues la máscara de subred es 255.255.0.0, que es lo normal en las redes de tipo B. ¿Cuál es el rango de direcciones IP válidas (asignables a estaciones) de nuestra red? Del 172.26.0.1 al 172.26.255.254, que son 65534 en total. ¿Puede tener un host de nuestra red la IP 172.26.0.0? No. La dirección IP con el campo de host completamente a cero es una dirección reservada para nombrar a la red a la que pertenecemos. ¿Puede tener un host de nuestra red la IP 172.26.255.255? No. La dirección IP con todos los bits a 1 en el campo de host es la dirección de broadcast dirigido. Si enviamos un datagrama a esa dirección queremos expresar que ese datagrama está dirigido a todas las direcciones que forman parte de dicha red. ¿Cuál es nuestro router por defecto? El 172.26.0.1 ¿Es obligatorio que el router tenga asignada la dirección IP válida más baja del la red? No. En nuestra red se ha hecho así, pero es una costumbre y no algo obligatorio. ¿Puede que existan otros routers en nuestra red? Sí. Además del router por defecto que ya conocemos, podrían existir otros routers en nuestra red.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Qué hace el comando PING cuando lo ejecutamos sin parámetros? Nos muestra una pantalla de ayuda con la forma de usarlo y el significado de los diferentes opciones que podemos utilizar al invocar dicho comando. ¿Para que sirve el comando PING? El comando PING es pequeño programa (una utilidad) que se encuentra disponible en todos los equipos en los que se tenga implementado el protocolo TCP/IP. Básicamente, el objeto del programa PING es comprobar si desde su estación es posible el intercambio (envío y recepción) de datagramas IP con otra estación que el usuario determine. ¿Cómo comprueba el comando PING si es posible el intercambio de datagramas con otra estación? El programa PING envía, a la estación destino que el usuario determine, un mensaje especial del protocolo ICMP, llamado mensaje de “petición de eco”. Cuando la estación destino reciba y procese ese mensaje de “petición de eco” generará otro mensaje del protocolo ICMP, concretamente el mensaje de “respuesta de eco”, cuyo destinatario será la estación desde la que se envió el mensaje de “petición de eco”. ¿Qué significa el acrónimo ICMP? “Internet Control Message Protocol” (Protocolo de Mensajes de Control de Internet). ¿En que se encapsulan los mensajes ICMP para poder llegar a su destino? Para poder viajar por la Internet (InterNetwork o InterRed), los mensajes ICMP se encapsulan dentro de un paquete IP. ¿Tienen otro nombre los paquetes IP? “Datagrama IP” o simplemente “datagrama”, si no es posible confundirse con otro tipo. ¿Contienen siempre los datagramas IP mensajes ICMP? No. Los datagramas IP pueden contener datos del protocolo ICMP pero también datos de otros muchos protocolos, siendo TCP y UDP unos de los más habituales. ¿En qué se van a encapsular los datagramas IP que enviemos desde nuestro PC? En una trama, la cual será enviada al medio físico por la tarjeta de red Ethernet de nuestro PC. ¿Es lo mismo una trama Ethernet que una trama IEEE 802.3? No, pero son muy similares. De hecho, lo que ocurre es que la especificación IEEE 802.3 se hizo de tal forma que incluyese a la especificación Ethernet. ¿Son idénticos los 64 bits que preceden a la dirección MAC destino en las tramas Ethernet y en las tramas IEEE 802.3? Sí. Esos 64 bits son en ambos casos 62 bits de valor “10101010.......101010” seguidos de un par de bits “11”. Lo que pasa es que Ethernet llama preámbulo a esos 64 bits, mientras que IEEE 802.3 los estructura en 7 octetos de preámbulo seguido de un octeto que hace de SFD, “Start of Frame Delimiter” (Delimitador de Inicio de Trama). ¿Puede recibir y enviar una tarjeta Ethernet ambos tipos de tramas, Ethernet e IEEE 802.3? Sí, pues tienen una estructura completamente compatible. ¿Cuál es la longitud máxima de los datos de nivel superior que pueden llegar a contener las tramas Ethernet e IEEE 802.3? 1500 octetos en ambos casos. ¿Dónde está entonces la diferencia entre ambos tipos de tramas? En ambos tipos de tramas, en la misma posición, justo detrás de la dirección MAC origen, hay un campo de 16 bits que Ethernet denomina “Ethertype” e IEEE 802.3 llama “Tipo/Longitud”. El objeto de que el campo de IEEE 802.3 tenga ese nombre “doble” es conseguir la compatibilidad con Ethernet y considerar las tramas Ethernet como un caso particular de trama IEEE 802.3. ¿Cómo sabe una estación que lo que ha recibido una trama IEEE 802.3 y no una trama Ethernet? Si el valor del campo “Tipo/Longitud” es igual o inferior a 1500 (en decimal), puede considerarse como un valor apropiado de la “Longitud” de los datos contenidos en la trama, y no puede tratarse de un valor apropiado para el “Tipo” (ni el “Ethertype”) de los datos contenidos en la trama. Es decir, en ese caso podríamos decir que lo que se ha recibido es una trama IEEE 802.3 con un campo “Tipo/Longitud” que hace el papel de “Longitud”. ¿Cómo sabe una estación que lo que ha recibido una trama Ethernet y no una trama IEEE 802.3? Si el valor del campo “Tipo/Longitud” es superior a 1500 (en decimal), no puede considerarse como un valor apropiado de la “Longitud” de los datos contenidos en la trama, así que debe tratarse de un valor apropiado para el “Tipo” (o el “Ethertype”) de los datos contenidos en la trama . Es decir, en ese caso podríamos decir que lo que se ha recibido es una trama Ethernet con un “Ethertype” o bien que se ha recibido una trama IEEE 802.3 con un campo “Tipo/Longitud” que hace el papel de “Tipo”, las cuales sí que son completamente iguales.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Cuál es exactamente la comprobación que le debemos hacer al campo “Ethertype” de una trama para saber que se trata de una trama Ethernet (o la IEEE 802.3 en la que el campo “Tipo/Longitud” hace el papel de campo “Tipo”)? Hemos dicho que se debe comprobar que sea mayor de 1500, pero en realidad basta con comprobar que sea mayor o igual que 0x600 (1536 en decimal), ya que están prohibidos los valores “Ethertype” entre 1501 y 1536 (inclusive). Esto se hizo para tener que comprobar sólo el valor del octeto más significativo del campo “Ethertype” y no los dos octetos. A continuación se muestra una ventana del analizador de protocolos “Optiview Protocol Expert Demo” en la que aparece el tráfico que se ha generado en nuestra red cuando hemos ejecutado el comando PING descrito anteriormente. A esta ventana se la llama ventana o vista de captura (“capture view”).

¿Con qué equipo queremos comprobar si es posible intercambiar paquetes IP? Con el equipo 172.26.0.3, que es la dirección IP que hemos usado en el comando PING.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿A que se denomina coloquialmente “hacer PING” al equipo “X”? A utilizar el programa PING para enviar al equipo “X” unos mensajes ICMP de “petición de eco” y comprobar si éste nos devuelve los correspondientes mensajes ICMP de “respuesta de eco”, lo cual confirmaría que es posible el intercambio de paquetes IP con el equipo “X” a través de la Internet. ¿Ha intervenido el router en el PING que hemos hecho? No, porque le hemos hecho ping a un host de nuestra misma red. ¿Cuántos mensajes ICMP le hemos enviado al otro host con el comando PING? Hemos usado el comando PING con la opción “–n” con el parámetro 1 (uno) para generar sólo un mensaje ICMP de “petición de eco”. ¿Ha respondido el host destino al mensaje ICMP que le hemos enviado? Sí, pues la salida del comando PING indica “Recibidos=1” ¿Cuál es el tiempo de vida del mensaje ICMP que nos ha llegado a nosotros? 128, pues así lo indica la salida del comando PING al decirnos “TDV=128”. ¿Le hemos dado al comando PING alguna indicación acerca del tamaño del mensaje ICMP que debe enviar? Sí, pues la opción “–l” con el parámetro 15 fuerza a que los datos opcionales del mensaje ICMP generado tengan una longitud de 15 octetos exactamente. La salida del comando PING también nos confirma este hecho con la línea “Haciendo ping a 172.26.0.3 con 15 bytes de datos:” ¿Cuántas tramas se han capturado? En la parte superior de la vista de captura aparece un listado de tramas en el que sólo se ven dos tramas. Además, el título de la ventana también nos informa de este hecho: (2 frames total) ¿Cuál de las tramas aparece decodificada en la parte central de la vista de captura? La primera de las tramas, que es la que aparece resaltada y tiene un ID (identificador) de 0. Nótese que el analizador le asigna un ID a cada trama conforme las va capturando. ¿Cuál es nuestra dirección MAC? 00C026260D14, que es la MAC “Source” de la primera trama. ¿Cuál es la MAC del host al que hemos hecho PING? 0004758A7729, que es la MAC “Destination” de la primera trama. ¿Nos está decodificando el analizador la trama como si fuera de tipo Ethernet? Sí, pues nos presenta el campo que viene detrás de las direcciones MAC destino y origen como un campo “Ethertype”. Es cierto que también podría habernos mostrado dicho campo como si fuese el campo “Tipo/Longitud” de las tramas IEEE 802.3, pero haciendo mención de que en este caso hay que interpretar dicho campo como “Tipo” y no como “Longitud”. Esta última alternativa no es frecuente que la implementen los analizadores, aunque teóricamente es posible. Lo normal es que el analizador muestre únicamente el campo “Tipo/Longitud” únicamente cuando tiene el sentido de “Longitud” y que cuando tenga el sentido de “Tipo” opte por mostrar el campo “Ethertype”. ¿Siempre que hacemos un PING a otro host se genera una trama destinada a dicho host? No. Sólo es así cuando el host destino pertenece a nuestra misma red (dominio de broadcast) y es posible enviarle una trama directamente. En los demás casos la trama debe ir dirigida a un router. ¿Qué tiempo de vida tiene el datagrama que hemos enviado? 32, según aparece en el campo “Time to Live” de la cabecera IP. ¿Es posible hacer un PING que genere un datagrama con un tiempo de vida menor? Si, por ejemplo, el comando “ping -n 1 -l 15 –i 5 172.26.0.3” habría generado un datagrama con un tiempo de vida de valor 5. ¿Habría llegado a su destino el datagrama que hemos enviado si le hubiésemos puesto un tiempo de vida de valor 1? Sí, porque el datagrama va ser enviado directamente a su destino sin pasar por ningún router. Un router decrementa en 1 el tiempo de vida de los paquetes que recibe y nunca envía un paquete con tiempo de vida 0. ¿Cuál es el tiempo de vida del paquete que nos ha enviado el host 172.26.0.3? Como el paquete recibido no ha pasado por ningún router, quiere decir que el 172.26.0.3 nos envió el paquete con un tiempo de vida de 128, que es el TTL que nos muestra el comando PING en su salida por pantalla. ¿De que tipo son los mensajes ICMP que genera el comando PING? De tipo 8, tal y como se puede ver en el campo “Type” que muestra el analizador dentro de la zona del panel del medio de la vista de captura en la que aparece decodificado el mensaje ICMP. El tipo 8 es un mensaje de petición de eco (Echo Request).

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Muestra el analizador de protocolos la parte de la trama anterior a la dirección MAC destino? No. Al ser una parte común a todas las tramas y que tiene una longitud fija (64 bits) y un valor también fijo, el analizador no la muestra en ningún sitio. De hecho, esos 64 bits no se contabilizan a la hora de medir el tamaño de las tramas (“Size”). Hay que tener en cuenta que la misión de estos bits es permitir al receptor sincronizarse y puede ocurrir que no se puedan leer correctamente los primeros bits de estos 64 bits con que empiezan las tramas, sin que esto suponga una situación de error, así que es por eso que no se suelen contabilizar a la hora de “medir” las tramas. ¿Cuántos octetos mide en total la trama que hemos enviado? 64 octetos, tal y como se muestra en la columna “Size” del listado de tramas. Otra forma de conocer el tamaño de la trama es contar los octetos que aparecen en la parte inferior de la vista de captura, que en este caso son 4 filas de 16 octetos cada una lo cual hace el total de 64 que habíamos dicho. Nótese que, tal y como hemos dicho antes, no se consideran para nada los 64 bits iniciales que tienen las tramas antes de la dirección MAC destino. ¿Cuál es el último campo de la trama que muestra decodificada el analizador? El campo FCS (Frame Check Sequence), que tiene el valor 0x0CB05EA3 (el prefijo 0x delante de un número indica que es hexadecimal). ¿Qué tamaño tiene el datagrama que hemos enviado? 43 octetos, tal y como muestra el campo “Total Length” del encabezado IP. ¿Qué longitud tiene la cabecera IP del datagrama que hemos enviado? El campo “Header Length” tiene un valor de 5 (“0101” en binario), lo cual quiere decir que la cabecera tiene 5 palabras de 32 bits, que son 20 octetos, tal y como nos dice el analizador de protocolos. ¿Tiene opciones la cabecera del datagrama que hemos enviado? No. Una cabecera IP sin opciones mide 20 octetos, que es justo lo que mide esta cabecera. ¿Cómo sabe el analizador de protocolos que detrás de la cabecera IP viene un mensaje ICMP? Porque el campo “Protocol ID” de la cabecera IP vale 1, que es el identificador reservado para ICMP. ¿Cómo sabe el analizador de protocolos que detrás de la cabecera del datagrama vienen 23 octetos de datos que forman parte del datagrama? Porque 23 es el resultado de restarle a la longitud total del datagrama (que es 43) la longitud de la cabecera del datagrama (que es 20). ¿Cómo sabe el analizador de protocolos que son 15 el número de octetos que componen los datos opcionales que forman parte del mensaje ICMP de petición de eco que hemos enviado? Porque sabe que el mensaje ICMP de petición de eco tiene una cabecera fija de 8 octetos, seguida de los datos opcionales. Por tanto, restando 8 a los 23 octetos que mide el mensaje ICMP completo, se obtiene que 15 son los octetos de que hay como datos opcionales. ¿Cuánto mide el campo FCS de las tramas Ethernet? 4 octetos. ¿Por qué aparecen 3 octetos en la trama, justo cuando acaba el datagrama, detrás de los datos opcionales del mensaje ICMP? Son 3 octetos de relleno que ha colocado ahí la tarjeta Ethernet. El motivo es que una tarjeta de red Ethernet nunca debe transmitir una trama de tamaño (“Size”) inferior a 64 octetos o, lo que es lo mismo, conteniendo menos de 46 octetos de datos. Si se le dice a la tarjeta que envíe una trama conteniendo menos de 46 octetos, la tarjeta completa los datos con tantos octetos de relleno como sean necesarios hasta alcanzar los 46 octetos de datos, de forma que la trama completa mida 64 octetos en total. En el ejemplo el datagrama contenido en la trama mide 43 octetos, que sumados a los 3 octetos de relleno dan un total 46 octetos contenido en la trama, que sumados a los 14 octetos de cabecera de trama y a los 4 octetos de cola de trama nos dan los 64 octetos de longitud minina que debe tener la trama. ¿Qué número de octetos de datos puede contener como máximo una trama Ethernet? 1500 octetos. Al número de octetos de datos puede contener como máximo una trama de una determinada tecnología de red física se le denomina MTU (Maximum Transfer Unit). ¿Cuál es la longitud máxima de una trama Ethernet? 1518 octetos. Este resultado se obtiene al sumarle los 14 octetos de la cabecera de la trama Ethernet y los 4 octetos de la cola de la trama Ethernet a los 1500 octetos de datos que puede contener como máximo la trama Ethernet. Nuevamente, no estamos considerando los 64 bits iniciales previos a la dirección MAC destino. ¿Cómo sabe el analizador que la trama Ethernet contiene un datagrama IP? Porque el campo “Ethertype” tiene el valor 0x800 (2048 en decimal), que es el código que indica que el contenido de la trama es un datagrama IP.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Cuáles son los 5 primeros caracteres de los datos opcionales del mensaje ICMP que hemos enviado? Los 5 primeros caracteres del campo “Optional Data” son “abcde”, pues el contenido de dicho campo puede verse en formato ASCII en la posición 0x2A del panel inferior de la ventana de captura. ¿Es posible enviar un mensaje ICMP de “petición de eco” que no contenga datos opcionales? Sí, pues como su propio nombre indica, estos datos son opcionales y pueden omitirse. ¿Cuál debe ser el contenido de los datos opcionales de los mensajes ICMP de “petición de eco”, caso de que existan esto datos? El contenido que desee poner el que los envía. Según hemos visto, el programa PING de Windows 98 rellena estos datos con la cadena “abcdefghijk...”, sin embargo los programas PING de otros sistemas operativos o en diferentes versiones de Windows pueden optar por usar otro contenido diferente o incluso darle al usuario la posibilidad de escoger sus propios datos opcionales. ¿Aparece en el datagrama que hemos enviado algún dato que permita conocer la máscara de subred del host al que va dirigido el datagrama? No. Examinando el datagrama IP que hemos enviado, sólo se sabe que la dirección destino pertenece a una red de clase B, pero se ignora si se ha hecho o no “subnetting” en dicha red, por lo que no se puede conocer la máscara de subred de dicho host. ¿Hemos permitido que se fragmente el datagrama que hemos enviado? Sí. El segundo bits de los “Flags”, que es el bit DF (Don´t Fragment), está desactivado (a cero), luego permitimos que el datagrama pueda fragmentarse, si fuese necesario, en su viaje hacia la red destino. ¿Se ha fragmentado en algún momento el datagrama que hemos enviado? No. El motivo es que la MTU de la única red que ha atravesado era una MTU suficientemente grande como para dar cabida al datagrama completo. ¿Se habría fragmentado el datagrama que hemos enviado si el comando PING hubiese tenido la opción “–l” con el parámetro 1472 en lugar de 15? No. Esa opción habría generado un mensaje ICMP de tipo 8 (Echo Request) con 1472 octetos de datos opcionales, que sumados a los 8 octetos de cabecera que tiene dicho mensaje, nos dan un mensaje ICMP de 1480 octetos de longitud total. El datagrama generado tendría una cabecera de la misma longitud que antes, 20 octetos, que sumados a los 1480 octetos del mensaje ICMP contenido en él nos dan un datagrama de 1500 octetos de longitud total. Precisamente esa es la longitud máxima que pueden tener los datos contenidos en una trama Ethernet, por lo que no sería necesario fragmentar el datagrama. ¿En cuántos fragmentos se habría dividido el datagrama enviado si el comando PING hubiese tenido la opción “–l” con el parámetro 1473 en lugar de 15? En dos fragmentos. ¿Tienen cabecera IP los fragmentos de un datagrama? Sí. La estructura de un fragmento de un datagrama es igual que la estructura de un datagrama completo, salvo que los datos que contienen son una porción del datagrama completo original. En realidad un fragmento de datagrama es también un datagrama, con su parte de cabecera y su parte de datos. ¿Qué son las tramas Ethernet versión II? La última versión de la norma Ethernet es la II, publicada en 1982. Hoy por hoy el término Ethernet se utiliza para referirse a la versión II, aunque no se haga mención expresa a la versión. Esto es así porque no hay lugar a confusión al haber dejado de usarse la versión anterior. ¿Cómo se suele denominar, de forma genérica, a la norma IEEE 802.3? Se la suele llamar “Ethernet”, a pesar de que sabemos que no son exactamente iguales. ¿Qué es una PDU? Una PDU es una unidad de datos de protocolo (“Protocol data Unit”). No es más que un mensaje de los que se intercambian las entidades que “hablan” un determinado protocolo. ¿Cuántas PDUs nos está mostrando el analizador en el panel central de la ventana de captura? Tres PDUs, encapsuladas unas dentro de otras. Por un lado podemos ver una PDU del protocolo ICMP, concretamente un mensaje ICMP de “petición de eco” que ocupa, en este caso, 23 octetos. Esta PDU está encapsulada dentro de otra PDU, la PDU del protocolo IP (un paquete IP), la cual ocupa 46 octetos (20 de cabecera más 23 del mensaje ICMP). Por último podemos ver como este datagrama IP está encapsulado dentro de una trama (la PDU del protocolo Ethernet). Esta trama ocupa 64 octetos (14 de cabecera, 4 de cola, 46 de datos y 3 de relleno) por supuesto sin contra con los bits de preámbulo que preceden al campo de dirección MAC destino.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Ejercicio 2: En nuestro PC hemos abierto una ventana MS-DOS y hemos ejecutado los siguientes comandos: C:\WINDOWS>ipconfig Configuración IP de Windows 98 0 Ethernet adaptador : Dirección IP . . . . . . . . . . . . . : 172.26.0.2 Máscara de subred . . . . . . . . . . : 255.255.0.0 Puerta de enlace predeterminada . . . : 172.26.0.1 C:\WINDOWS>arp -a Interfaz: 172.26.0.2 on Interface 0x1000002 Dirección IP Dirección física Tipo 172.26.0.3 00-04-75-8a-77-29 dinámico C:\WINDOWS>ping -n 1 172.26.0.1 Haciendo ping a 172.26.0.1 con 32 bytes de datos: Respuesta desde 172.26.0.1: bytes=32 tiempo=1ms TDV=64 Estadísticas de ping para 172.26.0.1: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 1ms, máximo = 1ms, promedio = 1ms C:\WINDOWS>arp -a Interfaz: 172.26.0.2 on Interface 0x1000002 Dirección IP Dirección física Tipo 172.26.0.1 00-20-ea-18-d1-51 dinámico 172.26.0.3 00-04-75-8a-77-29 dinámico C:\WINDOWS> ¿A qué equipo le hemos hecho PING? Al equipo que tiene la dirección IP 172.26.0.1, que es el router que usamos para que nos enrute los paquetes dirigidos a redes distintas de la nuestra. Sabemos esto porque el comando “ipconfig” nos dice que el 172.26.0.1 es nuestra “puerta de enlace predeterminada”. ¿Forma parte de nuestra red la dirección IP 172.26.0.1? Sí. Como nuestra dirección IP es 172.26.0.2 y nuestra máscara es 255.255.0.0, sabemos que todas las direcciones IP cuyos dos primeros octetos sean 172 y 26 pertenecen a nuestra misma red. ¿Conocemos la dirección MAC del equipo al que le vamos a hacer PING? No. En la caché ARP, la cual hemos consultado con el comando “arp –a”, no aparece una entrada para la dirección IP 172.26.0.1 ¿Por qué no está vacía la caché ARP? La caché ARP contiene la dirección MAC del host 172.26.0.3 porque anteriormente habremos tenido alguna comunicación con dicho equipo, lo cuál provocó que se crease dicha entrada. ¿Cómo se vacía la caché ARP de su contenido? Las entradas de la caché ARP tienen un tiempo de caducidad. Si transcurre ese tiempo y la entrada no ha sido utilizada, se borra de la caché. ¿Por qué no se dejan las entradas para siempre en la caché ARP? Porque entonces la caché ocuparía mucho espacio. Además podría ocurrir que un host cambiase su tarjeta de red por otra diferente (con otra dirección MAC), pero sin cambiar de dirección IP. Si las entradas no caducasen, nosotros seguiríamos usando la dirección MAC de la antigua tarjeta de red para comunicarnos con ese host. ¿Cómo vamos a averiguar la dirección MAC del equipo 172.26.0.1? Al solicitarle a nuestro equipo que envíe un datagrama al 172.26.0.1, lo primero que se hace es buscar en la caché ARP una entrada para el 172.26.0.1. Como esta entrada no existe, se va a generar un paquete ARP encapsulado en una trama BROADCAST, pidiéndole al equipo 172.26.0.1 que responda informando acerca de cuál es su dirección MAC. A continuación se muestra una ventana de un analizador de protocolos en la que aparece el tráfico que se ha generado en nuestra red cuando hemos ejecutado el comando PING descrito anteriormente.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Cuántas tramas se han capturado? Cuatro tramas (frames), tal y como aparece en el listado de tramas y en el título de la ventana. ¿Dónde están almacenadas las tramas? Las tramas mostradas por el analizador están almacenadas en un fichero de nombre “c:\archivo.cap” ¿Cuál de las tramas aparece decodificada en la parte central de la vista de captura? La segunda de las tramas, que es la que aparece resaltada y tiene un ID (identificador) de 1. Nótese que el analizador le asigna un ID a cada trama conforme las va capturando. ¿Cuál es nuestra dirección MAC? 00C026260D14, que es la MAC “Source” de la tercera trama (ID 2), que contiene la petición de eco “Echo request” que le hemos hecho al otro equipo. ¿Cuál es la MAC del equipo al que hemos hecho PING? 0020EA18D151, que es la MAC “Source” de la segunda trama (ID 1), que contiene la respuesta ARP que nos ha devuelto el equipo 172.26.0.1 después de recibir nuestra petición ARP. ¿Por qué el analizador muestra en la parte superior de la ventana de captura la dirección MAC “ENI 18D151” en lugar de mostrar “0020EA18D151”? Porque los tres primeros octetos de la dirección MAC identifican al fabricante de la tarjeta, en este caso “EFFICIENT NETWORKS, INC.”, como puede verse en la segunda trama que es la que estamos viendo decodificada. El analizador está sustituyendo esos tres octetos por “ENI”, que es la abreviatura del nombre del fabricante. Esta sustitución sólo la hace en el listado de tramas que nos muestra en la parte superior de la ventana de captura. ¿Cuántos octetos mide en total la primera trama que nos ha llegado? 64 octetos, tal y como se muestra en la columna “Size” del listado de tramas que aparece en la parte superior de la ventana de captura. Otra forma de conocer el tamaño de la trama es contar los octetos que aparecen en la parte inferior de la vista de captura, que en este caso son 4 filas de 16 octetos cada una lo cual hace el total de 64 que habíamos dicho.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Cuál es el tamaño del paquete ARP que nos ha llegado? Un paquete ARP tiene una longitud variable, pues depende de la longitud que tengan las direcciones hardware (direcciones de nivel 2) y las direcciones de protocolo (direcciones de nivel 3). En el caso que nos ocupa, estas longitudes son de 6 octetos para las direcciones MAC de Ethernet y 4 octetos para las direcciones IP, tal y como podemos ver en los campos “Hardware Address Length” y “Protocol Address Length” que nos está mostrando el analizador en la parte central de la ventana. Conociendo esto y como resulta que el resto de campos del paquete ARP que no son direcciones tienen una longitud fija, ya podemos saber la longitud total del mensaje: Campo “Hardware Type”, 2 octetos. Campo “Protocol Type”, 2 octetos. Campo “Hardware Address Length”, 1 octeto. Campo “Protocol Address Length”, 1 octeto. Campo “Operation”, 2 octetos. Campo “Sender Hardware Address”, 6 octetos. Campo “Sender Protocol Address”, 4 octetos. Campo “Target Hardware Address”, 6 octetos. Campo “Target Protocol Address”, 4 octetos. Lo cual hace una longitud total de 28 octetos para el paquete ARP. ¿Qué son los 18 octetos que aparecen a continuación del paquete ARP contenido en la segunda trama que nos muestra el analizador? Son 18 octetos de relleno que mete la tarjeta Ethernet para conseguir que la trama contenga los 46 octetos de datos que debe tener como mínimo. Si a esos 46 octetos le sumamos las direcciones MAC origen y destino, el campo “Ethertype” y el campo “Frame Check Sequence”, tenemos los 64 octetos que aparecen en la columna “Size” que se muestra en la parte superior de la ventana de captura. ¿Por qué valen 0x88 (hexadecimal) los 18 octetos que aparecen a continuación del paquete ARP contenido en la segunda trama que nos muestra el analizador? Pueden tomar el valor que quiera darle la tarjeta Ethernet, pues son octetos de relleno cuyo valor carece de importancia. ¿Por qué llama el analizador “Sender IP Address” al campo “Sender Protocol Address” del paquete ARP que nos está mostrando? Porque sabe que el protocolo de nivel 3 utilizado es IP, puesto que el campo “Protocol Type” vale 0x800 (hexadecimal), que es el código asociado a IP. ¿Por qué llama el analizador “Sender Ethernet Address” al campo “Sender hardware Address” del paquete ARP que nos está mostrando? Porque sabe que el protocolo de nivel 2 utilizado es Ethernet, puesto que el campo “Hardware Type” vale 1, que es código asociado a Ethernet. ¿Cuantos equipos han procesado el paquete ARP que contenía nuestra petición? Todos los equipos conectados a nuestra red que estuviesen funcionando en ese momento habrán procesado nuestra petición, pues iba encapsulada en una trama con dirección MAC destino BROADCAST. No obstante, al procesar el paquete se habrán dado cuenta de que era una petición destinada al equipo 172.26.0.1, por lo que sólo el equipo 172.26.0.1 ha respondido a nuestra petición con un paquete ARP de respuesta en el que nos comunica su dirección MAC. ¿Podríamos haber encapsulado la petición ARP en una trama con una MAC destino que no fuese BROADCAST? No, pues precisamente el motivo de nuestra petición es que ignoramos la dirección MAC del destino. ¿Qué sentido tiene hacerle PING al router? A veces no podemos acceder al exterior de nuestra red y queremos averiguar la causa. Si al hacerle PING al router obtenemos una respuesta, podemos descartar que la causa de nuestros problemas sea que el router se encuentre desconectado. ¿Cuál es el tiempo de vida del paquete que nos ha enviado el equipo 172.26.0.1? Como el paquete recibido nos ha llegado directamente desde el equipo 172.26.0.1, sin pasar por ningún router intermedio, quiere decir que el 172.26.0.1 nos envió el paquete con un tiempo de vida de 64, que es el tiempo de vida (TDV = 64) que nos muestra el comando PING en su salida. ¿Cuántos mensajes ICMP de petición de eco hemos generado? Sólo uno pues hemos usado el comando PING con la opción –n y el parámetro 1. ¿Habríamos generado nosotros una petición ARP si le hubiésemos hecho PING al 172.26.0.3? No, pues la MAC de ese equipo ya estaba en la caché ARP. ¿Cuántas entradas hay en la caché ARP después de hacer el PING al 172.26.0.1? Hay dos entradas. Está la entrada que había antes de haber hecho PING y la que se ha introducido nueva al haber averiguado la dirección MAC del equipo con dirección IP 172.26.0.1.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Ha generado el equipo 172.26.0.1 una petición ARP para averiguar nuestra dirección MAC? No. El equipo 172.26.0.1 averiguó nuestra dirección MAC cuando le llegó nuestra petición ARP. En ese momento decidió almacenar nuestra dirección MAC en su caché ARP, pues era muy probable que, si le habíamos hecho una petición ARP, muy pronto le iba a hacer falta conocer nuestra dirección MAC para comunicarse con nosotros. Este comportamiento “previsor” evita generar demasiadas peticiones ARP, las cuales, al ir en tramas BROADCAST, son procesadas por todos los equipos de la red. ¿De qué nivel es el protocolo ARP? Está comprendido entre los niveles 2 y 3 del modelo OSI. Se apoya en un protocolo de nivel 2 para hacer llegar sus peticiones y respuestas de un host a otro. Sirve a los protocolos de nivel 3 para convertir las direcciones de nivel 3 en direcciones de nivel 2. ¿Podemos forzar la introducción de una entrada en la caché ARP? Sí. A continuación se muestra cómo introducir una entrada que asocia la dirección IP 172.26.0.1 con la dirección MAC 0020EA18D151, haciendo uso del comando “arp –s” de MS-DOS. C:\WINDOWS>arp Muestra y modifica las tablas de traducción de direcciones IP a físicas usadas por el protocolo de resolución de direcciones (ARP). ARP -s dir_inet dir_eth [dir_if] ARP -d dir_inet [dir_if] ARP -a [dir_inet] [-N dir_if] -a Muestra las entradas actuales de ARP preguntando por los datos del protocolo. Si se especifica dir_inet, se muestran las direcciones IP y Física sólo para el equipo especificado. Cuando ARP se utiliza en más de una interfaz de red, entonces se muestran entradas para cada tabla ARP. -g Lo mismo que -a. dir_inet Especifica una dirección internet. -N dir_if Muestra las entradas de ARP para las interfaces de red especificadas por dir_if. -d Elimina el host especificado por dir_inet. -s Agrega el host y asocia la dirección internet dir_inet con la dirección física dir_eth. La dirección física se especifica con 6 bytes en hexadecimal separados por guiones. La entrada es permanente. dir_eth Especifica una dirección física. dir_if Si está presente, especifica la dirección Internet de la interfaz con la tabla de traducción de direcciones a modificar. Si no se especifica, se utiliza la primera interfaz aplicable. Ejemplo: > arp -s 157.55.85.212 00-aa-00-62-c6-09 .... Añade una entrada estática. > arp -a .... Muestra la tabla ARP. C:\WINDOWS>arp -s 172.26.0.1 00-20-EA-18-D1-51 C:\WINDOWS>arp –a Interfaz: 172.26.0.2 on Interface 0x1000002 Dirección IP Dirección física Tipo 172.26.0.1 00-20-ea-18-d1-51 estático C:\WINDOWS> ¿Es posible distinguir las entradas que se han introducido en la tabla mediante el protocolo ARP de otras entradas que hayamos creado nosotros manualmente? Sí. El comando “arp –a” nos muestra las entradas que hemos introducido manualmente catalogándolas como entradas de tipo “estático”, lo cual quiere decir que no serán eliminadas de la caché al pasar un cierto tiempo. Las entradas de tipo “dinámico” son entradas que se han averiguado mediante el protocolo ARP. ¿Se hacen peticiones ARP para las direcciones IP de tipo “estático”? No. Antes de hacer una petición ARP se mira en la caché ARP para ver si ya existe esa entrada. Caso de existir ya esa entrada no se hace la petición ARP, sin importar si la entrada era de tipo “estático” o “dinámico”. ¿Se guardarán en la caché ARP entradas de tipo “dinámico” con las direcciones MAC de los hosts que no pertenecen a nuestra misma red? No. Esas direcciones MAC no nos servirían de nada, pues una trama emitida en nuestra red nunca podrá llegar a otra red distinta. Por el mismo motivo, además de no tener sentido, resultaría imposible averiguar mediante peticiones ARP las direcciones MAC de hosts que se encuentren en una red diferente a la nuestra, pues no les llegarían las tramas conteniendo las peticiones ARP.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Ejercicio 3: En nuestro PC hemos abierto una ventana MS-DOS y hemos ejecutado los siguientes comandos: C:\WINDOWS>ipconfig Configuración IP de Windows 98 0 Ethernet adaptador : Dirección IP . . . . . . . . . . . . . : 172.26.0.2 Máscara de subred . . . . . . . . . . : 255.255.0.0 Puerta de enlace predeterminada . . . : 172.26.0.1 C:\WINDOWS>arp -s 172.26.0.1 00-20-EA-18-D1-51 C:\WINDOWS>arp –a Interfaz: 172.26.0.2 on Interface 0x1000002 Dirección IP Dirección física Tipo 172.26.0.1 00-20-ea-18-d1-51 estático C:\WINDOWS>ping 172.26.0.1 Haciendo ping a 172.26.0.1 con 32 bytes de datos: Respuesta desde 172.26.0.1: bytes=32 tiempo=2ms TDV=64 Respuesta desde 172.26.0.1: bytes=32 tiempo<10ms TDV=64 Respuesta desde 172.26.0.1: bytes=32 tiempo<10ms TDV=64 Respuesta desde 172.26.0.1: bytes=32 tiempo<10ms TDV=64 Estadísticas de ping para 172.26.0.1: Paquetes: enviados = 4, Recibidos = 4, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 0ms, máximo = 2ms, promedio = 0ms C:\WINDOWS>arp –a Interfaz: 172.26.0.2 on Interface 0x1000002 Dirección IP Dirección física Tipo 172.26.0.1 00-20-ea-18-d1-51 estático C:\WINDOWS> ¿A qué equipo de nuestra red le hemos hecho PING? Al que tiene la dirección IP 172.26.0.1, que es el router que usamos para que nos enrute los paquetes dirigidos a redes distintas de la nuestra. Sabemos esto porque el comando “ipconfig” nos dice que el 172.26.0.1 es nuestra “puerta de enlace predeterminada”. ¿Está vacía la caché ARP antes de hacer el PING? No. Contiene una entrada para la dirección IP 172.26.0.1, la cual ha sido introducida de forma estática mediante el comando “arp –s”. ¿Se habrá generado una petición ARP para averiguar la dirección MAC del equipo 172.26.0.1? El equipo 172.26.0.1 forma parte de nuestra red, por lo que es accesible directamente enviándole una trama a su propia dirección MAC. Antes de generar una petición MAC que nos permita averiguar la dirección MAC asociada a una determinada IP, lo primero que hace el protocolo ARP es comprobar si ya existe en la caché ARP una entrada asociada a dicha IP. Como en este caso ya existe esa entrada, no es necesario realizar la petición ARP. ¿Nos hemos equivocado al introducir la dirección MAC de la entrada estática de la caché ARP? No. La hemos debido introducir correctamente, pues nos han respondido al PING. De haber introducido una dirección MAC errónea, el equipo 172.26.0.1 no habría recibido el mensaje ICMP. ¿Cuántos mensajes ICMP le hemos enviado al otro equipo? Al no haber usado la opción –n del comando PING, éste ha enviado los que tiene configurados por defecto. A juzgar por la información mostrada en pantalla, el comando PING de MS-DOS envía 4 mensajes ICMP de petición de eco “Echo request” a menos que se le indique otra cosa. ¿Ha respondido el equipo a todos los mensajes ICMP de petición de eco? Sí. El comando PING indica que se han enviado 4 mensajes y se han recibido otros 4 mensajes. A continuación se muestra una ventana de un analizador de protocolos en la que aparece el tráfico que se ha generado en nuestra red cuando hemos ejecutado el comando PING descrito anteriormente.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Cuál de las tramas aparece decodificada en la parte central de la vista de captura? La segunda de las tramas, que es la que aparece resaltada y tiene un ID (identificador) de 1. Nótese que el analizador le asigna un ID a cada trama conforme las va capturando. ¿Cuál es nuestra dirección MAC? 00C026260D14, que es la MAC “Source” de la primera trama (ID 0), que contiene la petición de eco “Echo request” que le hemos hecho al otro equipo. ¿Cuál es la MAC del equipo al que hemos hecho PING? 0020EA18D151, que es la MAC “Source” de la segunda trama (ID 1), que contiene una petición ARP realizada por el equipo con dirección IP 172.26.0.1. ¿Cómo sabe el analizador de protocolos que la segunda trama (ID 1) contiene un paquete ARP? Porque el campo “Ethertype” tiene un valor de 0x806 hexadecimal. ¿Por qué no hemos realizado una petición ARP? Porque la dirección MAC que necesitábamos ya se encontraba en la caché ARP. ¿Por qué nos ha enviado el equipo 172.26.0.1 una petición ARP justo después de recibir nuestro paquete conteniendo una petición de respuesta de eco? El equipo 172.26.0.1 quiere enviarnos a nosotros un paquete con un mensaje ICMP de respuesta de eco. Conoce nuestra dirección IP, la 172.26.0.2, y sabe, gracias a su propia máscara de red, que nosotros estamos en su misma red. Necesita averiguar nuestra dirección MAC y como no la ha encontrado en su caché ha generado una petición ARP para que nosotros le respondamos con una respuesta ARP en la que le informemos de cuál es nuestra MAC. ¿Averiguó el equipo 172.26.0.1 nuestra MAC cuando le llegó el primer mensaje ICMP? No. La llegada de un paquete IP no hace que se cree una entrada en la tabla ARP. ¿Necesita el equipo 172.26.0.1 realizar nuevas peticiones ARP para poder responder a los otros tres mensajes ICMP que le hemos enviado? No. Cuando llegan los restantes mensajes ICMP de petición de eco, el equipo 172.26.0.1 ya tiene en su caché ARP una entrada que le permite averiguar la dirección MAC asociada a la IP 172.26.0.2.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Ejercicio 4: En nuestro PC hemos abierto una ventana MS-DOS y hemos ejecutado los siguientes comandos: C:\WINDOWS>ipconfig /all Configuración IP de Windows 98 Nombre del host . . . . . . . . . . . : zenith.dte.us.es Servidores DNS . . . . . . . . . . . . : 150.214.186.69 150.214.130.15 150.214.4.34 Tipo de nodo . . . . . . . . . . . . . : Difusión Id. de ámbito NetBIOS . . . . . . . . : Enrutamiento IP activado . . . . . . . : No WINS Proxy activado . . . . . . . . . : No Resolución NetBIOS usa DNS . . . . . . : Sí 0 Ethernet adaptador : Descripción . . . . . . . . . . . . . : NDIS 4.0 driver Dirección física . . . . . . . . . . . : 00-E0-7D-7A-5A-94 DHCP activado . . . . . . . . . . . . : No Dirección IP . . . . . . . . . . . . . : 150.214.141.181 Máscara de subred . . . . . . . . . . : 255.255.255.0 Puerta de enlace predeterminada . . . : 150.214.141.1 Servidor WINS primario . . . . . . . : Servidor WINS secundario . . . . . . . : Permiso obtenido . . . . . . . . . . . : Permiso caduca . . . . . . . . . . . . : C:\WINDOWS>arp -a No se encontraron entradas ARP C:\WINDOWS>ping -n 2 -i 20 207.70.7.168 Haciendo ping a 207.70.7.168 con 32 bytes de datos: Respuesta desde 207.70.7.168: bytes=32 tiempo=195ms TDV=235 Respuesta desde 207.70.7.168: bytes=32 tiempo=187ms TDV=235 Estadísticas de ping para 207.70.7.168: Paquetes: enviados = 2, Recibidos = 2, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 187ms, máximo = 195ms, promedio = 191ms C:\WINDOWS>arp -a Interfaz: 150.214.141.181 on Interface 0x1000002 Dirección IP Dirección física Tipo 150.214.141.1 00-00-0c-07-ac-0e dinámico C:\WINDOWS> ¿Cuál es nuestra red? La 150.214.141.0 con máscara 255.255.255.0 ¿Cuál es el rango de direcciones IP de nuestra red? De la 150.214.141.0 a la 150.214.141.255, teniendo en cuenta que la primera y la última son direcciones reservadas que no pueden asignarse a ningún equipo. ¿De que clase es nuestra red? Nuestra red es una subred de la red de tipo B 150.214.0.0, pues la máscara de subred que estamos utilizando no es la 255.255.0.0, sino que es la 255.255.255.0, indicando que se ha hecho subnetting, pidiéndole 8 bits prestados al campo de host. ¿Cuál es nuestro gateway por defecto o “puerta de enlace predeterminada”? El equipo 150.214.141.1 ¿Le hemos hecho PING a un equipo de nuestra misma red? No. Estamos en la subred 150.214.141.0 con máscara de red /24 y el equipo al que le hemos hecho PING es el 207.70.7.168, que evidentemente no tiene los primeros 24 bits iguales a los 24 primeros bits de la subred 150.214.141.0. ¿Qué tiempo de vida tienen los datagramas IP que hemos enviado con el comando PING? Tienen un tiempo de vida de 20, pues eso es lo que hemos querido al usar el comando PING con la opción “–i” acompañada del parámetro 20. A continuación se muestra una ventana de un analizador de protocolos en la que aparece el tráfico que se ha generado en nuestra red debido al comando PING que acabamos de ejecutar.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Cuántos mensajes ICMP hemos enviado? Con la opción –n y el parámetro 2 le solicitamos al comando PING que enviase dos mensajes ICMP de petición de eco. ¿Por qué hemos hecho una petición ARP? Porque el host destino de los PINGs está fuera de nuestra red, lo cual nos obliga a enviar los paquetes al router por defecto. Para enviar los paquetes al router por defecto encapsulados en una trama debemos ponerle a esas tramas como dirección destino la dirección MAC del router. Como en la caché ARP no existe la entrada que nos hace falta, automáticamente se lanza una petición ARP dentro de una trama BROADCAST para que todos la procesen y el que tenga que respondernos (el router en este caso) se de por enterado y nos devuelva una respuesta ARP diciendo cuál su dirección MAC. ¿Cuál es nuestra dirección MAC? Según el comando “ipconfig /all” nuestra dirección MAC es 00-E0-7D-7A-5A-94. Esto coincide plenamente con la dirección MAC “Source” de la primera todas las tramas, que es la petición ARP que le estamos haciendo al router: “ARP Q PA=150.214.141.1”, o lo que es lo mismo “ARP reQuest, Target Protocol Address=150.214.141.1” ¿Cuál es la dirección MAC del router? La segunda trama es la respuesta ARP a nuestra petición ARP. Por tanto el que nos la envía debe ser el router. En dicha trama podemos ver que el campo “Source” es “Cisco 07AC0E”, luego esa es la MAC del router. Si queremos conocer también el valor de los tres primeros octetos, en lugar del nombre del fabricante al cual equivalen, podemos verlos en el “Summary” (resumen) que aparece a la derecha de dicha trama en el listado de tramas. Este resumen nos dice “ARP R HA=00000C07AC0E”, o lo que es lo mismo, “ARP Reply, Sender hardware Address=00000C07AC0E”.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Qué es lo que estamos viendo en el panel central de la ventana de captura? Un trozo de una trama, debidamente decodificado por el analizador. Concretamente se trata de la cuarta trama (ID=3), que es la que se encuentra seleccionada en la lista de tramas que aparece en la parte superior de la ventana. ¿A quién va dirigida la trama con ID=3? A nosotros, pues es nuestra dirección MAC, la 00E07D7A5A94, la que aparece en el campo “Destination” de dicha trama. ¿A quién va dirigido el datagrama IP contenido en la trama con ID=3? A nosotros, pues es nuestra dirección IP, la 150.214.141.181, la que aparece en el campo “Destination Address” de la cabecera del datagrama IP contenido en dicha trama. ¿De donde proviene el datagrama IP contenido en la trama con ID=3? Viene del host al que le hemos hecho el ping, pues es esa dirección IP, la 207.70.7.168, la que aparece en el campo “Source Address” de la cabecera del datagrama IP contenido en dicha trama. ¿A quién corresponde la dirección MAC “Source” de la trama con ID=3? Al router, pues el router el que nos está enviando a nosotros esa trama conteniendo un paquete proveniente de un host que no está en nuestra misma red. ¿Cuál es la dirección MAC del host con dirección IP 207.70.7.168? No podemos saberlo examinando las tramas que se han generado en la red 150.214.141.0 /24. Para averiguarlo habría que capturar las tramas generadas en la red del host 207.70.7.168. ¿Cuál es la máscara de red del host con dirección 207.70.7.168? No lo sabemos. De todas formas, tampoco nos hace falta saber la máscara de red de dicho host para poder enviarle un datagrama IP. Los routers no necesitan tampoco la máscara de red del host destino para poder enrutar correctamente un datagrama. ¿Cuál es el tiempo de vida de los datagramas que hemos recibido? Según la salida del comando PING, el tiempo de vida es 235. Podemos comprobar que, efectivamente, esto es así viendo el valor del campo “Time To Live” de la cabecera del datagrama IP que está contenido en la cuarta trama de la lista (la de ID=3). ¿Cuántos routers han atravesado a lo largo de su camino los datagramas IP que nos ha enviado el host al que le hemos hecho PING? No podemos saber el número exacto, pero seguro que es un número de routers menor que 21. Si los paquetes hubiesen pasado por 21 routers en su camino hacia nosotros, como cada router disminuye en 1 el tiempo de vida, querría decir que el paquete salió del host 207.70.7.168 con un tiempo de vida de 235 (el que tenía al llegar) más 21 (los routers que ha atravesado) que son 256. Esto es imposible, pues es 255 el mayor valor que se le puede dar al campo “Time To Live” cuando se crea un datagrama. ¿Cuántos routers han atravesado, a lo largo de todo su camino por la red, los paquetes que le hemos enviado al host 207.70.7.168? Tampoco se puede saber con las pruebas que hemos hecho, pero sí que podemos asegurar que no han atravesado más de 19 routers. Sabemos que los paquetes fueron enviados con un tiempo de vida igual a 20 y que todos han llegado a su destino, pues su destinatario nos ha enviado los correspondientes mensajes de respuesta de eco. Un tiempo de vida de 20 permite a un paquete atravesar 19 routers y llegar a su destino con un tiempo de vida de 1. No es posible que el paquete atraviese 20 routers, pues en ese caso el router número 20 debería emitir un datagrama IP con tiempo de vida cero, lo cual no está permitido. ¿Han pasado por los mismos routers los paquetes que hemos enviado y los que hemos recibido? No lo sabemos, pero no es obligatorio. En internet, cada paquete es rutado de forma independiente a los demás. De hecho, ni siquiera se puede garantizar que hayan seguido el mismo camino los dos paquetes que le hemos enviado al host 207.70.7.168? ¿Por qué el analizador de protocolos, al decodificar el campo “Type Of Service” contenido en la trama con ID 3, cataloga el valor de sus tres primeros bits como “Flash Override”? Los tres primeros bits del campo “Type Of Service” de la cabecera IP indican la precedencia asignada al datagrama. El significado de los diferentes valores que pueden tomar estos bits se define en la RFC791, que trata de IP (Internet Protocol). El valor 100 corresponde a la precedencia “Flash Override”, que es mayor que “Flash”, “Immediate”, “Priority” y “Routine”. ¿Es posible modificar la forma en que se muestran las tramas en el listado de tramas que aparece en la parte superior de la ventana de captura? Sí. Existen muchas formas de modificar la manera en que el analizador nos presenta el listado de tramas. A veces, seleccionando adecuadamente lo que queremos ver en el listado de tramas, podemos ahorrarnos el tener que examinar la decodificación completa de cada trama en el panel central de la ventana de captura.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


A continuación se muestra otra vez la ventana de captura del analizador, conteniendo las mismas seis tramas que antes, pero habiéndole indicado en el cuadro de diálogo “Capture View Display Options” que debía mostrar las direcciones de red (“Display Network Address”):

¿Qué ventaja tiene esta forma de ver el listado de tramas sobre la anterior? Tiene la ventaja de que ahora podemos ver rápidamente las direcciones IP origen y destino de los datagramas IP contenidos en las tramas. La otra visión nos mostraba siempre las direcciones MAC, por lo que solo veíamos direcciones origen y destino pertenecientes a la misma red en la que se habían capturado las tramas. Antes, si el tráfico era externo a la red siempre una de las direcciones MAC era la dirección MAC de un router de la red en la que nos encontrabamos. Si el contenido de la trama es un paquete ARP y no un paquete IP, el analizador muestra ahora las direcciones IP del “Sender” y del “Target” de dicho paquete ARP, permitiendo ver rápidamente quién está intentando comunicarse con quién a nivel de red. ¿De qué sirven los campos “Identified” y “Sequence Number” en los mensajes ICMP de petición de eco y de respuesta de eco? Sirven para que el receptor de las respuestas de eco pueda asociarlas a las peticiones de eco que ha realizado. Nótese que los valores de los campos “Identified” y “Sequence Number” de la petición de eco de la trama con ID=2 son los mismos que los de la respuesta de eco de la trama con ID=3.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Ejercicio 5: En nuestro PC hemos abierto una ventana MS-DOS y hemos ejecutado los siguientes comandos: C:\WINDOWS>ipconfig /all Configuración IP de Windows 98 Nombre del host . . . . . . . . . . . : caracola Servidores DNS . . . . . . . . . . . . : 193.152.63.197 195.235.113.3 Tipo de nodo . . . . . . . . . . . . . : Difusión Id. de ámbito NetBIOS . . . . . . . . : Enrutamiento IP activado . . . . . . . : No WINS Proxy activado . . . . . . . . . : No Resolución NetBIOS usa DNS . . . . . . : No 0 Ethernet adaptador : Descripción . . . . . . . . . . . . . : Realtek 8139-series PCI NIC Dirección física . . . . . . . . . . . : 00-C0-26-26-0D-14 DHCP activado . . . . . . . . . . . . : Sí Dirección IP . . . . . . . . . . . . . : 172.26.0.2 Máscara de subred . . . . . . . . . . : 255.255.0.0 Puerta de enlace predeterminada . . . : 172.26.0.1 Servidor DHCP . . . . . . . . . . . . : 172.26.0.1 Servidor WINS primario . . . . . . . : Servidor WINS secundario . . . . . . . : Permiso obtenido . . . . . . . . . . . : 15 04 02 22:16:38 Permiso caduca . . . . . . . . . . . . : C:\WINDOWS>arp -a Interfaz: 172.26.0.2 on Interface 0x1000002 Dirección IP Dirección física Tipo 172.26.0.1 00-20-ea-18-d1-51 dinámico C:\WINDOWS>ping -n 1 -i 25 12.0.1.28 Haciendo ping a 12.0.1.28 con 32 bytes de datos: Respuesta desde 12.0.1.28: bytes=32 tiempo=190ms TDV=237 Estadísticas de ping para 12.0.1.28: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 190ms, máximo = 190ms, promedio = 190ms C:\WINDOWS>ping -n 1 -i 25 130.94.157.169 Haciendo ping a 130.94.157.169 con 32 bytes de datos: Respuesta desde 130.94.157.169: bytes=32 tiempo=195ms TDV=45 Estadísticas de ping para 130.94.157.169: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 195ms, máximo = 195ms, promedio = 195ms C:\WINDOWS>ping -n 1 -i 25 207.70.7.168 Haciendo ping a 207.70.7.168 con 32 bytes de datos: Respuesta desde 207.70.7.168: bytes=32 tiempo=229ms TDV=235 Estadísticas de ping para 207.70.7.168: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 229ms, máximo = 229ms, promedio = 229ms C:\WINDOWS>arp -a Interfaz: 172.26.0.2 on Interface 0x1000002 Dirección IP Dirección física Tipo 172.26.0.1 00-20-ea-18-d1-51 dinámico C:\WINDOWS> ¿Pertenecen a nuestra red los hosts a los que les hemos hecho PING? No. Nuestra red es la 172.26.0.0 con máscara 255.255.0.0 y ninguna de las direcciones IP de los hosts a los que les hemos hecho PING tiene como primeros dos octetos el 172 y el 26.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿A qué dirección MAC se habrán dirigido todas las tramas que contenían los paquetes con mensajes ICMP que hemos enviado? A la dirección MAC del router. Al ser hosts que están fuera de nuestra red, los paquetes deben llegarles pasando a través de un router. Es imposible que una trama que nosotros enviemos salga fuera de nuestra red. ¿ha sido necesario generar una petición ARP para obtener la dirección MAC del router por defecto de nuestra red, el 172.26.0.1? No. La caché ARP ya contenía esa información, pues seguramente habrá habido recientemente alguna comunicación entre el router y nosotros. A continuación se muestra una ventana de un analizador de protocolos en la que aparece el tráfico que se ha generado en nuestra red debido a los comandos PING que acabamos de ejecutar.

¿Qué significa la columna “Elapsed [sec]” que aparece en el listado de tramas? Son los segundos que han transcurrido desde que se capturó la primera trama hasta que se ha capturado la trama en cuestión. Por ejemplo, la trama con ID=3 se ha capturado 1,677641 segundos después de que se capturase la primera trama. ¿Qué equipos están intercambiando tramas? El nuestro, con IP 172.26.0.2, que sabemos que tiene la MAC 00C026260D14 gracias al comando “ipconfig /all” y el router, con IP 172.26.0.1, que sabemos que tiene la dirección MAC 0020EA18D151 pues así nos lo ha mostrado el comando “arp –a” que ejecutamos anteriormente. ¿Van dirigidos a la IP del router los paquetes encapsulados en las tramas que le estamos enviando? No. Aunque en esta ventana de captura no se está viendo, la IP destino de los paquetes que hay encapsulados en las tramas que estamos enviando será la IP de los equipos a los que les queremos hacer llegar los mensajes ICMP de petición de eco. No le estamos haciendo PING al router, simplemente estamos haciendo uso del router para que nos enrute los paquetes con destino externo a nuestra propia red. A continuación se muestra la misma ventana de captura de antes pero configurada de forma que en el listado de tramas aparecen ahora las direcciones de red en lugar de las MAC.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Es más clara ahora la información de la ventana de captura? Sí. A pesar de que el panel central está casi cerrado y de que el panel inferior está completamente cerrado, el hecho de que aparezcan las direcciones IP origen y destino de los paquetes contenidos en las tramas hace que, en este ejemplo concreto se vea mejor lo que está ocurriendo. De un vistazo nos damos cuenta que desde el host 172.26.0.1 se ha enviado un mensaje ICMP de petición de eco “Echo Request” a otros tres hosts, con direcciones IP 12.0.1.28, 130.94.157.169 y 207.70.7.168, respectivamente. También se observa cómo esos tres host han respondido al host 172.26.0.2 con los correspondientes mensajes ICMP de respuesta de eco “Echo Reply”. ¿Cuánto tiempo ha tardado en llegar el mensaje de respuesta del host 207.70.7.168, contado desde que le enviamos el mensaje ICMP de petición de eco? Pues la diferencia entre 3,192862 segundos y 2,974271 segundos, que son 0,218591 segundos. Nótese que esto concuerda aproximadamente con los 229 milisegundos que ha calculado el programa PING como tiempo de recorrido redondo (ida y vuelta). Lógicamente éste es un poco superior porque el programa PING empieza a contar cuando le pasa el mensaje de petición de eco al nivel de red y deja de contar cuando el nivel de red le pasa al programa PING el mensaje de respuesta de eco, mientras que el cálculo que nosotros hemos hecho se basa en los tiempos de salida y llegada de las tramas. A continuación se muestra el contenido de la trama con ID=4.

¿Cómo sabe el analizador que es correcto el campo “Checksum” del mensaje ICMP de esta trama? Lo calcula nuevamente y comprueba que coincide con el que ha recibido. Para calcularlo realiza la suma de todas las palabras de 16 bits del mensaje ICMP, salvo el propio checksum, que no es sumado. En nuestro caso la suma es 0800 + 0100 + 7000 + 6162 + 6364 + 6566 + 6768 + 696A + 6B6C + 6D6E + 6F70 + 7172 + 7374 + 7576 + 7761 + 6263 + 6465 + 6667 + 6869 = 7239D. Si el número que hemos obtenido fuese mayor de 16 bits, cogeríamos los bits sobrantes y los volveríamos a sumar a los 16 bits menos significativos, lo que en nuestro caso sería 239D + 7 = 23A4. Por último, el resultado de 16 bits así obtenido se complementa a uno para obtener el cheksum. En nuestro caso el complemento a uno de 23A4 es DC5B, que coincide exactamente con el checksum que hemos recibido. Quiere esto decir que el mensaje ICMP no tiene errores, o al menos que no tiene errores que puedan detectarse con esta sencilla técnica de detección de errores. ¿Qué significa la anotación que pone el analizador al lado de campo “Code” del mensaje ICMP de petición de eco? La anotación “Not used (MBZ)” significa que como el campo “Code” no se usa en este tipo de mensaje, su valor debe ser cero (MBZ = Must Be Zero). ¿Cómo es el mensaje ICMP de respuesta de eco que devuelve un host al recibir el correspondiente mensaje de petición de eco? Debe ser idéntico en todo al mensaje de petición de eco que acaba de recibir, salvo que el campo “Type” debe ser 0 (respuesta de eco) y que, como es lógico, el campo “Checksum” deberá ser calculado nuevamente.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Ejercicio 6: Observe la siguiente red de ordenadores:

Estrictamente hablando, lo que se muestra en la figura no es una red (dominio de broadcast) sino que es un conjunto de redes interconectadas mediante routers. Por tanto, lo más correcto sería decir que estamos frente a una interred o una internetwork. En esta interred podemos distinguir cinco redes Ethernet, implementadas con un sencillo concentrador (Hub). Nótese que los enlaces Ethernet entre equipos están etiquetados con la palabra “Eth”. Los enlaces que no están etiquetados con “Eth” están etiquetados con “PPP” indicando que son enlaces serie punto a punto que usan como protocolo de nivel 2 el protocolo PPP (Point to Point Protocol). En esta interred, la mayoría de enlaces entre routers son de tipo “PPP”. Cada enlace “PPP” es una red independiente con tan solo dos equipos. Cada equipo tiene asignado un nombre. Los PCs tienen asignada una dirección IP y una máscara de subred en la notación “/n”, donde “n” es el número de bits a uno en la máscara de subred. Los hubs son modelos sencillos, no gestionables, y no tienen dirección IP. Los routers tienen una dirección IP en cada interfaz. Las interfaces Ethernet están etiquetadas con “e0” o “e1”. Las interfaces serie están etiquetadas con “s0” o “s1”. Los PCs conectados al “Hub_DE” tienen configurado como router por defecto al “Router_D”, de forma que dirigirán a él los paquetes que quieran hacer llegar fuera de su propia red. En el “PC_A0_55” se ha abierto una sesión MS-DOS y se han ejecutado los comandos que aparecen listados a continuación:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


C:\WINDOWS>ipconfig Configuración IP de Windows 98 0 Ethernet adaptador : Dirección IP . . . . . . . . . . . . . : 192.5.5.55 Máscara de subred . . . . . . . . . . : 255.255.255.0 Puerta de enlace predeterminada . . . : 192.5.5.1 C:\WINDOWS>arp –a Interfaz: 192.5.5.55 on Interface 0x1000002 Dirección IP Dirección física Tipo 192.5.5.1 00-10-7b-81-ae-26 dinámico 192.5.5.18 00-04-76-99-09-dd dinámico C:\WINDOWS>ping -n 1 210.93.105.13 Haciendo ping a 210.93.105.13 con 32 bytes de datos: Tiempo de espera agotado. Estadísticas de ping para 210.93.105.13: Paquetes: enviados = 1, Recibidos = 0, perdidos = 1 (100% loss), Tiempos aproximados de recorrido redondo en milisegundos: Mínimo = 0ms, máximo = 0ms, promedio = 0ms C:\WINDOWS>arp –a Interfaz: 192.5.5.55 on Interface 0x1000002 Dirección IP Dirección física Tipo 192.5.5.1 00-10-7b-81-ae-26 dinámico C:\WINDOWS> ¿Concuerda el resultado del comando “ipconfig” con los datos de la red de la figura? Sí. La máscara de subred 255.255.255.0 es equivalente a “/24”, que es la que aparece en el diagrama como la máscara de subred de la red a la que está conectado el “PC_A0_55”. Por otra parte, la dirección IP, la 192.5.5.55, también es la correcta. Además, dado que el “Router_A” es el único router en la red de este ordenador, es correcto considerar que sea el router por defecto. Como es lógico la IP del router que aparece en la salida del comando “ipconfig” (192.5.5.1) es la IP de la interfaz Ethernet del router que se encuentra conectada al “Hub_A0” que es el mismo al que está conectado el “PC_A0_55”. ¿En que red está el ordenador al que le estamos haciendo PING? Estamos haciendo PING al “PC_DE_13” desde el “PC_A0_55”. El “PC_DE_13” está en una red distinta, que es 210.93.105.0 /24, pero conectada a la red del equipo que realiza los PINGs mediante una serie de routers y redes. ¿Cuántas rutas puede seguir un paquete para ir desde “PC_A0_55” a “PC_DE_13” y viceversa? Viendo la red de la figura nos damos cuenta de que solo hay una ruta posible. Esa ruta y atraviesa cuatro routers y tres redes intermedias (sin contar las redes origen y destino), por lo que si midiésemos la longitud de la ruta en saltos (hops) diríamos que mide 4. ¿Con cuantos PCs de nuestra propia red nos hemos comunicado antes de hacer el PING? Con uno solamente. La caché ARP muestra una entrada con la dirección IP 192.5.5.18, lo cuál hace pensar que hemos debido de tener algún tipo de comunicación con dicho PC, lo cual habrá hecho necesario que se tenga que averiguar su dirección MAC y guardarla temporalmente en la caché ARP. La otra dirección IP que aparece en la caché ARP es la del router por defecto de nuestra red. ¿Indica la presencia de la dirección IP del router en la caché ARP que nos hemos comunicado con otros equipos de otras redes distintas a la nuestra antes de ejecutar el comando PING? No necesariamente. Hay que tener en cuenta que al hacerle un PING al router nos estamos comunicando con el router y no con un equipo externo a nuestra red y sin embargo esto provocaría la aparición de la dirección IP del router en la caché ARP. ¿Por qué después del PING desaparece de la caché ARP la entrada correspondiente al PC cuya IP es la IP 192.5.5.18? Hay que tener en cuenta la caché ARP se va vaciando sola conforme las entradas que no se utilizan van caducando. Seguramente la entrada que ha desaparecido estaba punto de caducar y como el hecho de hacer PING al equipo 210.93.105.13 no generado tráfico con el equipo 192.5.5.18, dicha entrada ha caducado en el intervalo de tiempo comprendido entre los dos comandos “arp –a”.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Conoce el comando PING cuál es la máscara de subred del equipo al que le va a enviar los mensajes ICMP, en esta caso el 210.93.105.13? No la conoce ni le hace falta conocerla. ¿Cómo se sabe si el equipo destino del PING está en la misma red que el equipo origen? Se compara el nombre de la red origen con el resultado de hacer la operación lógica AND bit a bit entre la máscara de subred de la red del equipo origen y la IP del equipo destino. Si son distintos es porque están es redes distintas. Si son iguales quiere decir que la parte de red de sus direcciones IP son idénticas, por lo que el equipo origen y el equipo destino pertenecen a la misma red. ¿Pertenece nuestro equipo, el “PC_A0_55” (con IP 192.5.5.55) a la misma red del equipo destino del PING, el “PC_DE_33” (con IP 210.93.105.13)? La máscara de la red del equipo 192.5.5.55 es 255.255.255.0, por lo que el nombre de la red de dicho equipo puede obtenerse haciendo el AND lógico bit a bit entre 192.5.5.55 y 255.255.255.0, lo cual nos da 192.5.5.0. Ahora hay que comparar es ese nombre de red (el de la red de origen) con el resultado de hacer la operación lógica AND bit a bit entre la máscara de red del equipo 192.5.5.55 (el origen) y la IP del equipo destino, 210.93.105.13, lo cual nos da como resultado 210.93.105.0. Como resulta que 192.5.5.0 y 210.93.105.0 son números diferentes, podemos decir que el equipo con la dirección IP 192.5.5.55 y el equipo con la dirección IP 210.93.105.13 pertenecen a redes diferentes. Se ha capturado el tráfico generado por los comandos anteriores tanto en la red origen de los PINGs como en la red destino de los PINGs. Es decir, se han capturado las tramas vistas por el “PC_A0_55” en su red y las tramas vistas por el “PC_DE_13” en su red. A continuación se muestra una ventana de un analizador de protocolos en la que aparece el tráfico visto por “PC_A0_55”:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Y a continuación puede verse la ventana del analizador correspondiente al tráfico capturado en la red del ordenador “PC_DE_13”:

¿A qué dirección MAC ha dirigido el equipo 192.5.5.55 la trama que contenía el mensaje ICMP de petición de eco que se muestra en la primera ventana? A la dirección MAC de su router por defecto, que es 00107B81AE26. Sabemos esto porque la dirección MAC que aparece como destino en dicha trama es la misma que aparece en su caché ARP asociada a la IP 192.5.5.1, que es la del router. De todas formas esto era lo lógico, pues el equipo 192.5.5.55 sabe que debe enviarle la trama al router por defecto para que sea él el que enrute hacia su destino el paquete contenido en esa trama. ¿Por qué no aparece en la primera ventana de captura una petición APR previa al envío del mensaje ICMP de petición de eco? Porque en la caché ARP del “PC_A0_55” ya se encontraba la dirección MAC del router, que es la que se ha usado como destino en la trama enviada por dicho PC. ¿Cuál es la dirección MAC de “PC_A0_55”? Es 000102B44EB0, que es la MAC origen de la trama que contiene el mensaje ICMP de petición de eco que se ha capturado en la red del “PC_A0_55”. ¿A que dirección IP va dirigido el paquete encapsulado en la trama que “PC_A0_55” ha dirigido al router por defecto de su red? A la IP 210.93.105.13, que es la IP del equipo al que le hemos hecho el PING. ¿Cómo se escribe en hexadecimal la IP 210.93.105.13? D25D690D, que son precisamente los cuatro octetos que aparecen resaltado en el panel inferior de la primera ventana de captura, correspondiendo a la IP 210.93.105.13 que se encuentra resaltada en el panel central de esa misma ventana. ¿Cuántos octetos de datos opcionales se han incluido en el mensaje ICMP de petición de eco? 32 octetos de datos opcionales, según se muestra en el campo “Optional Data” que se ve en el panel central de la primera ventana de captura. El comando PING implementado por Windows 98 incluye ese número de octetos a menos que se le diga otra cosa al comando PING con la opción adecuada. ¿Cuántos mensajes ICMP de petición de eco se han generado con el comando PING que hemos ejecutado en el “PC_A0_55”? Tan sólo uno, pues así lo hemos querido al usar la opción “-n” con el parámetro 1. ¿Cuál es el “EtherType” de IP? 0x0800 en hexadecimal, tal y como se ve en la trama de la primera ventana de captura.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Por qué sabemos que el datagrama IP mostrado en la primera ventana de captura es un datagrama completo y no se trata de un fragmento. Como el campo “Fragment Offset” vale 0, sabemos que, caso de ser un fragmento, se trataría del primero, pues hay 0 octetos de datos delante suya. Como el bit “MF” vale 0, sabemos que, caso de ser un fragmento, sería el último. Pero si un datagrama es el primero de una serie de fragmentos y también es el último de dicha serie, quiere decir que realmente la serie de fragmentos se compone de un único fragmento. Es decir que no se ha producido fragmentación y lo que se nos está mostrando es un datagrama completo y no un fragmento. ¿Hemos obtenido respuesta al comando PING por parte de “PC_DE_13”? Entre el tráfico capturado en la red del equipo “PC_A0_55” no se muestra ningún mensaje ICMP de respuesta de eco. Además, la salida del comando PING nos dice “Tiempo de espera agotado”, indicando que no se ha recibido el mensaje de respuesta en el tiempo de espera que dicho comando PING tiene establecido por defecto. ¿Quién realiza la petición ARP que se muestra en la segunda ventana de captura? El equipo con IP 210.93.105.1, que es la IP que aparece en el campo “Sender IP Address”. Si buscamos esta IP en el gráfico de la red que estamos estudiamos, vemos que dicha IP corresponde a la interfaz e0 del “Router_D”, que es la interfaz que dicho router tiene conectada a la red del “PC_DE_13”, destino del PING que realizó el “PC_A0_55”. ¿Qué valor tiene el campo “Target Ethernet Address” en la petición ARP que se muestra en la segunda ventana de captura? Tiene el valor 000000000000, pues precisamente lo que se pretende averiguar con la petición ARP es el valor del “Target Ethernet Address”. En realidad en una petición ARP no tiene por qué ponerse este campo a ningún valor en concreto pues nadie va a usarlo. Sin embargo parece que para no dar lugar a confusiones es conveniente ponerlo todo a 0 o todo a 1. ¿A quién va dirigida la petición ARP que se muestra en la segunda ventana de captura? Va dirigida al equipo con IP 210.93.105.13, que es la IP que aparece en el campo “Target IP Address”. Esto quiere decir que el “Router_D”, que es el que ha hecho la petición ARP, no tenía en su caché ARP una entrada asociada a la dirección IP 210.93.105.13, pues de haber sido así no habría tenido que hacer la petición ARP. ¿Por qué se ha realizado la petición ARP que se muestra en la segunda ventana de captura? Es de suponer que el “Router_D” ha realizado la petición ARP porque está interesado en averiguar la dirección MAC del equipo “PC_DE_13” para poder, más tarde, comunicarse con él enviándole una trama que tenga por dirección MAC destino la de dicho PC. Parece lógico pensar que el deseo del “Router_D” por comunicarse con el “PC_DE_13” estará motivado por la llegada a dicho router de un datagrama IP destinado a este PC. Este datagrama IP que ha llegado al “Router_D” será con toda seguridad el datagrama IP que ha enviado el “PC_A0_55” y ha pasado por el “Router_A”, el “Router_B” y el “Router_C” hasta llegar al “Router_D”, que debe enviarlo al “PC_DE_13”. ¿Por qué no aparece en la segunda ventana de captura ninguna trama dirigida la dirección MAC del “PC_DE_13”, obtenida mediante ARP? Seguramente el “Router_D” posee una implementación del protocolo ARP que descarta los datagramas IP para los cuales no encuentra en su caché ARP la dirección MAC necesaria para enviarlos. El “Router_D” al recibir el paquete con la IP destino 210.93.105.13, la cual forma parte de una red directamente conectada al router, y ver que la dirección MAC de dicho equipo no se encontraba en su caché ARP, decidió que necesitaba hacer una petición ARP para dicha IP, pero en lugar de poner en espera el paquete IP mientras se recibía la respuesta ARP, decidió descartar el paquete. El router confía que el emisor del paquete detectará de alguna forma que el paquete no ha llegado a su destino y volverá a enviarlo de nuevo. Cuando llegue un nuevo paquete al router dirigido al mismo destino que antes, el router ya dispondrá en su caché ARP de una entrada con la dirección MAC que necesita, por lo que este paquete podrá ser enviado inmediatamente y no será descartado. Hay que hacer notar que otras implementaciones de ARP no descartan los paquetes por el mero hecho de que la dirección MAC necesaria para enviarlos no se encuentre en la caché ARP, sino que los retienen hasta que se obtiene mediante ARP la dirección MAC que se necesita y entonces son enviados encapsulados en una trama. ¿Qué habría ocurrido si después del primer comando PING hubiésemos ejecutado otro idéntico? Se generaría otro paquete IP, pero seguramente este segundo paquete IP conteniendo otro mensaje ICMP de petición de eco habría llegado correctamente a su destino final, el “PC_DE_13”, pues el “Router_D” aún tendría en su caché ARP la MAC del “PC_DE_13” y por tanto no descartaría este paquete, a diferencia de lo que hizo con el primer paquete. ¿Cuál es el “EtherType” del protocolo ARP? Es 0x0806, tal y como se muestra en la segunda ventana de captura.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP




Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


C:\WINDOWS>ipconfig Configuración IP de Windows 98 0 Ethernet adaptador : Dirección IP . . . . . . . . . . . . . : 192.5.5.55 Máscara de subred . . . . . . . . . . : 255.255.255.0 Puerta de enlace predeterminada . . . : 192.5.5.1 C:\WINDOWS>ping Uso: 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. C:\WINDOWS>ping -n 3 -l 22 -i 5 -f -v 64 -w 5000 210.93.105.13 Haciendo ping a 210.93.105.13 con 22 bytes de datos: Tiempo de espera agotado. Respuesta desde 210.93.105.13: bytes=22 tiempo=55ms TDV=124 Respuesta desde 210.93.105.13: bytes=22 tiempo=52ms TDV=124 Estadísticas de ping para 210.93.105.13: Paquetes: enviados = 3, Recibidos = 2, perdidos = 1 (33% loss), Tiempos aproximados de recorrido redondo en milisegundos: Mínimo = 52ms, máximo = 55ms, promedio = 35ms C:\WINDOWS>ping -n 1 -l 54 -i 5 -f -v 64 -w 5000 210.93.105.13 Haciendo ping a 210.93.105.13 con 54 bytes de datos: Respuesta desde 210.93.105.13: bytes=54 tiempo=80ms TDV=124 Estadísticas de ping para 210.93.105.13: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: Mínimo = 80ms, máximo = 80ms, promedio = 80ms C:\WINDOWS>ping -n 1 -l 25 -i 4 -f -v 64 -w 5000 210.93.105.13 Haciendo ping a 210.93.105.13 con 25 bytes de datos: Respuesta desde 204.204.7.2: El tiempo de vida caducó en tránsito. Estadísticas de ping para 210.93.105.13: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: Mínimo = 0ms, máximo = 0ms, promedio = 0ms C:\WINDOWS>ping -n 1 -l 55 -i 3 -f -v 64 -w 5000 210.93.105.13 Haciendo ping a 210.93.105.13 con 55 bytes de datos: Respuesta desde 199.6.13.2: El tiempo de vida caducó en tránsito. Estadísticas de ping para 210.93.105.13: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: Mínimo = 0ms, máximo = 0ms, promedio = 0ms C:\WINDOWS>arp –a Interfaz: 192.5.5.55 on Interface 0x1000002 Dirección IP Dirección física Tipo 192.5.5.1 00-10-7b-81-ae-26 dinámico C:\WINDOWS>

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Concuerda el resultado del comando “ipconfig” con los datos de la red de la figura? Sí. La máscara de subred 255.255.255.0 es equivalente a “/24”, que es la que aparece en el diagrama como la máscara de subred de la red a la que está conectado el “PC_A0_55”. Por otra parte, la dirección IP, la 192.5.5.55, también es la correcta. Además, dado que el “Router_A” es el único router en la red de este ordenador, es correcto considerar que sea el router por defecto. Como es lógico la IP del router que aparece en la salida del comando “ipconfig” (192.5.5.1) es la IP de la interfaz Ethernet del router que se encuentra conectada al “Hub_A0” que es el mismo al que está conectado el “PC_A0_55”. ¿En que red está el ordenador al que le estamos haciendo PING? Estamos haciendo PING al “PC_DE_13” desde el “PC_A0_55”. El “PC_DE_13” está en una red distinta, que es 210.93.105.0 /24, pero conectada a la red del equipo que realiza los PINGs mediante una serie de routers y redes. ¿Cuántas rutas puede seguir un paquete para ir desde “PC_A0_55” a “PC_DE_13” y viceversa? Viendo la red de la figura nos damos cuenta de que solo hay una ruta posible. Esa ruta y atraviesa cuatro routers y tres redes intermedias (sin contar las redes origen y destino), por lo que si midiésemos la longitud de la ruta en saltos (hops) diríamos que mide 4. Se ha capturado el tráfico generado por los comandos anteriores tanto en la red origen de los PINGs como en la red destino de los PINGs. Es decir, se han capturado las tramas vistas por el “PC_A0_55” en su red y las tramas vistas por el “PC_DE_13” en su red. A continuación se muestra una ventana de un analizador de protocolos en la que aparece el tráfico visto por “PC_A0_55”, el cual se ha almacenado en el archivo “fichero55.cap”:

Y a continuación puede verse la ventana del analizador correspondiente al tráfico capturado en la red del ordenador “PC_DE_13”, el cual se ha almacenado en el archivo “fichero13.cap”:

Las dos ventanas anteriores están mostrando únicamente el listado de tramas capturadas, pues el panel central y el panel inferior de la ventana de captura han sido reducidos de tamaño hasta dejarlos reducidos a una simple línea. ¿Por qué algunas tramas se encuentran resaltadas en el listado de tramas? En ambas ventanas se observa que además de la trama que se encuentra seleccionada (la de ID=0), hay más tramas que presentan una banda de color (verde en este caso) para resaltarlas. El motivo de que aparezcan resaltadas es que el analizador tiene un modulo experto al que se le puede decir que nos muestre las tramas que el considere que son el “síntoma” de algún problema. Por ejemplo, la trama con ID=10 capturada en la red 192.5.5.0 /24 aparece resaltada y en el resumen (summary) se nos dice que es un mensaje ICMP de tiempo de vida excedido enviado por un router que ha descartado un paquete por ese motivo. Esto puede ser síntoma de un problema o puede ser algo

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


perfectamente normal, todo depende de lo que estemos haciendo en la red, lo cual es algo que el analizador de protocolos no puede saber. Otro ejemplo de actuación del módulo experto es la trama con ID=2 capturada en la red 210.93.105.13 /24, que aparece resaltada y se nos dice que contiene un paquete IP cuyo tiempo de vida está expirando (vale 1), por lo que no podrá atravesar ningún router más. ¿Es posible configurar el analizador para que nos muestre en el listado de tramas información acerca del instante en que se capturaron las tramas, las direcciones de red de los paquetes contenidos en ellas y que omita la información “extra” relativa a las tramas que presentan “síntomas” de errores? Sí. A continuación se muestra como, teniendo abierta la ventana de captura, es posible seleccionar una opción en el menú para que se nos abra la ventana “Capture View Display Options”:

Una vez abierta la ventana “Capture View Display Options” podremos modificar a nuestra conveniencia las opciones de visualización de la ventana de captura. A continuación se muestra la ventana “Capture View Display Options” configurada para conseguir lo que se nos está pidiendo:

Después de efectuar estos cambios en las opciones de visualización, se ilustra a continuación la ventana que muestra el contenido del archivo “fichero55.cap” que no es otro que el tráfico de la red en la que se encuentra el ordenador “PC_A0_55”:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Con los mismos cambios se presenta a continuación la ventana que muestra el contenido del archivo “fichero13.cap” que no es otro que el tráfico de la red en la que se encuentra el ordenador “PC_DE_13”:

¿Se corresponde el primer mensaje ICMP que envía “PC_A0_55” con el primer mensaje ICMP que recibe “PC_DE_13”? A primera vista puede parecer que sí, pero en realidad no se corresponden. Ambos tienen 22 octetos de datos opcionales (Optional Data) lo cual da lugar (después de sumarle las cabeceras ICMP, IP, Ethernet y los 4 octetos de la cola de la trama Ethernet) a los 68 octetos que aparecen en la columna “Size” del listado de tramas. También son idénticas las direcciones IP origen y destino del datagrama IP contenido en ambas tramas. Lo que nos hace ver que son mensajes ICMP diferentes es que el campo “Sequence Number” tiene el valor 23296 en el primer mensaje enviado por “PC_A0_55” y un valor distinto, 23552, en el primer mensaje ICMP recibido por “PC_DE_13”. A continuación se muestra decodificada una trama transmitida por “PC_A0_55” conteniendo el segundo mensaje ICMP de petición de eco que envió dicho ordenador:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Corresponde el segundo mensaje ICMP enviado por “PC_A0_55” con el primer mensaje ICMP recibido por “PC_DE_13”? Sí. No sólo coinciden los tamaños de las tramas y las direcciones IP origen y destino, sino que coinciden también los valores de los campos “Identified” y “Sequence Number” de la cabecera ICMP. ¿Qué ha ocurrido con el primer mensaje ICMP de petición de eco enviado por “PC_A0_55”? Da la impresión de que, por algún motivo, no ha llegado a su destino. Es cierto que puede ocurrir que dos paquetes que se envían en un cierto orden lleguen a su destino en orden inverso, pero no parece que esto haya ocurrido en este caso. Por un lado resulta que en la red que estamos estudiando sólo existe una ruta posible entre el origen y el destino, por lo que parece lógico que el primer paquete en enviarse vaya a llegar después del segundo en enviarse. Por otro lado, el segundo mensaje ICMP se ha enviado 5,218044 segundos después que el primero, lo cual parece tiempo más que suficiente para que el primer mensaje supere cualquier problema que haya podido encontrarse en el camino. Además, examinando la salida en pantalla ofrecida por el primer comando PING vemos que se envían 3 mensajes ICMP con 22 octetos de datos opcionales y se obtiene respuesta para el segundo y para el tercero, pero no para el primero, del cual se nos dice que se ha agotado el tiempo de espera sin haber obtenido respuesta. El primero en obtener respuesta es, como ya se ha demostrado, el contenido en la trama con ID=2 del “fichero13.cap”, mientras que el otro que obtiene respuesta debe ser el contenido en la trama ID=4 del “fichero13.cap”. Por tanto, no hay en el “fichero13.cap” ninguna otra trama que por tamaño y características pueda corresponder al primer mensaje ICMP enviado por “PC_A0_55”, así que podemos decir rotundamente que dicho mensaje se ha perdido por el camino antes de llegar a su destino. ¿Por qué se produce la petición ARP que se ve en la red del “PC_A0_55”? Porque en el momento de hacer el primer PING el “PC_A0_55” no conoce la dirección MAC del router por defecto y lo primero que tiene que hacer es averiguarla. Cuando, mediante ARP, haya obtenido dicha dirección MAC, ya podrá enviarle una trama a dicho router conteniendo el primer mensaje ICMP de petición de eco. El resto de PINGs no provocan más peticiones ARP porque una vez que se obtiene la MAC asociada a una determinada IP, dicha información permanecerá en la caché ARP del ordenador hasta que pase un cierto tiempo sin ser utilizada, en cuyo caso desaparecerá de la caché. ¿Por qué se produce la petición ARP que se ve en la red del “PC_DE_13”? La petición ARP la ha hecho el router de dicha red, el 210.93.105.1, porque tiene necesidad de comunicarse con el host con dirección IP 210.93.105.13, que es precisamente “PC_DE_13”. Lo curioso es que desde que el router tiene necesidad de comunicarse con “PC_DE_13” y le pregunta su dirección MAC, hasta que el router envía una trama al “PC_DE_13” transcurren 5,2172832 segundos, lo cuál no es lógico. No parece que sea la trama que envía el router después de la petición ARP la que le motivó a hacer dicha petición. Además resulta que el “PC_A0_55” envió su primer mensaje ICMP unos 5,218044 segundos antes de enviar su segundo mensaje ICMP. Parece razonable pensar que el primer mensaje ICMP dirigido al “PC_DE_13” llegó correctamente al router 210.93.105.1 y eso fue lo que provocó que el router generase una petición ARP al no encontrar en su caché ARP la MAC que necesitaba. Parece ser que lo que está ocurriendo es que el router cuando no encuentra en su caché ARP la dirección MAC que necesita para poder enrutar un paquete, procede a descartar dicho paquete y a realizar una petición ARP para averiguar dicha dirección MAC y almacenarla en la caché ARP, de forma que pueda usarla más tarde cuando le llegue un nuevo paquete que deba seguir el mismo camino que el anterior paquete que descartó. Efectivamente, el segundo mensaje ICMP dirigido al “PC_DE_13” llega al router 210.93.105.1 unos 5 segundos después de que el primer mensaje fuese descartado, pero en este caso el router es capaz de enrutarlo inmediatamente pues ya

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


dispone en su caché ARP de la dirección MAC que necesita. Este comportamiento no es algo anómalo, sino que es una de las posibles formas de implementar el protocolo ARP. ¿Por qué el primer comando PING espera aproximadamente 5 segundos desde que envía el primer mensaje ICMP hasta que envía el segundo? El primer comando PING va a enviar 3 mensajes ICMP al host destino, pues hemos usado la opción “–n” con el parámetro 3. Como, además, se le ha especificado la opción “–w” con el parámetro 5000, va a esperar 5000 milisegundos a que llegue la respuesta a un mensaje ICMP de petición de eco. Si no llega la respuesta en ese tiempo límite, (como en nuestro caso) procederá a enviar el siguiente mensaje ICMP que tenga programado. ¿Por qué hay tramas de cuatro tamaños diferentes (68, 100, 71 y 101 octetos según muestra la columna”Size”) conteniendo mensajes ICMP de petición de eco? Porque los mensajes ICMP de petición de eco que se han generado tenían datos opcionales de diferentes longitudes, pues se ha usado la opción “-l” con diferentes valores en cada uno de los comandos PING que se ejecutado. Así, el primer comando PING generó mensajes ICMP con 22 octetos de datos opcionales, el segundo comando PING lo hizo con 54 octetos de datos opcionales, el tercero con 25 octetos y el cuarto con 55 octetos. Por ejemplo, si sumamos 6 octetos de MAC origen, 6 de MAC destino, 2 de EtherType, 20 de cabecera IP, 8 de cabecera ICMP de petición de eco, 55 de datos opcionales de mensaje ICMP de petición de eco y 4 de campo “Frame Check Sequence” tenemos los 101 octetos que mide la trama que contiene el último mensaje ICMP de petición de eco, como siempre sin tener en cuenta el preámbulo ni el delimitador de inicio que vienen al principio de la trama. ¿Cuáles son los diez primeros caracteres de los datos opcionales del primer mensaje ICMP de petición de eco enviado por “PC_A0_55”? El campo “Opcional Data” del mensaje ICMP de petición de eco viene a continuación de la campo “Sequence Number”, que podemos ver resaltado en la trama con ID=2 del “fichero55.cap” en una de las ventanas de captura que se han visto anteriormente. En el panel inferior de dicha ventana se observa que los dos octetos que forman el mencionado campo “Sequence Number” ocupan la posición 0x28 y 0x29 (hexadecimal) dentro de la trama, por lo que el campo que nos interesa, el “Optional Data”, ocupa la posición 0x2A que está justo a continuación. En la parte derecha del panel inferior podemos ver en formato ASCII los mismos caracteres que estamos de forma numérica y en hexadecimal en la parte derecha, por lo que podemos decir que los diez caracteres que nos piden son “abcdefghij”. ¿Ha llegado al “PC_DE_13” el mensaje ICMP que enviamos con el segundo comando PING? El segundo comando PING genera una trama de 100 octetos (54 octetos de datos opcionales), la cual también llega a la red del PC destino, según se observa en las dos ventanas que muestran el tráfico capturado en ambas redes. Además, la salida en pantalla del segundo comando PING confirma que se ha recibido respuesta del PC con IP 210.93.105.13, lo cual es síntoma de que nuestro mensaje ha llegado a su destino y de que el mensaje de respuesta correspondiente también nos ha llegado a nosotros. ¿Han llegado al “PC_DE_13” los mensajes ICMP correspondientes los comandos PING que hemos ejecutado en tercer y cuarto lugar? En la red del “PC_A0_55” se observan dos tramas, una de 71 octetos y otra de 101 octetos, las cuales contienen los mensajes ICMP emitidos al ejecutarse los comandos PING tercero y cuarto. No obstante, en la red del “PC_DE_13” no se ha capturado ninguna trama de estas características. Podemos decir, por tanto, que dichos mensajes ICMP no han llegado a su destino. ¿Qué ha ocurrido con el mensaje ICMP enviado por el tercer comando PING? Según la salida en pantalla del tercer comando PING, el router 204.204.7.2 nos está informando de que el tiempo de vida de dicho mensaje ICMP ha caducado en tránsito. Si nos fijamos en la topología de la red vemos que el “Router_D” es el router que no s está respondiendo, pues es él el que tiene la dirección IP 204.204.7.2 en su interfaz s1 (interfaz serie número 1). Si además nos damos cuenta de que el mensaje ICMP se ha enviado con un tiempo de vida de valor 4, ya que hemos usado la opción “-i” con el parámetro 4, llegamos a la conclusión de que éste mensaje ICMP llegó al “Router_D” con un tiempo de vida de valor 1, pues ya ha atravesado tres routers. El “Router_D” al ir a enviarlo por su interfaz e0 debería decrementar en 1 dicho tiempo de vida, lo que haría que alcanzase el valor cero y por lo tanto no podría llegar a enviarlo. El “Router_D” avisa de esta circunstancia al emisor del datagrama mediante un mensaje ICMP especialmente diseñado para ello. A continuación se muestra la ventana de captura con el contenido del “fichero55.cap”. En la parte superior puede verse una pequeña parte del listado de tramas y en la parte central se observa completamente decodificado el mensaje ICMP que ha recibido “PC_A0_55” del “Router_D”:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Por qué el analizador de protocolos, al decodificar el campo “Type Of Service” del paquete IP contenido en la trama con ID=10 mostrada anteriormente, cataloga el valor de sus tres primeros bits como “Internetwork Control”? Los tres primeros bits del campo “Type Of Service” de la cabecera IP indican la precedencia asignada al datagrama. El significado de los diferentes valores que pueden tomar estos bits se define en la RFC791, que trata de IP (Internet Protocol), de la forma siguiente: 111 - Network Control 110 - Internetwork Control 101 - CRITIC/ECP 100 - Flash Override 011 - Flash 010 - Immediate 001 - Priority 000 - Routine El valor “110”, que es el que presenta el datagrama IP que contiene el mensaje ICMP que ha enviado el “Router_D” al host “PC_A0_55” al descartar un datagrama porque su TTL (“Time To Live”) ha expirado, indica que es un datagrama al que hay que darle precedencia de tipo “Internetwork Control”, que es una de las más elevadas. ¿Cuáles son las direcciones IP origen y destino del datagrama IP contenido en la trama con ID=10? En el panel central de la ventana anterior puede verse que dichas direcciones son 204.204.7.2 y 192.5.5.55 respectivamente. En otras ventanas de captura anteriores a ésta se podían ver también las direcciones de red en el listado de tramas, mientras que ésta ventana lo que se muestra en el listado de tramas son las direcciones origen y destino de nivel 2 (direcciones MAC). ¿De qué clase es el mensaje ICMP contenido en la trama con ID=10? Si nos fijamos en la cabecera del mensaje ICMP que aparece a continuación de la cabecera IP, podemos ver que el campo “Type” vale 11 lo que indica que es un mensaje del tipo “Time exceeded” (Tiempo excedido). Si queremos concretar aún mas, debemos mirar el valor del campo “Code”, que al valer 0 nos quiere decir que el tiempo que se ha excedido es el tiempo de vida del paquete “Time-To-Live Count Exceeded”. ¿Por qué aparecen dos cabeceras IP en la decodificación de la trama con ID=10? La trama en cuestión contiene un único datagrama IP, por lo que la única cabecera IP que tenemos que considerar es la primera de ellas. Todo lo que aparece a continuación de la primera cabecera IP forma parte de los datos del datagrama IP. Lo que ocurre es los datos del datagrama IP son un mensaje ICMP de tipo 11 y código 0 que ha enviado un router al descartar un datagrama por haber llegado a cero su TTL. Este mensaje ICMP de tipo 11 y código 0 incluye, entre otras cosas, una copia de parte del datagrama que el router ha descartado, con objeto de que el destinatario del mensaje ICMP sepa, no sólo que ha habido un problema, sino también qué datagrama concreto lo ha causado. Ese es el motivo de que a continuación del los primeros campos del mensaje ICMP aparezca una segunda cabecera IP. Eso nos permite ver que el datagrama descartado contenía a su vez un mensaje ICMP, pues, en la segunda cabecera IP que se muestra en la ventana, el campo “Protocol” vale 1. ¿A quién iba destinado el datagrama IP descartado a causa del TTL expirado del que se informa en el mensaje ICMP contenido en la trama con ID=10? Al host 210.93.105.13, pues ése es el valor del campo “Destination Address” que aparece en la segunda cabecera IP que se ve en la ventana. de la trama. Esto es así porque esa segunda cabecera IP es la copia de la cabecera IP del datagrama IP que se ha descartado. ¿Por qué en el interior del mensaje ICMP de tipo 11 y código 0 no aparece completo el datagrama IP que se ha descartado? Los mensajes ICMP que contienen a otros datagramas IP que han generado algún problema no tienen por qué incluir una copia del datagrama original completo. Sólo se copia la cabecera IP y 8 octetos de datos de dicho datagrama. Eso suele ser suficiente para que el receptor del mensaje ICMP sea capaz de averiguar, analizando el trozo de datagrama que se le adjunta, cuál ha sido la causa del problema. En el caso del mensaje ICMP que nos ocupa, vemos que sólo se ha podido adjuntar la cabecera IP del datagrama descartado, junto con 8 octetos de datos, que corresponden a la cabecera completa del mensaje ICMP de petición de eco. Lo único que se ha omitido son los 25 octetos de datos opcionales, que no son en este caso, importantes para la resolución del problema. De hecho, el receptor del mensaje ICMP de tipo 11 podrá darse cuenta de que el datagrama descartado contenía un mensaje ICMP de tipo 8 “Echo Request”, e incluso podrá saber cuáles son los valores de los campos “Identified” y “Sequence Number”, lo cuál le puede ser útil para investigar mejor las causas del problema.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


A continuación se muestra el mensaje ICMP de petición de eco generado por el tercer comando PING, el cual se encuentra en el interior del datagrama IP contenido en la trama cuyo ID es 9:

¿Hay alguna diferencia entre el datagrama IP mostrado en la trama con ID=9 y el que se encuentra contenido en el interior del mensaje ICMP de tipo 11 que se muestra en la trama con ID=10? Son datagramas IP ligeramente diferentes pues el TTL y el checksum han cambiado. Además, el datagrama contenido en el mensaje ICMP no está completo, pues le faltan los 25 octetos de los datos opcionales del mensaje ICMP de tipo 8. ¿Por qué el datagrama IP de la trama con ID=9 se ha emitido con una precedencia “Immediate”? Porque al ejecutar el tercer comando PING se usó la opción “–v” con el valor 64. Ese valor 64 (0x40 en hexadecimal o 01000000 en binario) es el que se le ha dado al octeto que ocupa el campo “Type Of Service” del datagrama IP que encapsula al mensaje ICMP de petición de eco. Los tres primeros bits de ese octeto valen, por tanto, 010, lo que según la RFC791 indican que el datagrama tiene una precedencia de tipo “Immediate”. ¿Qué router es el que descarta el mensaje ICMP enviado por el cuarto comando PING? El “Router_C”. Al enviar un mensaje con un tiempo de vida inferior en una unidad al tiempo de vida del mensaje ICMP del tercer comando PING, el tiempo de vida del mensaje llega a cero un router antes que el otro. Un tiempo de vida de 3 hace que el mensaje sólo pueda atravesar 2 routers.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


A continuación se muestra parte de la trama con ID=6 que se ha capturado en la red del “PC_DE_13”:

¿Qué contiene el datagrama IP que se muestra en la ventana anterior? Aunque no se ve en el panel central, el listado de tramas del panel superior nos dice que se trata de un mensaje ICMP de petición de eco. ¿Qué comando de los que se han ejecutado en el “PC_A0_55” ha generado el datagrama IP que se muestra en la ventana anterior? Este datagrama tiene 62 octetos de datos, lo cual quiere decir que el mensaje ICMP de petición de eco tiene 54 octetos de datos opcionales (62 menos los 8 octetos de los campos que van delante de los datos opcionales). Si nos fijamos en las opciones de los comandos PING vemos que únicamente el segundo comando PING genera mensajes ICMP con 54 octetos de datos opcionales. ¿Habría llegado hasta su destino este datagrama que estamos analizando si algún router intermedio lo hubiese tenido que fragmentar? En ese caso no habría podido llegar, pues el bit DF está puesto a 1, lo cual hace que los routers, en lugar de fragmentarlo, lo descarten cuando sea necesario fragmentarlo. Este bit se ha puesto a uno porque en el comando PING se ha usado la opción “–f”. Puede observarse como, efectivamente en el campo “Flags/Fragment Offset”, el segundo bit (el DF) está a 1 y por eso el analizador de protocolos lo etiqueta como “Don´t Fragment” (No Fragmentar). ¿Habría llegado hasta su destino este datagrama que estamos analizando si se hubiese encontrado en su camino con un red cuya MTU (Maximum Transfer Unit) fuese de 90 octetos? Sí, pues aunque tiene prohibido ser fragmentado, realmente no necesita ser fragmentado para atravesar una red con MTU de 90 octetos. El datagrama tiene una longitud total (“Total Length”) de 82 octetos, por lo que cabe sin fragmentarse por redes cuya MTU sea mayor o igual a 82 octetos.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Ha llegado a su destino el datagrama IP contenido en la trama con ID=7 que se muestra en el listado de tramas de la ventana anterior? Este datagrama IP contiene la respuesta al mensaje ICMP que se ha enviado al ejecutarse el segundo comando PING. Si observamos la salida en pantalla del segundo comando PING podemos ver que efectivamente llega la respuesta desde 210,93.105.13, por lo que podemos afirmar que este datagrama llega correctamente a su destino. ¿Con qué tiempo de vida (“Time To Live”) se envía el datagrama contenido en la trama con ID=7 que se muestra en el listado de tramas de la ventana anterior? Con un tiempo de vida de 128. Sabemos esto porque la salida del segundo comando PING nos dice que este datagrama llega al “PC_A0_55” con un tiempo de vida de 124 (TDV=124) y como vemos en la topología de la red que el datagrama ha pasado por 4 routers para llegar a su destino, quiere decir que el tiempo de vida con el que se envió originalmente es de 124 más 4, lo que nos da 128. ¿Por qué sabe el analizador de protocolos que el campo “Checksum” de la cabecera IP contenida en la trama con ID=6 que se muestra en la ventana anterior tiene un valor correcto? El analizador etiqueta como “Correct” el campo “Checksum” porque se ha encargado de calcularlo. Para ello suma todas las palabras de 16 bits que componen la cabecera salvo el propio “Checksum”, sin olvidar que las opciones, de haberlas, también forman parte de la cabecera. En nuestro caso la suma sería 4540 + 0052 + B401 + 4000 + 0101 + C005 + 0537 + D25D + 690D lo cual daría como resultado 33B3A. Como es mayor de 16 bits, los bits más significativos se eliminan y se suman otra vez a los 16 bits menos significativos, lo que en nuestro caso significa sumar 3B3A + 3 obteniéndose 3B3D. Esta cifra aún no es el checksum, pues falta complementarlo a uno. Al hacer el complemento a uno de 3B3D obtenemos C4C2 que coincide con el “Checksum” que aparece en la cabecera, así que podemos decir que éste es correcto y que la cabecera está libre de errores, o al menos de errores que se puedan detectar mediante esta sencilla técnica de detección de errores. A continuación se muestra la trama con ID=9 contenida en el archivo “fichero55.cap”:

¿Cómo sabe el analizador que es correcto el campo “Checksum” del mensaje ICMP de esta trama? Lo calcula nuevamente y comprueba que coincide con el que ha recibido. Para calcularlo realiza la suma de todas las palabras de 16 bits del mensaje ICMP, salvo el propio checksum, que no es sumado. Si el número de octetos fuese impar, como en nuestro caso, se añade un octeto a cero al final para que haya un numero entero de palabras de 16 bits. En nuestro caso la suma es 0800 + 0100 + 5F00 + 6162 + 6364 + 6566 + 6768 + 696A + 6B6C + 6D6E + 6F70 + 7172 + 7374 + 7576 + 7761 + 6200 = 5DF05. Si el número que hemos obtenido fuese mayor de 16 bits, cogeríamos los bits sobrantes y los volveríamos a sumar a los 16 bits menos significativos, lo que en nuestro caso sería DF05 + 5 = DF0A. Por último, el resultado de 16 bits así obtenido se complementa a uno para obtener el checksum. En nuestro caso el complemento a uno de DF0A es 20F5, que coincide exactamente con el checksum que hemos recibido. Quiere esto decir que el mensaje ICMP no tiene errores, o al menos que no tiene errores que puedan detectarse con esta sencilla técnica de detección de errores. ¿Por qué no tiene problemas de tiempo de vida el mensaje ICMP generado por el segundo comando PING? Porque se genera con un tiempo de vida de valor 5, que es el valor mínimo suficiente para poder recorrer una ruta que tenga 4 routers, justo los que separan al “PC_A0_55” del “PC_DE_13”.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP




Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


C:\WINDOWS>ipconfig Configuración IP de Windows 98 0 Ethernet adaptador : Dirección IP . . . . . . . . . . . . . : 192.5.5.55 Máscara de subred . . . . . . . . . . : 255.255.255.0 Puerta de enlace predeterminada . . . : 192.5.5.1 C:\WINDOWS>arp –a Interfaz: 192.5.5.55 on Interface 0x1000002 Dirección IP Dirección física Tipo 192.5.5.1 00-10-7b-81-ae-26 dinámico C:\WINDOWS>ping -n 1 -l 172 219.17.100.16 Haciendo ping a 219.17.100.16 con 172 bytes de datos: Respuesta desde 219.17.100.16: bytes=172 tiempo=64ms TDV=126 Estadísticas de ping para 219.17.100.16: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 64ms, máximo = 64ms, promedio = 64ms C:\WINDOWS>ping -n 1 -l 173 219.17.100.16 Haciendo ping a 219.17.100.16 con 173 bytes de datos: Respuesta desde 219.17.100.16: bytes=173 tiempo=73ms TDV=126 Estadísticas de ping para 219.17.100.16: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 73ms, máximo = 73ms, promedio = 73ms C:\WINDOWS>ping -n 1 -l 345 219.17.100.16 Haciendo ping a 219.17.100.16 con 345 bytes de datos: Respuesta desde 219.17.100.16: bytes=345 tiempo=122ms TDV=126 Estadísticas de ping para 219.17.100.16: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 122ms, máximo = 122ms, promedio = 122ms C:\WINDOWS> ¿En que red está el ordenador al que le estamos haciendo PING? Estamos haciendo PING al “PC_B_16” desde el “PC_A0_55”. El “PC_B_16” está en la red 219.17.100.0 /24, que es distinta a la red del equipo que realiza los PINGs, pero que está conectada a ella mediante una serie de routers y otras redes. ¿Se habrá generado alguna petición ARP en la red del “PC_A0_55”? Todo el tráfico de tramas es entre el “Router_A” y el “PC_A0_55” y por el comando “arp –a” vemos que el PC conoce la MAC del router antes de empezar a ejecutarse el primer comando PING. A menos que dicha entrada de la caché ARP del PC caduque justo antes de ejecutar el primer comando PING, el PC no realizará ninguna petición ARP. No sabemos si el router conoce la MAC del PC, aunque parece lógico pensar que si el PC conoce la del router, el router conocerá la del PC, así que es muy probable que el router tampoco realice una petición ARP para averiguar la dirección MAC del “PC_A0_55”. ¿Cuántas rutas puede seguir un paquete para ir desde “PC_A0_55” a “PC_B_16” y viceversa? Sólo hay una ruta posible, la que pasa por el “Router_A” y el “Router_B”. ¿Cuántos mensajes ICMP de petición de eco se han generado? Tres mensajes, uno por cada comando PING, ya que se ha usado la opción “-n” con el parámetro 1. ¿Se han recibido todos los mensajes ICMP de respuesta de eco que se estaban esperando? Sí. La salida en pantalla de los comandos PING indica que se han recibido todos las respuestas. Se ha capturado el tráfico generado por los comandos anteriores tanto en la red origen de los PINGs como en la red destino de los PINGs. Es decir, se han capturado las tramas vistas por el “PC_A0_55” en su red y las tramas vistas por el “PC_B_16” en su red. A continuación se muestra una ventana de un analizador de protocolos en la que aparece el tráfico visto por “PC_A0_55”, el cual se ha almacenado en el archivo “fichero55.cap”:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Y a continuación puede verse la ventana del analizador correspondiente al tráfico capturado en la red del ordenador “PC_B_16”, el cual se ha almacenado en el archivo “fichero16.cap”:

Las dos ventanas anteriores están mostrando en el listado de tramas información acerca del instante de tiempo en que se capturaron las tramas, medido en segundos y de forma relativa al instante en que se capturó la primera de las tramas. En dicho listado se muestran también las direcciones MAC origen y destino de las tramas. Puede observarse que en ambas redes sólo hay intercambio de tramas entre el router por defecto de la red y un único PC. No hay señales de que otros PCs hayan enviado alguna trama.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Tienen las tramas que emite el “PC_A0_55” el tamaño que se esperaba? El “PC_A0_55” ha emitido tres tramas dirigidas al router por defecto de su red. Se distinguen por tener como MAC origen 000102B44EB0 y como MAC destino 00107B81AE26. Todas ellas están etiquetadas en la columna “Summary” del listado de tramas con el texto “ICMP Echo Request”, y sus longitudes son 218, 219 y 391 octetos respectivamente. Cada trama se ha generado al ejecutar un comando PING. Son de diferentes longitudes porque cada comando PING usaba una longitud distinta para los datos opcionales del mensaje ICMP de petición de eco. El primer PING incluía en el mensaje ICMP de petición de eco unos 172 octetos de datos opcionales, que sumados a los 8 del principio del mensaje ICMP de petición de eco, los 20 de la cabecera mínima de IP y los 18 de los diferentes campos de cabecera y cola de la trama, dan lugar a una trama de un tamaño (“Size”) de 218 octetos, que es precisamente lo que nos dice el analizador que mide la primera de las tramas que aparecen en el listado de tramas. Análogamente, el segundo PING, con 173 octetos de datos opcionales, se comprueba que hecho que el PC genere una trama de 219 octetos. Lo mismo ocurre con el tercer PING de 345 octetos datos opcionales, que ha generado una trama con un tamaño de 391 octetos., así que podemos decir que las todas las tramas emitidas por “PC_A0_55” tienen una tamaño acorde al contenido que transportan. ¿Tienen las tramas que emite el “PC_B_16” el tamaño que se esperaba? El “PC_B_16” ha emitido tres tramas dirigidas al router por defecto de su red. Se distinguen por tener como MAC origen 00047699097C y como MAC destino 00D058ADCD17. Todas ellas están etiquetadas en la columna “Summary” del listado de tramas con el texto “ICMP Echo Reply”, y sus longitudes son 218, 219 y 391 octetos respectivamente. Cada trama se ha generado como respuesta a la llegada de un mensajes ICMP de petición de eco proveniente del “PC_A0_55”. Los mensajes ICMP de respuesta de eco son del mismo tamaño que los mensajes ICMP de petición de eco a los que están asociados. Quiere esto decir que los tres mensajes ICMP de respuesta de eco tendrán 172, 173 y 345 octetos respectivamente de datos opcionales, pues eso es lo que tenían los mensajes de petición de eco. Por tanto, que el “PC_B_16” haya generado tramas con un tamaño de 218, 219 y 391 octetos es completamente normal. Nótese que son los mismos tamaños de las tramas emitidas por el “PC_A0_55”. ¿Cuántas tramas le envía el “Router_A” al “PC_A0_55”? Le envía 5 tramas. ¿Le ha llegado al “PC_A0_55” algún fragmento de datagrama? Sí. Según se ve en el panel central de la primera ventana de captura, la trama con ID=3 del “fichero55.cap” muestra en su interior un fragmento de datagrama. El campo “Flags/Fragment Offset” vale 0x2000 (hexadecimal), luego los “Flags” valen 001 en binario, por lo que el bit MF vale 1, indicando que hay más fragmentos (“More Fragments”) detrás de este fragmento. Como el campo “Fragment Offset” vale 0, quiere decir que este fragmento es el primero de todos los fragmentos en los que se ha dividido el datagrama original. El datagrama original, en lugar de llegar entero y encapsulado en una sola trama, tendrá que llegar fragmentado y cada uno de los fragmentos encapsulado en una trama, lo cual parece ser la razón por la cual el “Router_A” le ha hecho entrega de más de tres tramas al “PC_A0_55”. ¿Se ha producido fragmentación en el primer PING? No. Ya hemos comentado antes que la primera trama que envía “PC_A0_55” contiene un datagrama completo y como la primera trama que recibe “PC_A0_55”, conteniendo el mensaje ICMP de respuesta de eco, tiene el mismo tamaño que la que envió, podemos decir que en el viaje desde “PC_B_16” hacia “PC_A0_55” no se produce fragmentación. Simplemente analizando el tráfico visto en la red de “PC_A0_55” no podemos saber si el datagrama que se ha enviado se ha fragmentado. Podría ocurrir que aunque el que nos llega no está fragmentado, el que hemos enviado si se haya fragmentado, debido a que haya seguido otra ruta distinta. En nuestro caso, como sabemos que la ruta seguida a sido la misma, sabemos que si no se ha fragmentado en el camino de vuelta, tampoco tienen por qué fragmentarse en el camino de ida. Además, puesto que nosotros también tenemos acceso al tráfico capturado en la red del “PC_B_16”, podemos confirmar que el mensaje de petición de eco que envió “PC_A0_55” ha llegado en un datagrama completo y sin fragmentar. ¿Podemos hacer alguna afirmación acerca de la MTU de las redes que unen “PC_A0_55” y “PC_B_16” después de analizar el tráfico generado por la ejecución del primer comando PING? Ya sabíamos que la MTU de las redes en las que se encuentran ambos PCs es de 1500, pues son redes Ethernet. Son redes capaces de transportar sin fragmentar datagramas IP con una longitud total de hasta 1500 octetos. De la red que une el “Router_A” con el “Router_B” lo único que podemos decir hasta el momento es que si ha sido capaz de dejar pasar un datagrama de 200 octetos de longitud total, su MTU debe ser mayor o igual a 200 octetos. Nótese que sabemos que el datagrama IP emitido por el primer comando PING tiene 200 octetos de longitud total porque 200 es la suma de

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


20 octetos de la cabecera IP mínima, 8 octetos de cabecera ICMP de petición de eco y 172 octetos de datos opcionales del datagrama ICMP de petición de eco. ¿Cuándo se ejecutó el segundo comando PING? Analizando los tiempos que se muestran en la columna “Elapsed [sec]” del listado de tramas, podemos ver que el segundo comando PING se ejecutó, aproximadamente, unos 23 segundos después de que se ejecutase el primer comando PING. ¿Cuándo se ejecutó el tercer comando PING? Analizando los tiempos que se muestran en la columna “Elapsed [sec]” del listado de tramas, podemos ver que el tercer comando PING se ejecutó, aproximadamente, unos 46 segundos después de que se ejecutase el primer comando PING. ¿Se ha producido fragmentación en el segundo comando PING? Sí que se ha producido fragmentación. Sabemos, por el tamaño de la segunda trama enviada por “PC_A0_55”, que ésta contenía un datagrama IP sin fragmentar que transportaba el mensaje ICMP de petición de eco enviado por el segundo comando PING. Por otra parte, nos damos cuenta de que, a los pocos milisegundos de enviar la segunda trama, al “PC_A0_55” le llegan dos tramas que, por su tamaño, son incapaces de albergar un datagrama completo conteniendo el mensaje ICMP de respuesta de eco que se está esperando. Sin embargo, por la salida en pantalla del segundo comando PING, sabemos que la respuesta al PING llegó a los 73 milisegundos, por lo que podemos decir que esas dos tramas que se han recibido en la red del “PC_A0_55”, con ID=3 e ID=4, contienen los fragmentos en los que se ha dividido el datagrama con el mensaje ICMP de respuesta de eco que ha enviado el “PC_B_16”. Naturalmente se puede llegar a esta misma conclusión realizando, con ayuda del analizador de protocolos, una inspección más minuciosa del contenido de estas tramas. ¿Qué podemos decir de la MTU de la red que une al “Router_A” con el “Router_B”, a la vista del análisis del tráfico generado por el primer y el segundo PING? Ya habíamos dicho que la MTU de dicha red era mayor o igual que 200, pues dejó pasar un datagrama de 200 octetos de longitud total generado por el primer comando PING. Como acabamos de decir que se ha producido fragmentación con el segundo comando PING, en el cual lo que se envía y se recibe es un datagrama IP de 201 octetos de longitud total, esto quiere decir que la MTU de dicha red es inferior a 201 octetos. En conclusión, debemos afirmar que la MTU de la red que une al “Router_A” con el “Router_B” es de 200 octetos exactamente. ¿Por qué dice el analizador de protocolos que la trama con ID=3 del “fichero55.cap” tiene incorrecto el valor del campo “Checksum” del mensaje ICMP contenido en dicha trama? El analizador ha calculado el “Checksum” del trozo de mensaje ICMP contenido en esta trama, lo cual le da un valor de 0x7D8C. Sin embargo el valor almacenado en el campo “Checksum” del mensaje ICMP es de 0x3EB7, lo cual le induce a pensar que este “Checksum” es erróneo. En realidad no hay tal error, pues lo que debería hacer el analizador es calcular el “Checksum” del mensaje ICMP completo, para lo cual debería buscar todos los trozos del mensaje ICMP, que están repartidos en más de una trama, ya que este datagrama es realmente un fragmento de datagrama. ¿Qué estructura tiene el fragmento contenido en la trama con ID=3 del archivo “fichero55.cap”? Tiene una estructura idéntica a la de un datagrama normal y corriente. Los fragmentos de datagrama tienen una cabecera IP del mismo tipo que los datagramas normales. Lo que ocurre cuando un datagrama se fragmenta es que sus datos son repartidos en varios datagramas llamados fragmentos. Estos datagramas se sabe que son fragmentos porque, o tienen a valor 1 el bit “MF” de la cabecera IP, o tienen el campo “Fragment Offset” a un valor distinto de cero, o ambas cosas. ¿Qué contienen las trama con ID=2 e ID=3 del archivo “fichero16.cap”? Como ya hemos dicho anteriormente, la trama con ID=4 capturada en la red del “PC_B_16” contiene el mensaje ICMP que envía dicho PC como respuesta al mensaje ICMP de petición de eco generado por el segundo comando PING. Nótese como en el panel central de la ventana de captura puede verse que la longitud total de dicho datagrama es de 201 octetos, que es lo adecuado para contener un mensaje ICMP de petición de eco con 173 octetos de datos opcionales. Pues bien, si esta trama es la respuesta de eco, quiere decir que las tramas con ID=2 e ID=3 deben transportar los dos fragmentos en que se ha dividido el datagrama que contenía el mensaje ICMP de petición de eco. Nótese también que los tiempos de llegada de estas tres tramas son muy similares, en torno a los 23 segundos, y que los tamaños de las dos primeras son inferiores al tamaño de la tercera de ellas. ¿Qué quiere decir el texto “IP PRO=ICMP ID=62237 LEN=25 FRAG” que aparece en la columna “Summary”, asociado a la trama con ID=4 del archivo “fichero55.cap”? Quiere decir que la trama contiene un datagrama IP que a su vez contiene datos del protocolo ICMP. El datagrama IP tiene el valor 62237 en el campo “Identification” de su cabecera, siendo 25 octetos la longitud total del datagrama. Además, nos indica que el datagrama IP no es un datagrama completo, sino que se trata de un fragmento.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


A continuación se muestra el contenido de la trama con ID=4 del archivo “fichero55.cap”:

¿Contiene un fragmento de datagrama la trama con ID=4 del “fichero55.cap”? Sí. Concretamente se trata del fragmento que ocupa el último lugar de la serie de fragmentos en que se ha dividido el datagrama original, pues el bit “MF” (“More Fragments”) está a cero. Nótese que el bit “MF” es el tercero de los bits del campo “Flags” y que, cuando su valor es cero, el analizador de protocolos lo etiqueta con el texto “Last Fragment” (último fragmento). ¿Dónde están los demás fragmentos que derivan del mismo datagrama original del que deriva el fragmento mostrado en la trama con ID=4 del ·fichero55.cap”? En la trama con ID=3 del “fichero55.cap”, mostrada en una de las ventanas anteriores, se encuentra el otro fragmento de datagrama que falta para poder reconstruir el datagrama completo. Sabemos que ese fragmento deriva del mismo datagrama original que el otro fragmento pues el campo “Identification” tiene el mismo valor en ambos casos, 62237. Por otro lado, en la cabecera de dicho fragmento puede verse que se trata del primer fragmento, pues el campo “Fragment Offset” vale cero y el bit “MF” está a valor 1. Se trata de un fragmento con 176 octetos de datos (196 de longitud total menos 20 de cabecera), que son precisamente los octetos que indica el campo “Fragment Offset” del fragmento de datagrama contenido en la trama con ID=4 del “fichero55.cap”. Es por eso que sabemos que un fragmento va justo a continuación del otro, sin más fragmentos intermedios. Nótese que el valor del campo “Fragment Offset” viene expresado en grupos de 8 octetos, por lo que los 176 octetos que hemos mencionado antes se calculan multiplicando por 8 el valor del dicho campo, que en este caso era de 22 (0000000010110 en binario). ¿Cómo sabemos de que tipo son los 5 octetos de datos contenidos en el fragmento de datagrama de la trama con ID=4 del “fichero55.cap”? A través del valor del campo “Protocol” de la cabecera IP del fragmento. En este caso, al valer 1 sabemos que se trata de 5 octetos de datos del protocolo ICMP. No podemos interpretarlos porque para ello necesitaríamos conocer de que tipo de mensaje ICMP se trata, lo cuál es algo que sólo se sabe analizando el primer octeto del mensaje ICMP.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Por qué tiene un tamaño de 64 octetos la trama ID=4 del “fichero55.cap”, si el contenido de dicha trama es un fragmento de datagrama cuya longitud total (“Total Length”) es de sólo 25 octetos? En principio bastaría con una trama de 43 octetos para dar cabida un contenido de 25 octetos. Lo que ocurre es que las tramas Ethernet deben tener un tamaño mínimo de 64 octetos. Ese es el motivo de que el campo “Data/Padding” (Datos/Relleno) aparezca con una longitud de 21 octetos. Esos 21 octetos de relleno pueden tomar cualquier valor, pues no son serán tratados por el equipo que reciba los 25 octetos del fragmento de datagrama. Es la tarjeta Ethernet la que se encarga automáticamente de introducir este relleno siempre que sea necesario. ¿Porqué el fragmento de datagrama de la trama con ID=3 del “fichero55.cap” es de una longitud total de 196 octetos cuando sabemos que la red que ha causado la fragmentación tiene una MTU de 200 octetos? Todos los fragmentos, con excepción del último, tienen que tener unos datos cuya longitud sea múltiplo de 8. Esto es así porque un cada fragmento se anota la longitud del los datos que van delante de ellos, pero medida en grupos de 8 octetos. Así, este fragmento tiene 176 octetos de datos (196 menos 20 de cabecera) y el siguiente fragmento (el de la trama con ID=4 del “fichero55.cap”) tiene un valor de 22 en su campo “Fragment Offset”, indicando que hay 176 (22 por 8) octetos de datos delante de él. Por todo ello, si el fragmento que nos ocupa hubiese tenido una longitud total de 197, 198, 199 o 200 octetos (el máximo), los datos que hubiese contenido no habrían tenido una longitud múltiplo de 8. Cuando se fragmenta se intenta crear fragmentos del mayor tamaño posible, de forma que el último fragmento sea lo menor posible, cumpliendo siempre la norma de que todos los fragmentos, con excepción del último, deben tener unos datos cuya longitud sea múltiplo de ocho. A continuación se muestra el contenido de la trama con ID=2 del archivo “fichero55.cap”:

¿Por qué sabemos que el mensaje ICMP de respuesta de eco contenido en las tramas con ID=3 e ID=4 del “fichero55.cap” se corresponde con el mensaje ICMP de petición de eco contenido en la trama con ID=2 del “fichero55.cap”? Porque el valor del los campos “Identified” y “Sequence Number” es el mismo en ambos mensajes. ¿Cuáles son los tres últimos caracteres de los datos opcionales del mensaje ICMP de petición de eco que fueron enviados por “PC_A0_55” mediante la ejecución del segundo comando PING?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Los datos opcionales que se devuelven en la respuesta de eco son los mismos que se han recibido en la petición de eco. En la trama con ID=4 del “fichero55.cap” pueden verse los 5 últimos octetos del datagrama IP que contiene el mensaje ICMP de respuesta de eco debido al segundo comando PING. Estos 5 caracteres que, según se aprecia en la parte inferior de la ventana de captura son “hijkl”, se corresponden con la parte final del mensaje ICMP, que es precisamente el campo “Optional Data”, por lo que podemos decir que los tres caracteres a los que se refiere la pregunta son “jkl”. ¿Debe coincidir el valor del campo “Identification” de la cabecera IP de un datagrama que contenga un mensaje ICMP de respuesta de eco con el valor del mismo campo del datagrama que contenga el mensaje ICMP de petición de eco al que se encuentra asociado dicho mensaje de respuesta? No. Cada equipo va numerando los datagramas IP de forma independiente al resto de equipos, sin tener en cuenta el contenido de los datagramas y procurando distanciar al máximo en el tiempo la emisión de datagramas con el mismo valor del campo “Identification”. ¿En cuantos fragmentos ha llegado al “PC_A0_55” la respuesta al tercer comando PING? En dos fragmentos. El primero le ha llegado en una trama con 214 octetos de tamaño, lo cual quiere decir que el primer fragmento mide 196 octetos de longitud total y tiene 176 octetos de datos (176 es múltiplo de ocho). El segundo fragmento le ha llegado en una trama con 215 octetos de tamaño, lo cual quiere decir que el segundo fragmento mide 197 octetos de longitud total y tiene 177 octetos de datos (177 no es múltiplo de ocho). 176 más 177 son 353 octetos de datos, lo que nos da una longitud total de 373 octetos para el datagrama original sin fragmentar. Esto concuerda perfectamente con los 391 octetos que tiene por tamaño la trama emitida por “PC_A0_55” como consecuencia de la ejecución del tercer comando PING. ¿Supone un error el que se haya recibido el segundo fragmento con una longitud mayor al primero? En este caso no pues el primer fragmento es de la mayor longitud posible y el último fragmento es de la menor longitud posible, aunque ésta sea mayor que la del primero. ¿Se habrían recibido estos dos mismos fragmentos como respuesta al tercer comando PING, caso de haber tenido una MTU de 196 octetos la red que une al “Router_A” con el “Router_B”? No. En ese caso el segundo fragmento no cabría por la red, por lo que se habrían generado tres fragmentos en lugar de dos. ¿Se habrían recibido estos dos mismos fragmentos como respuesta al tercer comando PING, caso de haber tenido una MTU de 197 octetos la red que une al “Router_A” con el “Router_B”? Sí. Ambos fragmentos habrían cabido perfectamente. ¿Se podría haber averiguado la MTU de la red que une al “Router_A” con el “Router_B” analizando únicamente el tráfico generado en la red del “PC_A0_55” como consecuencia de la ejecución del tercer comando PING? No. La prueba está en que una MTU de 197 octetos habría generado unos fragmentos iguales a los que se han generado para una MTU de 200 octetos, como resultado de la ejecución del tercer comando PING. A continuación se muestra el contenido de la trama con ID=7 del archivo “fichero16.cap”:

¿Cuál es el valor del campo “Checksum” de la cabecera IP del datagrama contenido en la trama con ID=7 del archivo “fichero16.cap”? Como estamos viendo únicamente el volcado en hexadecimal de la trama, debemos averiguar la posición que ocupa dicho campo “Checksum” en la trama sin ayuda del analizador de protocolos. Para ello podemos empezar a contar desde el principio de la trama los campo que le preceden: MAC destino (6 octetos), MAC origen (6 octetos), “EtherType” (2 octetos), “Version/Header Length” (1 octeto), “Type of Service” (1 octeto), “Total Length” (2 octetos), “Identification” (2 octetos), “Flags/Fragment Offset” (2 octetos), “Time To Live” (1 octeto) y “Protocol” (1 octeto), lo que nos indica que el campo “Checksum” de la cabecera IP está en la posición 0x18 (hexadecimal) empezando a contar desde el cero. Y como el campo “Checksum” ocupa dos octetos, resulta que su valor es 0x410C en hexadecimal.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP



Estrictamente hablando, lo que se muestra en la figura no es una red (dominio de broadcast) sino que es un conjunto de redes interconectadas mediante routers. Por tanto, lo más correcto sería decir que estamos frente a una interred o una internetwork. En esta interred podemos distinguir cinco redes Ethernet, implementadas con un sencillo concentrador (Hub). Nótese que los enlaces Ethernet entre equipos están etiquetados con la palabra “Eth”. Los enlaces que no están etiquetados con “Eth” están etiquetados con “PPP” indicando que son enlaces serie punto a punto que usan como protocolo de nivel 2 el protocolo PPP (Point to Point Protocol). En esta interred, la mayoría de enlaces entre routers son de tipo “PPP”. Cada enlace “PPP” es una red independiente con tan solo dos equipos. Cada equipo tiene asignado un nombre. Los PCs tienen asignada una dirección IP y una máscara de subred en la notación “/n”, donde “n” es el número de bits a uno en la máscara de subred. Los hubs son modelos sencillos, no gestionables, y no tienen dirección IP. Los routers tienen una dirección IP en cada interfaz. Las interfaces Ethernet están etiquetadas con “e0” o “e1”. Las interfaces serie están etiquetadas con “s0” o “s1”. Los PCs conectados al “Hub_DE” tienen configurado como router por defecto al “Router_D”, de forma que dirigirán a él los paquetes que quieran hacer llegar fuera de su propia red. En el “PC_DE_13” se ha abierto una sesión MS-DOS y se han ejecutado los comandos que aparecen listados a continuación:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


C:\WINDOWS>ipconfig Configuración IP de Windows 98 0 Ethernet adaptador : Dirección IP . . . . . . . . . . . . . : 210.93.105.13 Máscara de subred . . . . . . . . . . : 255.255.255.0 Puerta de enlace predeterminada . . . : 210.93.105.1 C:\WINDOWS>ping -n 1 -l 232 223.8.151.10 Haciendo ping a 223.8.151.10 con 232 bytes de datos: Respuesta desde 223.8.151.10: bytes=232 tiempo=98ms TDV=126 Estadísticas de ping para 223.8.151.10: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 98ms, máximo = 98ms, promedio = 98ms C:\WINDOWS>ping -n 1 -l 10 -f 223.8.151.10 Haciendo ping a 223.8.151.10 con 10 bytes de datos: Respuesta desde 223.8.151.10: bytes=10 tiempo=17ms TDV=126 Estadísticas de ping para 223.8.151.10: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 17ms, máximo = 17ms, promedio = 17ms C:\WINDOWS>ping -n 1 -l 233 223.8.151.10 Haciendo ping a 223.8.151.10 con 233 bytes de datos: Respuesta desde 223.8.151.10: bytes=233 tiempo=106ms TDV=126 Estadísticas de ping para 223.8.151.10: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 106ms, máximo = 106ms, promedio = 106ms C:\WINDOWS>ping -n 1 -l 1300 -f 223.8.151.10 Haciendo ping a 223.8.151.10 con 1300 bytes de datos: Respuesta desde 210.93.105.1: Es necesario fragmentar el paquete pero se especificó DF. Estadísticas de ping para 223.8.151.10: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 0ms, máximo = 0ms, promedio = 0ms C:\WINDOWS>ping -n 1 -l 1000 -f 223.8.151.10 Haciendo ping a 223.8.151.10 con 1000 bytes de datos: Es necesario fragmentar el paquete pero se especificó DF. Estadísticas de ping para 223.8.151.10: Paquetes: enviados = 1, Recibidos = 0, perdidos = 1 (100% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 0ms, máximo = 0ms, promedio = 0ms C:\WINDOWS> ¿En que red está el ordenador al que le estamos haciendo PING? Estamos haciendo PING al “PC_C_10” desde el “PC_DE_13”. El “PC_C_10” está en la red 223.8.151.0 /24, que es distinta a la red del equipo que realiza los PINGs, pero que está conectada a ella mediante una serie de routers y otras redes. ¿Cuántas rutas puede seguir un paquete para ir desde “PC_DE_13” a “PC_C_10” y viceversa? Sólo hay una ruta posible, la que pasa por el “Router_D” y el “Router_C”. ¿Cuántos mensajes ICMP hemos solicitado que se generen mediante los comandos PING? Cinco mensajes, uno por cada comando PING, ya que se ha usado la opción “-n” con el parámetro 1. ¿Se han recibido todos los mensajes ICMP de respuesta de eco que se estaban esperando? No. Sólo los tres primeros comandos PING han recibido de vuelta mensajes ICMP de respuesta de eco. Los dos últimos comandos PING no han recibido respuesta de parte de “PC_C_10” debido a que el mensaje ICMP de petición de eco no pudo llegar al necesitar fragmentarse y habérselo prohibido.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Se ha capturado el tráfico generado por los comandos anteriores tanto en la red origen de los PINGs como en la red destino de los PINGs. Es decir, se han capturado las tramas vistas por el “PC_DE_13” en su red y las tramas vistas por el “PC_C_10” en su red. A continuación se muestra una ventana de un analizador de protocolos en la que aparece el tráfico visto por “PC_DE_13”, el cual se ha almacenado en el archivo “fichero13.cap”:

Y a continuación puede verse la ventana del analizador correspondiente al tráfico capturado en la red del ordenador “PC_C_10”, el cual se ha almacenado en el archivo “fichero10.cap”:

¿Qué información muestran las dos ventanas anteriores? Únicamente están mostrando el listado con de tramas capturadas en cada una de las redes. Para cada trama sólo se está mostrando el tamaño y las direcciones MAC origen y destino junto con un pequeño resumen (“Summary”) del contenido de la misma. ¿Cuántos equipos están intercambiando tramas en la red del “PC_DE_13”? Sólo dos, pues las dos únicas direcciones MAC que aparecen en dichas tramas son la 00D058ADCD11, que es la dirección MAC de la interfaz e0 del “Router_D” y la 000102B44F4B, que es la MAC del “PC_DE_13”. Esto no tiene por qué significar que los que están intercambiando paquetes sean el “Router_D” y el “PC_DE_13”. Habría que ver las direcciones IP de los paquetes contenidos en las tramas para saber qué equipos están enviándose de datagramas IP. ¿Cuántos equipos están intercambiando tramas en la red del “PC_C_10”? Sólo dos, pues las dos únicas direcciones MAC que aparecen en dichas tramas son la 00D058ADCD13, que es la dirección MAC de la interfaz e0 del “Router_C” y la 000476990971, que es la MAC del “PC_C_10”. ¿Genera el “PC_DE_13” alguna trama que contenga fragmentos de datagrama? No. Los comandos PING que se han ejecutado en “PC_DE_13” generan datagramas IP con una longitud menor de 1500 octetos, los cuales caben en la red Ethernet a la que está conectado dicho PC, sin necesidad de ser fragmentados. ¿Genera el “PC_C_10” alguna trama que contenga fragmentos de datagrama? No. Las tramas generadas por “PC_C_10” contienen datagramas del mismo tamaño que los que envió el “PC_DE_13”, puesto que son los mensajes ICMP de respuesta de eco asociados a los mensajes ICMP de petición de eco que ha enviado el “PC_DE_13”. Quiere esto decir que como los comandos PING que se han ejecutado en “PC_DE_13” han generado datagramas IP menores de 1500 octetos, los datagramas generados por “PC_C_10” también lo serán menores que y cabrán en la red Ethernet a la que está conectado el “PC_C_10” sin necesidad de ser fragmentados. A continuación se muestra una ventana de un analizador de protocolos en la que aparece el tráfico visto por “PC_DE_13”, el cual se ha almacenado en el archivo “fichero13.cap”, de forma que en el listado de tramas se vean las direcciones de red junto con información temporal:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Proviene del “PC_C_10” el datagrama IP que se muestra decodificado en la ventana anterior?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


No. Proviene del “Router_D”, pues la IP origen de dicho datagrama es la 210.93.105.1, que es precisamente la dirección IP de la interfaz e0 de dicho router. A juzgar por el listado de tramas que aparece en la ventana anterior, éste es el único datagrama de los que ha recibido el “PC_DE_13” que no ha sido enviado por el “PC_C_10”. ¿Qué indica el datagrama IP contenido en la ventana anterior? El datagrama IP que ha enviado el router contiene un mensaje ICMP del tipo 3, “Destination Unreachable” (Destino inalcanzable) y cuyo código es el 4, “Fragmentation Needed but Don’t-Fragment Bit Set” (Se necesita fragmentar pero el bit DF está activado). Este mensaje ICMP es enviado por el “Router_D” al “PC_DE_13” para avisarle de que va a descartar un datagrama que dicho PC ha enviado, siendo el motivo del descarte el que el datagrama necesita ser fragmentado para poder ser enviado y se ha prohibido su fragmentación mediante la activación del bit DF en dicho datagrama. Este mensaje ICMP de tipo 3 incluye una copia de parte del datagrama descartado, concretamente su cabecera IP y 8 octetos (64 bits) de datos. ¿Por qué en el datagrama mostrado en la ventana anterior se pueden ver dos cabeceras IP? La primera de ellas es la cabecera del datagrama que se encuentra encapsulado en la trama. Este datagrama contiene un mensaje ICMP de tipo 3 que informa de un problema con un datagrama. Dicho mensaje ICMP contiene un trozo del datagrama que ha tenido el problema con objeto de que el que lo envió pueda saber exactamente de qué datagrama se trata, así que ese es el motivo por el que el analizador de protocolos nos está mostrando una segunda cabecera IP. Como resulta que en este caso el datagrama con el problema era un mensaje ICMP de petición de eco, podemos ver un trozo de dicho mensaje ICMP a continuación de la segunda cabecera. Nótese como el router sola ha podido copiar los 8 primeros octetos del mensaje ICMP, por lo que ha tenido que omitir todos los datos opcionales. No obstante, estos datos opcionales del mensaje ICMP que han tenido que ser omitidos no son algo relevante para que el “PC_DE_13” averigüe la causa del problema. ¿Qué comando PING generó el datagrama IP del cuál nos está informando el “Router_D”? Ha sido el cuarto comando PING. Nótese que el campo “Total Length” de la segunda cabecera IP que podemos ver en la ventana anterior, correspondiente al datagrama descartado, tiene un valor de 1328. Precisamente es el cuarto comando PING el único que ha generado un datagrama IP de 1328 octetos de longitud total, pues es el único en el que se ha usado la opción “-l” con el parámetro 1300. A continuación se muestra una ventana de un analizador de protocolos en la que aparece el tráfico visto por “PC_C_10”, el cual se ha almacenado en el archivo “fichero10.cap”, de forma que en el listado de tramas se vean las direcciones de red junto con información temporal:

¿Con quién está intercambiando paquetes el “PC_C_10”? Unicamente con el “PC_DE_13”, según se puede comprobar en el listado de tramas tras analizar las direcciones IP origen y destino de los paquetes contenidos en cada una de las tramas. ¿Qué relación guarda cada trama del “fichero10.cap” con cada uno de los comandos PING? Es posible averiguar esto sin necesidad de entrar a analizar en detalle el interior de las tramas, simplemente estudiando el instante en el que se emiten las tramas, su tamaño y el resumen (“Summary”) de su contenido. Se observa en la ventana anterior que el “PC_C_10” transmite tres tramas de tamaños 278, 64 y 279 octetos, lo cual se corresponde con las tres tramas de idénticos tamaños que ha emitido el “PC_DE_13”. Es lógico pensar que estas tres tramas que contienen mensajes de respuesta de eco se corresponden con los tres primeros comandos PING que se han ejecutado, cuyos datos opcionales eran de 232, 10 y 233 octetos respectivamente. Por otro lado, pocos milisegundos antes de la transmisión de cada una de estas tramas se aprecia la llegada de unas tramas que contienen datagramas (fragmentos, sin duda) provenientes del “PC_DE_13” y que están relacionadas también con las ejecución de los tres primeros comandos PING. ¿Por qué no se aprecia en la red del “PC_C_10” el efecto del cuarto y del quinto comando PING?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Porque, según nos muestra la salida en pantalla de dichos comandos, los datagramas no pueden llegar a su destino debido a que se está prohibiendo su fragmentación (usando la opción “-f” del comando PING) y sin embargo para llegar a su destino necesitan ser fragmentados. ¿Qué podemos decir de la MTU de la red que une al “Router_D” con el “Router_C” después de analizar el tráfico generado en la red del “PC_DE_13” por la ejecución del primer comando PING? Vemos que el primer comando PING ha generado la trama con ID=0 conteniendo un datagrama de 260 octetos de longitud total (240 octetos de datos). El datagrama que llega como respuesta a éste debería ser un datagrama del mismo tamaño pero en su lugar han llegado las tramas con ID=1, ID=2 e ID=3, que en este caso son todas del mismo tamaño y contienen cada una un datagrama de 100 octetos de longitud total (80 octetos de datos), que al reensamblarse darán lugar al datagrama que se espera de 260 octetos de longitud total (20 de cabecera más tres veces 80 octetos de datos). Dicho esto, la única conclusión que podemos sacar acerca de la MTU es que es mayor o igual que 100 y menor o igual que 107. Cualquier MTU en ese rango habría provocado los mismos resultados. ¿Qué podemos decir de la MTU de la red que une al “Router_D” con el “Router_C” después de analizar el tráfico generado en la red del “PC_DE_13” por la ejecución del tercer comando PING? Vemos que el primer comando PING ha generado la trama con ID=6 conteniendo un datagrama de 261 octetos de longitud total (241 octetos de datos). El datagrama que llega como respuesta a éste debería ser un datagrama del mismo tamaño pero en su lugar han llegado las tramas con ID=7, ID=8, ID=9 e ID=10, conteniendo los fragmentos que darán lugar al datagrama que se espera. Las tres primeras tramas son del mismo tamaño pues contiene cada una un datagrama de 100 octetos de longitud total (80 octetos de datos). La cuarta trama (ID=10) contiene un datagrama de 21 octetos de longitud total (1 octeto de datos), lo cuál es síntoma de que ese octeto de datos no cabía en el fragmento que portaba la trama con ID=9. Este hecho es lo que nos hace pensar que la MTU de la red es de 100 octetos exactamente, pues de haber sido 101 octetos, la trama con ID=10 no habría sido necesaria ya que la trama con ID=9 habría contenido un datagrama de 101 octetos. ¿Por qué el mensaje ICMP de tipo 3 mostrado en la trama con ID=12 del “fichero13.cap” no tiene su campo “Unused” a valor cero, tal y como especifica la RFC792, sino que su valor es 0x00000064 en hexadecimal? Eso es porque el router que está enviando este mensaje ICMP de tipo 3 y código 4 es un router que implementa el protocolo “Path MTU Discovery” (descrito en la RFC1191) y es capaz de enviar dichos mensajes ICMP con la siguiente estructura: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Code = 4 | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused = 0 | Next-Hop MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internet Header + 64 bits of Original Datagram Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Se observa que el campo “Unused” ocupa ahora solo dos octetos y aparece un nuevo campo “Next-Hop MTU”, que en nuestro caso vale 0x0064 hexadecimal (100 en decimal) y que sirve para que el router informe de cuál es la MTU de la red que ha provocado el descarte del datagrama al no caber por ella y tener el bit DF activado. ¿Ha generado algún tráfico el quinto comando PING? No. En la red del “PC_DE_13” no se observa ninguna trama con 1036 octetos de tamaño, como sería de esperar. Lo que ha ocurrido es que el mensaje ICMP de tipo 3 y código 4 que ha recibido el “PC_DE_13”, después de la ejecución del cuarto comando PING, ha conseguido que el “PC_DE_13” aprenda que en la ruta al “PC_C_10” hay un estrechamiento que no deja pasar sin fragmentar a los datagramas de tamaño mayor que 100 octetos, por lo que al ejecutar el quinto comando PING el PC nos informa de dicha circunstancia sin llegar siquiera a enviar el datagrama. ¿Qué habría ocurrido si no hubiésemos utilizado la opción “-f” en el segundo comando PING? El bit DF de la cabecera IP del datagrama generado estaría en ese caso a valor 0, permitiendo la fragmentación. No obstante, como el tamaño del datagrama generado es inferior a los 100 octetos de la MTU de la red que debe atravesar, da igual que se active o no se active el bit DF pues el datagrama, al no necesitar ser fragmentado, atravesará en ambos casos dicha red sin ninguna clase de problemas.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP




Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


C:\WINDOWS>ipconfig Configuración IP de Windows 98 0 Ethernet adaptador : Dirección IP . . . . . . . . . . . . . : 192.5.5.55 Máscara de subred . . . . . . . . . . : 255.255.255.0 Puerta de enlace predeterminada . . . : 192.5.5.1 C:\WINDOWS>arp –a Interfaz: 192.5.5.55 on Interface 0x1000002 Dirección IP Dirección física Tipo 192.5.5.1 00-10-7b-81-ae-26 dinámico C:\WINDOWS>ping -n 1 -l 1000 210.93.105.13 Haciendo ping a 210.93.105.13 con 1000 bytes de datos: Respuesta desde 210.93.105.13: bytes=1000 tiempo=514ms TDV=124 Estadísticas de ping para 210.93.105.13: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: Mínimo = 514ms, máximo = 514ms, promedio = 514ms C:\WINDOWS> ¿Se ha obtenido respuesta por parte del PC al que se le ha hecho PING? Sí. ¿Cuántas redes ha atravesado el datagrama que hemos enviado con el comando PING? Cinco, contando la red origen y la red destino. ¿Se conoce la MTU de las redes que tiene que atravesar el mensaje ICMP de petición de eco? De momento sólo sabemos que la red origen (192.5.5.0 /24) y la red destino (210.93.105.0 /24) son redes Ethernet, por lo que su MTU es de 1500 octetos. ¿Qué MTU deben tener como mínimo todas las redes que se van a atravesar para que no se produzca la fragmentación del datagrama que hemos enviado con el comando PING? El datagrama enviado tiene 1028 octetos de longitud total, luego necesita que las redes por la que pase tengan una MTU mayor o igual que 1028. ¿Enviará el “PC_A0_55” algún fragmento debido a la ejecución del comando PING? No, pues la MTU de 1500 de la red a la que está conectado dicho PC no hace necesaria la fragmentación en este caso, ya que el único datagrama IP que ha enviado mide 1028 octetos. ¿Enviará el “PC_DE_13” algún fragmento debido a la ejecución del comando PING? No, pues la MTU de 1500 de la red a la que está conectado dicho PC no hace necesaria la fragmentación en este caso, ya que el único datagrama IP que ha enviado mide 1028 octetos. Se ha capturado el tráfico generado por el comando PING tanto en la red origen del PING como en la red destino del PING. Es decir, se han capturado las tramas vistas por el “PC_A0_55” en su red y las tramas vistas por el “PC_DE_13” en su red. A continuación se muestra una ventana de un analizador de protocolos en la que aparece el tráfico visto por “PC_A0_55”, el cual se ha almacenado en el archivo “fichero55.cap”:

¿En cuantos fragmentos se ha dividido el mensaje de respuesta de eco enviado por “PC_DE_13”?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


En 13 fragmentos. Todas las tramas que le han llegado al “PC_A0_55” contienen un fragmento del datagrama original, cuya longitud total era de 1028 octetos (1008 octetos de datos). Eso concuerda con las trece tramas recibidas. Hay 12 tramas que contienen datagramas con 80 octetos de datos, lo cual hace uno 960 octetos de datos. Si a eso le sumamos los 48 octetos de datos del datagrama de la última trama, tenemos los 1008 octetos de datos del datagrama que ha enviado el “PC_DE_13”. Es interesante destacar que todos los fragmentos son iguales salvo el último, que es donde se mete el sobrante. Todos los fragmentos, a excepción del último, están obligados a tener una longitud de los datos que sea múltiplo de 8, cosa que también se está cumpliendo. ¿Qué puede decirse de la MTU de las redes que han atravesado los datagramas IP, después de analizar el tráfico visto en la red del “PC_A0_55”? De momento sólo podemos decir que se ha atravesado una red con una MTU mayor o igual que 100 y menor o igual que 107. Puede haber otras redes con otras MTU mayores que esta, como por ejemplo las dos redes Ethernet con MTU de 1500 octetos. A continuación puede verse la ventana del analizador correspondiente al tráfico capturado en la red del ordenador “PC_DE_13”, el cual se ha almacenado en el archivo “fichero13.cap”:

¿Cuántos fragmentos han llegado al “PC_DE_13”? Han llegado 17 fragmentos, de diferentes longitudes. ¿De qué tamaño son los fragmentos que han llegado al “PC_DE_13”? Hay 11 fragmentos de 100 octetos de longitud total, encapsulados en tramas de 118 octetos de tamaño. También hay 5 fragmentos de 36 octetos de longitud total, encapsulados en tramas de 64 octetos de tamaño, las cuales tendrán 10 octetos de relleno, pues sin él sólo tendrían un tamaño de 54 octetos, insuficiente para una trama Ethernet. Por último ha llegado un fragmento de 68 octetos de longitud total encapsulado en una trama de 86 octetos de tamaño. Todo esto concuerda, pues tenemos 11 fragmentos con 80 octetos de datos, 5 fragmentos con 16 octetos de datos y un fragmento con 48 octetos de datos, lo cual suma 1008 octetos de datos, que son exactamente los que contenía el datagrama original enviado por “PC_A0_55”. ¿Es imprescindible que todos los fragmentos de un mismo datagrama tengan el mismo valor en el campo “Identification” de la cabecera IP? Sí, pues de esta manera se evita que al reensamblar los fragmentos se cuele alguno que provenga de otro datagrama diferente, ya que éste tendrá un valor distinto en el campo “Identification”? podríamos unir inadvertidamente fragmentos que es la única forma de distinguir los fragmentos ¿Qué valor tienen en el campo “Identification” de la cabecera IP el datagrama que envió originalmente el “PC_A0_55”? 39680, pues es ese el valor que se observa también en los fragmentos de dicho datagrama. ¿A que se debe que al “PC_DE_13” hayan llegado fragmentos de tres tamaños diferentes? Está claro que si hubiese sido sólo un router el que ha creado estros fragmentos, entonces sólo habría, como mucho, dos tamaños distintos, siendo de igual tamaño todos los fragmentos distintos del último y pudiendo ocurrir que el último también fuese igual en tamaño a los demás fragmentos. Al no ocurrir esto, podemos decir, de momento, que se ha producido fragmentación en más de un router. Es decir, primero se crearon una serie de fragmentos en un router y luego esos fragmentos han debido ser fragmentados nuevamente en, al menos, otro router más.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Por qué los fragmentos recibidos por “PC_A0_55” sólo presentan dos tamaños diferentes si la ruta que separa ambos PCs es la misma en la ida que en la vuelta? La ruta es la misma, pero no es lo mismo pasar primero por una red con una MTU pequeña y luego por una red con una MTU algo mayor que hacerlo al revés. Si la primera vez que se fragmenta se hace para ajustarse a la MTU más pequeña de entre todas las MTU de las redes que se van a atravesar, el resultado es que sólo se necesita fragmentar una vez. Por el contrario, si primero se fragmenta el datagrama para acomodarse a una MTU que no es la menor de todas, los fragmentos así creados van a tener que fragmentarse nuevamente al pasar por redes con MTU menores. ¿Es compatible el tráfico que ha recibido “PC_A0_55” con la hipótesis de que la red 201.100.11.0 /24 tenga una MTU de 200 octetos, la red 199.6.13.0 /24 tenga una MTU de 1500 octetos y que la red 204.204.7.0 /24 tenga una MTU de 100 octetos? Si las MTU de las redes fuesen esas, efectivamente el tráfico recibido por “PC_A0_55” sería idéntico al que ha recibido. Hay que tener en cuenta que los datagramas enviados por “PC_DE_13” se fragmentarían únicamente en el “Router_D” para acomodarse a una MTU de 100 octetos, que es precisamente el tamaño de todos los fragmentos recibidos por “PC_A0_55”, con excepción del último. ¿Es compatible el tráfico que ha recibido “PC_DE_13” con la hipótesis de que la red 201.100.11.0 /24 tenga una MTU de 200 octetos, la red 199.6.13.0 /24 tenga una MTU de 1500 octetos y que la red 204.204.7.0 /24 tenga una MTU de 100 octetos? Si las MTU de las redes fuesen esas, el datagrama enviado desde el “PC_A0_55” debería fragmentarse en el “Router_A” para acomodarse a la MTU de 200 octetos y luego esos fragmentos deberían fragmentarse otra vez en el “Router_C” para acomodarse a la MTU de 100 octetos. El datagrama original, con 1008 octetos de datos (1028 octetos de longitud total) se fragmentaría en el “Router_A” en 5 fragmentos de 196 octetos de longitud total (176 octetos de datos, múltiplo de 8) y un fragmento de 148 octetos de longitud total (128 octetos de datos). Al pasar por el “Router_C” los fragmentos deberían acomodarse a una MTU de 100 octetos, por lo que los fragmentos de 196 octetos de longitud total (176 de datos) se dividirían en dos fragmentos de 100 octetos de longitud total y uno de 36 octetos de longitud total, mientras que el fragmento de 148 octetos de longitud total se dividiría en uno de 100 octetos de longitud total y otro de 68 octetos de longitud total. Podemos comprobar que eso es precisamente lo que ha recibido el “PC_DE_13”, por lo que la hipótesis de partida es compatible con el tráfico recibido. A continuación se muestra parte de la cabecera IP del datagrama contenido de la trama con ID=5 del “fichero13.cap”:

¿Qué valor tiene el campo “Fragment Offset” del datagrama IP mostrado en la ventana anterior? 0000000101010 en binario o 42 en decimal, lo cuál quiere decir que los datos contenidos en este fragmento deben posicionarse dentro de los datos del datagrama original pero desplazados unos 336 octetos (42 por 8), a contar desde el comienzo de los datos originales. ¿Cuántos fragmentos de los que le llegan a “PC_DE_13” tienen el bit “MF” a valor cero? Sólo puede tener el bit “MF” a cero el fragmento cuyos datos ocupan el último lugar dentro de los datos del datagrama original. ¿Podría ocurrir que llegasen los fragmentos desordenados a su destino final? Podría ocurrir, si existiese más de una ruta posible y no todos los fragmentos siguiesen la misma. Aún así, el destino final podría reensamblar los fragmentos de forma ordenada gracias a la información contenida en cada uno de los fragmentos, la cual sirve para saber qué lugar ocupa cada uno de ellos.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP



Estrictamente hablando, lo que se muestra en la figura no es una red (dominio de broadcast) sino que es un conjunto de redes interconectadas mediante routers. Por tanto, lo más correcto sería decir que estamos frente a una interred o una internetwork. En el “PC_A0_55” se ha abierto una sesión MS-DOS y se ha ejecutado el comando que aparece listado a continuación: C:\WINDOWS>ping 210.93.105.2 Haciendo ping a 210.93.105.2 con 32 bytes de datos: Tiempo de espera agotado. Respuesta desde 210.93.105.2: bytes=32 tiempo=63ms TDV=251 Respuesta desde 210.93.105.2: bytes=32 tiempo=62ms TDV=251 Respuesta desde 210.93.105.2: bytes=32 tiempo=62ms TDV=251 Estadísticas de ping para 210.93.105.2: Paquetes: enviados = 4, Recibidos = 3, perdidos = 1 (25% loss), Tiempos aproximados de recorrido redondo en milisegundos: Mínimo = 62ms, máximo = 63ms, promedio = 46ms C:\WINDOWS>

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Se ha obtenido respuesta por parte del equipo al que se le ha hecho PING? Sí. El equipo destino del PING está respondiendo, aunque no se han recibido el 100% de los mensajes ICMP de respuesta de eco que se estaban esperando. ¿A que equipo se le ha hecho PING? Al “Router_E”, que está conectado a la red 210.93.105.0 /24 por su interfaz Ethernet e0. Se ha capturado el tráfico generado por el comando PING tanto en la red origen del PING como en la red destino del PING. Es decir, se han capturado las tramas vistas por el “PC_A0_55” en su red y las tramas vistas por el “Router_E” en su red. A continuación se muestra una ventana de un analizador de protocolos en la que aparece el tráfico visto por el “PC_A0_55”, el cual se ha almacenado en el archivo “fichero55.cap”:

¿Por qué se han generado cuatro mensajes ICMP de petición de eco? Porque el comando PING del “PC_A0_55” genera cuatro mensajes ICMP a menos que se le diga otra cosa con la opción “–n”. ¿Cuántos mensajes ICMP de respuesta de eco se han recibido? Tres. ¿Cuál de los mensajes ICMP de respuesta de eco no se ha recibido? A juzgar por la salida en pantalla del comando PING, el que se ha perdido es el que iba asociado al primer mensaje ICMP de petición de eco. ¿Cómo sabe el “PC_A0_55” que el primer mensaje ICMP de respuesta de eco que le llega es el que corresponde al segundo mensaje ICMP de petición de eco y no el que corresponde al primer mensaje ICMP de petición de eco?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Lo sabe por el valor de los campos “Identified” y “Sequence Number” de la cabecera ICMP, los cuales son iguales en un mensaje de petición de eco y en su mensaje de respuesta de eco asociado. ¿Podría haber llegado con un tiempo de vida mayor el datagrama que se muestra en la ventana anterior? Teniendo en cuenta que el datagrama IP que se muestra en la ventana anterior ha atravesado cuatro routers y que ha llegado con un valor de TTL de 251, sabemos que se envió con un TTL de 255. Así, para que nos llegue con un TTL mayor de 251 debe enviarse con un TTL mayor de 255, lo cual es imposible. A continuación puede verse la ventana del analizador correspondiente al tráfico capturado en la red del “Router_E”, el cual se ha almacenado en el archivo “ficheroE.cap”:

¿Cuántos mensajes de petición de eco ha recibido el “Router_E”? Cuatro. ¿Cuántos mensajes de respuesta de eco ha enviado el “Router_E”? Tres. ¿Han llegado a su destino todos los mensajes ICMP enviados por el “Router_E”? Si, pues así lo muestra el contenido del “fichero55.cap” ¿Por qué hace el “Router_E” una petición ARP para preguntar la dirección MAC del “Router_D”? Porque no la tiene en su caché ARP y necesita averiguarla para comunicarse con dicho router. ¿Por qué no responde el “Router_E” al primer mensaje ICMP de petición de eco? Porque cuando iba a enviarlo se dio cuenta de que le hacía falta conocer la dirección MAC del “Router_D” y ésta no se encontraba en su caché ARP. Entonces decidió descartar ese paquete y

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


procedió a averiguar la dirección MAC del “Router_D” mediante una petición ARP. Otras inplementaciones de ARP no habrían descartado el paquete, sino que lo habrían dejado esperando hasta que hubiese llegado la respuesta de la petición ARP. ¿Qué dirección MAC origen tiene la primera trama recibida por el “Router_E”? 00D058ADCD11, que es la MAC del “Router_D” ¿Por qué no aprovecha el “Router_E” la llegada de la primera trama para aprender la dirección MAC del “Router_D”? El “Router_E” sólo sabe que le ha llegado una trama con un datagrama dentro, pero ignora si el que envía esa trama es el “Router_D” o es cualquier otro equipo. Para aprender la dirección MAC de un equipo a partir de la dirección IP se usa el protocolo ARP. No se utiliza la llegada de tramas con datagramas IP para deducir cuál es la dirección MAC de un determinado equipo. ¿Por qué el “Router_D” no ha realizado una petición ARP para averiguar la dirección MAC del “Router_E”, mientras que el “Router_E” sí ha tenido que hacerla? Porque el “Router_D” tendría en su caché ARP la MAC del “Router_E”, mientras que el “Router_E” no tendría la del “Router_D”. Un motivo de esto podría ser, por ejemplo, que el “Router_D” tenga establecido un periodo de caducidad para las entradas de la caché ARP más largo que el otro router. A continuación se muestra parte del contenido del primer mensaje ICMP que le llega al “Router_E”:

A continuación se muestra parte del contenido del segundo mensaje ICMP que le llega al “Router_E”:

¿A cuál de los dos mensajes anteriores está respondiendo el “Router_E” con la emisión del mensaje ICMP de respuesta de eco contenido en la trama con ID=4? Está contestando al mensaje que ha recibido en la trama con ID=3, como ya habíamos dicho anteriormente. La ventana anterior nos sirve para confirmarlo, pues en ella podemos ver que el campo “Identified” vale 256 y el campo “Sequence Number” vale 35328, que son exactamente los mismos valores que tiene el mensaje ICMP de respuesta que se mostraba en la trama con ID=4.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP



Estrictamente hablando, lo que se muestra en la figura no es una red (dominio de broadcast) sino que es un conjunto de redes interconectadas mediante routers. Por tanto, lo más correcto sería decir que estamos frente a una interred o una internetwork. En esta interred podemos distinguir cinco redes Ethernet, implementadas con un sencillo concentrador (Hub). Nótese que los enlaces Ethernet entre equipos están etiquetados con la palabra “Eth”. Los enlaces que no están etiquetados con “Eth” están etiquetados con “PPP” indicando que son enlaces serie punto a punto que usan como protocolo de nivel 2 el protocolo PPP (Point to Point Protocol). En esta interred, la mayoría de enlaces entre routers son de tipo “PPP”. Cada enlace “PPP” es una red independiente con tan solo dos equipos. Cada equipo tiene asignado un nombre. Los PCs tienen asignada una dirección IP y una máscara de subred en la notación “/n”, donde “n” es el número de bits a uno en la máscara de subred. Los hubs son modelos sencillos, no gestionables, y no tienen dirección IP. Los routers tienen una dirección IP en cada interfaz. Las interfaces Ethernet están etiquetadas con “e0” o “e1”. Las interfaces serie están etiquetadas con “s0” o “s1”. Los PCs conectados al “Hub_DE” tienen configurado como router por defecto al “Router_D”, de forma que dirigirán a él los paquetes que quieran hacer llegar fuera de su propia red. En el “PC_A0_55” se ha capturado el tráfico generado por una serie de comandos ejecutados en dicho PC. A continuación se muestra una ventana de captura en la que puede verse dicho tráfico:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Los comandos que han provocado el tráfico anterior en la red 192.5.5.18 /24 son los siguientes: C:\WINDOWS>ipconfig Configuración IP de Windows 98 0 Ethernet adaptador : Dirección IP . . . . . . . . . . . . . : 192.5.5.55 Máscara de subred . . . . . . . . . . : 255.255.255.0 Puerta de enlace predeterminada . . . : 192.5.5.1 C:\WINDOWS>arp -a No se encontraron entradas ARP C:\WINDOWS>ping 200.200.200.200 Haciendo ping a 200.200.200.200 con 32 bytes de datos: Respuesta desde 192.5.5.1: Host de destino inaccesible. Respuesta desde 192.5.5.1: Host de destino inaccesible. Respuesta desde 192.5.5.1: Host de destino inaccesible. Respuesta desde 192.5.5.1: Host de destino inaccesible. Estadísticas de ping para 200.200.200.200: Paquetes: enviados = 4, Recibidos = 4, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 0ms, máximo = 0ms, promedio = 0ms C:\WINDOWS>arp -a Interfaz: 192.5.5.55 on Interface 0x1000002 Dirección IP Dirección física Tipo 192.5.5.1 00-10-7b-81-ae-26 dinámico C:\WINDOWS> ¿Se ha obtenido respuesta por parte del equipo al que se le ha hecho PING? No. ¿Pertenece el equipo con dirección IP 200.200.200.200 a la Interred (“Internetwork”) mostrada en una de las páginas anteriores? No. Esa dirección IP no pertenece a ninguna de las redes que constituyen la Interred. ¿De que equipo provienen los mensajes ICMP que han llegado al “PC_A0_55”? Del router 192.5.5.1, que es el router por defecto del “PC_A0_55”. ¿Cuál es la dirección MAC origen de todas las tramas que han llegado al “PC_A0_55”? 00107B81AE26 ¿Por qué han llegado mensajes ICMP de tipo 3 y código 1 al “PC_A0_55”? Estos mensajes ICMP de tipo 3, “Destination Unreachable” (destino inalcanzable) y código 1, “Host Unreachable” (host inalcanzable), nos los envía el router cuando descarta un paquete que le hemos enviado y que no puede ser rutado debido a que no encuentra una ruta por la cuál poder enviarlo. Es decir, el router nos avisa de que en su tabla de rutado no hay información acerca de cómo enrutar un paquete cuya IP destino es la 200.200.200.200, adjuntándonos además una copia de parte del paquete que va a descartar, con idea de que nos ayude a nosotros a resolver el problema. ¿Ha enviado el “PC_A0_55” sus datagramas indicando que desea que sean enrutados preferentemente por redes de bajo retardo? No. Para ello debería haberse puesto a 1 el cuarto bit del campo “Type of Service” de la cabecera IP, de forma que el router que lo reciba intente enrutarlo por redes de “Low Delay” (Bajo retardo). Podemos observar, en la copia del paquete que nos devuelve el router, que dicho bit está a 0, indicando “Normal Delay” (Retardo normal). ¿Tienen todos los paquetes que ha enviado el “PC_A0_55” el mismo valor en el campo “Identification” de la cabecera IP? No. Ese campo debe variarse en cada paquete completo que se genera. ¿Por qué sabe el analizador de protocolos que el paquete que ha descartado el router tenía 40 octetos de datos pero al copiarlo dentro del mensaje ICMP de tipo 3 se han perdido 32 octetos? Sabe que tenía 40 octetos originalmente porque la cabecera IP cuya copia viene en el mensaje ICMP indica que la longitud total es de 60 octetos, que se quedan en 40 al restarle 20 de la cabecera. Por otra parte, sabe que el datagrama IP enviado por el router tiene 36 octetos de datos, por lo que descontando los 8 octetos de la cabecera ICMP, tan solo hay cabida para copiar 28 octetos de los 60 octetos que tenía el datagrama descartado, por lo que se han perdido 32 octetos. Estos octetos no son muy importantes, pues son los datos opcionales del mensaje ICMP de petición de eco.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


A continuación se muestra uno de los datagramas IP enviados por el “PC_A0_55”:

¿Por qué el datagrama descartado por el router tiene un tiempo de vida de 31? El datagrama que ha enviado el “PC_A0_55” tenía un tiempo de vida de 32 pues eso es lo que le hemos indicado al comando PING que hiciera. Si el router descarta este datagrama con un tiempo de vida de 31, quiere esto decir que el router primero le ha decrementado en 1 el tiempo de vida y luego se ha dado cuenta de que debía descartarlo pues su destino no formaba parte de ninguna de las redes conocidas por el router. ¿Tiene el “Router_A” una ruta por defecto? No. Está claro que, si el router tuviese una ruta por defecto, habría enviado por dicha ruta a nuestro datagrama en lugar de haberlo descartado. ¿Tienen los cuatro mensajes ICMP de petición de eco el mismo valor en los campos “Identified” y “Sequence Number”? No. Estos campos sirven para luego poder saber a que petición de eco corresponde cada respuesta de eco, por lo que si fueran iguales en los cuatro, no sería posible saberlo. ¿Podemos saber analizando el tráfico capturado, si antes de hacer el PING, el router tenía en su caché ARP una entrada con la dirección IP y la dirección MAC del “PC_A0_55”? Al haber hecho el PC la petición ARP al router, es imposible saber si el router ya tenía la entrada o si la ha creado aprovechando la petición ARP que le hace el PC.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP



Estrictamente hablando, lo que se muestra en la figura no es una red (dominio de broadcast) sino que es un conjunto de redes interconectadas mediante routers. Por tanto, lo más correcto sería decir que estamos frente a una interred o una internetwork. En esta interred podemos distinguir cinco redes Ethernet, implementadas con un sencillo concentrador (Hub). Nótese que los enlaces Ethernet entre equipos están etiquetados con la palabra “Eth”. Los enlaces que no están etiquetados con “Eth” están etiquetados con “PPP” indicando que son enlaces serie punto a punto que usan como protocolo de nivel 2 el protocolo PPP (Point to Point Protocol). En esta interred, la mayoría de enlaces entre routers son de tipo “PPP”. Cada enlace “PPP” es una red independiente con tan solo dos equipos. Cada equipo tiene asignado un nombre. Los PCs tienen asignada una dirección IP y una máscara de subred en la notación “/n”, donde “n” es el número de bits a uno en la máscara de subred. Los hubs son modelos sencillos, no gestionables, y no tienen dirección IP. Los routers tienen una dirección IP en cada interfaz. Las interfaces Ethernet están etiquetadas con “e0” o “e1”. Las interfaces serie están etiquetadas con “s0” o “s1”. Los PCs conectados al “Hub_DE” tienen configurado como router por defecto al “Router_D”, de forma que dirigirán a él los paquetes que quieran hacer llegar fuera de su propia red. En el “PC_A0_55” se ha abierto una sesión MS-DOS y se ha ejecutado el comando que aparece a continuación:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


C:\WINDOWS>ping 200.200.200.200 Haciendo ping a 200.200.200.200 con 32 bytes de datos: Respuesta desde 201.100.11.2: Host de destino inaccesible. Respuesta desde 201.100.11.2: Host de destino inaccesible. Respuesta desde 201.100.11.2: Host de destino inaccesible. Respuesta desde 201.100.11.2: Host de destino inaccesible. Estadísticas de ping para 200.200.200.200: Paquetes: enviados = 4, Recibidos = 4, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 0ms, máximo = 0ms, promedio = 0ms C:\WINDOWS> ¿Por qué está enviando el “Router_B” mensajes ICMP al “PC_A0_55”? Porque está descartando los datagramas Ip que le están llegando con destino al equipo con dirección IP 200.200.200.200, al no conocer a que por qué ruta debe enviarlo. A continuación se muestra el tráfico capturado en la red del “PC_A0_55” como consecuencia de la ejecución del comando PING:

¿Ha sido el “Router_A” capaz de enrutar los cuatro datagramas que le ha enviado el “PC_A0_55”? Sí. La prueba de ello es que han llegado al “Router_B”, que es el que al no poder enrutarlos los ha descartado y ha avisado al “PC_A0_55” con los correspondientes mensajes ICMP. ¿Es probable que el “Router_A” tenga una ruta específica para la red a la que pertenece el equipo con dirección IP 200.200.200.200? No es probable, puesto que la IP 200.200.200.200 no forma parte de ninguna de las redes que forman la interred a la que pertenece el “Router_A”. Lo que si es más normal es que el “Router_A” tenga establecida una ruta por defecto hacia el “Router_B”, de forma que todos aquellos paquetes para los que no encuentre una red concreta en la tabla de rutado serán enviados al “Router_B”, tal y como se ha hecho con los cuatro datagramas que provenían del “Router_A”. ¿Cuánto vale el “Checksum” del primer mensaje ICMP enviado por el “PC_A0_55”? vale 0xDF5B (hexadecimal), como puede verse en el panel inferior de la ventana de captura. Hay que tener en cuenta que en el primer mensaje ICMP enviado por el “Router_A” viene una copia de la cabecera ICMP del mensaje sobre el que nos están preguntando. Luego el valor que nos interesa está 22 octetos después de que acabe la cabecera de 8 octetos del mensaje ICMP de tipo 3. ¿Con qué tiempo de vida ha emitido el “Router_B” sus datagramas IP? Con 255, pues llegan al “PC_A0_55” con un TTL de 254 y sólo han atravesado un router.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP



Estrictamente hablando, lo que se muestra en la figura no es una red (dominio de broadcast) sino que es un conjunto de redes interconectadas mediante routers. Por tanto, lo más correcto sería decir que estamos frente a una interred o una internetwork. En esta interred podemos distinguir cinco redes Ethernet, implementadas con un sencillo concentrador (Hub). Nótese que los enlaces Ethernet entre equipos están etiquetados con la palabra “Eth”. Los enlaces que no están etiquetados con “Eth” están etiquetados con “PPP” indicando que son enlaces serie punto a punto que usan como protocolo de nivel 2 el protocolo PPP (Point to Point Protocol). En esta interred, la mayoría de enlaces entre routers son de tipo “PPP”. Cada enlace “PPP” es una red independiente con tan solo dos equipos. Cada equipo tiene asignado un nombre. Los PCs tienen asignada una dirección IP y una máscara de subred en la notación “/n”, donde “n” es el número de bits a uno en la máscara de subred. Los hubs son modelos sencillos, no gestionables, y no tienen dirección IP. Los routers tienen una dirección IP en cada interfaz. Las interfaces Ethernet están etiquetadas con “e0” o “e1”. Las interfaces serie están etiquetadas con “s0” o “s1”. Los PCs conectados al “Hub_DE” tienen configurado como router por defecto al “Router_D”, de forma que dirigirán a él los paquetes que quieran hacer llegar fuera de su propia red. En el “PC_A0_55” se ha abierto una sesión MS-DOS y se ha ejecutado el comando que aparece a continuación:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


C:\WINDOWS>ping -n 1 -i 11 200.200.200.200 Haciendo ping a 200.200.200.200 con 32 bytes de datos: Respuesta desde 210.93.105.2: El tiempo de vida caducó en tránsito. Estadísticas de ping para 200.200.200.200: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 0ms, máximo = 0ms, promedio = 0ms C:\WINDOWS> ¿Qué está diciéndole el “Router_E” al “PC_A0_55” mediante un mensaje ICMP? El “Router_E”, con IP 210.93.105.2, está informando mediante un mensaje ICMP que el paquete enviado por el “PC_A0_55” ha sido descartado al haber expirado su tiempo de vida. ¿Cómo es posible que haya llegado al “Router_E” un paquete cuya IP destino es 200.200.200.200? No es normal que los routers tengan en sus tablas de enrutamieno una ruta específica para una red que es inalcanzable, como es el caso de la red a la que pertenece el equipo con IP 200.200.200.200, así que seguramente los routers tendrán una ruta por defecto, que es la que habrá seguido éste paquete. A continuación se muestra el tráfico capturado en la red del “PC_A0_55” como consecuencia de la ejecución del comando PING:

¿Qué dirección IP origen tiene el datagrama encapsulado en la trama recibida por “PC_A0_55”?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


La “Source Address” del datagrama es 210.93.105.2, pues es la dirección que aparece en la primera de las dos cabeceras que se pueden ver en el panel central de la ventana de captura. La segunda cabecera forma parte de la copia del datagrama descartado acerca del cuál se está informando. ¿Con qué tiempo de vida ha envió el “Router_E” el datagrama que le ha llegado al “PC_A0_55”? Con un TTL de 255, pues al “PC_A0_55” ha llegado con un TTL de 251 después de haber atravesado cuatro routers. ¿Qué clase de mensaje ICMP ha enviado el “Router_E”? Es un mensaje ICMP de tipo 11 (tiempo excedido) y código 0 (Contador del tiempo de vida excedido), que indica que un router ha descartado un datagrama porque su tiempo de vida se ha excedido. A continuación se muestra el tráfico capturado en la red que une al “Router_D” con el “Router_E” como consecuencia de la ejecución del comando PING:

¿Cuántos routers ha atravesado el paquete IP de la trama con ID=0 del archivo “ficheroDE.cap”? Ese paquete fue enviado por el “PC_A0_55” con un TTL de 11 y se ha capturado en la red 210.93.105.0 /24 con un TTL de 7, luego ha tenido que atravesar 4 routers. Esto concuerda perfectamente con la topología de red mostrada en una de las figuras anteriores. ¿Quién ha enviado la trama con ID=0 del archivo “ficheroDE.cap”? El “Router_D”, cuya dirección MAC es 00D058ADCD11. ¿A quién ha enviado el “Router_D” la trama con ID=0? No puede habérsela enviado a su destinatario final, pues el equipo 200.200.200.200 no pertenece a la red 210.93.105.0 /24, así que se lo habrá enviado a otro router, el “Router_E” en este caso. ¿Qué equipos están intercambiando tramas en la red 210.93.105.0 /24? Únicamente el “Router_D” y el “Router_E”. A continuación se muestra el tráfico capturado en la red que une al “Router_D” con el “Router_E” pero presentando diferente información en el listado de tramas:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Por qué el “Router_E” le vuelve a enviar al “Router_D” encapsulado en la trama con ID=1 el mismo datagrama que le ha llegado encapsulado en la trama con ID=0? Ambos routers están rutando el datagrama porque tienen una ruta por defecto y no porque sepan exactamente cual es la mejor ruta para alcanzar la red a la que pertenece el equipo al que va dirigido el datagrama. Parece ser que el “próximo salto” de la ruta por defecto del “Router_D” es el “Router_E”, mientras que el “próximo salto” de la ruta por defecto del “Router_E” es el “Router_D”. Esto quiere decir que hay un bucle de enrutamiento que va a provocar que el paquete destinado a la IP 200.200.200.200 vaya a ir dando saltos del “Router_D” al “Router_E” y viceversa. A continuación se muestra parcialmente decodificada otra de las tramas del archivo “ficheroDE.cap”:

¿Quién envía la trama con ID=5? El “Router_E”, cuya MAC es 00D058ADCD10. ¿Con qué tiempo de vida le llega al “Router_E” el último paquete que envía el “Router_D”? Con un TTL de 1, lo cual hace que el “Router_D” al ver que con ese tiempo de vida no va a poder llegar a su destinatario, decide descartarlo y avisar al que lo envió originalmente de que dicho paquete va a ser descartado por haber excedido su tiempo de vida. A continuación se muestra parcialmente decodificada otra de las tramas del archivo “ficheroDE.cap”:

¿En qué se diferencian el datagrama IP enviado por el “Router_D” al “PC_A0_55” del datagrama que finalmente recibe el “PC_A0_55”? La diferencia está únicamente en el valor del campo TTL y el valor del campo “Checksum” de la cabecera IP. El campo TTL se ha disminuido en una unidad en cada router que atraviesa. Al cambiar este campo el “Checksum” debe recalcularse también. El resto del datagrama no ha sufrido cambios.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP



Estrictamente hablando, lo que se muestra en la figura no es una red (dominio de broadcast) sino que es un conjunto de redes interconectadas mediante routers. Por tanto, lo más correcto sería decir que estamos frente a una interred o una internetwork. En esta interred podemos distinguir cinco redes Ethernet, implementadas con un sencillo concentrador (Hub). Nótese que los enlaces Ethernet entre equipos están etiquetados con la palabra “Eth”. Los enlaces que no están etiquetados con “Eth” están etiquetados con “PPP” indicando que son enlaces serie punto a punto que usan como protocolo de nivel 2 el protocolo PPP (Point to Point Protocol). En esta interred, la mayoría de enlaces entre routers son de tipo “PPP”. Cada enlace “PPP” es una red independiente con tan solo dos equipos. Cada equipo tiene asignado un nombre. Los PCs tienen asignada una dirección IP y una máscara de subred en la notación “/n”, donde “n” es el número de bits a uno en la máscara de subred. Los hubs son modelos sencillos, no gestionables, y no tienen dirección IP. Los routers tienen una dirección IP en cada interfaz. Las interfaces Ethernet están etiquetadas con “e0” o “e1”. Las interfaces serie están etiquetadas con “s0” o “s1”. Los PCs conectados al “Hub_DE” tienen configurado como router por defecto al “Router_D”, de forma que dirigirán a él los paquetes que quieran hacer llegar fuera de su propia red. Nótese que la red tiene rutas redundantes, de forma que puede existir más de un camino para que un paquete llegue a un determinado destino.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


En el “PC_DE_13” se ha abierto una sesión MS-DOS y se han ejecutado los comandos que aparecen a continuación: C:\WINDOWS>ipconfig Configuración IP de Windows 98 0 Ethernet adaptador : Dirección IP . . . . . . . . . . . . . : 210.93.105.13 Máscara de subred . . . . . . . . . . : 255.255.255.0 Puerta de enlace predeterminada . . . : 210.93.105.1 C:\WINDOWS>route print Rutas activas: Dirección de red Máscara de red Puerta de enlace Interfaz Métrica 0.0.0.0 0.0.0.0 210.93.105.1 210.93.105.13 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 210.93.105.0 255.255.255.0 210.93.105.13 210.93.105.13 1 210.93.105.13 255.255.255.255 127.0.0.1 127.0.0.1 1 210.93.105.255 255.255.255.255 210.93.105.13 210.93.105.13 1 224.0.0.0 224.0.0.0 210.93.105.13 210.93.105.13 1 255.255.255.255 255.255.255.255 210.93.105.13 210.93.105.13 1 C:\WINDOWS>arp -a No se encontraron entradas ARP C:\WINDOWS>ping -n 1 -l 34 192.5.5.55 Haciendo ping a 192.5.5.55 con 34 bytes de datos: Respuesta desde 192.5.5.55: bytes=34 tiempo=31ms TDV=126 Estadísticas de ping para 192.5.5.55: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 31ms, máximo = 31ms, promedio = 31ms C:\WINDOWS>route print Rutas activas: Dirección de red Máscara de red Puerta de enlace Interfaz Métrica 0.0.0.0 0.0.0.0 210.93.105.1 210.93.105.13 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.5.5.55 255.255.255.255 210.93.105.2 210.93.105.13 1 210.93.105.0 255.255.255.0 210.93.105.13 210.93.105.13 1 210.93.105.13 255.255.255.255 127.0.0.1 127.0.0.1 1 210.93.105.255 255.255.255.255 210.93.105.13 210.93.105.13 1 224.0.0.0 224.0.0.0 210.93.105.13 210.93.105.13 1 255.255.255.255 255.255.255.255 210.93.105.13 210.93.105.13 1 C:\WINDOWS>ping -n 1 -l 54 192.5.5.55 Haciendo ping a 192.5.5.55 con 54 bytes de datos: Respuesta desde 192.5.5.55: bytes=54 tiempo=29ms TDV=126 Estadísticas de ping para 192.5.5.55: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: mínimo = 29ms, máximo = 29ms, promedio = 29ms C:\WINDOWS>arp -a Interfaz: 210.93.105.13 on Interface 0x1000002 Dirección IP Dirección física Tipo 210.93.105.1 00-d0-58-ad-cd-11 dinámico 210.93.105.2 00-d0-58-ad-cd-10 dinámico C:\WINDOWS> ¿Cuántos routers hay en la red del PC en el que se han ejecutado los comandos PING? Hay dos routers. El “Router_D”, que tiene la interfaz Ethernet e0 en dicha red, con la IP 210.93.105.1, y el “Router_E”, que tiene la interfaz Ethernet e0 en dicha red, con la IP 210.93.105.2. ¿Cuál es el router por defecto del “PC_DE_13”, según indica la salida de los comandos ejecutados? El “Router_D”, según indica el valor de la “Puerta de enlace predeterminada“ de la salida del comando “ipconfig”. Lo mismo indica el comando “route print”, pues para la red 0.0.0.0 con mascara 0.0.0.0 muestra como puerta de enlace asociada la dirección IP 210.93.105.1, del “Router_D”.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Cuántas direcciones IP forman parte de la red que tiene por nombre 0.0.0.0 y por máscara de red también el valor 0.0.0.0? Si a cualquier dirección IP se le hace el AND lógico con la máscara 0.0.0.0 y luego se compara el resultado (0.0.0.0) con el nombre de la red 0.0.0.0, resulta que son idénticos, luego cualquier dirección IP pertenece a dicha red. Es por eso que en las tablas de enrutamiento se suele asociar esta red con el router que es próximo salto de la ruta por defecto. ¿Qué significado tienen la dirección IP 127.0.0.1? Todas las direcciones IP de la forma 127.X.Y.Z son direcciones IP reservadas. Al enviar un paquete a una de esas direcciones IP lo que ocurre es que nos llega devuelto a nosotros mismos, pero sin llegar siquiera a transmitirse por el cable. ¿A qué direcciones nos estamos refiriendo con la red 224.0.0.0 y la máscara 224.0.0.0? 224 es 11100000 en binario, luego nos estamos refiriendo a todas las direcciones que empiezan por 111 en binario. ¿Cuántos mensajes ICMP de petición de eco va a enviar el “PC_DE_13”? Dos, pues se han ejecutado dos comandos PING con la opción –n y el parámetro 1. ¿De que tamaño serán los mensajes ICMP de petición de eco? El primer mensaje ICMP de petición de eco tendrá 34 octetos de datos y el segundo 54, lo cual hace una longitud de 42 octetos para el primer mensaje ICMP y 62 octetos para el segundo. ¿De que tamaño serán los datagramas IP enviados por “PC_DE_13” que van a contener a los mensajes ICMP de petición de eco? Puesto que en los comandos PING ejecutados no se han utilizado opciones especiales, los datagramas generados tendrán una cabecera IP de longitud mínima (20 octetos), lo que nos da un primer datagrama de 62 octetos de longitud total y un segundo datagrama de 82 octetos. ¿De que tamaño serán las tramas enviadas por “PC_DE_13” que van a contener los datagramas IP que a su vez contendrán a los mensajes ICMP de petición de eco? Como se trata de tramas Ethernet, sabemos que las tramas serán, como mínimo 18 octetos mayores que los datagramas que contenga, porque a lo mejor hay que añadir algún octeto de relleno para alcanzar el tamaño mínimo de trama. No es este el caso, pues nos sale una primera trama de 80 octetos de tamaño y una segunda trama de 100 octetos. ¿Ha obtenido el “PC_DE_13” respuesta del “PC_A0_55” como consecuencia de los comandos PING PINGs que se han ejecutado? El “PC_A0_55” ha enviado respuesta a los dos PINGs, y las dos han llegado al equipo en el que se ejecutaron los comandos PING, según se muestra en la salida en pantalla de dichos comandos. Se ha capturado el tráfico generado en la red del “PC_DE_13” a consecuencia de la ejecución de los comandos PING. Este tráfico está almacenado en el archivo “fichero13.cap” y se muestra a continuación en la ventana de captura del analizador de protocolos:

¿Cuántos equipos diferentes están enviando tramas en la red 210.93.105.0 /24? Según puede verse en la ventana anterior, hay tres equipos enviando tramas, pues se observan tres direcciones MAC diferentes en la columna “Source” del listado de tramas. Está el equipo con MAC 000102B44FFB, el equipo con MAC 00D058ADCD11 y el equipo con MAC 00D058ADCD10. ¿Qué equipo tiene la dirección MAC 000102B44FFB? La primera trama que se observa en la ventana anterior es una petición ARP en la que se pregunta por la dirección MAC del router por defecto del “PC_DE_13”, luego es lógico pensar que es el “PC_DE_13” el que está haciendo esa petición para informarse de la dirección MAC de su router por defecto y luego poderle enviar una trama conteniendo el primer mensaje ICMP de petición de eco, tal y como se puede ver en la trama con ID=2 del “fichero13.cap”. Luego si esta primera trama es una petición realizada por el “PC_DE_13” y resulta que la dirección MAC “Source” (origen) de dicha trama

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


es la 000102B44FFB, podemos afirmar que esa dirección MAC corresponde al “PC_DE_13”, que además tiene asociada la dirección IP 210.93.105.13, como ya sabemos por el gráfico de la topología de la red y por la salida del comando “ipconfig” que se ha ejecutado en el mismo. ¿De quién es la dirección MAC 00D058ADCD11? La segunda trama mostrada en la ventana anterior es la respuesta ARP asociada a petición ARP de la primera trama, en la cual se preguntaba por la dirección MAC de la IP 210.93.105.1, que es la de la interfaz Ethernet e0 del “Router_D”. En esta respuesta ARP se dice que la MAC asociada a dicha IP del “Router_D” es la 00D058ADCD11. Además puede verse como el “PC_DE_13” utiliza luego esa dirección MAC como destino de la trama que contiene el primer mensaje de petición de eco. ¿De quién es la dirección 00D058ADCD10? Del mismo modo que hemos razonado anteriormente podemos hacerlo ahora con la petición y la respuesta ARP contenidas en las tramas con ID=6 e ID=7 del “fichero13.cap”. De ellas se deduce que la dirección MAC 00D058ADCD10 corresponde dirección IP 210.93.105.2, que como sabemos es la IP asociada a la interfaz Ethernet e0 del “Router_E”. ¿Qué origen y qué destino tiene la trama que contiene el primer mensaje ICMP de petición de eco que puede verse en el “fichero13.cap”? Es una trama enviada por el “PC_DE_13” al “Router_D”. ¿Qué origen y qué destino tiene la trama que contiene el segundo mensaje ICMP de petición de eco que puede verse en el “fichero13.cap”? Es una trama enviada por el “Router_D” al “Router_E”. ¿Qué origen y qué destino tiene la trama que contiene el tercer mensaje ICMP de petición de eco que puede verse en el “fichero13.cap”? Es una trama enviada por el “PC_DE_13” al “Router_E”. A continuación se muestra parte del contenido de la trama que contiene el primer mensaje ICMP de petición de eco que se ha capturado en la red del “PC_DE_13”:

A continuación se muestra parte del contenido de la trama que contiene el segundo mensaje ICMP de petición de eco que se ha capturado en la red del “PC_DE_13”:

¿Muestran el mismo mensaje ICMP de petición de eco las dos ventanas anteriores?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Los paquetes que contienen a ambos mensajes tienen las mismas direcciones IP origen y destino, además ambos mensajes ICMP tienen los mismos valores en los campos “Identified” y “Sequence Number”. Se observa que el primer paquete tiene un tiempo de vida superior en una unidad al tiempo de vida del segundo paquete. Por otro lado la dirección MAC destino de la primera trama es igual que la dirección MAC origen de la segunda trama. Todo hace pensar que se trata del mismo mensaje ICMP en ambos casos y que lo que ha ocurrido es que el paquete que lo contenía ha sido enviado a un router (el “Router_D”), el cual lo ha vuelto a enviar por la misma interfaz por la que lo ha recibido, no sin antes decrementar en una unidad el tiempo de vida del paquete. A continuación se muestra parte del contenido de la trama con ID=3 del “fichero13.cap”:

¿Por qué ha enviado el “Router_D” la trama mostrada en la ventana anterior? Esta trama contiene un mensaje ICMP de tipo 3 “Redirect” (redirigir) y código 0 “Redirect for Network” (redirigir para la red). Es un mensaje ICMP contenido en un datagrama IP cuyo origen es el 210.93.105.1 y cuyo destino es el 210.93.105.13, tal y como puede verse en la cabecera IP del datagrama, que se muestra parcialmente en la parte superior del panel en el que aparece decodificado el contenido de la trama. Este mensaje ICMP de redirección pretende informar al “PC_DE_13” acerca de cuál es la mejor ruta para alcanzar la red a la que pertenece el destinatario del paquete IP que se adjunta en ese paquete. El campo “Gateway Internet Address” a valor 210.93.105.2 en la cabecera del mensaje ICMP de redirección le está indicando al host 210.93.105.13 cuál es el router que debe usar para enviar el datagrama que se le adjunta justo a continuación de la cabecera ICMP. Efectivamente, puede verse la cabecera IP del datagrama que ha originado este mensaje de redirección junto con algunos octetos de datos, lo cuál nos hace darnos cuenta de que se trata del primer datagrama enviado por el “PC_DE_13” al “PC_A0_55”. Por otra

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


parte, hay que hacer notar que el concepto de “mejor ruta” del “Router_D” dependerá de la métrica que esté utilizando, la cual podrá ser el número de saltos (hops), el retardo, el ancho de banda, etc. Obsérvese que el “Router_D” está seguro de que es preferible que el “PC_DE_13” envíe el paquete directamente al “Router_E” porque sabe que los tres (el “Router_E”, el “PC_DE_13” y él mismo) se encuentran en la misma red y de esa forma se evitaría que el paquete dé un salto adicional que es completamente innecesario. ¿Ha descartado el “Router_D” el datagrama al que hace referencia el mensaje ICMP de redirección? No. El “Router_D” ha enviado un mensaje ICMP de redirección para avisar de cuál es la mejor ruta para ese paquete (el “Router_E”, con IP 210.93.105.2), pero no lo ha descartado. La prueba de ello es que, justo a continuación del mensaje ICMP de redirección, el “Router_D” ha procedido a enviar al “Router_E” una trama conteniendo dicho paquete. A continuación se muestra parte del contenido de la trama que contiene el tercer mensaje ICMP de petición de eco que se ha capturado en la red del “PC_DE_13”:

¿Por qué se ha enviado al “Router_E” la trama que se muestra en la ventana anterior? Porque el “PC_DE_13” quiere que sea el “Router_E” el encargado de enrutar el paquete contenido en dicha trama. Puede observarse que se trata del mensaje ICMP asociado al segundo comando PING, pues tiene 54 octetos de datos opcionales. En el momento de ejecutar el segundo comando PING, el “PC_DE_13” ya ha recibido un mensaje ICMP de redirección que le ha hecho aprender que el mejor camino para llegar al “PC_A0_55” es el “Router_E” y no la ruta por defecto, que es el “Router_D”. Se comprende mejor ahora el motivo por el cual la salida en pantalla del comando “route print” ejecutado justo antes del segundo comando PING nos muestra una línea en la cual se dice que para la “Red” 192.5.5.55, con “Máscara de red” 255.255.255.255, la mejor “Puerta de enlace” es la 210.93.105.2, que es precisamente el “Router_E”. ¿Podemos eliminar la nueva ruta que se ha creado en la tabla de rutas del “PC_DE_13”? Sí, simplemente ejecutando el comando “route delete 192.5.5.55” conseguiríamos borrar dicha ruta, de forma que si se tuviese que enviar otro paquete al 192.5.5.55, éste seguiría la ruta por defecto. ¿Cuántas entradas se han añadido a la caché ARP del “PC_DE_13” a consecuencia de la ejecución de los dos comandos PING? Según la salida mostrada en pantalla por los dos comandos “arp –a” se puede ver que antes de la ejecución del primer PING la caché ARP estaba vacía, mientras que después de ejecutarse los dos

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


PINGs el contenido de la misma ha aumentado en dos entradas, correspondientes a los dos routers a los que se les han enviado tramas. Se ha capturado en el archivo “fichero55.cap” el tráfico generado en la red del “PC_A0_55” como consecuencia de la ejecución de los dos comandos PING. A continuación se muestra parte de la trama con ID=0 del “fichero55.cap”.

¿Qué mensaje ICMP se muestra decodificado en la ventana anterior? Se trata del primer mensaje ICMP que envió el “PC_DE_13” al “PC_A0_55”. Obsérvese que coinciden todos los valores de todos los campos de la cabecera ICMP con los de los mensajes ICMP contenidos en las tramas con ID=2 e ID=4 del “fichero13.cap”. Las direcciones IP origen y destino de los paquetes en los que viajan los mensajes ICMP también son idénticos en los tres casos. Lógicamente, los valores del campo “Time to Live” de dichos paquetes son diferentes, pues en cada router que atraviesa el paquete se decrementa en uno su valor. Eso explica que el paquete que envió el “PC_DE_13” a consecuencia del primer PING tuviese un TTL de valor 32 mientras que ese mismo paquete al llegar a su destino tiene un TTL de valor 29, pues ha pasado por 3 routers, el “Router_D”, el “router_E” y el “Router_A”. ¿Qué tiempo de vida tendrá el paquete contenido en la trama con ID=4 del “fichero55.cap”? Ese paquete ha atravesado sólo dos routers para llegar al “PC_A0_55” desde el “PC_DE_13”, pues corresponde al segundo comando PING, que fue ejecutado cuando el “PC_DE_13” ya sabía que la mejor ruta hacia el “PC_A0_55” pasaba por el “Router_E”. Luego, como el paquete que envió el “PC_DE_13” tenía un TTL de 32, tal y como se aprecia en la trama con ID=8 del “fichero13.cap”, el paquete contenido en la trama con ID=4 del “fichero55.cap” tendrá un TTL de valor 30. ¿Tenía el “Router_A” en su caché ARP la dirección MAC del “PC_A0_55” antes de llegarle el primer mensaje ICMP de petición de eco? Sí, pues no ha tenido necesidad de realizar ninguna petición ARP. ¿ Tenía el “PC_A0_55” en su caché ARP la dirección MAC del “Router_A” antes de llegarle el primer mensaje ICMP de petición de eco? No, pues justo después de llegarle dicho mensaje ICMP de petición de eco y antes de poder enviar de vuelta el correspondiente mensaje ICMP de respuesta de eco, el “PC_A0_55” ha realizado una petición ARP para preguntar por la dirección MAC del “Router_A”. Nótese que la implementación que hace el “PC_A0_55” pone en espera el datagrama IP mientras se averigua mediante ARP la dirección MAC destino de la trama en la que se va a encapsular dicho datagrama. ¿Qué perjuicios se han producido al no usar el “PC_DE_13” el router adecuado para enrutar su primer mensaje ICMP de petición de eco? El mensaje ha llegado a su destino a través de una ruta que contiene una salto extra que podía haberse evitado el cuál está consumiendo ancho de banda en la red “PC_DE_13” y recursos en el “Router_D”. Además, el mensaje ICMP de redirección enviado por el “Router_D” también consume recursos en dicho router y ancho de banda en la red del “PC_DE_13”. Por estas razones es aconsejable que el “PC_DE_13” tome nota de cuál es la mejor ruta para este paquete y la use para los sucesivos paquetes que tengan el mismo destino que éste.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP



Estrictamente hablando, lo que se muestra en la figura no es una red (dominio de broadcast) sino que es un conjunto de redes interconectadas mediante routers. Por tanto, lo más correcto sería decir que estamos frente a una interred o una internetwork. En esta interred podemos distinguir cinco redes Ethernet, implementadas con un sencillo concentrador (Hub). Nótese que los enlaces Ethernet entre equipos están etiquetados con la palabra “Eth”. Los enlaces que no están etiquetados con “Eth” están etiquetados con “PPP” indicando que son enlaces serie punto a punto que usan como protocolo de nivel 2 el protocolo PPP (Point to Point Protocol). En esta interred, la mayoría de enlaces entre routers son de tipo “PPP”. Cada enlace “PPP” es una red independiente con tan solo dos equipos. Cada equipo tiene asignado un nombre. Los PCs tienen asignada una dirección IP y una máscara de subred en la notación “/n”, donde “n” es el número de bits a uno en la máscara de subred. Los hubs son modelos sencillos, no gestionables, y no tienen dirección IP. Los routers tienen una dirección IP en cada interfaz. Las interfaces Ethernet están etiquetadas con “e0” o “e1”. Las interfaces serie están etiquetadas con “s0” o “s1”. Los PCs conectados al “Hub_DE” tienen configurado como router por defecto al “Router_D”, de forma que dirigirán a él los paquetes que quieran hacer llegar fuera de su propia red. Nótese que la red tiene rutas redundantes, de forma que puede existir más de un camino para que un paquete llegue ir a un determinado destino. Los routers usan RIP como protocolo de enrutamiento.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


En el “PC_C_10” se ha abierto una sesión MS-DOS y se han ejecutado los comandos que aparecen a continuación: C:\WINDOWS>ping Uso: 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. C:\WINDOWS>ipconfig Configuración IP de Windows 98 0 Ethernet adaptador : Dirección IP . . . . . . . . . . . . . : 223.8.151.10 Máscara de subred . . . . . . . . . . : 255.255.255.0 Puerta de enlace predeterminada . . . : 223.8.151.1 C:\WINDOWS>ping -n 1 -k 223.8.151.1 199.6.13.1 201.100.11.1 202.2.2.1 210.93.105.13 Haciendo ping a 210.93.105.13 con 32 bytes de datos: Respuesta desde 210.93.105.13: bytes=32 tiempo=94ms TDV=124 Ruta: 202.2.2.1 -> 201.100.11.1 -> 199.6.13.1 -> 223.8.151.1 Estadísticas de ping para 210.93.105.13: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: Mínimo = 94ms, máximo = 94ms, promedio = 94ms C:\WINDOWS> ¿Cuántos routers hay en la red del PC que ha emitido el mensaje ICMP de petición de eco? En la red del “PC_C_10” sólo está el “Router_C”, con la IP 204.204.7.1 en su interfaz Ethernet e0. ¿Cuántos routers hay en la red del PC al que se le ha hecho PING? En la red del “PC_DE_13” hay dos routers. El “Router_D”, que tiene la interfaz Ethernet e0 en dicha red, con la IP 210.93.105.1, y el “Router_E”, que tiene la interfaz Ethernet e0 en dicha red, con la IP 210.93.105.2. Según se nos ha dicho anteriormente, el “Router_D” es el que tienen asignado como router por defecto los PCs de dicha red. ¿Cuántos caminos posibles puede seguir un paquete que vaya desde el “PC_C_10” al “PC_DE_13”? Hay sólo dos caminos posibles. El camino más corto en número de saltos es el que pasa por el “Router_C” y el “Router_D”. El camino más largo en número de saltos es el que pasa por el “Router_C”, el “Router_B”, el “Router_A” y el “Router_E”. ¿Qué se pretende con la opción “-k” del comando PING? Esta opción va acompañada de una lista de direcciones IP correspondientes a los equipos por los que se desea que pase el paquete IP generado por el comando PING. Esta lista debe incluir, de forma ordenada, absolutamente a todos los equipos intermedios por los que ha de pasar el paquete, sin omitir ninguno de ellos. Para conseguir esto el paquete generado debe incluir en su cabecera IP la opción “Strict Source and Record Route”. ¿Qué ruta habría seguido el mensaje ICMP de petición de eco generado si no se hubiese utilizado la opción “–k“ en el comando PING? Hubiese seguido la ruta que los routers hubiesen considerado más adecuada. En este caso, puesto que nos dicen que los routers usan RIP como protocolo de enrutamiento, esa ruta habría sido la que pasa por el “Router_C” y el “Router_D”, que es la que tiene menos saltos.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Qué ruta va a seguir el paquete IP que ha generado el “PC_C_10” mediante el comando PING? El paquete conteniendo al mensaje ICMP de petición de eco va a salir del equipo con dirección IP 223.8.151.10 y se le ha dicho (mediante la opción “Strict Source and Record Route”) que su próximo salto debe ser el equipo con dirección IP 223.8.151.1, el siguiente ha de ser el equipo 199.6.13.1, luego el 201.100.11.1, a continuación el 202.2.2.1 y por último, el destino final del paquete es el host con dirección IP 210.93.105.13, que es el que debe contestar al mensaje ICMP de petición de eco con un mensaje ICMP de respuesta de eco. A continuación se muestra el tráfico capturado en la red del “PC_C_10”:

¿Se ha obtenido respuesta del equipo al que se le ha hecho PING? Según la salida en pantalla del comando PING, el equipo 210.93.105.13 ha respondido al PING. Además, se nos muestra que la respuesta enviada por el equipo 210.93.105.13 ha seguido la ruta inversa a la seguida por el mensaje ICMP de petición de eco.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Qué ruta habría seguido el mensaje ICMP de respuesta de eco si no se hubiese utilizado la opción “-k” en el comando PING? Hubiese seguido la ruta que los routers hubiesen considerado más adecuada. En este caso, puesto que nos dicen que los routers usan RIP como protocolo de enrutamiento, esa ruta habría sido la que pasa por el “Router_D” y el “Router_C”, que es la que tiene menos saltos. ¿Tiene que ser idéntica la ruta de ida de un mensaje ICMP de petición de eco a la ruta de vuelta del un mensaje ICMP de respuesta de eco asociado a éste? Cuando se especifica en el paquete IP la opción “Strict Source Route”, la ruta de ida la fija el que ha generado el paquete y la ruta de vuelta será la misma pero en orden inverso. Cuando no se especifican opciones especiales en el paquete, la ruta de ida y la de vuelta son calculadas por los routers, según lo que ellos consideren en cada momento que es la mejor ruta, por lo que no se puede garantizar que el camino de vuelta vaya a ser igual al camino de ida pero en orden inverso. ¿Cuántos octetos mide la cabecera IP del paquete contenido en la trama con ID=2? El campo “Version/Header Length” vale 0x4A (hexadecimal), luego los cuatro bits del campo “Header Length” valen 0xA (hexadecimal). Quiere esto decir que la cabecera mide 10 palabras de 32 bits, o lo que es lo mismo, 40 octetos. ¿Cuántos octetos correspondientes a opciones tiene la cabecera IP del paquete contenido en la trama con ID=2? Al restarle a los 40 octetos de la cabecera los 20 octetos que ocupa la parte fija de la cabecera, nos sale que la parte correspondiente a las opciones también ocupa 20 octetos en este caso. ¿Cuál es la primera opción que aparece en el campo de opciones de la cabecera IP del paquete contenido en la trama con ID=2? Las opciones se identifican por el valor de su primer octeto, “option-type” (“option ID según el analizador de protocolos). En nuestro caso , el primer octeto que aparece tiene el valor 137 (0x89 en hexadecimal), que corresponde a la opción “Strict Source and Record Route” que, según se muestra en la RFC791, correspondiente a IP, en su página 19, tiene la siguiente estructura: Strict Source and Record Route +--------+--------+--------+---------//--------+ |10001001| length | pointer| route data | +--------+--------+--------+---------//--------+ Type=137

¿Qué estructura tiene el campo “Option ID”? Tal y como se explica en la página 15 de la RFC791, éste es un campo de 8 bits estructurado en tres partes: Una primera parte de un bit (“copied flag”), una segunda parte de dos bits (“option class”) y una tercera parte de cinco bits (“option number”). Si el “option flag” está a 1, la opción debe copiarse en todos los fragmentos (y no sólo en el primero), si es que el datagrama es fragmentado. La “option class” indica de que clase es la opción, según el siguiente criterio: 0=”control”, 1=”reserved”, 2=”debugging and measurement”, 3=”reserved”. Por último, el valor de la parte “option number” es el que define de qué tipo de opción se trata. Por ejemplo: 0=”End of Option List”, 1=”No operación”, 3=”Loose Source and Record Route”, 9=”Strict Source and Record Route”. ¿Cuál es el valor de todos los octetos correspondientes a la primera opción, de tipo “Strict Source and record Route” en la trama de ID=2 mostrada en la ventana anterior? Para saber cuáles son todos los octetos, lo primero es saber cuantos octetos ocupa la opción. Como es del tipo 137, sabemos que es una opción multi-octeto, cuyo segundo octeto indicará la longitud de la misma, en este caso 19 octetos, según podemos ver en el panel inferior de la ventana de captura, donde se muestra el octeto 0x13 (19 en decimal) justo a continuación del código 0x89 (137 en decimal).Ya podemos decir, puesto que los vemos en el panel inferior de la ventana, que los 19 octetos que componen la primera opción son, en hexadecimal: 89, 13, 04, C7, 06, 0D, 01, C9, 64, 0B, 01, CA, 02, 02, 01, D2, 5D, 69 y 0D. ¿Cuál es la segunda opción presente en el campo de opciones de la cabecera IP de la trama de ID=2 mostrada en la ventana anterior? Es una opción de un único octeto, concretamente la opción “End of Option List”, de valor 0. Se usa para rellenar al final el campo de opciones para conseguir que la longitud de la cabecera sea un múltiplo de cuatro objetos. Con este octeto adicional y los 19 de la opción anterior se consigue una longitud de 40 octetos para la cabecera. ¿Qué contienen los 16 últimos octetos de la opción SSRR (“Strict Source and Record Route”) de la trama de ID=2 mostrada en la ventana anterior?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Esos 16 octetos corresponden a 4 direcciones IP, que son 199.6.13.1, 201.100.11.1, 202.2.2.1 y 210.93.105.13 respectivamente. Son las direcciones IP de los equipos por los que tiene que pasar el datagrama una vez que llegue a su primer destino. Si nos fijamos nos damos cuenta de que el destino final del datagrama, el “PC_DE_13” está anotado al final de la lista, mientras que la IP del primer equipo por el que debe pasar el datagrama, el “Router_C”, está presente en el campo “Destination Address” de la cabecera IP del datagrama. ¿Qué va a hacer el “Router_C” cuando reciba el datagrama IP contenido en la trama de ID=2 mostrada en la ventana anterior? El “Router_C” verá que el datagrama tiene la opción SSRR (“Strict Source and Record Route”), por lo que aunque ve que la dirección IP destino del datagrama es la suya, la 223.8.151.1, sabe que se trata de un caso especial y que debe reenviar el datagrama para que llegue a su verdadero destino, pues según puede verse en dicha opción, éste aún no ha sido alcanzado . Es más, no sólo debe reenviarlo, sino que debe hacerlo de forma que siga la ruta que el equipo que lo envió originalmente ha dejado marcada en la opción SSRR. Además tiene que encargarse de grabar su IP en dicha opción para que luego el datagrama pueda seguir el camino inverso. Para conseguir todo esto el router se fija en el valor del octeto “Pointer”, que es el tercero de la opción. Su valor es 4, lo que indica que el router debe enviar el datagrama a la IP colocada en octeto número 4 (y siguientes) de la opción SSRR, colocando antes en dicha posición su propia IP. Esta IP es la 199.6.13.1 (C7060D01 en hexadecimal), luego es esa IP la que aparecerá en el campo “Destination Address” del datagrama. Hay que hacer notar que la IP que grabará el “Router_C” en la posición ocupada por la IP 199.6.13.1 dentro de la opción SSRR será la IP 199.6.13.2 y no la 223.8.151.1, pues esa IP se usará luego para que el datagrama pueda seguir el camino de vuelta en orden inverso. Un último detalle a tener en cuenta es que el valor del campo “Pointer” debe ser incrementado en cuatro antes de enviar el datagrama. ¿Qué va a hacer el “Router_B” cuando reciba el datagrama IP con la opción SSRR que le ha enviado el “Router_D”? Actuará de forma análoga a como lo ha hecho el ”Router_B”. Verá que aunque la “Destination Address” del datagrama es la suya propia, como existe la opción SSRR y el valor del campo “Pointer” es 8, menor que 19, la longitud de la opción SSRR, quiere decir que ese datagrama aún no ha llegado a su destino. Procederá a pasárselo al siguiente de la lista, el “Router_A”, grabando la IP 210.100.11.2 en la posición 8 de la opción e incrementando en 4 el valor del campo “Pointer”. A continuación se muestra un trozo del paquete IP conteniendo un mensaje ICMP de petición de eco capturado en la red del “PC_DE_13”, al cual va destinado:

¿Qué contiene la opción SSRR del datagrama IP que le llega al “PC_DE_13”? Los 19 octetos de la opción SSRR son, en hexadecimal, los siguientes: 89, 13, 14, C7, 06, 0D, 02, C9, 64, 0B, 02, CA, 02, 02, 02, D2, 5D, 69 y 02. Las cuatro direcciones IP almacenadas en la lista son 199.6.13.2, 210.100.11.2, 202.2.2.2 y 210.93.105.2, correspondientes a las direcciones IP que han ido grabando los cuatro routers por los que ha pasado el datagrama. ¿Cómo sabe el “PC_DE_13” que el datagrama que ha recibido es para él y que no debe reenviarlo a nadie más?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Lo sabe porque la “Destination Address” de la cabecera IP es la suya y resulta que, aunque existe la opción SSRR, el valor de su campo “Pointer” es 20, superior a los 19 octetos de longitud que tiene dicha opción, lo cuál indica que la lista de equipos intermedios ya ha sido recorrida por completo. Además sabe quién se lo ha enviando originalmente, pues el valor del campo “Source Address” de la cabecera IP no ha cambiado a lo largo de todo el viaje que ha seguido el datagrama. A continuación se muestra parte del contenido de la trama enviada por “PC_DE_13”:

¿Qué ha hecho el “PC_DE_13” al recibir el datagrama IP que le envió el “PC_C_10”? Al ver que era para él lo ha procesado y como contenía un mensaje ICMP de petición de eco, le ha devuelto un mensaje ICMP de respuesta de eco. Este mensaje viajará en una datagrama con la opción SSRR, pues el mensaje ICMP de petición de eco también viajaba en un paquete con dicha opción. El datagrama enviado tendrá la IP 210.93.105.2 como “Destination Address”, correspondiente al “Router_E”, pues ese es el primer salto que debe dar. En la opción SSRR se incluirán las IPs 202.2.2.2, 210.100.11.2, 199.6.13.2 y 223.8.151.10, siendo esta última la IP del equipo final al que va destinado el datagrama. El “Pointer” de la opción SSRR se pondrá a valor 4 inicialmente. A continuación se muestra el contenido del datagrama recibido por “PC_C_10”:

¿Ha seguido el datagrama recibido por “PC_C_10” la misma ruta que el que envió este PC? Sí, tal y como puede verse en el interior de la opción SSRR. El comando PING ha utilizado el contenido de esta opción para mostrarnos en pantalla las IPs de los routers por los que ha pasado el datagrama que contenía al mensaje ICMP de respuesta de eco.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP



Estrictamente hablando, lo que se muestra en la figura no es una red (dominio de broadcast) sino que es un conjunto de redes interconectadas mediante routers. Por tanto, lo más correcto sería decir que estamos frente a una interred o una internetwork. En esta interred podemos distinguir cinco redes Ethernet, implementadas con un sencillo concentrador (Hub). Nótese que los enlaces Ethernet entre equipos están etiquetados con la palabra “Eth”. Los enlaces que no están etiquetados con “Eth” están etiquetados con “PPP” indicando que son enlaces serie punto a punto que usan como protocolo de nivel 2 el protocolo PPP (Point to Point Protocol). En esta interred, la mayoría de enlaces entre routers son de tipo “PPP”. Cada enlace “PPP” es una red independiente con tan solo dos equipos. Cada equipo tiene asignado un nombre. Los PCs tienen asignada una dirección IP y una máscara de subred en la notación “/n”, donde “n” es el número de bits a uno en la máscara de subred. Los hubs son modelos sencillos, no gestionables, y no tienen dirección IP. Los routers tienen una dirección IP en cada interfaz. Las interfaces Ethernet están etiquetadas con “e0” o “e1”. Las interfaces serie están etiquetadas con “s0” o “s1”. Los PCs conectados al “Hub_DE” tienen configurado como router por defecto al “Router_D”, de forma que dirigirán a él los paquetes que quieran hacer llegar fuera de su propia red. Nótese que la red tiene rutas redundantes, de forma que puede existir más de un camino para que un paquete llegue ir a un determinado destino. Los routers usan RIP como protocolo de enrutamiento.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Se ha capturado el tráfico generado en la red 210.93.105.13 /24 durante algunos minutos y se ha almacenado en el archivo “ficheroDE.cap”. Las tramas capturadas se muestran a continuación:

¿Qué equipos están generando tráfico en la red 210.93.105.0 /24? Por lo que se ve en el listado de tramas de la ventana anterior, sólo hay dos equipos generando tramas. El equipo cuya dirección MAC es la 00D058ADCD11, y el equipo cuya dirección MAC es la 00D058ADCD10. No sabemos qué equipos son pero es de suponer que sean los dos routers que existen en dicha red, puesto que las tramas contienen actualizaciones del protocolo RIP, que es un protocolo de enrutamiento usado por los routers para mantener actualizadas sus tablas de rutado. ¿A quién van dirigidas las tramas generadas en la red 210.93.105.0 /24? La dirección MAC destino de todas las tramas es FFFFFFFFFFFF (BROADCAST), por lo que son tramas que serán procesadas a nivel 2 por todos los equipos. Es decir, todos los equipos abrirán esas tramas y comprobarán si deben procesar o no su contenido. A continuación se muestra el listado de tramas capturadas pero de forma que muestre información temporal y las direcciones de red de los paquetes contenidos en las tramas:

¿Qué equipos están generando paquetes IP? Ahora ya sabemos quién está generando el tráfico, pues podemos ver las direcciones IP de los paquetes contenidos en las tramas. Son, como ya suponíamos, el “Router_D”, con IP 210.93.105.1 y el “Router_E”, con IP 210.93.105.2, los únicos en generar tráfico en la red. ¿A quién van destinados los paquetes IP generados por el “Router_D” y el “Router_E”?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Los datagramas IP generados tienen una dirección IP destino de valor 255.255.255.255 (BROADCAST de red local o BROADCAST inundado o BROADCAST limitado) por lo que cualquier equipo que reciba este datagrama deberá abrirlo y averiguar si debe procesar o no su contenido. ¿Cada cuanto tiempo están enviando actualizaciones RIP los routers? Si nos fijamos en la información temporal que nos muestra el analizador asociada a cada trama, podemos ver que no es un tiempo fijo, pero que es cercano a los 30 segundos, que es el tiempo que debe separar las actualizaciones periódicas enviadas por el protocolo RIP, salvo que se diga lo contrario. ¿Contienen lo mismo todos los paquetes enviados por un mismo router? Es imposible saberlo por que sólo estamos viendo el listado de tramas y no el contenido de todas ellas. No obstante, parece ser que sí, pues el tamaño de todas las tramas enviadas por un mismo router es siempre el mismo. Además, en la columna “Summary” de la primera de las ventanas podía verse el número de entradas de enrutamiento (“Routing Entries”) que contenía cada uno de los mensajes RIP, y éste era siempre el mismo para los mensajes que provienen de un mismo router (4 los del “Router_D” y 5 los del “Router_E”). Si a esto añadimos que la topología de la red es muy simple, es de suponer que lo que está ocurriendo es que en el intervalo de tiempo en el que se han capturado las tramas, el estado de la red es constante (no ha habido cambios) y por tanto las actualizaciones RIP enviadas por los routers reflejan siempre el mismo estado de la red. A continuación se muestra parte del contenido de la primera trama emitida por el “Router_D”:

¿Qué equipos van a procesar el contenido del segmento UDP (datagrama UDP) que se muestra en la ventana anterior? Este datagrama UDP va a llegar a todos los equipos de la red Ethernet del “Router_D” (salvo él mismo, que es el emisor), pues el paquete IP que lo transporta lleva como destino la dirección IP 255.255.255.255, y la trama que transporta a dicho paquete tiene como destino la dirección MAC FFFFFFFFFFFF. Sin embargo, una vez dentro del equipo, el datagrama UDP será descartado a menos que exista algún proceso asignado al puerto 520 (decimal), que es el puerto destino que tiene este datagrama UDP. Es de suponer que únicamente el “Router_E” tendrá un proceso asignado a dicho puerto (que es el puerto asociado a RIP) y por tanto será el único que procesará su contenido.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Cómo se sabe cuáles son los números de puerto reservados para cada uno de los protocolos? Hasta el 1994, al organización IANA publicaba periódicamente la RFC “Assigned Numbers”, cuya edición más reciente es la RFC1700, en la cual se recopilan muchas tablas con asignaciones de parámetros de protocolos, entre las cuales se encuentra la tabla con los “Well Known Ports” (Puertos Bien Conocidos). No obstante, en la RFC3232, de enero de 2002, se nos advierte que dicha RFC1700 está ya obsoleta (su estado actual es “Historic”) y que su contenido puede (y debe) consultarse en la página web de la organización IANA, que actualmente es www.iana.org. ¿Cómo sabe el analizador de protocolos que el datagrama UDP mostrado en la ventana anterior contiene 84 octetos de datos? Sabe que el campo “Length” del datagrama UDP vale 92, luego si a 92 octetos de longitud total se le restan los 8 octetos que ocupa la cabecera del datagrama UDP, nos queda que el datagrama tiene 84 octetos en el campo de datos. ¿Sabe siempre el analizador de protocolos a que protocolo pertenecen los datos contenidos en un datagrama UDP? No siempre. Sólo cuando el datagrama tiene como puerto origen o como puerto destino un puerto bien conocido (“Well Known Port”), el analizador es capaz de saber a que protocolo pertenecen los datos y podrá presentarlos decodificados en el panel central de la ventana de captura. ¿Qué precedencia tiene el datagrama IP mostrado en la ventana anterior? “Internetwork Control”, pues los tres primeros bits del campo “Type of Service” son 110. ¿Cómo sabe el analizador de protocolos que el paquete IP mostrado en la ventana anterior contiene un datagrama UDP? Porque el campo “Protocol ID” del paquete tiene el valor 17 (decimal), que es el que identifica a UDP. ¿En qué documento puede consultarse la descripción del protocolo RIP? El documento de referencia es la RFC1058, “Routing Information Protocol”, donde se describe la primera versión de este protocolo. No obstante, actualmente dicho documento es obsoleto y ha recibido el estado “Historic”, por lo que es preferible consultar la RFC2453, “RIP Version 2”, que además de detallar el funcionamiento de la primera versión, RIPv1, también explica el de RIPv2. A continuación se muestra el primer mensaje ICMP capturado en “ficheroDE.cap”:

¿Qué aparece al principio de un mensaje RIP, justo antes de la lista de entradas de enrutamiento? Todo mensaje RIP debe comenzar por cuatro octetos. El primero puede ser 1 ó 2, indicando si se trata de una pregunta (1=“Request”) o de una respuesta (2=”Response”). El segundo octeto es la versión del protocolo RIP que se está usando, que en este caso es la 1. Los otros dos octetos no se usan en la versión 1 del protocolo RIP, por lo que deben estar a cero. ¿Cuántas entradas de enrutamiento pueden aparecer en un mensaje RIPv1? Según se cuenta en la RFC2453, el número de entradas RIP (de 20 octetos de longitud), que pueden aparecer en un mensaje RIPv1 debe estar comprendido entre 1 y 25 (ambos inclusive).

http://www.iana.org

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Cuál es la estructura de una entrada de enrutamiento de un mensaje RIPv1? Esta es la estructura de una entrada RIPv1, según se muestra en la RFC2453: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | address family identifier (2) | must be zero (2) | +-------------------------------+-------------------------------+ | IPv4 address (4) | +---------------------------------------------------------------+ | must be zero (4) | +---------------------------------------------------------------+ | must be zero (4) | +---------------------------------------------------------------+ | metric (4) | +---------------------------------------------------------------+

Entre paréntesis aparecen las longitudes de cada campo en octetos. Sólo hay tres campos que no deben estar obligatoriamente a cero. El primero de ellos es el campo “address family identifier”, debe tener el valor 2 cuando RIP se esté usando con direcciones IP, como es este caso. Los otros dos campos útiles son la dirección IP de la red a la que se refiere la entrada y la métrica que le ha asignado a esa red el router que está enviando la actualización. ¿Acerca de qué redes está informando el “Router_D” en su primer mensaje RIP? Según puede verse en la ventana anterior, el “Router_D” está informando acerca de las redes cuyas IP son 199.6.13.0, 204.204.7.0, 219.17.100.0 y 223.8.151.0. ¿Qué conclusión sacan los routers (el “Router_E” en este caso) al recibir la información de enrutamiento contenido en el primer mensaje RIP enviado por el “Router_D”? El “Router_E” se entera de que existe una ruta que pasa por el “Router_D” (el que envía el mensaje RIP) y que llega a la red 199.6.13.0 en 2 saltos (pues es 2 la métrica que aparece asociada a dicha red en el mensaje RIP). Se entera de que existe una ruta hacia la red 204.204.7.0, pasando por el “Router_D”, que llega a ella en 1 salto. Sabe que hay una ruta a la 219.17.100.0 en 3 saltos y otra a la 223.8.151.0 en 2 saltos, ambas pasando por el “Router_D”. Si nos fijamos en el gráfico con la topología de la red, vemos que toda esta información que recibe el “Router_E” es correcta. A continuación se muestra parte de la primera trama enviada por el “Router_E”:

¿Acerca de qué redes está informando el “Router_E” con su primer mensaje RIP? Acerca de las redes 192.5.5.0, 201.100.11.0, 202.2.2.0, 205.7.5.9 y 219.17.100.0. ¿Qué máscara de red tienen las redes acerca de las que está informando el “Router_E” en su primer mensaje RIP?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Nosotros sabemos que las cinco redes acerca de las que informa el “Router_E” tienen una máscara de red de 24 bits de longitud, o lo que es lo mismo la máscara 255.255.255.0, puesto que en el gráfico de la topología de la red vemos que dichas redes tienen asignada esa máscara. Sin embargo, los mensajes RIPv1 informan exclusivamente acerca del nombre de la red, pero no de la máscara de red. El destinatario de un mensaje RIPv1 tiene que intentar “adivinar” la máscara de red. Lo normal es que le asigne la máscara de red “natural”, propia de la clase de dirección IP de que se trate. En este caso, como las cinco redes son de clase C, el “Router_D” pensaría que la máscara de red de estas cinco redes es la 255.255.255.0, pues esa es la máscara “natural” o “por defecto” para esa clase. ¿Qué pasaría si se utilizase RIPv1 en una internetwork en la que existiesen subredes creadas mediante la realización de subnetting en una red mayor? Esta claro que pueden darse situaciones en las que la información de enrutamiento no sea la correcta. Al publicar información de enrutamiento acerca de una subred (red obtenida mediante subnetting) pero sin poder decir cuál es la máscara de subred, el destinatario de un mensaje RIPv1 se encuentra con un problema difícil de resolver. Si el destinatario del mensaje RIPv1 está conectado directamente a una subred “hermana” de aquella acerca de la cuál le están informando, entonces sí que puede conocer la máscara de red de dicha subred, pues debe ser la misma que la de la subred a la que está directamente conectado. Esto es correcto sólo si se ha hecho subnetting con una única máscara de red, porque si lo que se ha hecho es subnetting con máscara de red de longitud variable (VLSM), los routers pueden llegar a confundirse al intentar “adivinar” la máscara de subred. Ese es uno de los motivos por los que se aconseja el uso de RIPv2, que si informa de la máscara de red. ¿Por qué no informa el “Router_E” en su primer mensaje RIP acerca de la red 223.8.151.0? El “Router_E” sabe que puede alcanzar la red 223.8.151.0 en 2 saltos, pasando por el “Router_D”, puesto que el “Router_D” así se lo ha comunicado en un mensaje RIP. La otra ruta que existe para que el “Router_E” alcance la red 223.8.151.0, es una ruta en 3 saltos que pasa por el “Router_A”. En los mensajes RIP se informa sólo acerca de la mejor ruta para alcanzar una red, así que si el “Router_E” informase acerca de la red 223.8.151.0 en su mensaje, lo haría diciendo que su métrica es de 3 saltos (uno más que la mejor ruta, pues se incluye a él mismo como salto). No tiene sentido que, si el “Router_E” ha escuchado en la red 210.93.105.0 un mensaje RIP que informa que la red 223.8.151.0 es accesible en 2 saltos, ahora él envíe otro mensaje RIP a la red 210.93.105.0 informando de que la red 223.8.151.0 es accesible en 3 saltos (uno más que la otra). A nadie le sería de utilidad este mensaje pues en realidad la ruta que se publica es igual que la otra salvo que la otra no pasa por el “Router_E” y es un salto más corta. Además, no sólo es inútil publicar esta información, sino que en ciertas circunstancias puede llegar a confundir a los otros routers. A esta técnica que evita que una información que se obtenido a través de una red sea enviada de nuevo hacia la misma red se la llama “split horizon” (horizonte dividido). Se ha abierto una sesión en la consola del “Router_E” y se ha ejecutado el comando “show ip route” para que éste nos muestre su tabla de enrutamiento. A continuación se muestran los resultados: Router_E#show ip route Codes: C – connected, S - static, I - IGRP, R - RIP, M – mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E – EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o – ODR P - periodic downloaded static route Gateway of last resort is not set C 210.93.105.0/24 is directly connected, Ethernet0 C 202.2.2.0/24 is directly connected, Serial0 R 205.7.5.0/24 [120/1] via 202.2.2.2, 00:00:04, Serial0 R 219.17.100.0/24 [120/2] via 202.2.2.2, 00:00:04, Serial0 R 199.6.13.0/24 [120/2] via 210.93.105.1, 00:00:16, Ethernet0 [120/2] via 202.2.2.2, 00:00:04, Serial0 R 204.204.7.0/24 [120/1] via 210.93.105.1, 00:00:16, Ethernet0 R 192.5.5.0/24 [120/1] via 202.2.2.2, 00:00:04, Serial0 R 223.8.151.0/24 [120/2] via 210.93.105.1, 00:00:17, Ethernet0 R 201.100.11.0/24 [120/1] via 202.2.2.2, 00:00:04, Serial0 Router_E# ¿Cuántas redes conoce el “Router_E”? El router sabe cómo llegar a nueve redes. Si nos fijamos podemos ver que todas las redes que aparecen en el gráfico con la topología de la red también se encuentran en la tabla de enrutamiento que nos ha mostrado el “Router_E” al ejecutar el comando “show ip route”.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Cómo ha obtenido el “Router_E” la información acerca de las redes a las que sabe como llegar? El “Router_E” tiene la interfaz s0 configurada con la dirección IP 202.2.2.1 y la máscara “/24” y tiene la interfaz e0 configurada con la dirección IP 210.93.105.2 y la máscara “/24”. Por eso sabe cómo llegar a las redes 210.93.105.0 /24 y 202.2.2.0 /24, porque está directamente conectado a ellas. Al ejecutar el comando “show ip route” el router muestra su tabla de enrutamiento, marcando con una “C” inicial las redes a las cuales está directamente conectado. Las redes marcadas con una “R” inicial son redes a las que el router sabe llegar porque ha obtenido información acerca de ellas mediante mensajes RIP que le han enviado otros routers. ¿Por qué ni el “Router_D” ni el “Router_E” informan acerca de la red 210.93.105.0 en los mensajes RIP mostrados en las ventanas anteriores? Porque están aplicando la técnica del “horizonte dividido”. Ambos routers están directamente conectados a esa red. Si enviasen un mensaje RIP a esa red informando de una ruta para llegar a ella, la métrica sería de 1 salto, lo cual no sería de utilidad para ningún router que pudiera escuchar este mensaje, pues sólo lo escuchan los equipos directamente conectados a la red 210.93.105.0 /24. ¿Tiene el “Router_E” más de una ruta asignada para cada red en su tabla de enrutamiento? Para las redes aprendidas mediante RIP, el router guarda en su tabla de enrutamiento sólo la mejor de las rutas. En el caso de que se conozcan dos rutas iguales hacia una misma red, el router muestra las dos rutas en la tabla de enrutamiento, como en el caso de la red 199.6.13.0/24, que es accesible en dos saltos a través del router 210.93.105.1 y del router 202.2.2.2. ¿Cuál es el significado de los diferentes elementos que aparecen en las entradas de la tabla de enrutamiento del “Router_E” asociadas a redes aprendidas mediante RIP? Para las redes aprendidas mediante RIP, el “Router_E” muestra una línea de este estilo: R 219.17.100.0/24 [120/2] via 202.2.2.2, 00:00:04, Serial0

La R inicial significa que ha obtenido la información mediante RIP. A continuación aparece el nombre de la red a la que se refiere la entrada y su máscara de red. El segundo número entre corchetes es la distancia a la que está la red en número de saltos, la cual coincide con la métrica que tenía esa red asignada en uno de los mensajes RIP que ha recibido el “Router_E”. El primer número entre corchetes es la distancia administrativa asignada por el administrador para esa ruta, cuya misión es ayudar al router a decidirse en el caso de que existan varias rutas hacia la misma red, cada una aprendida mediante un método diferente (RIP, IGRP, OSPF...). La IP que aparece después de la palabra “via” corresponde a la del router vecino que nos ha informado acerca de la red, el cuál actúa como “próximo salto” en la ruta hacia la red. La hora que puede verse cerca del final de la línea es el tiempo que hace que recibimos el mensaje RIP que nos informaba acerca de esta red. Por último se muestra el nombre de la interfaz por la que hay que enviar los datos para alcanzar el router que actúa de “próximo salto”. Hay que destacar que si existiesen varias rutas con la misma métrica hacia la misma red, se agruparían en la misma entrada de la tabla de enrutamiento, de esta forma: R 199.6.13.0/24 [120/2] via 210.93.105.1, 00:00:16, Ethernet0 [120/2] via 202.2.2.2, 00:00:04, Serial0

¿Qué tienen en común las redes 210.93.105.0/24, 199.6.13.0/24, 204.204.7.0/24 y 223.8.151.0/24 que aparecen en la tabla de enrutamiento del “Router_E”? Son redes a las se puede llegar de forma óptima saliendo del “Router_E” por la interfaz Ethernet número 0 (e0). Nótese que ninguna de estas redes es “publicada” en los mensajes RIP que el “Router_E” inyecta a través de la interfaz Ethernet e0, pues está usando la técnica del horizonte dividido. ¿Envía el “Router_E” actualizaciones RIP por su interfaz serie número 0 (s0)? Lo lógico es que sí, pues de lo contrario el “Router_A” no podría aprender las mejores rutas a todas las redes de la internetwork. Lo que si es seguro es que el “Router_A” está enviándole actualizaciones RIP al “Router_E”, pues el “Router_E” tiene en su tabla de enrutamiento varias rutas aprendidas mediante RIP en las que aparece el “Router_A” como “próximo salto”. ¿Enviará el “Router_E” mensajes RIP al “Router_A” informándole acerca de la red 199.6.13.0? No, pues la aplicación de la técnica del horizonte dividido se lo impide. Nótese que de nada le serviría al “Router_A” saber que a través del “Router_E” puede alcanzar dicha red en 3 saltos, puesto que el “Router_A” puede alcanzarla en sólo un salto.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Contradice la técnica del horizonte dividido el que tanto el “Router_D” como el “Router_E” incluyan información acerca de la red 219.17.100.0 en las actualizaciones RIP que envían hacia la red 210.93.105.0 y que se han capturado en el “ficheroDE.cap”? No, pues ambos routers tienen anotada en su tabla de enrutamiento que la mejor ruta para llegar a la red 219.17.100.0 no pasa por la red 210.93.105.0, luego es útil para los equipos que oyen las actualizaciones RIP enviadas en ésta red el recibir dicha información. Hay que tener en cuenta que los routers nunca saben cuantos routers reciben los mensajes RIP que ellos envían a la dirección IP 255.255.255.255, por lo que aunque el “Router_D” pueda pensar que al “Router_E” no le interesa la información acerca de la red 219.17.100.0, a lo mejor en la red 210.93.105.0 hay un router al que sí le puede interesar dicha información. ¿Tiene el “Router_E una ruta por defecto a la que enviar los paquetes que no sabe a dónde enviar? No. El “Router_E”, justo antes de mostrarnos su tabla de enrutamiento nos está diciendo “Gateway of last resort is not set”, lo que significa que no conoce cuál es el router que debe usar como “último recurso” en el caso de no encontrar en su tabla de enrutamiento la ruta adecuada para un paquete. ¿Cómo aparecería marcada una entrada de la tabla de enrutamiento del “Router_E” que hubiese sido introducida “a mano” por el administrador de la red? Una entrada introducida a mano por el administrador de la red aparecería marcada con un “S” inicial, indicando que es una entrada “Static” (estática). ¿Qué ocurre cuando un router recibe un mensaje RIP en el que se dice que una determinada red tiene una métrica 16? El router que recibe ese mensaje sabe que no puede utilizar al router que ha enviado el mensaje para intentar llegar a la red en cuestión. Es decir, el router que envía el mensaje está diciéndole a otros routers que la red esa es inaccesible a través suya. La métrica 16 se considera como “infinita” en el caso del protocolos RIP. ¿Cómo será la métrica RIP con la que publique un router una red que tiene marcada en su tabla de enrutamiento como accesible en 14 saltos? La publicará en un mensaje RIP con una métrica de 15. Este mensaje RIP, como es lógico, será enviado sólo por los interfaces que permita la aplicación de la técnica del horizonte dividido. ¿Es posible que, en una internetwork que usa RIP como protocolo de enrutamiento, un router aprenda las rutas para llegar a redes que se encuentran a 16 saltos de él? No. El router no tendría en cuenta los mensajes RIP que le llegasen informando acerca de redes con métricas de valor 16. La información de redes con métricas mayores de 16 ni siquiera le llegarían, pues ningún router genera mensajes RIP con métricas mayores de 16. ¿Cómo serían los mensajes RIP que envía un router por cada una de sus interfaces si no se emplease la técnica del horizonte dividido? El router enviaría por sus interfaces actualizaciones periódicas idénticas informando acerca de todas las redes que tiene anotadas en su tabla de enrutamiento. No habría diferencias entre los mensajes RIP enviados por una interfaz y el enviado por otra, pues al no emplear la técnica del horizonte dividido no es necesario eliminar del mensaje RIP las referencias a redes cuya mejor ruta tiene como próximo salto un router que pertenece a la misma red en la cual se está enviando el mensaje.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Ejercicio 18: En nuestro PC hemos abierto una ventana MS-DOS y hemos ejecutado los siguientes comandos: C:\WINDOWS>ipconfig /all Configuración IP de Windows 98 Nombre del host . . . . . . . . . . . : smartin Servidores DNS . . . . . . . . . . . . : 193.152.63.197 195.235.113.3 Tipo de nodo . . . . . . . . . . . . . : Difusión Id. De ámbito NetBIOS . . . . . . . . : Enrutamiento IP activado . . . . . . . : No WINS Proxy activado . . . . . . . . . : No Resolución NetBIOS usa DNS . . . . . . : No 0 Ethernet adaptador : Descripción . . . . . . . . . . . . . : Realtek 8139-series PCI NIC Dirección física . . . . . . . . . . . : 00-C0-26-26-0D-14 DHCP activado . . . . . . . . . . . . : Sí Dirección IP . . . . . . . . . . . . . : 200.200.200.5 Máscara de subred . . . . . . . . . . : 255.255.255.0 Puerta de enlace predeterminada . . . : 200.200.200.1 Servidor DHCP . . . . . . . . . . . . : 200.200.200.1 Servidor WINS primario . . . . . . . : Servidor WINS secundario . . . . . . . : Permiso obtenido . . . . . . . . . . . : 04 05 02 0:12:10 Permiso caduca . . . . . . . . . . . . : 04 05 02 1:12:10 C:\WINDOWS>arp -a No se encontraron entradas ARP C:\WINDOWS>ping -n 1 www.c2.com Haciendo ping a www.c2.com [209.162.215.78] con 32 bytes de datos: Respuesta desde 209.162.215.78: bytes=32 tiempo=268ms TDV=228 Estadísticas de ping para 209.162.215.78: Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: Mínimo = 268ms, máximo = 268ms, promedio = 268ms C:\WINDOWS> ¿Cuál es nuestra dirección MAC? 00C026260D14 ¿Cuál es la dirección IP y la máscara de red de nuestro PC? La 200.200.200.5, con máscara 255.255.255.0. ¿Cómo ha averiguado nuestro PC su dirección IP? La ha obtenido de un servidor DHCP, pues la salida del comando “ipconfig /all” nos indica que el DHCP está activado. ¿Cuál es el router por defecto de la red de nuestro PC? Es el 200.200.200.1, también llamado “Puerta de enlace predeterminada”. ¿Cuál es el servidor DHCP del que hemos obtenido la dirección IP? El servidor DHCP es el equipo 200.200.200.1, lo cual quiere decir que es el mismo router el que también está también haciendo las funciones de servidor DHCP. Hay que hacer notar que esto no es obligatorio y que dicha función de servidor DHCP podría haber sido implementada en cualquier otro equipo. ¿Cuándo obtuvimos por última vez permiso del servidor para usar nuestra dirección IP? El 4 de mayo de 2002 a las cero horas, 12 minutos y 10 segundos. ¿Por cuánto tiempo nos dieron permiso para usar nuestra dirección IP en el momento de concedérnosla? Por una hora, pues la salida del comando “ipconfig /all” nos indica que el permiso caduca justo una hora después del instante en que nos la concedieron. Antes de que transcurra ese tiempo debemos intentar que el servidor DHCP nos renueve la licencia de uso de la IP que nos ha asignado. ¿Qué hemos empleado al ejecutar el comando PING en lugar de la IP del host destino? Hemos utilizado el nombre de dominio de la máquina destino del ping. Queremos hacerle ping a una máquina llamada “www” dentro del dominio “c2” que se encuentra a su vez dentro del dominio de primer nivel “com”. ¿A qué dirección IP hemos dirigido el mensaje ICMP de petición de eco?

http://www.c2.com

http://www.c2.com

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


A la 209.162.215.78, que es la dirección IP asociada al nombre de dominio “www.c2.com”. A continuación se muestra el tráfico generado en la red 200.200.200.0 /24 como consecuencia de la ejecución del comando PING:

¿Cuál es la dirección MAC de nuestro router por defecto? 0020EA18D151, según se muestra en el mensaje ARP que nos ha enviado como respuesta a la petición ARP que hemos enviado en una trama con dirección destino BROADCAST. ¿A qué equipo hemos enviado el paquete IP cuyo contenido se muestra en la ventana anterior? A un equipo cuya IP es la 193.152.63.197, que sabemos que es un servidor DNS pues así nos lo ha indicado la salida del comando “ipconfig /all”. ¿Qué contiene el paquete IP mostrado en la ventana anterior? Contiene un segmento UDP (Datagrama UDP), pues el campo “Protocol ID” del paquete contiene el valor 17, que es el que identifica al protocolo UDP. ¿Cómo sabe el analizador de protocolos de qué tipo son los datos que contiene un datagrama UDP? Si el puerto origen o el puerto destino del datagrama UDP es un puertos bien conocido (“Well Known Port”), el analizador considera que los datos del datagrama son del protocolo asociado a dicho puerto. Por ejemplo, en la ventana anterior en analizador está decodificando los datos del datagrama UDP como si fuesen datos del protocolo DNS, pues se ha dado cuenta de que el puerto destino del datagrama UDP es el 53, que es un puerto bien conocido reservado para dicho protocolo. ¿Qué contiene el datagrama UDP mostrado en la ventana anterior? Contiene una pregunta realizada a un servidor DNS. En ella nuestro PC esta requiriendo que se le informe de la IP asociada al nombre “ww.c2.com". ¿Qué significado tiene el contenido de la columna “Summary” en el caso de la trama con ID=2?

http://www.c2.com

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


El texto mostrado en la columna “Summary” pretende describir de forma resumida el contenido de la trama. En este caso nos aparece la descripción a nivel de aplicación, pues actualmente el analizador está configurado para describir en la columna “Summary” los datos de mayor nivel encontrados en cada trama. Concretamente se nos da la cadena “DNS C ID=1 OP=Query QN=www.c2.com” como descripción de la trama con ID=2. La cadena aparece en color azul para indicar que el contenido descrito es de nivel de aplicación. La palabra “DNS” nos dice que los datos pertenecen al protocolo de aplicación DNS. La “C” indica que es un “Command”. Con “ID=1” se nos informa del valor del campo “Identification” del mensaje DNS. Por último, con “OP=Query QN=www.c2.com” nos confirma que se trata de una pregunta acerca del nombre “www.c2.com”. A continuación se muestra parte del contenido de la trama con ID=3, la cuál forma parte del tráfico generado en la red 200.200.200.0 /24 a consecuencia del comando PING.

¿Qué equipo envía la trama con ID=3? El equipo con IP 200.200.200.1, que es el router por defecto de nuestro PC, pues suya es la dirección MAC origen de dicha trama. ¿Qué equipo envía el paquete contenido en la trama con ID=3? El servidor DNS, cuya IP es la 193.152.63.197, como podemos ver en el campo “Source Address” del datagrama IP. ¿A qué equipo pertenecen la MAC destino de la trama con ID=3 y la “Destination Address” del paquete IP contenido en dicha trama? A nuestro PC.

http://www.c2.com

http://www.c2.com

http://www.c2.com

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Ha respondido el servidor a la pregunta que le ha realizado nuestro PC? Efectivamente, una análisis de los datos del protocolo DNS contenido en el datagrama muestran, entre otras cosas, que la IP asociada al nombre “www.c2.com” es la 209.162.215.78 . ¿Por qué el puerto destino del datagrama UDP mostrado en la ventana anterior es el 1044? Este datagrapa UDP nos lo envía el servidor DNS en respuesta al datagrama que le hemos enviado anteriormente. Como en nuestro datagrama el puerto origen era el 1044, el servidor DNS ha utilizado ese mismo puerto como destino a su respuesta, a sabiendas de que el proceso que le hizo la pregunta estará esperando la respuesta en ese mismo puerto. ¿Por qué el proceso que ha efectuado la labor de cliente DNS en nuestro PC ha escogido el puerto UDP 1044 para comunicarse con el proceso que efectúa la labor de servidor DNS? El proceso cliente puede escoger para comunicarse cualquier puerto que no se esté usando avtualmente en el PC y que no pertenezca al rango de puertos bien conocidos, o puertos reservados, que son los que van del 0 al 1023. Por tanto, se ha usado el 1044, pero podría haberse escogido el 2444, el 3902 o cualquier otro. Cuando no tiene libertad de elección para el proceso cliente DNS es a la hora de decidir qué puerto destino debe usar, pues forzosamente debe usar el 53, que es el que se reserva en las máquinas que actúan de servidor DNS para ubicar al proceso que efectúa dicha labor. A continuación se muestra parte de la trama que contiene el mensaje ICMP de petición de eco:

¿Se habría capturado en la red un tráfico diferente si en lugar de haber usado el nombre de dominio se hubiese usado la dirección IP 209.162.215.78 al hacer el PING? Las únicas tramas que no se habrían generado las tramas con ID=2 e ID=3 relacionadas con el servidor DNS. Los mensajes ICMP habrían sido exactamente iguales, al igual que los paquetes ARP, pues el equipo 209.162.215.78 está fuera de la red del PC, igual que los estaba el equipo 193.152.63.197, lo que obliga a averiguar la MAC del router para hacerle llegar a él los paquetes IP, de forma que puedan salir de la red 200.200.200.0 /24 en la que se encuentra el PC. ¿Se le ocurre alguna ventaja derivada de usar el nombre de dominio en lugar de la IP de un equipo? Es más fácil de recordar que la IP.

http://www.c2.com

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Ejercicio 19: Hemos encendido nuestro PC y se han capturado en el fichero “captura.cap” las tramas generadas como consecuencia del proceso de arranque. A continuación se muestra un listado con las tramas:

¿Qué son las tres últimas tramas capturadas, con ID=10, ID=11 e ID=12? Estas tramas contienen un mensaje ICMP de tipo 10 (“Router Solicitation”). Estos mensajes puede enviarlos un host después de arrancar para indicarle a todos los routers de la red a la que está directamente conectado que envíen un mensaje ICMP de tipo 9 (“Router Advertisement”), de forma que pueda conocerlos a todos. Puede observarse que ningún router ha respondido al mensaje, seguramente porque no tienen implementados estos dos mensajes ICMP. Nótese que la dirección IP a la que se envían estos mensajes es una dirección IP de clase D (Multicast), concretamente la 224.0.0.2, que está asignada a todos los routers de una subred. La dirección MAC asociada a esta IP multicast es la 01005E000002, que también es una dirección MAC especial, pues tiene a 1 el bit menos significativo de su primer octeto, indicando que es una dirección MAC multicast. Después del proceso de arranque hemos ejecutado lo siguiente en una ventana MS-DOS: C:\WINDOWS>ipconfig /all Configuración IP de Windows 98 Nombre del host . . . . . . . . . . . : PC1 Servidores DNS . . . . . . . . . . . . : 193.152.63.197 195.235.113.3 Tipo de nodo . . . . . . . . . . . . . : Difusión Id. De ámbito NetBIOS . . . . . . . . : Enrutamiento IP activado . . . . . . . : No WINS Proxy activado . . . . . . . . . : No Resolución NetBIOS usa DNS . . . . . . : No 0 Ethernet adaptador : Descripción . . . . . . . . . . . . . : Realtek 8139-series PCI NIC Dirección física . . . . . . . . . . . : 00-C0-26-26-0D-14 DHCP activado . . . . . . . . . . . . : Sí Dirección IP . . . . . . . . . . . . . : 200.200.200.5 Máscara de subred . . . . . . . . . . : 255.255.255.0 Puerta de enlace predeterminada . . . : 200.200.200.1 Servidor DHCP . . . . . . . . . . . . : 200.200.200.1 Servidor WINS primario . . . . . . . : Servidor WINS secundario . . . . . . . : Permiso obtenido . . . . . . . . . . . : 06 05 02 23:59:57 Permiso caduca . . . . . . . . . . . . : 07 05 02 0:59:57 C:\WINDOWS>

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿En qué RFC se describen los mensajes ICMP de tipo 9 y tipo 10? Buscando en la web http://www.rfc-editor.org aquellas que tienen en su título la palabra “ICMP” y después de un breve análisis de las mismas, hemos comprobado que la RFC1256, “ICMP Router Discovery Messages”, que actualmente no tiene el estado de “STANDARD”, es la que describe ambos mensajes ICMP. ¿Cuál es el servidor DHCP del que hemos obtenido la dirección IP? El servidor DHCP es el equipo 200.200.200.1, lo cual quiere decir que es el mismo router el que también está también haciendo las funciones de servidor DHCP. Hay que hacer notar que esto no es obligatorio y que dicha función de servidor DHCP podría haber sido implementada en cualquier otro equipo. A continuación se muestra parte del primer mensaje DHCP capturado en la red 200.200.200.0 /24:

¿Qué puertos origen y destino tiene la PDU de nivel 4 contenida en la trama con ID=0? La PDU de nivel 4 es, en este caso, un datagrama UDP, cuyo puerto origen es el 68 y cuyo puerto destino es el 67. Ambos puertos son “Well Known Ports” listados en la página web “http://www.iana.org/assignments/port-numbers”. En ella se nos dice que el puerto 67 de UDP es usado por los servidores del protocolo Bootstrap (BootP) y que el puerto 68 de UDP es usado por los clientes del protocolo Bootstrap. ¿Cuál es la estructura de un mensaje BootP?

http://www.rfc-editor.org

http://www.iana.org/assignments/port-numbers

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Según la RFC951, un mensaje BootP tiene una parte fija de 236 octetos, que es obligatoria, y una parte variable, que es opcional. La parte fija comprende desde el campo “Op Code”, justo a continuación de la cabecera UDP, hasta el campo “Boot File name”, ambos inclusive. La parte opcional está pensada para que los diferentes diseñadores de protocolos incluyan ahí la información que ellos estimen necesaria para complementar y extender la funcionalidad del protocolo Bootstrap. Es por ello que, caso de existir parte opcional, el único campo obligatorio es el primero, llamado “Magic Cookie”, que contiene un número de 32 bits que sirve para saber de qué forma hay que interpretar la información opcional que vienen a continuación. Lo más habitual es encontrarnos con que “Magic Cookie” vale 0x63825363 (hexadecimal), lo cual indica que se trata de opciones del protocolo DHCP. ¿Puede existir el protocolo DHCP sin el protocolo BootP? No. Tal y como se ha diseñado DHCP (“Dynamic Host Configuration Protocol”), no se trata de un protocolo “autónomo”. Ha sido concebido como una “extensión” de un protocolo ya existente, el BootP, que había sido diseñado de forma que fuese “extensible” gracias a su campo de opciones. ¿Dónde se definen el funcionamiento del protocolo DHCP así como las diferentes opciones que pueden aparecer en un mensaje BootP? Las RFC2131 describe el funcionamiento del protocolo DHCP y la RFC2132 describe las diferentes opciones que pueden aparecer en un mensaje BootP. ¿Cuánto ocupa la parte opcional del mensaje BootP contenido en la trama con ID=0? Según nos dice el analizador, el mensaje BootP contenido en el datagrama UDP mide 300 octetos. Si a esto le restamos los 236 octetos de la parte fija, tenemos que, en este caso, las opciones DHCP ocupan 64 octetos. ¿Cuántos tipos de mensajes BootP existen? Hay dos tipos. Los mensajes de tipo BOOTREQUEST, que tienen el campo “Op Code” a valor 1, y los mensajes BOOTREPLY, que tienen el campo “Op Code” a valor 2. Se pueden distinguir los dos tipos en el listado de tramas pues aparecen etiquetados con “Req” o “Rep” respectivamente en la columna “Summary” del listado de tramas. ¿Cuántos tipos de mensajes DHCP se han capturado en la red 200.200.200.0 /24? En el listado de tramas vemos que son cuatro mensajes DHCP los que se han capturado, cada uno de un tipo diferente. Estos tipos son DHCPDISCOVER, DHCPOFFER, DHCPREQUEST y DHCPACK. El analizador lo indica de forma resumida diciendo “MT=DISCOVER” (Message Type=DHCPDISCOVER). ¿A qué dirección IP va dirigido el paquete IP que contiene al mensaje DHCPDISCOVER? A la IP 255.255.255.255, puesto que el cliente DHCP acaba de arrancar y no conoce la IP del servidor o servidores DHCP. Este paquete será recibido por todos los equipos de la red Ethernet en la que se encuentra el cliente. Si los routers de esta red son capaces de actuar como retransmisores BootP (“relay agents”), entonces el mensaje BootP podrá salir de la red origen y alcanzar otras redes. ¿Qué dirección MAC destino tiene la trama que contiene al mensaje DHCPDISCOVER? BROADCAST, pues al igual por las mismas razones expuestas anteriormente. ¿Qué dirección IP origen tiene el paquete IP que contiene al mensaje DHCPDISCOVER? La IP 0.0.0.0, indicando que el que lo envía no conoce su dirección IP. Ésta es una dirección IP reservada que sólo puede ser utilizada en el campo “Source Address”. ¿Envía el cliente DHCP su dirección MAC en el mensaje BootP? Sí. El campo “Client Hardware Address” sirve para esto. Es un campo de 16 octetos de longitud, por lo que es necesario que en el campo “Hardware Address Length” se diga que son 6 octetos los que ocupa realmente dicha dirección MAC. ¿Qué pretende el cliente con su mensaje DHCPDISCOVER? Pretende, como su propio nombre indica, descubrir los servidores DHCP que se encuentran disponibles. Los servidores, al recibir este mensaje podrán enviarle al cliente mensajes DHCPOFFER en los que le ofrecerán una dirección IP. ¿Qué dirección IP se nos ha ofrecido? Por el comando “ipconfig /all” sabemos que nuestra dirección IP es la 200.200.200.5, luego como sólo nos han ofrecido una dirección IP, debe ser esa. ¿Por qué hace el servidor DHCP una petición ARP asociada a la 200.200.200.5? Antes de ofrecérnosla a nosotros, el servidor DHCP se asegura de que nadie está utilizándola haciendo una petición ARP y comprobando que nadie le responde. A continuación se muestran las opciones DHCP del primer mensaje enviado por nuestro PC:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Qué estructura tienen las opciones DHCP? Las opciones DHCP pueden ocupar un único octeto o bien ser opciones multiocteto. Con un solo octeto sólo existe la opción “Padding” (de valor 0) y la opción “End” (de valor 255 en decimal). Las opciones multiocteto son todas las demás, y se componen de un primer octeto llamado “Option Tag” que indica el tipo o código de la opción, un segundo octeto que indica la longitud de la opción en octetos (sin contar los dos primeros octetos) y luego un número variable de octetos, que puede ser cero. Un ejemplo de esto es la opción “Requested IP Address” que puede verse en la ventana anterior. Su “Option Tag” es 50 (en decimal), su longitud vale 4, por lo que a continuación vienen los 4 octetos de la dirección IP que contiene esta opción DHCP. ¿De que sirve la opción “Requested IP Address”? Permite que el cliente solicite una dirección IP concreta en su mensaje DHCPDISCOVER. Nótese que el cliente no está obligado a solicitar una IP en concreto, ni el servidor está obligado a ofrecérsela. No obstante el cliente suele estar interesado en que le ofrezcan la misma dirección IP que se la haya asignado anteriormente y, normalmente, si el servidor tiene disponible dicha dirección IP, suele satisfacer su petición. En el caso que nos ocupa, parece ser que nuestro PC ha tenido en otra ocasión la dirección 200.200.200.5 y desea que le sea asignada otra vez, cosa que el servidor no ha tenido inconveniente en hacer. ¿De qué sirve la opción “Padding”? Sirve para rellenar espacio y/o separar opciones. ¿De qué sirve la opción “End”? Marca el fin de la información válida en el campo de opciones del mensaje BootP. Después de esta opción la única opción que puede aparecer es la opción “Padding”. ¿Qué tamaño máximo tienen los mensajes DHCP que está obligado a aceptar un cliente DHCP? En la RFC2131 se establece que un cliente debe ser capaz de aceptar mensajes BootP con hasta 312 octetos de opciones. Si a esto le sumamos los 236 octetos de la parte fija del mensaje BootP, los 8 octetos de la cabecera UDP y los 20 octetos de la cabecera IP, tenemos un datagrama de 576 octetos de longitud total, que es el mayor datagrama que está obligado a aceptar cualquier equipo. ¿Solicita nuestro PC, en su mensaje DHCPDISCOVER, algo más aparte de una dirección IP?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Mediante el uso de la opción “Parameter Request List” el cliente puede solicitar al servidor una cantidad variable de parámetros que le hagan falta para configurarse adecuadamente. En este caso ha solicitado 9 parámetros. Cada uno de los parámetros solicitados viene identificado por un octeto, cuyo valor debe ser el de la “Option Tag” de una opción DHCP. Por ejemplo, vemos que nuestro PC ha incluido como primer parámetro el que tiene valor 1, que corresponde a la opción “Subnet Mask”, indicando por tanto que desea que se le informe de cuál es su máscara de red y poder así completar su configuración IP. También ha incluido en la lista de parámetros requeridos el parámetro de valor 6, correspondiente a la opción “Domain Name Server”, pues desea que se le informe de cuáles son los servidores DNS que puede utilizar. A continuación se muestran algunas de las opciones DHCP incluidas en el mensaje DHCPOFFER:

¿Qué tipo de mensaje BootP se muestra en la ventana anterior? Como el “Op Code” es 2, se trata de un mensaje BOOTREPLY. ¿Se utilizan los mismos puertos origen y destino en los mensajes BOOTREQUEST y BOOTREPLY? No. Ya hemos visto los puertos usados en los mensajes BOOTREQUEST. En los mensajes BOOTREPLY se invierten los puertos con respecto al mensaje BOOTREQUEST, pues ahora es el servidor DHCP el que envía el mensaje al cliente. ¿Cómo se sabe cuál es el tipo de un mensaje DHCP? Basta con mirar el contenido de la opción “DHCP Message Type” cuyo “Op Code” es el 53. Ésta es una opción multiocteto de longitud 1, lo que quiere decir que tiene un único campo de longitud 1. El valor de este único octeto es el que indica de que clase de mensaje DHCP se trata: 1=DHCPDISCOVER, 2=DHCPOFFER, 3=DHCPREQUEST, 4=DHCPDECLINE, 5=DHCPACK, 6=DHCPNAK, 7=DHCPRELEASE y 8=DHCPINFORM. Esta opción debe aparecer obligatoriamente en todos los mensajes DHCP.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Qué dirección IP está ofreciendo el servidor al cliente en este mensaje DHCPOFFER? La 200.200.200.5, que es le valor que aparece en el campo “Your (client) IP Address”. ¿Por cuánto tiempo dice que nos “presta” la dirección IP el servidor en su mensaje DHCPOFFER? La opción “IP Address Lease Time” nos indica que podemos disponer de la dirección durante 3600 segundos (1 hora). No obstante, lo normal es que podamos ir renovando el “préstamo” con el servidor antes de que expire el tiempo límite que éste nos indica cuando nos “presta” la IP. ¿Cómo sabe el cliente qué servidor le está enviando el mensaje DHCPOFFER? El cliente sabe que la IP del servidor es la 200.200.200.1 gracias a la opción “Server Identifier”. ¿Qué router podrá usar el cliente, a juzgar por el contenido del mensaje DHCPOFFER? El router con IP 200.200.200.1, según aparece en la opción “Router Option”. ¿Cuáles son las direcciones MAC origen y destino de la trama que contiene al mensaje DHCPOFFER? En este caso la MAC origen es la del servidor y la MAC destino es la del cliente. El servidor ha podido extraer la dirección MAC del cliente del mensaje DHCPDISCOVER. ¿Cuáles son las direcciones IP origen y destino del datagrama IP que contiene al mensaje DHCPOFFER? En este caso se observa que la dirección IP origen es la del servidor, mientras que la dirección IP destino corresponde a la que se ofrece al cliente. Quiere esto decir que el cliente debe ser capaz de aceptar un paquete IP dirigido a una IP concreta, la 200.200.200.5, pese a que él aún no tiene esa IP asignada. Algunos clientes antiguos no son capaces de hacer esto y se hace necesario usar otra técnica diferente, pero no es lo habitual. A continuación se muestra parte del contenido del mensaje DHCPREQUEST enviado por el cliente:

¿Qué contiene el mensaje DHCPREQUEST? Básicamente es muy parecido al mensaje DHCPDISCOVER. La diferencia es que ahora lo que el cliente ya conoce al servidor o servidores que la han hecho las ofertas y este mensaje le debe servir a todos los servidores para darse cuenta de que el cliente se ha decidido a aceptar la oferta de sólo uno de ellos. Ese es el motivo de enviar éste mensaje en BROADCAST, conseguir que llegue a todos los servidores. La opción “Server Identifier” incluida en este mensaje puede servir para que el servidor seleccionado sepa que el mensaje va dirigido a él y no a otro. ¿Cuál es la utilidad del campo “Transaction Id” del mensaje BootP”?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Es un número aleatorio escogido por el cliente que sirve para poder asociar las preguntas y respuestas que se intercambian el cliente y el servidor. A continuación se muestra el contenido del mensaje DHCPACK:

¿Qué sentido tiene la existencia del mensaje DHCPACK? Confirmar al cliente que el servidor le concede la IP que le ofreció en el anterior mensaje DHCPOFFER. Por lo demás, su contenido es idéntico al del mensaje DHCPOFFER. A veces, cuando al servidor le llega el mensaje DHCPREQUEST, puede ocurrir que la dirección ya haya sido asignada a otro cliente, por lo que en lugar de una DHCPACK el servidor enviaría un DHCPNAK para decirle al cliente que finalmente no es posible realizar el “préstamo” de la IP. ¿Están obligados todos los equipos de Internet a aceptar un paquete IP del tamaño que tiene el paquete IP mostrado en la ventana anterior?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Sí. El datagrama IP de la ventana anterior tiene 556 octetos de datos, que sumados a los 20 octetos de su cabecera IP nos dan 576 octetos, que es precisamente el tamaño del mayor datagrama que están obligados a aceptar todos los equipos que implementen el protocolo IP. ¿Se ha utilizado en el mensaje DHCPACK todo el espacio disponible para opciones BootP diferentes de la opción “Padding”? No. Se puede observar en el panel inferior de la ventana de captura que detrás de la opción “End” aparecen muchos octetos de relleno (la opción “Padding”), lo cual indica que a pesar de que se ha creado un mensaje BootP con un campo de opciones bastante grande, realmente hubiese bastado con un tamaño menor. ¿Qué servidores DNS le ha asignado el servidor al cliente? Según se observa en el interior de la opción “Domain Name Server” contenida en el mensaje DHCPACK mostrado en la ventana anterior, los servidores asignados son el 193.152.63.197 y el 195.235.113.3, lo cual coincide plenamente con la salida mostrada por el comando “ipconfig /all”. ¿Le ha suministrado el servidor al cliente todos los parámetros que solicitó el cliente en su mensaje DHCPDISCOVER? No. Por ejemplo, la opción 44, “NETBIOS over TCP/IP Name Server” no está incluida entre las que ha enviado el servidor, a pesar de que es un parámetro de los que solicitó el cliente. ¿Por qué se ha generado la trama con ID=5? Es una petición ARP realizada por el cliente al que acaba de concedérsele el uso de la dirección IP 200.200.200.5, en la cual se pregunta precisamente por a dirección MAC asociada a dicha dirección IP. Nadie ha respondido a la petición, lo cuál es una buena señal. Si alguien hubiese respondido a la petición ARP sería porque ya habría alguien usando esa dirección IP en la misma red que el cliente. En ese caso el cliente no haría uso de la dirección que se le ha asignado y debería avisar de este hecho al servidor mediante el mensaje DHCPDECLINE. ¿Quién ha generado un mensaje ICMP de petición de eco y por qué? El servidor DHCP, cuya IP es la 200.200.200.1 ha enviado un mensaje de petición de eco al cliente al poco tiempo de haberle enviado el mensaje DHCPACK. El objeto este mensaje es comprobar que efectivamente el cliente ha recibido el DHCPACK y ha empezado a usar con éxito la dirección IP 200.200.200.5, tal y como se le ha asignado. Nótese que el cliente no disponía en su caché ARP de la dirección MAC asociada a la IP 200.200.200.1, por lo que ha tenido que efectuar una petición ARP.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Ejercicio 20: En un PC conectado a una red Ethernet hemos abierto la ventana “Ejecutar” y hemos tecleado esto:

¿Qué pretendemos hacer al ejecutar ese comando? Queremos ejecutar el programa “telnet”, el cual nos abrirá una ventana de terminal “virtual” en nuestra máquina, desde la cual podremos enviar comandos a la máquina “route-server.ip.att.net” y ver la salida en pantalla de dichos comandos. ¿Qué es un terminal? Dicho de forma sencilla, un terminal es un equipo que sólo consta de una pantalla, un teclado y un puerto de comunicaciones serie, normalmente de muy baja velocidad. Los caracteres que se teclean en el terminal son transmitidos por la línea serie. Los caracteres que llegan por la línea serie se muestran en la pantalla conforme van llegando. La función de los terminales es poder conectarse de forma local (pocos metros de distancia) a equipos que dispongan de un puerto de comunicaciones serie, de forma que podamos introducir comandos y ver en pantalla los resultados. Es normal usarlos para dotar de pantalla y teclado a dispositivos que normalmente no lo tienen o bien tienen sólo uno. Por ejemplo podemos usarlo para conectarnos a un router e introducir su configuración. Otro uso típico es dotar a un equipo con varias pantallas en las que los usuarios puedan ejecutar programas en modo texto. Hoy por hoy, en el caso de que necesitemos un terminal, lo normal es que ejecutemos en nuestro PC una aplicación de emulación de terminal, del estilo al programa “Hyperterminal” que viene incluido en algunas versiones de Windows, el cual hace uso de la pantalla, el teclado y el puerto serie del PC para comportarse exactamente igual a como lo haría un terminal verdadero. El uso de los terminales plantea algunos inconvenientes. Por un lado, si queremos conectar varios usuarios simultáneamente a una máquina, necesitaremos que la máquina disponga de varios puertos de comunicaciones serie. Además, las técnicas de comunicación serie utilizadas en los terminales son muy sencillas y no suelen alcanzar más de unas decenas de metros de distancia, por lo que el terminal debe estar físicamente cerca de la máquina salvo que empleemos un par de modems que permitan extender la distancia. El uso de modems telefónicos permite que el terminal y la máquina a la que se conectan estén en cualquier lugar, siempre que ambos tengan acceso a una línea telefónica. ¿Qué es un terminal “virtual”? Cuando tanto el equipo al que nos queremos conectar (el servidor) como el equipo en el que vamos a ejecutar el programa de emulación de terminal (el cliente) están conectados a través de una red, el cable de comunicación serie ya no es necesario y su función puede ser implementada haciendo uso de la red. Por tanto, un terminal virtual es un emulador de terminal que no usa el puerto de comunicaciones serie para comunicarse con la máquina a la que se conecta, sino que en su lugar usa una red de comunicaciones. La información tecleada es transportada desde el terminal virtual al servidor a través de la red. Análogamente, la información que la máquina que hace de servidor desea mostrar en la pantalla del terminal será transportada también a través de la red. ¿Qué protocolo usa el programa “telnet” que hemos ejecutado en nuestro PC? El programa “telnet” que hemos ejecutado en nuestro PC (el terminal), usa para comunicarse con la otra máquina (el servidor) el protocolo “telnet”, descrito en la RFC854 y la RFC855. El protocolo “telnet” es un protocolo de nivel de aplicación (según la arquitectura TCP/IP), que viaja, por tanto, sobre una conexión TCP que habrá de establecerse antes de que puedan enviarse datos. ¿Qué puerto TCP utiliza para comunicarse el proceso servidor que se encuentra en la máquina a la que queremos conectarnos? La RFC854, en su página 15, indica que los procesos servidores que hablen el protocolo “telnet” deben usar el puerto 23 (decimal). Eso mismo es lo que nos encontramos si consultamos en http://www.iana.org/assignments/port-numbers la lista de puertos bien conocidos (Well Known Ports).

http://www.iana.org/assignments/port-numbers

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


A continuación podemos ver la ventana que nos muestra nuestro PC después de haber ejecutado el comando “telnet route-server.ip.att.net”:

¿A qué equipo nos hemos conectado como usuarios? Por lo que podemos ver en pantalla parece ser que estamos conectados a un router de la compañía AT&T (American Telephone and Telegraph). En la última línea de la pantalla, justo después de la información inicial que se nos muestra, podemos ver el “prompt” del router y el cursor, indicando que el router está a la espera de que tecleemos algún comando. Nótese que en este caso no se nos ha pedido ningún tipo de clave para poder iniciar la sesión TELNET con el router. Desde la ventana de terminal virtual que tenemos abierta en nuestro PC hemos ejecutado varios comandos, los cuales veremos en detalle más adelante. A continuación se muestra parte del tráfico generado en la red de nuestro PC como consecuencia del diálogo que ha tenido nuestro PC con el router:

¿Cuál es la IP de nuestro PC? Es la 200.200.200.5, pues la IP “Source” de la petición ARP contenida en la primera trama generada. ¿Cuál es la máscara de red de nuestro PC? Con la información que se nos ha dado hasta ahora es imposible saberlo.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Cuál es la IP del equipo que tiene por nombre “route-server.ip.att.net”? Según se ve en el listado de tramas, hay una conexión conexión TELNET establecida entre el equipo con IP 200.200.200.5 (nuestro PC) y el equipo con IP 12.0.1.28, por lo que podemos decir que esta última es la IP del equipo al que nos hemos conectado mediante “telnet” y cuyo nombre es “route-server.ip.att.net”. Nótese que una conexión TELNET es una conexión TCP por la cuál viajan datos del protocolo TELNET. ¿Cómo hemos averiguado la IP del equipo “route-server.ip.att.net”? Se lo hemos consultado a un servidor DNS (“Domain Name Server”). Concretamente, podemos ver en el listado de tramas que la IP del servidor DNS que hemos utilizado es la 193.152.63.97, pues esa es la IP “Destination” de la petición DNS contenida en la trama con ID=2. ¿cuántas tramas contiene el archivo “captura.cap”? 106 tramas. ¿Está el servidor DNS en la misma red que nuestro PC? No, pues antes de comunicarnos con él hemos hecho una petición ARP para conseguir la dirección MAC del equipo con dirección IP 200.200.200.1, lo cuál nos hace pensar que el equipo 200.200.200.1 es el router que vamos a utilizar para que nos enrute el paquete IP que queremos hacerle llegar al servidor DNS. Si el servidor DNS estuviese en nuestra misma red, la petición ARP hecha al equipo 200.200.200.1 no se habría efectuado. ¿Se habría efectuado una petición ARP para averiguar la dirección MAC del servidor DNS si éste hubiese estado en la misma red que nuestro PC? En ese caso se habría mirado primero en la caché ARP en busca de la IP del servidor DNS y, si no se hubiese encontrado, se habría procedido a efectuar la petición ARP correspondiente. ¿Es posible que la máscara de red de nuestro PC esté configurada actualmente a valor 0.0.0.0? Si estuviese configurada a 0.0.0.0, nuestro PC creería que la IP 193.152.63.97 forma parte de su misma red, cosa que no ha ocurrido, por lo que podemos afirmar que la 0.0.0.0 no es la máscara de red que tenemos asignada. Recuérdese que con la máscara “/0”asignada, cualquier equipo considerará que cualquier dirección IP forma parte de su misma red. ¿Qué valor tiene en binario la IP del servidor DNS? La IP 193.152.63.97 es 11000001 10011000 00111111 01100001 en binario. ¿Qué valor tiene en binario la IP del router por defecto de nuestro PC? La IP 200.200.200.1 es 11001000 11001000 11001000 00000001 en binario. ¿Qué valor tiene en binario la IP de nuestro PC? La IP 200.200.200.5 es 11001000 11001000 11001000 00000101 en binario. ¿Qué valor tiene en binario la IP del equipo “route-server.ip.att.net”? la IP 12.0.1.28, es 00001100 00000000 00000001 00011100 en binario. ¿Consideraría nuestro PC que el servidor DNS forma parte de su propia red si la máscara de red asignada a nuestro PC fuese la 224.0.0.0? La máscara 224.0.0.0 equivale a “/3”, por lo que nuestro PC consideraría que una IP forma parte de su red si los tres primeros bits de dicha IP son idénticos a los tres primeros bits de su propia dirección IP, que son “110” en este caso. Como resulta que la IP 193.152.63.97 tiene los tres primeros bits a “110”, podemos decir que con dicha máscara nuestro PC consideraría al servidor DNS como perteneciente a su misma red. ¿Qué máscara de red tendría que tener configurada nuestro PC para que éste considerase que la IP 12.0.1.28 forma parte de su misma red? Para que ocurra eso, la única máscara posible es la 0.0.0.0 (“/0”), pues se observa que las direcciones IP 200.200.200.5 y 12.0.1.28 no tienen ni siquiera el primer bit en común. Nótese que, como anteriormente habíamos llegado a la conclusión de que esa no era la máscara de red de nuestro PC, podemos decir que nuestro PC considera que la IP 12.0.1.28 no forma parte de su misma red. A continuación se muestra, de otra forma, algo del tráfico contenido en el fichero “captura.cap”:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Cuál es la dirección MAC del equipo con IP 200.200.200.1? 0020EA18D151, según se ve en la respuesta ARP. ¿A qué dirección MAC va dirigida la trama que contiene la petición DNS dirigida al servidor DNS? A la dirección MAC 0020EA18D151, que corresponde a la del equipo con IP 200.200.200.1, lo cuál nos confirma lo que ya decíamos antes: el 200.200.200.1 es un router y el servidor DNS está ubicado en una red diferente a la de nuestro PC. A continuación se muestra el contenido de la trama con ID=4 capturada en la red de nuestro PC:

¿Qué tipo de segmento TCP contiene la trama con ID=4? Un segmento SYN, tal como se indica en el listado de tramas, usado para abrir la conexión TCP. ¿A qué dirección MAC va dirigida la trama que contiene el segmento TCP que sirve para abrir la conexión con el equipo “route-server.ip.att.net”.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


A la dirección MAC 0020EA18D151, según podía verse en una de las ventanas anteriores, la cual corresponde a la del equipo con IP 200.200.200.1, lo cuál nos confirma lo que ya decíamos antes: el 200.200.200.1 es un router y el equipo al que le estamos haciendo TELNET está fuera de la red de nuestro PC. ¿Habría llegado al equipo 12.0.1.28 el segmento SYN que le ha enviado el 200.200.200.5 si en la ruta que tiene que seguir a través de Internet se hubiese encontrado con una red cuya MTU fuese de 45 octetos? No habría podido llegar, puesto que el datagrama dirigido al 12.0.1.28 tiene una longitud total de 48 octetos (20 de cabecera y 28 de datos) y se observa que tiene activado el bit DF , lo cual habría impedido la fragmentación necesaria para poder atravesar la red de 45 octetos de MTU. ¿Cuál es la longitud de la cabecera IP del paquete contenido en la trama con ID=4? En la ventana anterior el analizador nos muestra decodificada la parte final de la cabecera IP y puede verse que no hay opciones al final de la misma, justo detrás de la “Destinación Address”, así que la longitud de la cabecera es de 20 octetos, la mínima posible. Otra forma de averiguarlo es localizar en el panel inferior de la ventana de captura el octeto asociado al campo “Versión/Header Length”, que en este caso vale 0x45 (hexadecimal) y está colocado en la posición 0x0E (hexadecimal) de dicho panel. El valor 0x45 indica que el campo “Header Length” vale 5, por lo que la cabecera mide 5 palabras de 32 bits, que son los 20 octetos que habíamos dicho. ¿Cuál es la longitud de la cabecera TCP del segmento que hay en el interior de la trama con ID=4? El campo “Header Length” de la cabecera tiene una anchura de 4 bits y su valor es 7 en este caso, lo cual indica que la longitud de la cabecera TCP es de 28 octetos (7 palabras de 32 bits). ¿Incluye opciones el segmento TCP mostrado en la ventana anterior? Efectivamente, pues todo segmento TCP con más de 20 octetos de cabecera es un segmento con opciones. Según lo que nos muestra el analizador, hay una opción de tipo 2 (Maximum Segment Size), dos opciones de tipo 1 (No Operation) y una opción de tipo 4 (TCP Selective ACK Permitted). ¿Qué está indicando nuestro PC al usar la opción MSS (“Maximum Segment Size”) con el valor 1460 en el segmento SYN que envía al 12.0.1.28 para abrir la conexión TCP? Está informando al 12.0.1.28 de que está dispuesto a recibir segmentos TCP que contengan como mucho 1460 octetos de datos. Nótese que esta opción sólo puede usarse en segmentos SYN. No es obligatorio hacer uso de esta opción, pero es muy recomendable hacerlo. ¿Qué está indicando nuestro PC al usar la opción SACK-permitted (“TCP Selective ACK Permitted”) en el segmento SYN que envía al 12.0.1.28 para abrir la conexión TCP? Permitiendo al equipo 12.0.1.28 usar la opción SACK (“TCP Selective ACK”). Esto hay que hacerlo pues no todos los hosts implementan esta mejora sobre el funcionamiento normal de TCP, por lo que si no se le da permiso explícitamente, dicha opción no será utilizada por la otra parte. Nótese que la opción SACK-permitted sólo puede usarse en segmentos SYN. ¿Para que se han usado las dos opciones “No Operation” en el segmento TCP mostrado en la ventana anterior? Para conseguir que las opciones TCP ocupen 8 octetos, que es múltiplo de 4 octetos. ¿Cómo sabe el analizador que el datagrama IP mostrado en la ventana anterior contiene datos del protocolo TCP? Porque el valor del campo “Protocol ID” del cabecera IP es 6, que es le valor que identifica al protocolo TCP. ¿Qué flags tiene activados el segmento TCP contenido en la trama con ID=4? Sólo tiene activado (a valor 1) el bit SYN. Los otros cinco, URG, ACK, PSH, RST Y FIN están desactivados (a valor 0). Un segmento con el bit SYN es un segmento de sincronización que sirve para abrir la conexión y comunicarle al otro host nuestro número de secuencia inicial. ¿Es posible enviar un segmento TCP cuya longitud sea mayor que la longitud máxima de los datos que puede transportar un datagrama IP? No. Un segmento debe viajar siempre dentro de un único datagrama IP, por lo que si no cabe en un datagrama IP la solución es crear un segmento TCP más pequeño, con menos datos en su interior. Nótese que no hay ningún inconveniente en fragmentar un datagrama IP que contenga un segmento TCP, pues la fragmentación de un datagrama IP no tiene nada que ver con el contenido del mismo. ¿Cómo se sabe cuál es la longitud total de un segmento TCP? En la cabecera del segmento TCP existe un campo que indica la longitud de dicha cabecera, pero no existe ningún campo que indique la longitud total de un segmento TCP ni tampoco la longitud de los datos. Sin embargo, sabemos que es posible conocer la longitud de los datos contenidos en un datagrama IP, lo cual permite conocer la longitud del segmento TCP contenido en un datagrama IP.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


A continuación puede verse el primer segmento TCP enviado por el equipo al que se le está haciendo TELNET, cuya IP es 12.0.1.28.

¿Qué opción TCP ha usado el equipo 12.0.1.28 en su primer segmento TCP? Únicamente ha usado la opción MSS (“Maximum Segment Size”) para decir que no se le deben enviar segmentos que contengan más de 536 octetos de datos. Nótese que no aparece la opción SACK-Permitted, lo cuál indica que es un host que no reconoce las opciones SACK y por tanto ni las enviará ni deben enviársele. ¿Qué flags tiene activados el primer segmento TCP enviado por el equipo 12.0.1.28? Está activado el bit SYN, indicando que es un segmento de sincronización. También está activado el bit ACK para indicar que el campo “Acknowledgement Number” es significativo y su valor debe tenerse en cuenta. ¿Qué número de secuencia inicial han escogido los equipos 200.200.200.5 y 12.0.1.28 para ir numerando los datos? El 200.200.200.5 escogió en su segmento SYN el número 2221078 como número de secuencia inicial. Por su parte, el 120.0.1.28 ha escogido el 3077941795 en el segmento SYN mostrado en la ventana anterior. ¿Para que ha servido el segmento SYN enviado por el 12.0.1.18 además de para informar al 200.200.200.5 del número de secuencia inicial que escogido por el 12.0.1.28? El segmento SYN que le llega al 200.200.200.5 tiene el bit ACK activado y el valor del campo “Acknowledgement Number” es 2221079, lo cual indica que el 12.0.1.28 ha recibido correctamente el bit SYN (que tenía asociado el número de secuencia 2221078) y está esperando recibir el octeto de

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


datos con número de secuencia 2221079. Nótese que no se está reconociendo el segmento SYN sino el bit SYN, que tiene asociado un número de secuencia como si se tratase de un octeto de datos, el primero de todos. ¿Indica algo especial el valor 0 que tiene el campo “Identification” de la cabecera IP del primer datagrama IP que ha enviado el equipo 12.0.1.28? No. El valor 0 es tan válido como otro cualquiera. Este campo sólo se usa para reconocer los diferentes fragmentos en los que ha quedado dividido un datagrama. Lo importante es procurar que todos los datagramas IP enviados de un equipo a otro tengan valores distintos en ese campo o, por lo menos, que cuando se repita un valor, el anterior datagrama IP que lo usó ya haya llegado a su destino. ¿Qué puertos TCP se están usando en esta conexión? Cuando el cliente TELNET ubicado en nuestro PC envió el primer segmento TCP al servidor ubicado en el equipo 12.0.128, lo hizo poniendo como “Destination Port” el 23, pues ese es el puerto bien conocido que usan por defecto todos los procesos que hacen el papel de servidores TELNET. En ese mismo segmento, el cliente TELNET escogió el 1165 como “Source Port”, seguramente porque era un puerto que no estaba siendo usado por ningún otro proceso en ese momento. A partir de ese momento, todos los segmentos enviados por el cliente van desde el puerto 1165 al 23, mientras que los segmentos que le envía el servidor van del puerto 23 hacia el 1165. La ubicación de los servidores en puertos bien conocidos es simplemente una cuestión práctica, pues hace muy fácil averiguar en que puerto se encuentra esperando una conexión un determinado servidor dentro de una máquina. A continuación se muestra parte del contenido de la trama con ID=6:

¿Por qué en la ventana anterior nos muestra el analizador, justo después del segmento TCP, un campo llamado “Data/Padding” que tiene una longitud de 6 octetos? En el panel inferior de la ventana de captura podemos ver que la trama con ID=6 tiene 64 octetos de longitud y contiene 46 octetos de datos, al descontarle la MAC destino, MAC fuente, campo Ethertype y campo FCS. Los 46 octetos de longitud mínima que deben tener los datos contenidos en una trama

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Ethernet no han podido alcanzarse con el datagrama IP que contiene esta trama, pues éste sólo ha ocupado 40 octetos en este caso (20 de la cabecera IP y 20 de la cabecera TCP), así que la tarjeta Ethernet ha debido de añadir 6 octetos de relleno (“Padding”) para completar los datos de la trama. ¿Qué está queriendo decir el equipo 200.200.200.5 al enviar el segmento TCP mostrado en la ventana anterior? El segmento TCP mostrado en la ventana anterior no contiene datos. Su misión es indicarle al equipo 12.0.1.28 que se ha recibido correctamente el segmento SYN que éste ha enviado. Realmente el reconocimiento no va asociado al segmento SYN sino al bit SYN, cuyo número de secuencia era el 3077941795. Es por eso que el éste segmento tiene activado el flag ACK y el valor del campo “Acknowledgement Number” es 3077941796, indicando que se está esperando recibir el octeto con dicho número de secuencia y que se han recibido todos los anteriores a éste (incluyendo, por tanto, al bit SYN). Normalmente el analizador de protocolos muestra en la columna “Summary” del listado de tramas información relativa a los datos del protocolo de mayor nivel que se encuentran encapsulados en cada trama, tal y como se puede apreciar en la siguiente ventana:

No obstante, también se puede configurar el analizador de protocolos para que en la columna “Summary” la información mostrada sea del protocolo de mayor nivel posible, siempre que éste no sea mayor que el nivel de transporte, tal y como se puede ver en la siguiente ventana:

¿Qué ventajas ofrece cada una de las dos formas de presentar el listado de tramas frente a la otra? La presentación del listado de tramas omitiendo la información del nivel de aplicación hace que podamos ver de un vistazo un resumen del los principales campos de todos los segmentos TCP y de

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


los datagramas UDP, incluso de aquellos que contienen datos de nivel de aplicación. Esto es muy útil si lo que queremos es hacer un estudio del comportamiento del nivel de transporte sin importarnos los niveles superiores. Por otro lado, si lo que nos interesa es analizar el comportamiento del protocolo del nivel de aplicación, TELNET y DNS en nuestro caso, lógicamente lo mejor es que se muestre la información del protocolo de mayor nivel contenido en cada trama. De todas formas, se seguirá mostrando exclusivamente información de nivel de transporte para los segmentos TCP que no contengan datos (LEN=0). ¿Qué campos de las cabeceras de nivel de transporte se muestran en la columna “Summary” del listado de tramas? Lo primero es el tipo de protocolo de nivel de transporte (UDP o TCP) en este caso. Si es un datagrama UDP se muestran también el puerto origen, el puerto destino y la longitud total del datagrama. Si es un segmento UDP se muestra el puerto origen (SP), el puerto destino (DP), el número de secuencia (SEQ), el número de reconocimiento (ACK), el tamaño de la ventana (WS), los flags (PSH, SYN, etc. a excepción del ACK), la longitud de los datos contenidos en el segmento (LEN=n) y una indicación de si el segmento incluye opciones (OPT). ¿Qué se está indicando cuando se envía un segmento con el flag ACK activado? Si el flag ACK está activado, entonces el valor del campo “Acknowledgement Number” está indicando el número de secuencia de un octeto que aún no ha sido recibido. Además, implícitamente se está reconociendo que han llegado correctamente todos los octetos cuyos números de secuencia son inferiores ése. ¿Por qué, de los 102 segmentos TCP que se han intercambiado los dos equipos durante el tiempo que ha durado la conexión, tan sólo el primer segmento, enviado por el equipo 200.200.200.5, tenía el flag ACK desactivado? En ese primer segmento, el equipo 200.200.200.5 no podía indicar qué octeto estaba esperando recibir, pues la conexión no estaba establecida y el otro equipo no había elegido aún su número de secuencia inicial, así que el campo “Acknowledgement Number” tenía un valor sin sentido (cero en este caso) y el flag ACK estaba desactivado para indicar esta circunstancia. Sin embargo, en el resto de segmentos, el emisor ya sabía cual era el octeto que estaba esperando recibir de su interlocutor y por eso se incluye siempre dicho valor en el campo “Acknowledgement Number” y se activa el bit ACK. Téngase en cuenta que hacer esto no implica que el segmento tenga un mayor tamaño, pues tanto el flag ACK como el campo “Acknowledgement Number” ocupan espacio en la cabecera TCP, sea cual sea su valor. ¿Qué indica la llegada de un segmento con el campo “Sequence Number” a valor “x”? Quiere decir que el primer octeto de los datos contenidos en ese segmento tiene asignado el número de secuencia “x”, el segundo octeto de datos tendrá asignado el “x+1” y así sucesivamente. Si el segmento no contiene datos nos da igual el valor de este campo. Nótese que el flag SYN y el flag FIN consumen un número de secuencia, igual que si fueran un octeto de datos, aunque viajen en un segmento que no contenga datos. A continuación se muestra otra vez el listado de las tramas capturadas en la red de nuestro PC, encontrándose resaltada la trama con ID=6, la cual contiene el segundo segmento TCP enviado por el equipo 200.200.200.5:

¿Qué indica el equipo 200.200.200.5 con el valor 8576 en el campo “Window Size” del segmento contenido en la trama con ID=6? Ese valor es el tamaño de la ventana de recepción del equipo 200.200.200.5, por lo que cuando el 120.0.1.28 reciba este segmento sabrá que puede enviarle al 200.200.200.5 hasta 8576 octetos sin tener que esperar a que le vayan llegando los reconocimientos. Estos 8576 octetos se cuentan a partir del octeto con número de secuencia 3077941796, que es el número del primer octeto que el

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


equipo 200.200.200.5 está esperando recibir, pues ese es el valor del campo “Acknowledgement Number” presente en este mismo segmento. Podemos decir que la ventana de recepción de un equipo es un intervalo de números de secuencia que comprende desde el “Acknowledgement Number” (inclusive) hasta el “Acknowledgement Number + Window Size ” (exclusive). A estos números se les conoce como borde izquierdo y borde derecho de la ventana de recepción, respectivamente. ¿Ha reducido en algún momento el tamaño de la ventana de recepción el equipo 200.200.200.5? Sí. Por ejemplo, en la trama con ID=8 hay un segmento con el campo “Window Size” a valor 8564, que es una ventana de recepción 12 octetos menor que la que tenía antes. Se puede agrandar o reducir la ventana de recepción pero sin mover ninguno de sus dos bordes hacia atrás. En este caso lo que se ha hecho para reducir la ventana es avanzar en 12 octetos su borde izquierdo (“Acknowledgement Number” = 3077941808 = 3077941796 + 12) y se ha dejado quieto el borde derecho (“Acknowledgement Number + Window Size” = 3077941808 + 8564 = 3077941796 + 8576). ¿Ha reducido en algún momento el tamaño de la ventana de recepción el equipo 12.0.1.28? Sí. En la trama con ID=11 se ve que la anchura de la ventana de recepción es de 4288 octetos, mientras que en la trama con ID=12 la ventana de recepción del 12.0.1.28 es de 4285 octetos, tres menos que antes. La reducción de la anchura se ha efectuado correctamente, pues no se ha movido ninguno de los bordes de la ventana hacia atrás. El único que se ha movido ha sido el borde izquierdo, pues el campo “Acknowledgement Number” ha pasado de valer 2221079 a valer 2221082, que son tres octetos más que antes. A continuación se muestran los datos contenidos en un segmento TCP enviado por el servidor TELNET que se encuentra en la máquina 12.0.1.28:

¿Por qué sabe el analizador de protocolos que los datos contenidos en el segmento TCP mostrado en la ventana anterior corresponden al protocolo TELNET? El analizador, tal y como se muestra una de las ventanas anteriores, sabe que el puerto origen de este segmento TCP es el 23. Como el 23 es el puerto bien conocido reservado para el protocolo TELNET, se deduce que los datos son de dicho protocolo. Nótese que la misma deducción habría tenido lugar si hubiese sido 23 el valor del puerto destino. ¿Por qué aparece la etiqueta “Data” a la izquierda de los datos del protocolo TELNET? Porque se trata de datos y no de comandos TELNET.

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Qué ha hecho el cliente TELNET al recibir los datos del protocolo TELNET que se muestran en la ventana anterior? Como se trata de datos (caracteres de texto), el cliente TELNET ha procedido a representarlos en la ventana de salida del programa “telnet” que se está ejecutando en nuestro PC. Nótese que lo que el analizador nos muestra como <0D><0A> son los caracteres de control 0x0D y 0x0A correspondientes a un retorno de carro (CR, “Carriage Return”) y un avance de línea (LF, “Line Feed”), que tienen en pantalla el efecto de volver el cursor a la izquierda de la ventana y dejar una línea en blanco. Si nos fijamos en la ventana inicial que nos mostró el programa “telnet” nada más ejecutarlo, vemos que los datos mostrado en la parte final de dicha ventana son precisamente los datos contenidos en el segmento TCP mostrado en la ventana anterior. En la ventana del cliente TELNET, en la que se nos mostraba una pantalla de presentación y un “prompt”, hemos tecleado una interrogación “?” para ver qué comandos tenemos disponibles en el router y esto es lo que se nos ha mostrado en pantalla:

Como consecuencia de la pulsación de esta tecla se han generado en la red del PC 6 tramas, siendo la primera de ellas la que tiene el ID=21. A continuación puede verse un listado de las mismas:

¿Cuántos octetos de datos envía el PC al servidor TELNET, según lo visto en la ventana anterior? Sólo un octeto, el contenido en el segmento TCP de la trama con ID=21. Ese octeto será sin duda el carácter “?” que hemos tecleado en la ventana del terminal virtual. Los otros dos segmentos que envía el equipo 200.200.200.5 están vacíos. ¿Por qué están vacíos dos de los segmentos enviados por el cliente TELNET y mostrados en la ventana anterior?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Esos dos segmentos vacíos se han emitido para reconocer la llegada de los datos enviados por el servidor TELNET. Por ejemplo, en el tercer segmento mostrado en la ventana anterior han llegado al cliente 536 octetos con números de secuencia que van desde el 3077943310 al 3077943845. En el cuarto segmento se ve cómo con un ACK=3077943846 el 200.200.200.5 avisa al 12.0.1.28 de que le han llegado todos los octetos anteriores al 3077943846 y que está esperando precisamente el octeto con número de secuencia 3077943846. Lo mismo ocurre con el sexto segmento mostrado en la anterior ventana, que sirve únicamente para reconocer la llegada de los datos del quinto segmento y todos los anteriores. Nótese que si por algún motivo el cuarto segmento no llegase a su destino, bastaría con que llegase el sexto segmento para que todos los datos enviados hasta ahora por el servidor hubiesen quedado correctamente reconocidos. ¿Ha reconocido el servidor el octeto de datos que le ha enviado el cliente en el primer segmento mostrado en la pantalla anterior? Sí. En el segundo segmento que puede verse en la pantalla anterior se observa como ACK=2221105, indicando que se reconoce al octeto con SEQ=2221104 y a todos los anteriores. Este segundo segmento tiene datos, pero se trata solamente de un octeto. Sin duda debe ser el carácter “?” que llega devuelto al cliente desde el servidor debido a que éste último está haciendo “eco” de todos los caracteres que le envía el cliente. A continuación se muestran dos pantallas con el contenido de los dos primeros segmentos mostrados en la pantalla anterior, los cuales se encuentran en el interior de las tramas con ID=21 e ID=22:

¿Por qué ha enviado el cliente el carácter “?” al servidor, como puede verse en la trama con ID=21? Porque nosotros lo hemos tecleado. La misión del cliente es enviar al servidor TELNET todos los caracteres tecleados en la máquina en la que está el cliente, de manera que sean interpretados por el proceso de aplicación que está por encima del servidor TELNET. ¿Por qué el segmento enviado por el cliente con el “?” tiene activado el flag PSH? Para indicar que el cliente TELNET al decirle a la entidad TCP que enviase el carácter “?” solicitó la realización de un “PUSH” para provocar que ese dato se enviase inmediatamente, sin esperar a que se llenase con más datos el segmento en el que iba a ser transportado dicho carácter. ¿Por qué he enviado el servidor el carácter “?” al cliente, como puede verse en la trama con ID=22? Porque el servidor y el cliente han quedado previamente de acuerdo en que el servidor haga “eco” de todos los caracteres que le envíe el cliente. El cliente no pinta en pantalla los caracteres tecleados, sino que muestra sólo los caracteres que llegan desde el servidor. Esto provoca que a veces exista un retraso apreciable entre el instante en que se teclea un carácter y el instante en que lo vemos aparecer en pantalla. Con esta técnica el usuario está siempre seguro de que los caracteres que está tecleando le están llegando el servidor TELNET. Además esto permite el servidor pueda no mostrar

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


los caracteres que se teclean cuando lo considere oportuno, simplemente omitiendo el eco de dichos caracteres. Un ejemplo de esto puede ser el instante en el que estamos introduciendo una clave de acceso que no deseamos que puedan ver los que están cerca de nosotros. A continuación se muestran los segmentos TCP contenidos en las tramas con ID=23 e ID=25?

¿Qué contienen los dos segmentos mostrados en las dos pantallas anteriores? Contienen el resultado que el proceso de aplicación que actúa como usuario del servidor TELNET quiere que se muestre en la ventana del usuario del cliente TELNET como resultado de haber pulsado el carácter “?”. Dicho carácter es un comando de petición de ayuda, por lo que la respuesta obtenida es un listado de los comandos que podemos utilizar junto con una breve descripción. Nótese que, como el equipo al que le hemos hecho TELNET es un router, los comandos disponible son comandos los comandos típicos que tiene un router: “enable”, “show”, “ping”, etc. ¿Por qué el servidor TELNET ha enviado los resultados del comando “?” en dos segmentos TCP distintos en lugar de enviarlo en uno sólo? Los resultados ocupan 684 octetos y han sido enviados en un primer segmento con 536 octetos de datos y otro de 148 octetos. El hecho de no usar un segmento mayor seguramente es debido a que el servidor TELNET no quiere crear datagramas muy grandes, bien por que no quepan sin fragmentar en la propia red a la que está él directamente conectado, bien porque piense que es probable que vayan a tener que fragmentarse en su camino hacia el cliente. Nótese también que el primer

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


segmento de 536 octetos de datos irá encapsulado en un datagrama de 576 octetos de longitud total, pues las cabeceras sin opciones de IP y TCP ocupan 20 octetos cada una. Precisamente son 576 octetos la longitud total del mayor datagrama que está obligado a aceptar cualquier equipo conectado a Internet. No obstante hay que recordar que el equipo 200.200.200.5 le había dado permiso al 12.0.1.28 para que le enviase segmentos que contuviesen hasta 1460 octetos de datos, cosa que no está haciendo por ahora. A continuación se muestra parte del contenido de dos segmentos TCP que se han intercambiado el cliente y el servidor TELNET:

¿Qué tipo de datos contienen los dos segmentos TCP mostrados en las pantallas anteriores? Son datos del protocolo TELNET. Sin embargo no se trata de caracteres tecleados por el usuario del terminal ni es información que el servidor TELNET desee mostrar en la pantalla del cliente. Se trata de comandos TELNET, los cuales permiten que el cliente y el servidor se envíen información especial al margen de los datos normales. ¿Cuál es la estructura de un comando TELNET? Los comandos TELNET empiezan por el octeto IAC (“Interpret As Command”) que tiene el valor 255, lo cual permite distinguirlos de los datos normales. A continuación viene un octeto que nos dice de que tipo es el comando. Dependiendo del tipo de comando, su longitud podrá ser mayor o menor. ¿Qué clase de comando TELNET ha enviado el servidor en el segmento mostrado en la primera de las dos pantallas anteriores? Se trata de un comando “WILL”, con código 253, que indica el deseo de implementar una determinada opción que no forma parte del funcionamiento por defecto del protocolo TELNET. La opción que el servidor quiere empezar a ejecutar en este caso es el “ECHO”, con código 1. Es decir, lo que el servidor está haciendo es decirle al cliente que desea empezar a hacer eco de todos los caracteres de datos que le vayan llegando. No obstante, hasta que el cliente no de su conformidad, el servidor no empezará a implementar dicha opción. ¿Qué clase de comando TELNET ha enviado el cliente el segmento mostrado en la pantalla mostrada anteriormente? Es un comando TELNET, concretamente el comando “DO”, de código 253, asociado a la opción “ECHO”, de código 1. Cuando un comando “DO”, referido a una cierta opción, es enviado como respuesta a un comando “WILL” referido a esa misma opción, se entiende que se está dando permiso al que envió el “WILL” para que empiece a implementar dicha opción. Quiere esto decir que a partir de ahora el servidor TELNET empezará a hacer eco de todos los caracteres de datos que le lleguen desde el cliente. ¿Es posible que el servidor o el cliente TELNET empiecen a ejecutar una determinada opción sin contar con la otra parte?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


No. Siempre que se desee implementar una opción hay que avisarlo a la otra parte y esperar a que nos de permiso. También puede ocurrir que no nos de permiso. ¿Es posible que el servidor o el cliente TELNET le solicite a la otra parte que empiece a desarrollar una opción determinada? Efectivamente, si deseamos que la otra parte ejecute una cierta opción, podemos pedírselo con el comando “DO”, y ella podrá aceptarlo con el comando “WILL”. Sin embargo puede que no quiera hacerlo y nos lo diga con el comando “WON´T”. La idea es siempre la misma: Existe una serie de comandos que permiten al cliente y al servidor TELNET negociar el conjunto de opciones que desean añadir al funcionamiento por defecto del protocolo TELNET. A continuación se muestra el resultado que hemos obtenido en pantalla después de teclear el comando “ping www.dte.us.es”:

¿Qué equipo ha generado los mensajes ICMP de petición de eco asociados a este comando PING? El equipo 12.0.1.28 es el que envía los mensajes ICMP. Nosotros, desde el equipo 200.200.200.5 lo único que estamos haciendo es darle al equipo 12.0.1.28 la orden de que haga el PING. Como consecuencia de haber tecleado el comando “ping www.dte.us.es” y de la presentación en pantalla de los resultados de dicho comando, en la red del PC se han capturado una gran cantidad de tramas. Concretamente, todas las tramas capturadas en la red del PC cuyo ID está comprendido entre 27 y 90, ambas inclusive, contienen segmentos TCP relacionados con lo que se ha hecho. La primera de dichas tramas se muestra a continuación:

¿Qué datos TELNET contiene la trama con ID=27?

http://www.dte.us.es

http://www.dte.us.es

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Son datos que envía el equipo 200.200.200.5 al 12.0.1.28, concretamente se trata de la letra “p”, que es la primera letra del comando “ping” que se ha tecleado. A continuación se muestra la segunda de las tramas capturadas en la red del PC relacionadas con el comando PING que se ha tecleado:

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


¿Qué datos TELNET pueden verse en la trama con ID=28? El servidor TELNET ha enviado el eco “eco” del carácter “p” que le envió el cliente en el segmento anterior. Obsérvese que la trama ha Ethernet ha sido rellenada con 5 octetos de relleno para poder alcanzar su longitud total mínima, que son 64 octetos. Tener que enviar un segmento casi vacío para enviar sólo una letra supone un gran desperdicio, pero a veces no hay más remedio que hacerlo. El último segmento que envía el 12.0.1.28 al 200.200.200.5 en relación al comando PING es el que se muestra a continuación:

¿Qué datos TELNET envía el servidor al cliente en el segmento de la trama con ID=89? Envía la última línea de resultados del comando PING, en la que aparecen las estadísticas de tiempos. También envía una línea adicional con el “prompt”, que es “route-server>”. El último segmento que envía el cliente TELNET en relación al comando PING puede verse en la pantalla siguiente:

¿Qué contiene el segmento TCP que se encuentra en la trama con ID=90? No contiene datos, pues en la columna ”Summary2 aparece “LEN=0” y también puede verse que el analizador nos dice “[20 bytes of data]” para indicarnos que el datagrama IP sólo contiene los 20 octetos que corresponden a la cabecera TCP de tamaño mínimo. Se trata, por tanto de un segmento TCP cuya única misión es indicarle al 12.0.1.28 que al equipo 200.200.200.5 le han llegado todos los

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


octetos anteriores al 3077944277, pues el campo “Acknowledgement Number” tiene ese valor. Es importante darse cuenta de que el último segmento que ha recibido el 200.200.200.5 tenía 90 octetos de datos y sus números de secuencia iban desde el 3077944187 al 307794276, ambos inclusive, lo cuál nos confirma que efectivamente el segmento enviado por el cliente tenía como único objetivo reconocer estos datos y, de paso, todos los anteriores. El último comando que vamos a teclear en la ventana de terminal que nos muestra el programa “telnet” va a ser el comando “exit”, que va a obligar al servidor TELNET a iniciar el cierre de la conexión TCP que tenía establecida con el cliente. En la siguiente pantalla puede verse el resultado que se le muestra al usuario del terminal:

Las tramas capturadas en la red del PC como consecuencia del comando “exit” son éstas:

¿Qué contiene el segmento de la trama con ID=91? La letra “e”, que es la primera del comando “exit” que se ha tecleado. ¿Qué pretende el servidor con el envío del segmento contenido en la trama con ID=102?

Entra

en

http

://ww

w.dt

e.us

.es/t

ec_in

f/itig/

com

u_do

s/

para

des

carg

ar lo

s fich

eros

de ca

ptur

a *.C

AP


Es un segmento que tiene el flag FIN activado, así que lo que quiere decir el servidor TELNET es que desea finalizar la conexión y que a partir de ahora no va a enviar ningún octeto más al cliente. Al pulsar el botón “Aceptar” de la ventana en la que el programa “telnet” nos decía que “Se perdió la conexíón con el host”, se han generado dos tramas más, con ID=104 e ID=105 respectivamente. A continuación se muestran esas dos tramas junto con las de ID=102 e ID=103:

¿Qué ha hecho el 200.200.200.5 cuando hemos pulsado el botón “Aceptar”? También le ha enviado un segmento con el flag FIN al 12.0.1.28 para indicarle que desea finalizar la conexión y que no desea enviar más datos. ¿Es posible que una entidad TCP le siga enviando datos a su interlocutor después de haber recibido el flag FIN? Efectivamente, mientras nosotros no enviemos el flag FIN podemos seguir enviando datos aunque el otro extremo nos haya enviado el flag FIN. Es el que envía el flag FIN el que no puede enviar más datos. Cuando los dos extremos envían el flag FIN y ambos han recibido los respectivos reconocimientos es cuando la conexión TCP se da por cerrada definitivamente. ¿Qué pretende el 200.200.200.5 al enviar el segmento contenido en la trama con ID=103? Este segmento no tiene datos (LEN=0) por lo que su única función es reconocer la llegada de todos los octetos con números de secuencia anteriores al 3077944284. Efectivamente el último número de secuencia recibido por el 200.200.200.5 era el 3077944283, pero dicho número de secuencia iba asociado al flag FIN. Es decir, el flag FIN es tratado como si fuera un octeto, pues se le asigna un número de secuencia y por tanto debe ser reconocido como tal, aunque no ocupe espacio en la zona de datos del segmento TCP. ¿Qué pretende el 12.0.1.28 al enviar el segmento contenido en la trama con ID=105? Este segmento no tiene datos (LEN=0) por lo que su única función es reconocer la llegada de todos los octetos con números de secuencia anteriores al 2221132. Se está reconociendo, por tanto, la llegada del flag FIN, cuyo número de secuencia es el 2221131. Nótese que el flag FIN consume el número de secuencia siguiente al último número de secuencia que se haya asignado al último octeto de datos que se haya transmitido. En este instante el equipo 200.200.200.5 da por cerrada la conexión.

ejercicios 1 al 20 - cuaderno de bitacora de eidansoft | … · · 2010-11-26-i ttl tiempo de...

Documents