Ejercicios 1 al 20

htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
-a
-n
-l
-f
-i
-v
-r
-s
-j
-k
-w
Solicita eco al host hasta ser interrumpido.
Para ver estadísticas y continuar: presione Ctrl-Inter.
Para interrumpir: presione Ctrl-C.
Resuelve direcciones a nombres de host.
cantidad
Cantidad de solicitudes de eco a enviar.
tamaño
Tamaño del búfer de envíos.
No fragmentar el paquete.
TTL
Tiempo de vida.
TOS
Tipo de servicio.
cantidad
Registrar la ruta para esta cantidad de saltos.
cantidad
Registrar horarios para esta cantidad de saltos.
lista de hosts Ruta origen variable en la lista de host.
lista de hosts Ruta origen estricta en la lista de host.
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.
Página 1 del ejercicio1.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 2 del ejercicio1.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 3 del ejercicio1.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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).
Página 4 del ejercicio1.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 5 del ejercicio1.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 6 del ejercicio1.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
172.26.0.3
00-04-75-8a-77-29
Tipo
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
172.26.0.1
00-20-ea-18-d1-51
172.26.0.3
00-04-75-8a-77-29
Tipo
dinámico
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.
Página 1 del ejercicio2.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 2 del ejercicio2.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 3 del ejercicio2.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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
-g
dir_inet
-N dir_if
-d
-s
dir_eth
dir_if
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.
Lo mismo que -a.
Especifica una dirección internet.
Muestra las entradas de ARP para las interfaces de red
especificadas por dir_if.
Elimina el host especificado por dir_inet.
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.
Especifica una dirección física.
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
> arp -a
00-aa-00-62-c6-09
.... Añade una entrada estática.
.... 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
172.26.0.1
00-20-ea-18-d1-51
Tipo
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.
Página 4 del ejercicio2.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
172.26.0.1
00-20-ea-18-d1-51
Tipo
estático
C:\WINDOWS>ping 172.26.0.1
Haciendo ping a 172.26.0.1 con 32 bytes de datos:
Respuesta
Respuesta
Respuesta
Respuesta
desde
desde
desde
desde
172.26.0.1:
172.26.0.1:
172.26.0.1:
172.26.0.1:
bytes=32
bytes=32
bytes=32
bytes=32
tiempo=2ms TDV=64
tiempo<10ms TDV=64
tiempo<10ms TDV=64
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
172.26.0.1
00-20-ea-18-d1-51
Tipo
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.
Página 1 del ejercicio3.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 2 del ejercicio3.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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 . . . . . . . . . .
Dirección física . . . . . . . .
DHCP activado . . . . . . . . .
Dirección IP . . . . . . . . . .
Máscara de subred . . . . . . .
Puerta de enlace predeterminada
Servidor WINS primario . . . .
Servidor WINS secundario . . . .
Permiso obtenido . . . . . . . .
Permiso caduca . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
NDIS 4.0 driver
00-E0-7D-7A-5A-94
No
150.214.141.181
255.255.255.0
150.214.141.1
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.
Página 1 del ejercicio4.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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”.
Página 2 del ejercicio4.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 3 del ejercicio4.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 4 del ejercicio4.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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 . . . . . . . . . .
Dirección física . . . . . . . .
DHCP activado . . . . . . . . .
Dirección IP . . . . . . . . . .
Máscara de subred . . . . . . .
Puerta de enlace predeterminada
Servidor DHCP . . . . . . . . .
Servidor WINS primario . . . .
Servidor WINS secundario . . . .
Permiso obtenido . . . . . . . .
Permiso caduca . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
:
Realtek 8139-series PCI NIC
00-C0-26-26-0D-14
Sí
172.26.0.2
255.255.0.0
172.26.0.1
172.26.0.1
15 04 02 22:16:38
C:\WINDOWS>arp -a
Interfaz: 172.26.0.2 on Interface 0x1000002
Dirección IP
Dirección física
172.26.0.1
00-20-ea-18-d1-51
Tipo
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
172.26.0.1
00-20-ea-18-d1-51
Tipo
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.
Página 1 del ejercicio5.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 2 del ejercicio5.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 3 del ejercicio5.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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:
Página 1 del ejercicio6.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
192.5.5.1
00-10-7b-81-ae-26
192.5.5.18
00-04-76-99-09-dd
Tipo
dinámico
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
192.5.5.1
00-10-7b-81-ae-26
Tipo
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”.
Página 2 del ejercicio6.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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”:
Página 3 del ejercicio6.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 4 del ejercicio6.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 5 del ejercicio6.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
Ejercicio 7:
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:
Página 1 del ejercicio7.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
-a
-n
-l
-f
-i
-v
-r
-s
-j
-k
-w
cantidad
tamaño
TTL
TOS
cantidad
cantidad
lista de hosts
lista de hosts
tiempo
Solicita eco al host hasta ser interrumpido.
Para ver estadísticas y continuar: presione Ctrl-Inter.
Para interrumpir: presione Ctrl-C.
Resuelve direcciones a nombres de host.
Cantidad de solicitudes de eco a enviar.
Tamaño del búfer de envíos.
No fragmentar el paquete.
Tiempo de vida.
Tipo de servicio.
Registrar la ruta para esta cantidad de saltos.
Registrar horarios para esta cantidad de saltos.
Ruta origen variable en la lista de host.
Ruta origen estricta en la lista de host.
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
192.5.5.1
00-10-7b-81-ae-26
Tipo
dinámico
C:\WINDOWS>
Página 2 del ejercicio7.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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
Página 3 del ejercicio7.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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”:
Página 4 del ejercicio7.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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:
Página 5 del ejercicio7.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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
Página 6 del ejercicio7.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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”:
Página 7 del ejercicio7.doc
Página 8 del ejercicio7.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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-ToLive 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.
Página 9 del ejercicio7.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 10 del ejercicio7.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 11 del ejercicio7.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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”.
Página 12 del ejercicio7.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
Ejercicio 8:
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:
Página 1 del ejercicio8.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
192.5.5.1
00-10-7b-81-ae-26
Tipo
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”:
Página 2 del ejercicio8.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 3 del ejercicio8.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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
Página 4 del ejercicio8.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 5 del ejercicio8.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 6 del ejercicio8.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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?
Página 7 del ejercicio8.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 8 del ejercicio8.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
Ejercicio 9:
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_DE_13” se ha abierto una sesión MS-DOS y se han ejecutado los comandos que aparecen
listados a continuación:
Página 1 del ejercicio9.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 2 del ejercicio9.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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:
Página 3 del ejercicio9.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿Proviene del “PC_C_10” el datagrama IP que se muestra decodificado en la ventana anterior?
Página 4 del ejercicio9.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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?
Página 5 del ejercicio9.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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 “NextHop 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.
Página 6 del ejercicio9.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
Ejercicio 10:
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:
Página 1 del ejercicio10.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
192.5.5.1
00-10-7b-81-ae-26
Tipo
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”?
Página 2 del ejercicio10.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 3 del ejercicio10.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 4 del ejercicio10.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
Ejercicio 11:
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 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
Respuesta
Respuesta
Respuesta
espera agotado.
desde 210.93.105.2: bytes=32 tiempo=63ms TDV=251
desde 210.93.105.2: bytes=32 tiempo=62ms TDV=251
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>
Página 1 del ejercicio11.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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?
Página 2 del ejercicio11.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
Página 3 del ejercicio11.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 4 del ejercicio11.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
Ejercicio 12:
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 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:
Página 1 del ejercicio12.doc
Página 2 del ejercicio12.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
Respuesta
Respuesta
Respuesta
desde
desde
desde
desde
192.5.5.1:
192.5.5.1:
192.5.5.1:
192.5.5.1:
Host
Host
Host
Host
de
de
de
de
destino
destino
destino
destino
inaccesible.
inaccesible.
inaccesible.
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
192.5.5.1
00-10-7b-81-ae-26
Tipo
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.
Página 3 del ejercicio12.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 4 del ejercicio12.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
Ejercicio 13:
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 ha ejecutado el comando que aparece a
continuación:
Página 1 del ejercicio13.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
C:\WINDOWS>ping 200.200.200.200
Haciendo ping a 200.200.200.200 con 32 bytes de datos:
Respuesta
Respuesta
Respuesta
Respuesta
desde
desde
desde
desde
201.100.11.2:
201.100.11.2:
201.100.11.2:
201.100.11.2:
Host
Host
Host
Host
de
de
de
de
destino
destino
destino
destino
inaccesible.
inaccesible.
inaccesible.
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.
Página 2 del ejercicio13.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
Ejercicio 14:
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 ha ejecutado el comando que aparece a
continuación:
Página 1 del ejercicio14.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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”?
Página 2 del ejercicio14.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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:
Página 3 del ejercicio14.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 4 del ejercicio14.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
Ejercicio 15:
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.
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.
Página 1 del ejercicio15.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
0.0.0.0
127.0.0.0
210.93.105.0
210.93.105.13
210.93.105.255
224.0.0.0
255.255.255.255
Máscara de red Puerta de enlace
0.0.0.0
210.93.105.1
255.0.0.0
127.0.0.1
255.255.255.0
210.93.105.13
255.255.255.255
127.0.0.1
255.255.255.255
210.93.105.13
224.0.0.0
210.93.105.13
255.255.255.255
210.93.105.13
Interfaz Métrica
210.93.105.13
1
127.0.0.1
1
210.93.105.13
1
127.0.0.1
1
210.93.105.13
1
210.93.105.13
1
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
0.0.0.0
0.0.0.0
210.93.105.1
127.0.0.0
255.0.0.0
127.0.0.1
192.5.5.55 255.255.255.255
210.93.105.2
210.93.105.0
255.255.255.0
210.93.105.13
210.93.105.13 255.255.255.255
127.0.0.1
210.93.105.255 255.255.255.255
210.93.105.13
224.0.0.0
224.0.0.0
210.93.105.13
255.255.255.255 255.255.255.255
210.93.105.13
Interfaz Métrica
210.93.105.13
1
127.0.0.1
1
210.93.105.13
1
210.93.105.13
1
127.0.0.1
1
210.93.105.13
1
210.93.105.13
1
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”.
Página 2 del ejercicio15.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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
Página 3 del ejercicio15.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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?
Página 4 del ejercicio15.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
Página 5 del ejercicio15.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
Página 6 del ejercicio15.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 7 del ejercicio15.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
Ejercicio 16:
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.
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.
Página 1 del ejercicio16.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
-a
-n
-l
-f
-i
-v
-r
-s
-j
-k
-w
Solicita eco al host hasta ser interrumpido.
Para ver estadísticas y continuar: presione Ctrl-Inter.
Para interrumpir: presione Ctrl-C.
Resuelve direcciones a nombres de host.
cantidad
Cantidad de solicitudes de eco a enviar.
tamaño
Tamaño del búfer de envíos.
No fragmentar el paquete.
TTL
Tiempo de vida.
TOS
Tipo de servicio.
cantidad
Registrar la ruta para esta cantidad de saltos.
cantidad
Registrar horarios para esta cantidad de saltos.
lista de hosts Ruta origen variable en la lista de host.
lista de hosts Ruta origen estricta en la lista de host.
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.
Página 2 del ejercicio16.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 3 del ejercicio16.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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?
Página 4 del ejercicio16.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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?
Página 5 del ejercicio16.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 6 del ejercicio16.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
Ejercicio 17:
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.
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.
Página 1 del ejercicio17.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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”?
Página 2 del ejercicio17.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 3 del ejercicio17.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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).
Página 4 del ejercicio17.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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?
Página 5 del ejercicio17.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
C
R
R
R
R
R
R
R
210.93.105.0/24 is directly connected, Ethernet0
202.2.2.0/24 is directly connected, Serial0
205.7.5.0/24 [120/1] via 202.2.2.2, 00:00:04, Serial0
219.17.100.0/24 [120/2] via 202.2.2.2, 00:00:04, Serial0
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
204.204.7.0/24 [120/1] via 210.93.105.1, 00:00:16, Ethernet0
192.5.5.0/24 [120/1] via 202.2.2.2, 00:00:04, Serial0
223.8.151.0/24 [120/2] via 210.93.105.1, 00:00:17, Ethernet0
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”.
Página 6 del ejercicio17.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 7 del ejercicio17.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 8 del ejercicio17.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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 . . . . . . . . . .
Dirección física . . . . . . . .
DHCP activado . . . . . . . . .
Dirección IP . . . . . . . . . .
Máscara de subred . . . . . . .
Puerta de enlace predeterminada
Servidor DHCP . . . . . . . . .
Servidor WINS primario . . . .
Servidor WINS secundario . . . .
Permiso obtenido . . . . . . . .
Permiso caduca . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
:
Realtek 8139-series PCI NIC
00-C0-26-26-0D-14
Sí
200.200.200.5
255.255.255.0
200.200.200.1
200.200.200.1
04 05 02 0:12:10
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?
Página 1 del ejercicio18.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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?
Página 2 del ejercicio18.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 3 del ejercicio18.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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.
Página 4 del ejercicio18.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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 . . . . . . . . . .
Dirección física . . . . . . . .
DHCP activado . . . . . . . . .
Dirección IP . . . . . . . . . .
Máscara de subred . . . . . . .
Puerta de enlace predeterminada
Servidor DHCP . . . . . . . . .
Servidor WINS primario . . . .
Servidor WINS secundario . . . .
Permiso obtenido . . . . . . . .
Permiso caduca . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
:
Realtek 8139-series PCI NIC
00-C0-26-26-0D-14
Sí
200.200.200.5
255.255.255.0
200.200.200.1
200.200.200.1
06 05 02 23:59:57
07 05 02 0:59:57
C:\WINDOWS>
Página 1 del ejercicio19.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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?
Página 2 del ejercicio19.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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:
Página 3 del ejercicio19.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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?
Página 4 del ejercicio19.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 5 del ejercicio19.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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”?
Página 6 del ejercicio19.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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?
Página 7 del ejercicio19.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 8 del ejercicio19.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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).
Página 1 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 2 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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”:
Página 3 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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”.
Página 4 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 5 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
Página 6 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
Página 7 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
Página 8 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
Página 9 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 10 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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?
Página 11 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
Página 12 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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
Página 13 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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?
Página 14 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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?
Página 15 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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:
Página 16 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
¿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
Página 17 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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?
Página 18 del ejercicio20.doc
htt
p:/
/w
ww
.
pa dte
ra .us Ent
de .e ra
e
s
s
/
de ca tec n
ca rga _in
ptu r lo f/i
ra s f tig/
*.C ich com
AP ero u_
s
do
s/
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.
Página 19 del ejercicio20.doc