ejerciciosC2LIBRE PDF

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
Configuracin IP de Windows 98
0 Ethernet adaptador :
Direccin IP . . . . . . . . . . . . . : 172.26.0.2
Mscara de subred . . . . . . . . . . : 255.255.0.0
Puerta de enlace predeterminada . . . : 172.26.0.1
C:\WINDOWS>ping
Uso: ping [-t] [-a] [-n cantidad] [-l tamao] [-f] [-i TTL] [-v TOS]
[-r cantidad] [-s cantidad] [[-j lista de host] | [-k lista de host]]
[-w Tiempo de espera agotado] lista de destino
Opciones:
-t
-a
-n
-l
-f
-i
-v
-r
-s
-j
-k
-w
Solicita eco al host hasta ser interrumpido.

Para ver estadsticas y continuar: presione Ctrl-Inter.
Para interrumpir: presione Ctrl-C.
Resuelve direcciones a nombres de host.
cantidad
Cantidad de solicitudes de eco a enviar.
tamao
Tamao del bfer de envos.
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
Estadsticas de ping para 172.26.0.3:

Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss),
Tiempos aproximados de recorrido redondo en milisegundos:
Mnimo = 1ms, mximo = 1ms, promedio = 1ms
C:\WINDOWS>
Qu tipo de tarjeta de red tenemos instalada?

Ethernet
Cul es la IP de nuestro PC?
Nuestra direccin 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 mscara de subred es 255.255.0.0, que es lo normal en las redes de tipo B.
Cul es el rango de direcciones IP vlidas (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 direccin IP con el campo de host completamente a cero es una direccin 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 direccin IP con todos los bits a 1 en el campo de host es la direccin de broadcast dirigido. Si
enviamos un datagrama a esa direccin queremos expresar que ese datagrama est dirigido a todas
las direcciones que forman parte de dicha red.
Cul es nuestro router por defecto?
El 172.26.0.1
Es obligatorio que el router tenga asignada la direccin IP vlida ms 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. Adems del router por defecto que ya conocemos, podran existir otros routers en nuestra red.
Pgina 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 parmetros?
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 pequeo programa (una utilidad) que se encuentra disponible en todos los
equipos en los que se tenga implementado el protocolo TCP/IP. Bsicamente, el objeto del programa
PING es comprobar si desde su estacin es posible el intercambio (envo y recepcin) de datagramas
IP con otra estacin que el usuario determine.
Cmo comprueba el comando PING si es posible el intercambio de datagramas con otra estacin?
El programa PING enva, a la estacin destino que el usuario determine, un mensaje especial del
protocolo ICMP, llamado mensaje de peticin de eco. Cuando la estacin destino reciba y procese
ese mensaje de peticin de eco generar otro mensaje del protocolo ICMP, concretamente el
mensaje de respuesta de eco, cuyo destinatario ser la estacin desde la que se envi el mensaje
de peticin de eco.
Qu significa el acrnimo 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 tambin datos de otros
muchos protocolos, siendo TCP y UDP unos de los ms habituales.
En qu se van a encapsular los datagramas IP que enviemos desde nuestro PC?
En una trama, la cual ser enviada al medio fsico 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 especificacin IEEE 802.3 se hizo de
tal forma que incluyese a la especificacin Ethernet.
Son idnticos los 64 bits que preceden a la direccin 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 prembulo a esos 64 bits, mientras que IEEE 802.3 los
estructura en 7 octetos de prembulo 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.
Cul es la longitud mxima de los datos de nivel superior que pueden llegar a contener las tramas
Ethernet e IEEE 802.3?
1500 octetos en ambos casos.
Dnde est entonces la diferencia entre ambos tipos de tramas?
En ambos tipos de tramas, en la misma posicin, justo detrs de la direccin 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.
Cmo sabe una estacin 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 podramos decir que lo que se ha recibido es una trama IEEE 802.3 con un campo
Tipo/Longitud que hace el papel de Longitud.
Cmo sabe una estacin 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 podramos 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.
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/
Cul es exactamente la comprobacin 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 estn prohibidos los valores Ethertype
entre 1501 y 1536 (inclusive). Esto se hizo para tener que comprobar slo el valor del octeto ms
significativo del campo Ethertype y no los dos octetos.
A continuacin se muestra una ventana del analizador de protocolos Optiview Protocol Expert Demo
en la que aparece el trfico 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 direccin IP que hemos usado en el comando PING.
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 peticin de eco y
comprobar si ste nos devuelve los correspondientes mensajes ICMP de respuesta de eco, lo cual
confirmara que es posible el intercambio de paquetes IP con el equipo X a travs 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.
Cuntos mensajes ICMP le hemos enviado al otro host con el comando PING?
Hemos usado el comando PING con la opcin n con el parmetro 1 (uno) para generar slo un
mensaje ICMP de peticin de eco.
Ha respondido el host destino al mensaje ICMP que le hemos enviado?
S, pues la salida del comando PING indica Recibidos=1
Cul 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 indicacin acerca del tamao del mensaje ICMP que debe
enviar?
S, pues la opcin l con el parmetro 15 fuerza a que los datos opcionales del mensaje ICMP
generado tengan una longitud de 15 octetos exactamente. La salida del comando PING tambin nos
confirma este hecho con la lnea Haciendo ping a 172.26.0.3 con 15 bytes de datos:
Cuntas tramas se han capturado?
En la parte superior de la vista de captura aparece un listado de tramas en el que slo se ven dos
tramas. Adems, el ttulo de la ventana tambin nos informa de este hecho: (2 frames total)
Cul 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. Ntese
que el analizador le asigna un ID a cada trama conforme las va capturando.
Cul es nuestra direccin MAC?
00C026260D14, que es la MAC Source de la primera trama.
Cul 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 detrs de las direcciones MAC destino y origen como un
campo Ethertype. Es cierto que tambin podra habernos mostrado dicho campo como si fuese el
campo Tipo/Longitud de las tramas IEEE 802.3, pero haciendo mencin 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 tericamente 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. Slo es as cuando el host destino pertenece a nuestra misma red (dominio de broadcast) y es
posible enviarle una trama directamente. En los dems casos la trama debe ir dirigida a un router.
Qu tiempo de vida tiene el datagrama que hemos enviado?
32, segn 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 habra generado un datagrama con un
tiempo de vida de valor 5.
Habra llegado a su destino el datagrama que hemos enviado si le hubisemos puesto un tiempo de
vida de valor 1?
S, porque el datagrama va ser enviado directamente a su destino sin pasar por ningn router. Un
router decrementa en 1 el tiempo de vida de los paquetes que recibe y nunca enva un paquete con
tiempo de vida 0.
Cul 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 ningn 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 peticin de eco (Echo Request).
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 direccin MAC destino?
No. Al ser una parte comn a todas las tramas y que tiene una longitud fija (64 bits) y un valor
tambin fijo, el analizador no la muestra en ningn sitio. De hecho, esos 64 bits no se contabilizan a la
hora de medir el tamao de las tramas (Size). Hay que tener en cuenta que la misin 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 situacin de
error, as que es por eso que no se suelen contabilizar a la hora de medir las tramas.
Cuntos 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 tamao 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 habamos dicho.
Ntese que, tal y como hemos dicho antes, no se consideran para nada los 64 bits iniciales que
tienen las tramas antes de la direccin MAC destino.
Cul 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
nmero indica que es hexadecimal).
Qu tamao 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.
Cmo sabe el analizador de protocolos que detrs 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.
Cmo sabe el analizador de protocolos que detrs 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).
Cmo sabe el analizador de protocolos que son 15 el nmero de octetos que componen los datos
opcionales que forman parte del mensaje ICMP de peticin de eco que hemos enviado?
Porque sabe que el mensaje ICMP de peticin 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.
Cunto mide el campo FCS de las tramas Ethernet?
4 octetos.
Por qu aparecen 3 octetos en la trama, justo cuando acaba el datagrama, detrs 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 tamao (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 enve 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 nmero de octetos de datos puede contener como mximo una trama Ethernet?
1500 octetos. Al nmero de octetos de datos puede contener como mximo una trama de una
determinada tecnologa de red fsica se le denomina MTU (Maximum Transfer Unit).
Cul es la longitud mxima 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
mximo la trama Ethernet. Nuevamente, no estamos considerando los 64 bits iniciales previos a la
direccin MAC destino.
Cmo 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 cdigo que indica que
el contenido de la trama es un datagrama IP.
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/
Cules 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 posicin 0x2A del panel inferior de la ventana de captura.
Es posible enviar un mensaje ICMP de peticin de eco que no contenga datos opcionales?
S, pues como su propio nombre indica, estos datos son opcionales y pueden omitirse.
Cul debe ser el contenido de los datos opcionales de los mensajes ICMP de peticin de eco, caso
de que existan esto datos?
El contenido que desee poner el que los enva. Segn 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 algn dato que permita conocer la mscara de subred
del host al que va dirigido el datagrama?
No. Examinando el datagrama IP que hemos enviado, slo se sabe que la direccin 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 mscara 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 (Dont 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 algn 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 habra fragmentado el datagrama que hemos enviado si el comando PING hubiese tenido la
opcin l con el parmetro 1472 en lugar de 15?
No. Esa opcin habra 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 tendra 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
mxima que pueden tener los datos contenidos en una trama Ethernet, por lo que no sera necesario
fragmentar el datagrama.
En cuntos fragmentos se habra dividido el datagrama enviado si el comando PING hubiese tenido
la opcin l con el parmetro 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 porcin del datagrama completo original. En
realidad un fragmento de datagrama es tambin un datagrama, con su parte de cabecera y su parte
de datos.
Qu son las tramas Ethernet versin II?
La ltima versin de la norma Ethernet es la II, publicada en 1982. Hoy por hoy el trmino Ethernet se
utiliza para referirse a la versin II, aunque no se haga mencin expresa a la versin. Esto es as
porque no hay lugar a confusin al haber dejado de usarse la versin anterior.
Cmo se suele denominar, de forma genrica, 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 ms que un mensaje de
los que se intercambian las entidades que hablan un determinado protocolo.
Cuntas 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 peticin 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 ms 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 prembulo que preceden al campo de direccin MAC destino.
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:
C:\WINDOWS>ipconfig
Direccin IP . . . . . . . . . . . . . : 172.26.0.2
Mscara de subred . . . . . . . . . . : 255.255.0.0
C:\WINDOWS>arp -a
Interfaz: 172.26.0.2 on Interface 0x1000002

Direccin IP
Direccin fsica
172.26.0.3
00-04-75-8a-77-29
Tipo
dinmico
C:\WINDOWS>ping -n 1 172.26.0.1

mnimo = 1ms, mximo = 1ms, promedio = 1ms
C:\WINDOWS>arp -a

Direccin IP
Direccin fsica
172.26.0.1
00-20-ea-18-d1-51
172.26.0.3
00-04-75-8a-77-29
Tipo
dinmico
dinmico
C:\WINDOWS>
A qu equipo le hemos hecho PING?

Al equipo que tiene la direccin 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 direccin IP 172.26.0.1?
S. Como nuestra direccin IP es 172.26.0.2 y nuestra mscara 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 direccin 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 direccin IP 172.26.0.1
Por qu no est vaca la cach ARP?
La cach ARP contiene la direccin MAC del host 172.26.0.3 porque anteriormente habremos tenido
alguna comunicacin con dicho equipo, lo cul provoc que se crease dicha entrada.
Cmo se vaca 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 ocupara mucho espacio. Adems podra ocurrir que un host cambiase su
tarjeta de red por otra diferente (con otra direccin MAC), pero sin cambiar de direccin IP. Si las
entradas no caducasen, nosotros seguiramos usando la direccin MAC de la antigua tarjeta de red
para comunicarnos con ese host.
Cmo vamos a averiguar la direccin MAC del equipo 172.26.0.1?
Al solicitarle a nuestro equipo que enve 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, pidindole al equipo 172.26.0.1
que responda informando acerca de cul es su direccin MAC.
A continuacin se muestra una ventana de un analizador de protocolos en la que aparece el trfico
que se ha generado en nuestra red cuando hemos ejecutado el comando PING descrito
anteriormente.
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/
Cuntas tramas se han capturado?
Cuatro tramas (frames), tal y como aparece en el listado de tramas y en el ttulo de la ventana.
Dnde estn almacenadas las tramas?
Las tramas mostradas por el analizador estn almacenadas en un fichero de nombre c:\archivo.cap
La segunda de las tramas, que es la que aparece resaltada y tiene un ID (identificador) de 1. Ntese
00C026260D14, que es la MAC Source de la tercera trama (ID 2), que contiene la peticin de eco
Echo request que le hemos hecho al otro equipo.
Cul 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 despus de recibir nuestra peticin ARP.
Por qu el analizador muestra en la parte superior de la ventana de captura la direccin MAC
ENI 18D151 en lugar de mostrar 0020EA18D151?
Porque los tres primeros octetos de la direccin 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 sustitucin slo la hace en el listado de tramas que nos
muestra en la parte superior de la ventana de captura.
Cuntos 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 tamao 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 habamos dicho.
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/
Cul es el tamao 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 continuacin 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 mnimo. 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 continuacin 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 cdigo 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 cdigo asociado a Ethernet.
Cuantos equipos han procesado el paquete ARP que contena nuestra peticin?
Todos los equipos conectados a nuestra red que estuviesen funcionando en ese momento habrn
procesado nuestra peticin, pues iba encapsulada en una trama con direccin MAC destino
BROADCAST. No obstante, al procesar el paquete se habrn dado cuenta de que era una peticin
destinada al equipo 172.26.0.1, por lo que slo el equipo 172.26.0.1 ha respondido a nuestra peticin
con un paquete ARP de respuesta en el que nos comunica su direccin MAC.
Podramos haber encapsulado la peticin ARP en una trama con una MAC destino que no fuese
BROADCAST?
No, pues precisamente el motivo de nuestra peticin es que ignoramos la direccin 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.
Cul 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
ningn 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.
Cuntos mensajes ICMP de peticin de eco hemos generado?
Slo uno pues hemos usado el comando PING con la opcin n y el parmetro 1.
Habramos generado nosotros una peticin ARP si le hubisemos hecho PING al 172.26.0.3?
No, pues la MAC de ese equipo ya estaba en la cach ARP.
Cuntas entradas hay en la cach ARP despus de hacer el PING al 172.26.0.1?
Hay dos entradas. Est la entrada que haba antes de haber hecho PING y la que se ha introducido
nueva al haber averiguado la direccin MAC del equipo con direccin IP 172.26.0.1.
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 peticin ARP para averiguar nuestra direccin MAC?
No. El equipo 172.26.0.1 averigu nuestra direccin MAC cuando le lleg nuestra peticin ARP. En
ese momento decidi almacenar nuestra direccin MAC en su cach ARP, pues era muy probable
que, si le habamos hecho una peticin ARP, muy pronto le iba a hacer falta conocer nuestra
direccin 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 introduccin de una entrada en la cach ARP?
S. A continuacin se muestra cmo introducir una entrada que asocia la direccin IP 172.26.0.1 con
la direccin MAC 0020EA18D151, haciendo uso del comando arp s de MS-DOS.
C:\WINDOWS>arp
Muestra y modifica las tablas de traduccin de direcciones IP a fsicas usadas

por el protocolo de resolucin 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 Fsica slo para el equipo
especificado. Cuando ARP se utiliza en ms de una interfaz de
red, entonces se muestran entradas para cada tabla ARP.
Lo mismo que -a.
Especifica una direccin 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 direccin internet dir_inet
con la direccin fsica dir_eth. La direccin fsica
se especifica con 6 bytes en hexadecimal separados por guiones.
La entrada es permanente.
Especifica una direccin fsica.
Si est presente, especifica la direccin Internet de la
interfaz con la tabla de traduccin 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
.... Aade una entrada esttica.

.... Muestra la tabla ARP.
C:\WINDOWS>arp -s 172.26.0.1 00-20-EA-18-D1-51

C:\WINDOWS>arp a

Direccin IP
Direccin fsica
172.26.0.1
00-20-ea-18-d1-51
Tipo
esttico
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
catalogndolas como entradas de tipo esttico, lo cual quiere decir que no sern eliminadas de la
cach al pasar un cierto tiempo. Las entradas de tipo dinmico son entradas que se han averiguado
mediante el protocolo ARP.
Se hacen peticiones ARP para las direcciones IP de tipo esttico?
No. Antes de hacer una peticin ARP se mira en la cach ARP para ver si ya existe esa entrada.
Caso de existir ya esa entrada no se hace la peticin ARP, sin importar si la entrada era de tipo
esttico o dinmico.
Se guardarn en la cach ARP entradas de tipo dinmico con las direcciones MAC de los hosts
que no pertenecen a nuestra misma red?
No. Esas direcciones MAC no nos serviran de nada, pues una trama emitida en nuestra red nunca
podr llegar a otra red distinta. Por el mismo motivo, adems de no tener sentido, resultara imposible
averiguar mediante peticiones ARP las direcciones MAC de hosts que se encuentren en una red
diferente a la nuestra, pues no les llegaran las tramas conteniendo las peticiones ARP.
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:
C:\WINDOWS>ipconfig
Direccin IP . . . . . . . . . . . . . : 172.26.0.2
Mscara de subred . . . . . . . . . . : 255.255.0.0
C:\WINDOWS>arp -s 172.26.0.1 00-20-EA-18-D1-51

C:\WINDOWS>arp a

Direccin IP
Direccin fsica
172.26.0.1
00-20-ea-18-d1-51
Tipo
esttico
C:\WINDOWS>ping 172.26.0.1

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

C:\WINDOWS>arp a

Direccin IP
Direccin fsica
172.26.0.1
00-20-ea-18-d1-51
Tipo
esttico
C:\WINDOWS>
A qu equipo de nuestra red le hemos hecho PING?

Al que tiene la direccin 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 vaca la cach ARP antes de hacer el PING?
No. Contiene una entrada para la direccin IP 172.26.0.1, la cual ha sido introducida de forma
esttica mediante el comando arp s.
Se habr generado una peticin ARP para averiguar la direccin MAC del equipo 172.26.0.1?
El equipo 172.26.0.1 forma parte de nuestra red, por lo que es accesible directamente envindole una
trama a su propia direccin MAC. Antes de generar una peticin MAC que nos permita averiguar la
direccin 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 peticin ARP.
Nos hemos equivocado al introducir la direccin MAC de la entrada esttica de la cach ARP?
No. La hemos debido introducir correctamente, pues nos han respondido al PING. De haber
introducido una direccin MAC errnea, el equipo 172.26.0.1 no habra recibido el mensaje ICMP.
Cuntos mensajes ICMP le hemos enviado al otro equipo?
Al no haber usado la opcin n del comando PING, ste ha enviado los que tiene configurados por
defecto. A juzgar por la informacin mostrada en pantalla, el comando PING de MS-DOS enva 4
mensajes ICMP de peticin de eco Echo request a menos que se le indique otra cosa.
Ha respondido el equipo a todos los mensajes ICMP de peticin de eco?
S. El comando PING indica que se han enviado 4 mensajes y se han recibido otros 4 mensajes.
que se ha generado en nuestra red cuando hemos ejecutado el comando PING descrito
anteriormente.
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 segunda de las tramas, que es la que aparece resaltada y tiene un ID (identificador) de 1. Ntese
00C026260D14, que es la MAC Source de la primera trama (ID 0), que contiene la peticin de eco
Echo request que le hemos hecho al otro equipo.
Cul 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 peticin ARP
realizada por el equipo con direccin IP 172.26.0.1.
Cmo 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 peticin ARP?
Porque la direccin MAC que necesitbamos ya se encontraba en la cach ARP.
Por qu nos ha enviado el equipo 172.26.0.1 una peticin ARP justo despus de recibir nuestro
paquete conteniendo una peticin 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 direccin IP, la 172.26.0.2, y sabe, gracias a su propia mscara de red, que
nosotros estamos en su misma red. Necesita averiguar nuestra direccin MAC y como no la ha
encontrado en su cach ha generado una peticin ARP para que nosotros le respondamos con una
respuesta ARP en la que le informemos de cul 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 peticin de eco, el equipo 172.26.0.1 ya tiene en
su cach ARP una entrada que le permite averiguar la direccin MAC asociada a la IP 172.26.0.2.
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:
C:\WINDOWS>ipconfig /all
Nombre del host . . . . . . . . . . . : zenith.dte.us.es

Servidores DNS . . . . . . . . . . . . : 150.214.186.69
150.214.130.15
150.214.4.34
Tipo de nodo . . . . . . . . . . . . . : Difusin
Id. de mbito NetBIOS . . . . . . . . :
Enrutamiento IP activado . . . . . . . : No
WINS Proxy activado . . . . . . . . . : No
Resolucin NetBIOS usa DNS . . . . . . : S
Descripcin . . . . . . . . . .
Direccin fsica . . . . . . . .
DHCP activado . . . . . . . . .
Direccin IP . . . . . . . . . .
Mscara 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


C:\WINDOWS>arp -a

Direccin IP
Direccin fsica
Tipo
150.214.141.1
00-00-0c-07-ac-0e
dinmico
C:\WINDOWS>
Cul es nuestra red?

La 150.214.141.0 con mscara 255.255.255.0
Cul 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 ningn equipo.
De que clase es nuestra red?
Nuestra red es una subred de la red de tipo B 150.214.0.0, pues la mscara 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,
pidindole 8 bits prestados al campo de host.
Cul 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 mscara 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
opcin i acompaada del parmetro 20.
que se ha generado en nuestra red debido al comando PING que acabamos de ejecutar.
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/
Cuntos mensajes ICMP hemos enviado?
Con la opcin n y el parmetro 2 le solicitamos al comando PING que enviase dos mensajes ICMP
de peticin de eco.
Por qu hemos hecho una peticin 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 direccin destino la direccin MAC del router. Como en
la cach ARP no existe la entrada que nos hace falta, automticamente se lanza una peticin 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 cul su direccin
MAC.
Segn el comando ipconfig /all nuestra direccin MAC es 00-E0-7D-7A-5A-94. Esto coincide
plenamente con la direccin MAC Source de la primera todas las tramas, que es la peticin 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
Cul es la direccin MAC del router?
La segunda trama es la respuesta ARP a nuestra peticin ARP. Por tanto el que nos la enva 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 tambin 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.
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 quin va dirigida la trama con ID=3?
A nosotros, pues es nuestra direccin MAC, la 00E07D7A5A94, la que aparece en el campo
Destination de dicha trama.
A quin va dirigido el datagrama IP contenido en la trama con ID=3?
A nosotros, pues es nuestra direccin 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 direccin 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 quin corresponde la direccin 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.
Cul es la direccin MAC del host con direccin 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 habra que capturar las tramas generadas en la red del host 207.70.7.168.
Cul es la mscara de red del host con direccin 207.70.7.168?
No lo sabemos. De todas formas, tampoco nos hace falta saber la mscara de red de dicho host para
poder enviarle un datagrama IP. Los routers no necesitan tampoco la mscara de red del host destino
para poder enrutar correctamente un datagrama.
Cul es el tiempo de vida de los datagramas que hemos recibido?
Segn 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).
Cuntos 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 nmero exacto, pero seguro que es un nmero 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, querra decir que el paquete sali del host 207.70.7.168 con un tiempo de vida
de 235 (el que tena al llegar) ms 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.
Cuntos 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 ms 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 nmero 20 debera 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 dems. 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 decodificacin completa de cada trama en el panel
central de la ventana de captura.
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 continuacin se muestra otra vez la ventana de captura del analizador, conteniendo las mismas
seis tramas que antes, pero habindole indicado en el cuadro de dilogo Capture View Display
Options que deba 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 rpidamente las direcciones IP origen y destino de los
datagramas IP contenidos en las tramas. La otra visin nos mostraba siempre las direcciones MAC,
por lo que solo veamos direcciones origen y destino pertenecientes a la misma red en la que se
haban capturado las tramas. Antes, si el trfico era externo a la red siempre una de las direcciones
MAC era la direccin 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 rpidamente quin est intentando
comunicarse con quin a nivel de red.
De qu sirven los campos Identified y Sequence Number en los mensajes ICMP de peticin 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. Ntese que los valores de los campos Identified y Sequence Number de la peticin de
eco de la trama con ID=2 son los mismos que los de la respuesta de eco de la trama con ID=3.
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:
Nombre del host . . . . . . . . . . . : caracola

Servidores DNS . . . . . . . . . . . . : 193.152.63.197
195.235.113.3
Id. de mbito NetBIOS . . . . . . . . :
Resolucin NetBIOS usa DNS . . . . . . : No
Descripcin . . . . . . . . . .
DHCP activado . . . . . . . . .
Direccin IP . . . . . . . . . .
Servidor DHCP . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
:
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

Direccin IP
Direccin fsica
172.26.0.1
00-20-ea-18-d1-51
Tipo
dinmico
C:\WINDOWS>ping -n 1 -i 25 12.0.1.28

C:\WINDOWS>ping -n 1 -i 25 130.94.157.169

C:\WINDOWS>ping -n 1 -i 25 207.70.7.168

C:\WINDOWS>arp -a

Direccin IP
Direccin fsica
172.26.0.1
00-20-ea-18-d1-51
Tipo
dinmico
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 mscara 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.
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 direccin MAC se habrn dirigido todas las tramas que contenan los paquetes con mensajes
ICMP que hemos enviado?
A la direccin MAC del router. Al ser hosts que estn fuera de nuestra red, los paquetes deben
llegarles pasando a travs de un router. Es imposible que una trama que nosotros enviemos salga
fuera de nuestra red.
ha sido necesario generar una peticin ARP para obtener la direccin MAC del router por defecto de
nuestra red, el 172.26.0.1?
No. La cach ARP ya contena esa informacin, pues seguramente habr habido recientemente
alguna comunicacin entre el router y nosotros.
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 cuestin. Por ejemplo, la trama con ID=3 se ha capturado 1,677641 segundos
despus de que se capturase la primera trama.
Qu equipos estn 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 direccin 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 peticin 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 continuacin 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.
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 ms clara ahora la informacin 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 peticin 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. Tambin se observa cmo esos tres host han respondido al host 172.26.0.2 con los
correspondientes mensajes ICMP de respuesta de eco Echo Reply.
Cunto tiempo ha tardado en llegar el mensaje de respuesta del host 207.70.7.168, contado desde
que le enviamos el mensaje ICMP de peticin de eco?
Pues la diferencia entre 3,192862 segundos y 2,974271 segundos, que son 0,218591 segundos.
Ntese que esto concuerda aproximadamente con los 229 milisegundos que ha calculado el
programa PING como tiempo de recorrido redondo (ida y vuelta). Lgicamente ste es un poco
superior porque el programa PING empieza a contar cuando le pasa el mensaje de peticin 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 clculo que nosotros hemos hecho se basa en los tiempos de
salida y llegada de las tramas.
A continuacin se muestra el contenido de la trama con ID=4.
Cmo 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
nmero que hemos obtenido fuese mayor de 16 bits, cogeramos los bits sobrantes y los volveramos
a sumar a los 16 bits menos significativos, lo que en nuestro caso sera 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 tcnica de deteccin de errores.
Qu significa la anotacin que pone el analizador al lado de campo Code del mensaje ICMP de
peticin de eco?
La anotacin 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).
Cmo es el mensaje ICMP de respuesta de eco que devuelve un host al recibir el correspondiente
mensaje de peticin de eco?
Debe ser idntico en todo al mensaje de peticin de eco que acaba de recibir, salvo que el campo
Type debe ser 0 (respuesta de eco) y que, como es lgico, el campo Checksum deber ser
calculado nuevamente.
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 ms correcto sera decir que
estamos frente a una interred o una internetwork.
En esta interred podemos distinguir cinco redes Ethernet, implementadas con un sencillo
concentrador (Hub). Ntese que los enlaces Ethernet entre equipos estn etiquetados con la palabra
Eth. Los enlaces que no estn etiquetados con Eth estn 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 mayora 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 direccin IP y una mscara de subred en la notacin /n, donde n es el nmero
de bits a uno en la mscara de subred. Los hubs son modelos sencillos, no gestionables, y no tienen
direccin IP. Los routers tienen una direccin IP en cada interfaz. Las interfaces Ethernet estn
etiquetadas con e0 o e1. Las interfaces serie estn etiquetadas con s0 o s1. Los PCs
conectados al Hub_DE tienen configurado como router por defecto al Router_D, de forma que
dirigirn a l los paquetes que quieran hacer llegar fuera de su propia red.
En el PC_A0_55 se ha abierto una sesin MS-DOS y se han ejecutado los comandos que aparecen
listados a continuacin:
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
Direccin IP . . . . . . . . . . . . . : 192.5.5.55
Mscara de subred . . . . . . . . . . : 255.255.255.0
C:\WINDOWS>arp a

Direccin IP
Direccin fsica
192.5.5.1
00-10-7b-81-ae-26
192.5.5.18
00-04-76-99-09-dd
Tipo
dinmico
dinmico
C:\WINDOWS>ping -n 1 210.93.105.13

Tiempo de espera agotado.

C:\WINDOWS>arp a

Direccin IP
Direccin fsica
192.5.5.1
00-10-7b-81-ae-26
Tipo
dinmico
C:\WINDOWS>
Concuerda el resultado del comando ipconfig con los datos de la red de la figura?
S. La mscara de subred 255.255.255.0 es equivalente a /24, que es la que aparece en el
diagrama como la mscara de subred de la red a la que est conectado el PC_A0_55. Por otra
parte, la direccin IP, la 192.5.5.55, tambin es la correcta. Adems, 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 lgico 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.
Cuntas 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
midisemos la longitud de la ruta en saltos (hops) diramos 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 direccin IP 192.5.5.18, lo cul hace
pensar que hemos debido de tener algn tipo de comunicacin con dicho PC, lo cual habr hecho
necesario que se tenga que averiguar su direccin MAC y guardarla temporalmente en la cach ARP.
La otra direccin IP que aparece en la cach ARP es la del router por defecto de nuestra red.
Indica la presencia de la direccin 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 provocara la
aparicin de la direccin IP del router en la cach ARP.
Por qu despus 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 trfico con el equipo 192.5.5.18, dicha
entrada ha caducado en el intervalo de tiempo comprendido entre los dos comandos arp a.
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 cul es la mscara 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.
Cmo 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 operacin lgica AND bit a bit
entre la mscara de subred de la red del equipo origen y la IP del equipo destino. Si son distintos es
porque estn es redes distintas. Si son iguales quiere decir que la parte de red de sus direcciones IP
son idnticas, 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 mscara 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 lgico 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 operacin lgica AND bit a bit entre la mscara 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 nmeros diferentes, podemos decir que el equipo con la direccin
IP 192.5.5.55 y el equipo con la direccin IP 210.93.105.13 pertenecen a redes diferentes.
Se ha capturado el trfico 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 continuacin se muestra una ventana
de un analizador de protocolos en la que aparece el trfico visto por PC_A0_55:
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 continuacin puede verse la ventana del analizador correspondiente al trfico capturado en la red
del ordenador PC_DE_13:
A qu direccin MAC ha dirigido el equipo 192.5.5.55 la trama que contena el mensaje ICMP de
peticin de eco que se muestra en la primera ventana?
A la direccin MAC de su router por defecto, que es 00107B81AE26. Sabemos esto porque la
direccin 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 lgico, 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 peticin APR previa al envo del mensaje
ICMP de peticin de eco?
Porque en la cach ARP del PC_A0_55 ya se encontraba la direccin MAC del router, que es la que
se ha usado como destino en la trama enviada por dicho PC.
Cul es la direccin MAC de PC_A0_55?
Es 000102B44EB0, que es la MAC origen de la trama que contiene el mensaje ICMP de peticin de
eco que se ha capturado en la red del PC_A0_55.
A que direccin 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.
Cmo 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.
Cuntos octetos de datos opcionales se han incluido en el mensaje ICMP de peticin de eco?
32 octetos de datos opcionales, segn 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 nmero de octetos a menos que se le diga otra cosa al comando PING con la opcin adecuada.
Cuntos mensajes ICMP de peticin de eco se han generado con el comando PING que hemos
ejecutado en el PC_A0_55?
Tan slo uno, pues as lo hemos querido al usar la opcin -n con el parmetro 1.
Cul es el EtherType de IP?
0x0800 en hexadecimal, tal y como se ve en la trama de la primera ventana de captura.
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 tratara del
primero, pues hay 0 octetos de datos delante suya. Como el bit MF vale 0, sabemos que, caso de
ser un fragmento, sera el ltimo. Pero si un datagrama es el primero de una serie de fragmentos y
tambin 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 fragmentacin 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 trfico capturado en la red del equipo PC_A0_55 no se muestra ningn mensaje ICMP de
respuesta de eco. Adems, 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.
Quin realiza la peticin 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 grfico 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 peticin ARP que se muestra en la
segunda ventana de captura?
Tiene el valor 000000000000, pues precisamente lo que se pretende averiguar con la peticin ARP es
el valor del Target Ethernet Address. En realidad en una peticin ARP no tiene por qu ponerse este
campo a ningn 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 quin va dirigida la peticin 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 peticin ARP, no tena en su
cach ARP una entrada asociada a la direccin IP 210.93.105.13, pues de haber sido as no habra
tenido que hacer la peticin ARP.
Por qu se ha realizado la peticin ARP que se muestra en la segunda ventana de captura?
Es de suponer que el Router_D ha realizado la peticin ARP porque est interesado en averiguar la
direccin MAC del equipo PC_DE_13 para poder, ms tarde, comunicarse con l envindole una
trama que tenga por direccin MAC destino la de dicho PC. Parece lgico 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 direccin MAC del
PC_DE_13, obtenida mediante ARP?
Seguramente el Router_D posee una implementacin del protocolo ARP que descarta los
datagramas IP para los cuales no encuentra en su cach ARP la direccin 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 direccin MAC de dicho equipo no se
encontraba en su cach ARP, decidi que necesitaba hacer una peticin ARP para dicha IP, pero en
lugar de poner en espera el paquete IP mientras se reciba la respuesta ARP, decidi descartar el
paquete. El router confa 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 direccin
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 direccin MAC necesaria para enviarlos no se encuentre en la cach ARP, sino que
los retienen hasta que se obtiene mediante ARP la direccin MAC que se necesita y entonces son
enviados encapsulados en una trama.
Qu habra ocurrido si despus del primer comando PING hubisemos ejecutado otro idntico?
Se generara otro paquete IP, pero seguramente este segundo paquete IP conteniendo otro mensaje
ICMP de peticin de eco habra llegado correctamente a su destino final, el PC_DE_13, pues el
Router_D an tendra en su cach ARP la MAC del PC_DE_13 y por tanto no descartara este
paquete, a diferencia de lo que hizo con el primer paquete.
Cul es el EtherType del protocolo ARP?
Es 0x0806, tal y como se muestra en la segunda ventana de captura.
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:
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
Direccin IP . . . . . . . . . . . . . : 192.5.5.55
Mscara de subred . . . . . . . . . . : 255.255.255.0
C:\WINDOWS>ping
Opciones:
-t
-a
-n
-l
-f
-i
-v
-r
-s
-j
-k
-w
cantidad
tamao
TTL
TOS
cantidad
cantidad
lista de hosts
lista de hosts
tiempo

Tiempo de vida.
Tipo de servicio.
Ruta origen variable en la lista de host.
Ruta origen estricta en la lista de host.
C:\WINDOWS>ping -n 3 -l 22 -i 5 -f -v 64 -w 5000 210.93.105.13

Tiempo de espera agotado.



Respuesta desde 204.204.7.2: El tiempo de vida caduc en trnsito.


C:\WINDOWS>arp a

Direccin IP
Direccin fsica
192.5.5.1
00-10-7b-81-ae-26
Tipo
dinmico
C:\WINDOWS>
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 mscara de subred 255.255.255.0 es equivalente a /24, que es la que aparece en el
diagrama como la mscara de subred de la red a la que est conectado el PC_A0_55. Por otra
parte, la direccin IP, la 192.5.5.55, tambin es la correcta. Adems, 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 lgico 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.
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.
Cuntas 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
midisemos la longitud de la ruta en saltos (hops) diramos que mide 4.
en su red y las tramas vistas por el PC_DE_13 en su red. A continuacin se muestra una ventana
de un analizador de protocolos en la que aparece el trfico visto por PC_A0_55, el cual se ha
almacenado en el archivo fichero55.cap:
del ordenador PC_DE_13, el cual se ha almacenado en el archivo fichero13.cap:
Las dos ventanas anteriores estn mostrando nicamente el listado de tramas capturadas, pues el
panel central y el panel inferior de la ventana de captura han sido reducidos de tamao hasta dejarlos
reducidos a una simple lnea.
Por qu algunas tramas se encuentran resaltadas en el listado de tramas?

En ambas ventanas se observa que adems de la trama que se encuentra seleccionada (la de ID=0),
hay ms 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 sntoma de algn 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 sntoma de un problema o puede ser algo
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 actuacin del mdulo 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 ningn router
ms.
Es posible configurar el analizador para que nos muestre en el listado de tramas informacin acerca
del instante en que se capturaron las tramas, las direcciones de red de los paquetes contenidos en
ellas y que omita la informacin extra relativa a las tramas que presentan sntomas de errores?
S. A continuacin se muestra como, teniendo abierta la ventana de captura, es posible seleccionar
una opcin 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 visualizacin de la ventana de captura. A continuacin se muestra la
ventana Capture View Display Options configurada para conseguir lo que se nos est pidiendo:
Despus de efectuar estos cambios en las opciones de visualizacin, se ilustra a continuacin la

ventana que muestra el contenido del archivo fichero55.cap que no es otro que el trfico de la red
en la que se encuentra el ordenador PC_A0_55:
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 continuacin la ventana que muestra el contenido del archivo
fichero13.cap que no es otro que el trfico de la red en la que se encuentra el ordenador
PC_DE_13:
Se corresponde el primer mensaje ICMP que enva 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 (despus 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. Tambin son idnticas 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 continuacin se muestra decodificada una trama transmitida por PC_A0_55 conteniendo el
segundo mensaje ICMP de peticin de eco que envi dicho ordenador:
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 slo coinciden los tamaos de las tramas y las direcciones IP origen y destino, sino que
coinciden tambin los valores de los campos Identified y Sequence Number de la cabecera ICMP.
Qu ha ocurrido con el primer mensaje ICMP de peticin de eco enviado por PC_A0_55?
Da la impresin de que, por algn motivo, no ha llegado a su destino. Es cierto que puede ocurrir que
dos paquetes que se envan 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 slo
existe una ruta posible entre el origen y el destino, por lo que parece lgico que el primer paquete en
enviarse vaya a llegar despus del segundo en enviarse. Por otro lado, el segundo mensaje ICMP se
ha enviado 5,218044 segundos despus que el primero, lo cual parece tiempo ms que suficiente
para que el primer mensaje supere cualquier problema que haya podido encontrarse en el camino.
Adems, examinando la salida en pantalla ofrecida por el primer comando PING vemos que se
envan 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 tamao y caractersticas 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 peticin 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 direccin MAC del router
por defecto y lo primero que tiene que hacer es averiguarla. Cuando, mediante ARP, haya obtenido
dicha direccin MAC, ya podr enviarle una trama a dicho router conteniendo el primer mensaje ICMP
de peticin de eco. El resto de PINGs no provocan ms peticiones ARP porque una vez que se
obtiene la MAC asociada a una determinada IP, dicha informacin 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 peticin ARP que se ve en la red del PC_DE_13?
La peticin ARP la ha hecho el router de dicha red, el 210.93.105.1, porque tiene necesidad de
comunicarse con el host con direccin 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
direccin MAC, hasta que el router enva una trama al PC_DE_13 transcurren 5,2172832 segundos,
lo cul no es lgico. No parece que sea la trama que enva el router despus de la peticin ARP la
que le motiv a hacer dicha peticin. Adems 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 peticin 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 direccin MAC que necesita para poder enrutar un paquete, procede a descartar dicho
paquete y a realizar una peticin ARP para averiguar dicha direccin MAC y almacenarla en la cach
ARP, de forma que pueda usarla ms 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 despus de que el primer
mensaje fuese descartado, pero en este caso el router es capaz de enrutarlo inmediatamente pues ya
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 direccin MAC que necesita. Este comportamiento no es algo
anmalo, 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 enva el primer
mensaje ICMP hasta que enva el segundo?
El primer comando PING va a enviar 3 mensajes ICMP al host destino, pues hemos usado la opcin
n con el parmetro 3. Como, adems, se le ha especificado la opcin w con el parmetro 5000,
va a esperar 5000 milisegundos a que llegue la respuesta a un mensaje ICMP de peticin de eco. Si
no llega la respuesta en ese tiempo lmite, (como en nuestro caso) proceder a enviar el siguiente
mensaje ICMP que tenga programado.
Por qu hay tramas de cuatro tamaos diferentes (68, 100, 71 y 101 octetos segn muestra la
columnaSize) conteniendo mensajes ICMP de peticin de eco?
Porque los mensajes ICMP de peticin de eco que se han generado tenan datos opcionales de
diferentes longitudes, pues se ha usado la opcin -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 peticin de
eco, 55 de datos opcionales de mensaje ICMP de peticin de eco y 4 de campo Frame Check
Sequence tenemos los 101 octetos que mide la trama que contiene el ltimo mensaje ICMP de
peticin de eco, como siempre sin tener en cuenta el prembulo ni el delimitador de inicio que vienen
al principio de la trama.
Cules son los diez primeros caracteres de los datos opcionales del primer mensaje ICMP de
peticin de eco enviado por PC_A0_55?
El campo Opcional Data del mensaje ICMP de peticin de eco viene a continuacin 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
posicin 0x28 y 0x29 (hexadecimal) dentro de la trama, por lo que el campo que nos interesa, el
Optional Data, ocupa la posicin 0x2A que est justo a continuacin. En la parte derecha del panel
inferior podemos ver en formato ASCII los mismos caracteres que estamos de forma numrica 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
tambin llega a la red del PC destino, segn se observa en las dos ventanas que muestran el trfico
capturado en ambas redes. Adems, 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 sntoma de que nuestro mensaje ha
llegado a su destino y de que el mensaje de respuesta correspondiente tambin 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 caractersticas.
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?
Segn 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 trnsito. Si nos fijamos en la topologa
de la red vemos que el Router_D es el router que no s est respondiendo, pues es l el que tiene la
direccin IP 204.204.7.2 en su interfaz s1 (interfaz serie nmero 1). Si adems nos damos cuenta de
que el mensaje ICMP se ha enviado con un tiempo de vida de valor 4, ya que hemos usado la opcin
-i con el parmetro 4, llegamos a la conclusin 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 debera decrementar en 1 dicho tiempo de vida, lo que hara que alcanzase el valor cero y
por lo tanto no podra llegar a enviarlo. El Router_D avisa de esta circunstancia al emisor del
datagrama mediante un mensaje ICMP especialmente diseado para ello.
A continuacin se muestra la ventana de captura con el contenido del fichero55.cap. En la parte
superior puede verse una pequea 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:
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 ms elevadas.
Cules 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 podan ver tambin
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 continuacin 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 an 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 decodificacin de la trama con ID=10?
La trama en cuestin 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 continuacin 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 cdigo 0 que ha enviado un router al descartar un datagrama por haber
llegado a cero su TTL. Este mensaje ICMP de tipo 11 y cdigo 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 slo que ha habido un problema, sino tambin qu datagrama concreto lo ha causado.
Ese es el motivo de que a continuacin del los primeros campos del mensaje ICMP aparezca una
segunda cabecera IP. Eso nos permite ver que el datagrama descartado contena a su vez un
mensaje ICMP, pues, en la segunda cabecera IP que se muestra en la ventana, el campo Protocol
vale 1.
A quin 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 cdigo 0 no aparece completo el datagrama IP
que se ha descartado?
Los mensajes ICMP que contienen a otros datagramas IP que han generado algn problema no
tienen por qu incluir una copia del datagrama original completo. Slo 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, cul ha sido la causa del
problema. En el caso del mensaje ICMP que nos ocupa, vemos que slo 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 peticin de eco. Lo nico que se ha omitido son los 25 octetos de
datos opcionales, que no son en este caso, importantes para la resolucin del problema. De hecho, el
receptor del mensaje ICMP de tipo 11 podr darse cuenta de que el datagrama descartado contena
un mensaje ICMP de tipo 8 Echo Request, e incluso podr saber cules son los valores de los
campos Identified y Sequence Number, lo cul le puede ser til para investigar mejor las causas
del problema.
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 continuacin se muestra el mensaje ICMP de peticin 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. Adems, 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 opcin 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 peticin de eco. Los tres primeros
bits de ese octeto valen, por tanto, 010, lo que segn 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 slo pueda atravesar 2 routers.
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 continuacin 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 peticin 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 peticin 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.
Habra llegado hasta su destino este datagrama que estamos analizando si algn router intermedio
lo hubiese tenido que fragmentar?
En ese caso no habra 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 opcin 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 Dont Fragment (No Fragmentar).
Habra 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.
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 enva 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 topologa 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 ms 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, tambin forman parte de la cabecera. En nuestro caso la
suma sera 4540 + 0052 + B401 + 4000 + 0101 + C005 + 0537 + D25D + 690D lo cual dara como
resultado 33B3A. Como es mayor de 16 bits, los bits ms significativos se eliminan y se suman otra
vez a los 16 bits menos significativos, lo que en nuestro caso significa sumar 3B3A + 3 obtenindose
3B3D. Esta cifra an 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 tcnica de deteccin de errores.
A continuacin se muestra la trama con ID=9 contenida en el archivo fichero55.cap:
Cmo 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 nmero de octetos fuese impar, como en nuestro caso, se aade 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 nmero que hemos obtenido fuese mayor de 16 bits, cogeramos los bits
sobrantes y los volveramos a sumar a los 16 bits menos significativos, lo que en nuestro caso sera
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 tcnica de deteccin 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 mnimo suficiente para poder
recorrer una ruta que tenga 4 routers, justo los que separan al PC_A0_55 del PC_DE_13.
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:
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
Direccin IP . . . . . . . . . . . . . : 192.5.5.55
Mscara de subred . . . . . . . . . . : 255.255.255.0
C:\WINDOWS>arp a

Direccin IP
Direccin fsica
192.5.5.1
00-10-7b-81-ae-26
Tipo
dinmico
C:\WINDOWS>ping -n 1 -l 172 219.17.100.16

C:\WINDOWS>ping -n 1 -l 173 219.17.100.16

C:\WINDOWS>ping -n 1 -l 345 219.17.100.16

C:\WINDOWS>

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 peticin ARP en la red del PC_A0_55?
Todo el trfico 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 peticin ARP. No sabemos si el router conoce la MAC del PC,
aunque parece lgico 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 peticin ARP para averiguar la direccin MAC del
PC_A0_55.
Cuntas rutas puede seguir un paquete para ir desde PC_A0_55 a PC_B_16 y viceversa?
Slo hay una ruta posible, la que pasa por el Router_A y el Router_B.
Cuntos mensajes ICMP de peticin de eco se han generado?
Tres mensajes, uno por cada comando PING, ya que se ha usado la opcin -n con el parmetro 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.
en su red y las tramas vistas por el PC_B_16 en su red. A continuacin se muestra una ventana de
un analizador de protocolos en la que aparece el trfico visto por PC_A0_55, el cual se ha
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/
del ordenador PC_B_16, el cual se ha almacenado en el archivo fichero16.cap:
Las dos ventanas anteriores estn mostrando en el listado de tramas informacin 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 tambin las direcciones MAC
origen y destino de las tramas. Puede observarse que en ambas redes slo hay intercambio de
tramas entre el router por defecto de la red y un nico PC. No hay seales de que otros PCs hayan
enviado alguna trama.
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 tamao 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 estn
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 peticin de eco. El primer PING inclua en el mensaje
ICMP de peticin de eco unos 172 octetos de datos opcionales, que sumados a los 8 del principio del
mensaje ICMP de peticin de eco, los 20 de la cabecera mnima de IP y los 18 de los diferentes
campos de cabecera y cola de la trama, dan lugar a una trama de un tamao (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. Anlogamente, 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 tamao de 391 octetos.,
as que podemos decir que las todas las tramas emitidas por PC_A0_55 tienen una tamao acorde
al contenido que transportan.
Tienen las tramas que emite el PC_B_16 el tamao 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 estn
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 peticin de eco proveniente del PC_A0_55. Los mensajes
ICMP de respuesta de eco son del mismo tamao que los mensajes ICMP de peticin de eco a los
que estn asociados. Quiere esto decir que los tres mensajes ICMP de respuesta de eco tendrn
172, 173 y 345 octetos respectivamente de datos opcionales, pues eso es lo que tenan los mensajes
de peticin de eco. Por tanto, que el PC_B_16 haya generado tramas con un tamao de 218, 219 y
391 octetos es completamente normal. Ntese que son los mismos tamaos de las tramas emitidas
por el PC_A0_55.
Cuntas tramas le enva el Router_A al PC_A0_55?
Le enva 5 tramas.
Le ha llegado al PC_A0_55 algn fragmento de datagrama?
S. Segn 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 ms fragmentos (More Fragments) detrs 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 razn por la cual el Router_A le ha hecho entrega
de ms de tres tramas al PC_A0_55.
Se ha producido fragmentacin en el primer PING?
No. Ya hemos comentado antes que la primera trama que enva 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 tamao que la que envi, podemos decir que en el viaje desde
PC_B_16 hacia PC_A0_55 no se produce fragmentacin. Simplemente analizando el trfico visto
en la red de PC_A0_55 no podemos saber si el datagrama que se ha enviado se ha fragmentado.
Podra 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. Adems, puesto que nosotros tambin tenemos
acceso al trfico capturado en la red del PC_B_16, podemos confirmar que el mensaje de peticin
de eco que envi PC_A0_55 ha llegado en un datagrama completo y sin fragmentar.
Podemos hacer alguna afirmacin acerca de la MTU de las redes que unen PC_A0_55 y
PC_B_16 despus de analizar el trfico generado por la ejecucin del primer comando PING?
Ya sabamos 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. Ntese que sabemos que el datagrama
IP emitido por el primer comando PING tiene 200 octetos de longitud total porque 200 es la suma de
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 mnima, 8 octetos de cabecera ICMP de peticin de eco y 172 octetos
de datos opcionales del datagrama ICMP de peticin de eco.
Cundo 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
despus de que se ejecutase el primer comando PING.
Cundo 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 despus
de que se ejecutase el primer comando PING.
Se ha producido fragmentacin en el segundo comando PING?
S que se ha producido fragmentacin. Sabemos, por el tamao de la segunda trama enviada por
PC_A0_55, que sta contena un datagrama IP sin fragmentar que transportaba el mensaje ICMP
de peticin 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
tamao, 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 conclusin realizando, con
ayuda del analizador de protocolos, una inspeccin ms 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
anlisis del trfico generado por el primer y el segundo PING?
Ya habamos 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 fragmentacin con el segundo comando PING, en el cual lo que se
enva 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 conclusin, 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 errneo. En realidad no hay
tal error, pues lo que debera hacer el analizador es calcular el Checksum del mensaje ICMP
completo, para lo cual debera buscar todos los trozos del mensaje ICMP, que estn repartidos en
ms 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 idntica 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 enva dicho PC como respuesta al mensaje ICMP de peticin de eco generado
por el segundo comando PING. Ntese 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 peticin 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 contena el mensaje ICMP de peticin de eco.
Ntese tambin que los tiempos de llegada de estas tres tramas son muy similares, en torno a los 23
segundos, y que los tamaos de las dos primeras son inferiores al tamao 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. Adems, nos indica que el datagrama IP no es un datagrama completo,
sino que se trata de un fragmento.
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 continuacin 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. Ntese 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).
Dnde estn los dems 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 continuacin del otro, sin ms fragmentos intermedios. Ntese 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).
Cmo 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 travs 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 necesitaramos conocer de que tipo de mensaje ICMP se trata, lo cul es algo que slo se
sabe analizando el primer octeto del mensaje ICMP.
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 tamao 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 slo 25 octetos?
En principio bastara 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 tamao mnimo 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 sern tratados por el equipo que reciba
los 25 octetos del fragmento de datagrama. Es la tarjeta Ethernet la que se encarga automticamente
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 fragmentacin tiene una MTU de 200
octetos?
Todos los fragmentos, con excepcin del ltimo, tienen que tener unos datos cuya longitud sea
mltiplo 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 mximo), los datos que hubiese contenido no habran tenido una
longitud mltiplo de 8. Cuando se fragmenta se intenta crear fragmentos del mayor tamao posible,
de forma que el ltimo fragmento sea lo menor posible, cumpliendo siempre la norma de que todos
los fragmentos, con excepcin del ltimo, deben tener unos datos cuya longitud sea mltiplo de ocho.
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 peticin 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.
Cules son los tres ltimos caracteres de los datos opcionales del mensaje ICMP de peticin de eco
que fueron enviados por PC_A0_55 mediante la ejecucin del segundo comando PING?
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 peticin 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, segn 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 peticin 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 mximo en el tiempo la
emisin 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 tamao, lo cual quiere
decir que el primer fragmento mide 196 octetos de longitud total y tiene 176 octetos de datos (176 es
mltiplo de ocho). El segundo fragmento le ha llegado en una trama con 215 octetos de tamao, lo
cual quiere decir que el segundo fragmento mide 197 octetos de longitud total y tiene 177 octetos de
datos (177 no es mltiplo de ocho). 176 ms 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 tamao la trama emitida por PC_A0_55 como consecuencia de la
ejecucin 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 habran 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 cabra por la red, por lo que se habran generado tres
fragmentos en lugar de dos.
Se habran 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 habran cabido perfectamente.
Se podra haber averiguado la MTU de la red que une al Router_A con el Router_B analizando
nicamente el trfico generado en la red del PC_A0_55 como consecuencia de la ejecucin del
tercer comando PING?
No. La prueba est en que una MTU de 197 octetos habra generado unos fragmentos iguales a los
que se han generado para una MTU de 200 octetos, como resultado de la ejecucin del tercer
comando PING.
Cul 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
posicin 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 posicin 0x18 (hexadecimal) empezando a
contar desde el cero. Y como el campo Checksum ocupa dos octetos, resulta que su valor es
0x410C en hexadecimal.
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:
En el PC_DE_13 se ha abierto una sesin MS-DOS y se han ejecutado los comandos que aparecen
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
Direccin IP . . . . . . . . . . . . . : 210.93.105.13
Mscara de subred . . . . . . . . . . : 255.255.255.0
C:\WINDOWS>ping -n 1 -l 232 223.8.151.10

C:\WINDOWS>ping -n 1 -l 10 -f 223.8.151.10

C:\WINDOWS>ping -n 1 -l 233 223.8.151.10

Respuesta desde 210.93.105.1: Es necesario fragmentar el paquete pero se

especific DF.
Es necesario fragmentar el paquete pero se especific DF.

C:\WINDOWS>

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.
Cuntas rutas puede seguir un paquete para ir desde PC_DE_13 a PC_C_10 y viceversa?
Slo hay una ruta posible, la que pasa por el Router_D y el Router_C.
Cuntos mensajes ICMP hemos solicitado que se generen mediante los comandos PING?
Cinco mensajes, uno por cada comando PING, ya que se ha usado la opcin -n con el parmetro 1.
Se han recibido todos los mensajes ICMP de respuesta de eco que se estaban esperando?
No. Slo 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 peticin de eco no pudo llegar al necesitar fragmentarse y habrselo prohibido.
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/
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 continuacin se muestra una ventana de
un analizador de protocolos en la que aparece el trfico visto por PC_DE_13, el cual se ha
del ordenador PC_C_10, el cual se ha almacenado en el archivo fichero10.cap:
Qu informacin muestran las dos ventanas anteriores?

nicamente estn mostrando el listado con de tramas capturadas en cada una de las redes. Para
cada trama slo se est mostrando el tamao y las direcciones MAC origen y destino junto con un
pequeo resumen (Summary) del contenido de la misma.
Cuntos equipos estn intercambiando tramas en la red del PC_DE_13?
Slo dos, pues las dos nicas direcciones MAC que aparecen en dichas tramas son la
00D058ADCD11, que es la direccin 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 estn intercambiando
paquetes sean el Router_D y el PC_DE_13. Habra que ver las direcciones IP de los paquetes
contenidos en las tramas para saber qu equipos estn envindose de datagramas IP.
Cuntos equipos estn intercambiando tramas en la red del PC_C_10?
Slo dos, pues las dos nicas direcciones MAC que aparecen en dichas tramas son la
00D058ADCD13, que es la direccin 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 tamao que los que
envi el PC_DE_13, puesto que son los mensajes ICMP de respuesta de eco asociados a los
mensajes ICMP de peticin 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 tambin lo sern menores que y cabrn en
la red Ethernet a la que est conectado el PC_C_10 sin necesidad de ser fragmentados.
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 informacin temporal:
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?
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 direccin 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 cdigo es el 4, Fragmentation Needed but
Dont-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 fragmentacin mediante la activacin 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 peticin de eco, podemos ver un trozo
de dicho mensaje ICMP a continuacin de la segunda cabecera. Ntese 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 averige la causa del problema.
Qu comando PING gener el datagrama IP del cul nos est informando el Router_D?
Ha sido el cuarto comando PING. Ntese 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 opcin -l con el parmetro 1300.
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 informacin temporal:
Con quin est intercambiando paquetes el PC_C_10?

Unicamente con el PC_DE_13, segn 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 relacin 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 tamao y el resumen
(Summary) de su contenido. Se observa en la ventana anterior que el PC_C_10 transmite tres
tramas de tamaos 278, 64 y 279 octetos, lo cual se corresponde con las tres tramas de idnticos
tamaos que ha emitido el PC_DE_13. Es lgico 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 transmisin 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
estn relacionadas tambin con las ejecucin 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?
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, segn nos muestra la salida en pantalla de dichos comandos, los datagramas no pueden
llegar a su destino debido a que se est prohibiendo su fragmentacin (usando la opcin -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 despus de
analizar el trfico generado en la red del PC_DE_13 por la ejecucin 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
debera ser un datagrama del mismo tamao pero en su lugar han llegado las tramas con ID=1, ID=2
e ID=3, que en este caso son todas del mismo tamao y contienen cada una un datagrama de 100
octetos de longitud total (80 octetos de datos), que al reensamblarse darn lugar al datagrama que se
espera de 260 octetos de longitud total (20 de cabecera ms tres veces 80 octetos de datos). Dicho
esto, la nica conclusin 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 habra provocado los mismos resultados.
Qu podemos decir de la MTU de la red que une al Router_D con el Router_C despus de
analizar el trfico generado en la red del PC_DE_13 por la ejecucin 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
debera ser un datagrama del mismo tamao pero en su lugar han llegado las tramas con ID=7, ID=8,
ID=9 e ID=10, conteniendo los fragmentos que darn lugar al datagrama que se espera. Las tres
primeras tramas son del mismo tamao 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 cul es sntoma de que ese octeto de datos no caba 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 habra
sido necesaria ya que la trama con ID=9 habra 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 cdigo 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 cul 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 algn trfico el quinto comando PING?
No. En la red del PC_DE_13 no se observa ninguna trama con 1036 octetos de tamao, como sera
de esperar. Lo que ha ocurrido es que el mensaje ICMP de tipo 3 y cdigo 4 que ha recibido el
PC_DE_13, despus de la ejecucin 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 tamao 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 habra ocurrido si no hubisemos utilizado la opcin -f en el segundo comando PING?
El bit DF de la cabecera IP del datagrama generado estara en ese caso a valor 0, permitiendo la
fragmentacin. No obstante, como el tamao 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.
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:
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
Direccin IP . . . . . . . . . . . . . : 192.5.5.55
Mscara de subred . . . . . . . . . . : 255.255.255.0
C:\WINDOWS>arp a

Direccin IP
Direccin fsica
192.5.5.1
00-10-7b-81-ae-26
Tipo
dinmico
C:\WINDOWS>ping -n 1 -l 1000 210.93.105.13

C:\WINDOWS>
Se ha obtenido respuesta por parte del PC al que se le ha hecho PING?

S.
Cuntas 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 peticin de eco? De
momento slo 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 mnimo todas las redes que se van a atravesar para que no se
produzca la fragmentacin 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 algn fragmento debido a la ejecucin del comando PING?
No, pues la MTU de 1500 de la red a la que est conectado dicho PC no hace necesaria la
fragmentacin en este caso, ya que el nico datagrama IP que ha enviado mide 1028 octetos.
Enviar el PC_DE_13 algn fragmento debido a la ejecucin del comando PING?
No, pues la MTU de 1500 de la red a la que est conectado dicho PC no hace necesaria la
fragmentacin en este caso, ya que el nico datagrama IP que ha enviado mide 1028 octetos.
Se ha capturado el trfico 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 continuacin se muestra una ventana de un analizador
de protocolos en la que aparece el trfico 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?
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 excepcin del ltimo, estn obligados a tener una longitud de los
datos que sea mltiplo de 8, cosa que tambin se est cumpliendo.
Qu puede decirse de la MTU de las redes que han atravesado los datagramas IP, despus de
analizar el trfico visto en la red del PC_A0_55?
De momento slo 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 continuacin puede verse la ventana del analizador correspondiente al trfico capturado en la red
del ordenador PC_DE_13, el cual se ha almacenado en el archivo fichero13.cap:
Cuntos fragmentos han llegado al PC_DE_13?

Han llegado 17 fragmentos, de diferentes longitudes.
De qu tamao 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
tamao. Tambin hay 5 fragmentos de 36 octetos de longitud total, encapsulados en tramas de 64
octetos de tamao, las cuales tendrn 10 octetos de relleno, pues sin l slo tendran un tamao 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 tamao. 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
contena 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?
podramos 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 tambin en los fragmentos de dicho datagrama.
A que se debe que al PC_DE_13 hayan llegado fragmentos de tres tamaos diferentes?
Est claro que si hubiese sido slo un router el que ha creado estros fragmentos, entonces slo
habra, como mucho, dos tamaos distintos, siendo de igual tamao todos los fragmentos distintos
del ltimo y pudiendo ocurrir que el ltimo tambin fuese igual en tamao a los dems fragmentos. Al
no ocurrir esto, podemos decir, de momento, que se ha producido fragmentacin en ms 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 ms.
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 slo presentan dos tamaos 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 pequea y luego
por una red con una MTU algo mayor que hacerlo al revs. Si la primera vez que se fragmenta se
hace para ajustarse a la MTU ms pequea de entre todas las MTU de las redes que se van a
atravesar, el resultado es que slo 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 trfico que ha recibido PC_A0_55 con la hiptesis 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 trfico recibido por PC_A0_55 sera idntico
al que ha recibido. Hay que tener en cuenta que los datagramas enviados por PC_DE_13 se
fragmentaran nicamente en el Router_D para acomodarse a una MTU de 100 octetos, que es
precisamente el tamao de todos los fragmentos recibidos por PC_A0_55, con excepcin del ltimo.
Es compatible el trfico que ha recibido PC_DE_13 con la hiptesis 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 debera
fragmentarse en el Router_A para acomodarse a la MTU de 200 octetos y luego esos fragmentos
deberan 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 fragmentara en el
Router_A en 5 fragmentos de 196 octetos de longitud total (176 octetos de datos, mltiplo de 8) y un
fragmento de 148 octetos de longitud total (128 octetos de datos). Al pasar por el Router_C los
fragmentos deberan acomodarse a una MTU de 100 octetos, por lo que los fragmentos de 196
octetos de longitud total (176 de datos) se dividiran 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 dividira 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 hiptesis de
partida es compatible con el trfico recibido.
A continuacin 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 cul 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.
Cuntos fragmentos de los que le llegan a PC_DE_13 tienen el bit MF a valor cero?
Slo puede tener el bit MF a cero el fragmento cuyos datos ocupan el ltimo lugar dentro de los
datos del datagrama original.
Podra ocurrir que llegasen los fragmentos desordenados a su destino final?
Podra ocurrir, si existiese ms de una ruta posible y no todos los fragmentos siguiesen la misma. An
as, el destino final podra reensamblar los fragmentos de forma ordenada gracias a la informacin
contenida en cada uno de los fragmentos, la cual sirve para saber qu lugar ocupa cada uno de ellos.
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:
En el PC_A0_55 se ha abierto una sesin MS-DOS y se ha ejecutado el comando que aparece
listado a continuacin:
C:\WINDOWS>ping 210.93.105.2

Tiempo de
Respuesta
Respuesta
Respuesta
espera agotado.
desde 210.93.105.2: bytes=32 tiempo=63ms TDV=251

C:\WINDOWS>
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 trfico 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 continuacin se muestra una ventana de un analizador
de protocolos en la que aparece el trfico 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 peticin de eco?

Porque el comando PING del PC_A0_55 genera cuatro mensajes ICMP a menos que se le diga otra
cosa con la opcin n.
Cuntos mensajes ICMP de respuesta de eco se han recibido?
Tres.
Cul 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 peticin de eco.
Cmo 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 peticin de eco y no el que corresponde al primer mensaje
ICMP de peticin de eco?
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 peticin de eco y en su mensaje de respuesta de eco asociado.
Podra 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 continuacin puede verse la ventana del analizador correspondiente al trfico capturado en la red
del Router_E, el cual se ha almacenado en el archivo ficheroE.cap:
Cuntos mensajes de peticin de eco ha recibido el Router_E?

Cuatro.
Cuntos 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 peticin ARP para preguntar la direccin 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 peticin de eco?
Porque cuando iba a enviarlo se dio cuenta de que le haca falta conocer la direccin MAC del
Router_D y sta no se encontraba en su cach ARP. Entonces decidi descartar ese paquete y
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 direccin MAC del Router_D mediante una peticin ARP. Otras
inplementaciones de ARP no habran descartado el paquete, sino que lo habran dejado esperando
hasta que hubiese llegado la respuesta de la peticin ARP.
Qu direccin 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 direccin MAC
del Router_D?
El Router_E slo sabe que le ha llegado una trama con un datagrama dentro, pero ignora si el que
enva esa trama es el Router_D o es cualquier otro equipo. Para aprender la direccin MAC de un
equipo a partir de la direccin IP se usa el protocolo ARP. No se utiliza la llegada de tramas con
datagramas IP para deducir cul es la direccin MAC de un determinado equipo.
Por qu el Router_D no ha realizado una peticin ARP para averiguar la direccin MAC del
Router_E, mientras que el Router_E s ha tenido que hacerla?
Porque el Router_D tendra en su cach ARP la MAC del Router_E, mientras que el Router_E no
tendra la del Router_D. Un motivo de esto podra ser, por ejemplo, que el Router_D tenga
establecido un periodo de caducidad para las entradas de la cach ARP ms largo que el otro router.
A continuacin se muestra parte del contenido del primer mensaje ICMP que le llega al Router_E:
A continuacin se muestra parte del contenido del segundo mensaje ICMP que le llega al Router_E:
A cul de los dos mensajes anteriores est respondiendo el Router_E con la emisin 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 habamos 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.
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:
En el PC_A0_55 se ha capturado el trfico generado por una serie de comandos ejecutados en
dicho PC. A continuacin se muestra una ventana de captura en la que puede verse dicho trfico:
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 trfico anterior en la red 192.5.5.18 /24 son los siguientes:
C:\WINDOWS>ipconfig
Direccin IP . . . . . . . . . . . . . : 192.5.5.55
Mscara de subred . . . . . . . . . . : 255.255.255.0
C:\WINDOWS>arp -a
C:\WINDOWS>ping 200.200.200.200

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.

C:\WINDOWS>arp -a

Direccin IP
Direccin fsica
192.5.5.1
00-10-7b-81-ae-26
Tipo
dinmico
C:\WINDOWS>
Se ha obtenido respuesta por parte del equipo al que se le ha hecho PING?

No.
Pertenece el equipo con direccin IP 200.200.200.200 a la Interred (Internetwork) mostrada en una
de las pginas anteriores?
No. Esa direccin 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.
Cul es la direccin MAC origen de todas las tramas que han llegado al PC_A0_55?
00107B81AE26
Por qu han llegado mensajes ICMP de tipo 3 y cdigo 1 al PC_A0_55?
Estos mensajes ICMP de tipo 3, Destination Unreachable (destino inalcanzable) y cdigo 1, Host
Unreachable (host inalcanzable), nos los enva 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 cul poder enviarlo. Es
decir, el router nos avisa de que en su tabla de rutado no hay informacin acerca de cmo enrutar un
paquete cuya IP destino es la 200.200.200.200, adjuntndonos adems 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 debera 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 tena 40
octetos de datos pero al copiarlo dentro del mensaje ICMP de tipo 3 se han perdido 32 octetos?
Sabe que tena 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 tena 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 peticin de eco.
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 continuacin 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 tena 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 deba 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, habra enviado por dicha ruta a nuestro
datagrama en lugar de haberlo descartado.
Tienen los cuatro mensajes ICMP de peticin de eco el mismo valor en los campos Identified y
Sequence Number?
No. Estos campos sirven para luego poder saber a que peticin de eco corresponde cada respuesta
de eco, por lo que si fueran iguales en los cuatro, no sera posible saberlo.
Podemos saber analizando el trfico capturado, si antes de hacer el PING, el router tena en su
cach ARP una entrada con la direccin IP y la direccin MAC del PC_A0_55?
Al haber hecho el PC la peticin ARP al router, es imposible saber si el router ya tena la entrada o si
la ha creado aprovechando la peticin ARP que le hace el PC.
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:
En el PC_A0_55 se ha abierto una sesin MS-DOS y se ha ejecutado el comando que aparece a
continuacin:
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

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.

C:\WINDOWS>
Por qu est enviando el Router_B mensajes ICMP al PC_A0_55?

Porque est descartando los datagramas Ip que le estn llegando con destino al equipo con direccin
IP 200.200.200.200, al no conocer a que por qu ruta debe enviarlo.
A continuacin se muestra el trfico capturado en la red del PC_A0_55 como consecuencia de la
ejecucin 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 especfica para la red a la que pertenece el equipo
con direccin 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 ms 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 sern enviados al Router_B, tal y
como se ha hecho con los cuatro datagramas que provenan del Router_A.
Cunto 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 estn preguntando. Luego el valor que nos interesa
est 22 octetos despus 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 slo han atravesado un router.
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:
En el PC_A0_55 se ha abierto una sesin MS-DOS y se ha ejecutado el comando que aparece a
continuacin:
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

C:\WINDOWS>
Qu est dicindole 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.
Cmo 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 especfica 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 tendrn una ruta por defecto, que es la que habr seguido ste
paquete.
A continuacin se muestra el trfico capturado en la red del PC_A0_55 como consecuencia de la
Qu direccin IP origen tiene el datagrama encapsulado en la trama recibida por PC_A0_55?
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 direccin 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 cul 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 despus 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 cdigo 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 continuacin se muestra el trfico capturado en la red que une al Router_D con el Router_E
como consecuencia de la ejecucin del comando PING:
Cuntos 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 topologa de red mostrada en una de las figuras anteriores.
Quin ha enviado la trama con ID=0 del archivo ficheroDE.cap?
El Router_D, cuya direccin MAC es 00D058ADCD11.
A quin ha enviado el Router_D la trama con ID=0?
No puede habrsela 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 estn intercambiando tramas en la red 210.93.105.0 /24?
nicamente el Router_D y el Router_E.
A continuacin se muestra el trfico capturado en la red que une al Router_D con el Router_E pero
presentando diferente informacin en el listado de tramas:
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 estn 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 prximo salto de la ruta por defecto del Router_D es el
Router_E, mientras que el prximo 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 continuacin se muestra parcialmente decodificada otra de las tramas del archivo ficheroDE.cap:
Quin enva 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 enva 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 continuacin 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 tambin. El resto del datagrama no ha sufrido cambios.
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:
Ntese que la red tiene rutas redundantes, de forma que puede existir ms de un camino para que un
paquete llegue a un determinado destino.
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 sesin MS-DOS y se han ejecutado los comandos que aparecen
a continuacin:
C:\WINDOWS>ipconfig
Direccin IP . . . . . . . . . . . . . : 210.93.105.13
Mscara de subred . . . . . . . . . . : 255.255.255.0
C:\WINDOWS>route print
Rutas activas:
Direccin 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
Mscara 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 Mtrica
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
C:\WINDOWS>ping -n 1 -l 34 192.5.5.55

C:\WINDOWS>route print
Rutas activas:
Direccin de red
Mscara 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 Mtrica
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

C:\WINDOWS>arp -a

Direccin IP
Direccin fsica
Tipo
210.93.105.1
00-d0-58-ad-cd-11
dinmico
210.93.105.2
00-d0-58-ad-cd-10
dinmico
C:\WINDOWS>
Cuntos 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.
Cul es el router por defecto del PC_DE_13, segn indica la salida de los comandos ejecutados?
El Router_D, segn 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 direccin IP 210.93.105.1, del Router_D.
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/
Cuntas direcciones IP forman parte de la red que tiene por nombre 0.0.0.0 y por mscara de red
tambin el valor 0.0.0.0?
Si a cualquier direccin IP se le hace el AND lgico con la mscara 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 idnticos, luego cualquier
direccin IP pertenece a dicha red. Es por eso que en las tablas de enrutamiento se suele asociar
esta red con el router que es prximo salto de la ruta por defecto.
Qu significado tienen la direccin 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 mscara 224.0.0.0?
224 es 11100000 en binario, luego nos estamos refiriendo a todas las direcciones que empiezan por
111 en binario.
Cuntos mensajes ICMP de peticin de eco va a enviar el PC_DE_13?
Dos, pues se han ejecutado dos comandos PING con la opcin n y el parmetro 1.
De que tamao sern los mensajes ICMP de peticin de eco?
El primer mensaje ICMP de peticin 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 tamao sern los datagramas IP enviados por PC_DE_13 que van a contener a los
mensajes ICMP de peticin de eco?
Puesto que en los comandos PING ejecutados no se han utilizado opciones especiales, los
datagramas generados tendrn una cabecera IP de longitud mnima (20 octetos), lo que nos da un
primer datagrama de 62 octetos de longitud total y un segundo datagrama de 82 octetos.
De que tamao sern las tramas enviadas por PC_DE_13 que van a contener los datagramas IP
que a su vez contendrn a los mensajes ICMP de peticin de eco?
Como se trata de tramas Ethernet, sabemos que las tramas sern, como mnimo 18 octetos mayores
que los datagramas que contenga, porque a lo mejor hay que aadir algn octeto de relleno para
alcanzar el tamao mnimo de trama. No es este el caso, pues nos sale una primera trama de 80
octetos de tamao 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, segn se muestra en la salida en pantalla de dichos comandos.
Se ha capturado el trfico generado en la red del PC_DE_13 a consecuencia de la ejecucin de los
comandos PING. Este trfico est almacenado en el archivo fichero13.cap y se muestra a
continuacin en la ventana de captura del analizador de protocolos:
Cuntos equipos diferentes estn enviando tramas en la red 210.93.105.0 /24?

Segn 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 direccin MAC 000102B44FFB?
La primera trama que se observa en la ventana anterior es una peticin ARP en la que se pregunta
por la direccin MAC del router por defecto del PC_DE_13, luego es lgico pensar que es el
PC_DE_13 el que est haciendo esa peticin para informarse de la direccin MAC de su router por
defecto y luego poderle enviar una trama conteniendo el primer mensaje ICMP de peticin de eco, tal
y como se puede ver en la trama con ID=2 del fichero13.cap. Luego si esta primera trama es una
peticin realizada por el PC_DE_13 y resulta que la direccin MAC Source (origen) de dicha trama
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 direccin MAC corresponde al PC_DE_13, que
adems tiene asociada la direccin IP 210.93.105.13, como ya sabemos por el grfico de la topologa
de la red y por la salida del comando ipconfig que se ha ejecutado en el mismo.
De quin es la direccin MAC 00D058ADCD11?
La segunda trama mostrada en la ventana anterior es la respuesta ARP asociada a peticin ARP de
la primera trama, en la cual se preguntaba por la direccin 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. Adems puede verse como el PC_DE_13 utiliza luego esa
direccin MAC como destino de la trama que contiene el primer mensaje de peticin de eco.
De quin es la direccin 00D058ADCD10?
Del mismo modo que hemos razonado anteriormente podemos hacerlo ahora con la peticin y la
respuesta ARP contenidas en las tramas con ID=6 e ID=7 del fichero13.cap. De ellas se deduce que
la direccin MAC 00D058ADCD10 corresponde direccin 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 peticin 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 peticin 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 peticin de eco que
puede verse en el fichero13.cap?
Es una trama enviada por el PC_DE_13 al Router_E.
A continuacin se muestra parte del contenido de la trama que contiene el primer mensaje ICMP de
peticin de eco que se ha capturado en la red del PC_DE_13:
A continuacin se muestra parte del contenido de la trama que contiene el segundo mensaje ICMP de
Muestran el mismo mensaje ICMP de peticin de eco las dos ventanas anteriores?
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,
adems 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 direccin MAC destino de la primera trama es igual que
la direccin 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 contena 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 continuacin 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 cdigo 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 redireccin pretende informar al
PC_DE_13 acerca de cul 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 redireccin le est indicando al host
210.93.105.13 cul es el router que debe usar para enviar el datagrama que se le adjunta justo a
continuacin de la cabecera ICMP. Efectivamente, puede verse la cabecera IP del datagrama que ha
originado este mensaje de redireccin junto con algunos octetos de datos, lo cul nos hace darnos
cuenta de que se trata del primer datagrama enviado por el PC_DE_13 al PC_A0_55. Por otra
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 mtrica
que est utilizando, la cual podr ser el nmero de saltos (hops), el retardo, el ancho de banda, etc.
Obsrvese que el Router_D est seguro de que es preferible que el PC_DE_13 enve 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 evitara 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 redireccin?
No. El Router_D ha enviado un mensaje ICMP de redireccin para avisar de cul 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 continuacin del mensaje ICMP de redireccin, el Router_D ha procedido a enviar al
Router_E una trama conteniendo dicho paquete.
A continuacin se muestra parte del contenido de la trama que contiene el tercer mensaje ICMP de
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 redireccin 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 lnea en la cual se dice que para la Red
192.5.5.55, con Mscara 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 conseguiramos borrar dicha ruta,
de forma que si se tuviese que enviar otro paquete al 192.5.5.55, ste seguira la ruta por defecto.
Cuntas entradas se han aadido a la cach ARP del PC_DE_13 a consecuencia de la ejecucin
de los dos comandos PING?
Segn la salida mostrada en pantalla por los dos comandos arp a se puede ver que antes de la
ejecucin del primer PING la cach ARP estaba vaca, mientras que despus de ejecutarse los dos
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 trfico generado en la red del PC_A0_55 como
consecuencia de la ejecucin de los dos comandos PING. A continuacin 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. Obsrvese 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 tambin son idnticos en los tres casos.
Lgicamente, 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 slo 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 saba que la
mejor ruta hacia el PC_A0_55 pasaba por el Router_E. Luego, como el paquete que envi el
PC_DE_13 tena 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.
Tena el Router_A en su cach ARP la direccin MAC del PC_A0_55 antes de llegarle el primer
mensaje ICMP de peticin de eco?
S, pues no ha tenido necesidad de realizar ninguna peticin ARP.
Tena el PC_A0_55 en su cach ARP la direccin MAC del Router_A antes de llegarle el primer
mensaje ICMP de peticin de eco?
No, pues justo despus de llegarle dicho mensaje ICMP de peticin de eco y antes de poder enviar
de vuelta el correspondiente mensaje ICMP de respuesta de eco, el PC_A0_55 ha realizado una
peticin ARP para preguntar por la direccin MAC del Router_A. Ntese que la implementacin que
hace el PC_A0_55 pone en espera el datagrama IP mientras se averigua mediante ARP la direccin
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 peticin de eco?
El mensaje ha llegado a su destino a travs de una ruta que contiene una salto extra que poda
haberse evitado el cul est consumiendo ancho de banda en la red PC_DE_13 y recursos en el
Router_D. Adems, el mensaje ICMP de redireccin enviado por el Router_D tambin 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 cul es la mejor ruta para este paquete y la use para
los sucesivos paquetes que tengan el mismo destino que ste.
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:
paquete llegue ir a un determinado destino. Los routers usan RIP como protocolo de enrutamiento.
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 sesin MS-DOS y se han ejecutado los comandos que aparecen
a continuacin:
C:\WINDOWS>ping
Opciones:
-t
-a
-n
-l
-f
-i
-v
-r
-s
-j
-k
-w

cantidad
tamao
TTL
Tiempo de vida.
TOS
Tipo de servicio.
cantidad
cantidad
lista de hosts Ruta origen variable en la lista de host.
lista de hosts Ruta origen estricta en la lista de host.
tiempo
C:\WINDOWS>ipconfig
Direccin IP . . . . . . . . . . . . . : 223.8.151.10
Mscara de subred . . . . . . . . . . : 255.255.255.0
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


Ruta: 202.2.2.1 ->
201.100.11.1 ->
199.6.13.1 ->
223.8.151.1

C:\WINDOWS>
Cuntos routers hay en la red del PC que ha emitido el mensaje ICMP de peticin de eco?
En la red del PC_C_10 slo est el Router_C, con la IP 204.204.7.1 en su interfaz Ethernet e0.
Cuntos 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. Segn se nos ha dicho anteriormente, el Router_D es el que tienen asignado como
router por defecto los PCs de dicha red.
Cuntos caminos posibles puede seguir un paquete que vaya desde el PC_C_10 al PC_DE_13?
Hay slo dos caminos posibles. El camino ms corto en nmero de saltos es el que pasa por el
Router_C y el Router_D. El camino ms largo en nmero 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 opcin -k del comando PING?
Esta opcin va acompaada 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
opcin Strict Source and Record Route.
Qu ruta habra seguido el mensaje ICMP de peticin de eco generado si no se hubiese utilizado la
opcin k en el comando PING?
Hubiese seguido la ruta que los routers hubiesen considerado ms adecuada. En este caso, puesto
que nos dicen que los routers usan RIP como protocolo de enrutamiento, esa ruta habra sido la que
pasa por el Router_C y el Router_D, que es la que tiene menos saltos.
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 peticin de eco va a salir del equipo con direccin IP
223.8.151.10 y se le ha dicho (mediante la opcin Strict Source and Record Route) que su prximo
salto debe ser el equipo con direccin IP 223.8.151.1, el siguiente ha de ser el equipo 199.6.13.1,
luego el 201.100.11.1, a continuacin el 202.2.2.1 y por ltimo, el destino final del paquete es el host
con direccin IP 210.93.105.13, que es el que debe contestar al mensaje ICMP de peticin de eco
con un mensaje ICMP de respuesta de eco.
A continuacin se muestra el trfico capturado en la red del PC_C_10:
Se ha obtenido respuesta del equipo al que se le ha hecho PING?

Segn la salida en pantalla del comando PING, el equipo 210.93.105.13 ha respondido al PING.
Adems, 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 peticin de eco.
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 habra seguido el mensaje ICMP de respuesta de eco si no se hubiese utilizado la opcin
-k en el comando PING?
Hubiese seguido la ruta que los routers hubiesen considerado ms adecuada. En este caso, puesto
que nos dicen que los routers usan RIP como protocolo de enrutamiento, esa ruta habra sido la que
pasa por el Router_D y el Router_C, que es la que tiene menos saltos.
Tiene que ser idntica la ruta de ida de un mensaje ICMP de peticin 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 opcin 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, segn 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.
Cuntos 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.
Cuntos 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 tambin ocupa 20 octetos en este caso.
Cul es la primera opcin 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 segn el
analizador de protocolos). En nuestro caso , el primer octeto que aparece tiene el valor 137 (0x89 en
hexadecimal), que corresponde a la opcin Strict Source and Record Route que, segn se muestra
en la RFC791, correspondiente a IP, en su pgina 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 pgina 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 opcin debe copiarse
en todos los fragmentos (y no slo en el primero), si es que el datagrama es fragmentado. La option
class indica de que clase es la opcin, segn 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 opcin se trata. Por ejemplo: 0=End of Option List, 1=No operacin,
3=Loose Source and Record Route, 9=Strict Source and Record Route.
Cul es el valor de todos los octetos correspondientes a la primera opcin, de tipo Strict Source and
record Route en la trama de ID=2 mostrada en la ventana anterior?
Para saber cules son todos los octetos, lo primero es saber cuantos octetos ocupa la opcin. Como
es del tipo 137, sabemos que es una opcin multi-octeto, cuyo segundo octeto indicar la longitud de
la misma, en este caso 19 octetos, segn podemos ver en el panel inferior de la ventana de captura,
donde se muestra el octeto 0x13 (19 en decimal) justo a continuacin del cdigo 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 opcin son, en hexadecimal: 89, 13, 04, C7, 06, 0D, 01, C9, 64, 0B,
01, CA, 02, 02, 01, D2, 5D, 69 y 0D.
Cul es la segunda opcin presente en el campo de opciones de la cabecera IP de la trama de ID=2
mostrada en la ventana anterior?
Es una opcin de un nico octeto, concretamente la opcin 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
mltiplo de cuatro objetos. Con este octeto adicional y los 19 de la opcin anterior se consigue una
longitud de 40 octetos para la cabecera.
Qu contienen los 16 ltimos octetos de la opcin SSRR (Strict Source and Record Route) de la
trama de ID=2 mostrada en la ventana anterior?
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 opcin SSRR (Strict Source and Record Route), por lo
que aunque ve que la direccin 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
segn puede verse en dicha opcin, ste an no ha sido alcanzado . Es ms, no slo debe reenviarlo,
sino que debe hacerlo de forma que siga la ruta que el equipo que lo envi originalmente ha dejado
marcada en la opcin SSRR. Adems tiene que encargarse de grabar su IP en dicha opcin 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 opcin. Su valor es 4, lo que indica que el router
debe enviar el datagrama a la IP colocada en octeto nmero 4 (y siguientes) de la opcin SSRR,
colocando antes en dicha posicin 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 posicin ocupada por la IP 199.6.13.1
dentro de la opcin 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 opcin SSRR que le ha enviado
el Router_D?
Actuar de forma anloga a como lo ha hecho el Router_B. Ver que aunque la Destination
Address del datagrama es la suya propia, como existe la opcin SSRR y el valor del campo Pointer
es 8, menor que 19, la longitud de la opcin SSRR, quiere decir que ese datagrama an no ha
llegado a su destino. Proceder a pasrselo al siguiente de la lista, el Router_A, grabando la IP
210.100.11.2 en la posicin 8 de la opcin e incrementando en 4 el valor del campo Pointer.
A continuacin se muestra un trozo del paquete IP conteniendo un mensaje ICMP de peticin de eco
capturado en la red del PC_DE_13, al cual va destinado:
Qu contiene la opcin SSRR del datagrama IP que le llega al PC_DE_13?

Los 19 octetos de la opcin 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.
Cmo sabe el PC_DE_13 que el datagrama que ha recibido es para l y que no debe reenviarlo a
nadie ms?
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
opcin SSRR, el valor de su campo Pointer es 20, superior a los 19 octetos de longitud que tiene
dicha opcin, lo cul indica que la lista de equipos intermedios ya ha sido recorrida por completo.
Adems sabe quin 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 continuacin 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 contena un mensaje ICMP de peticin de eco, le ha
devuelto un mensaje ICMP de respuesta de eco. Este mensaje viajar en una datagrama con la
opcin SSRR, pues el mensaje ICMP de peticin de eco tambin viajaba en un paquete con dicha
opcin. 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 opcin SSRR se incluirn 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 opcin SSRR se pondr a valor 4 inicialmente.
A continuacin 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 opcin SSRR. El comando PING ha utilizado el
contenido de esta opcin para mostrarnos en pantalla las IPs de los routers por los que ha pasado el
datagrama que contena al mensaje ICMP de respuesta de eco.
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:
paquete llegue ir a un determinado destino. Los routers usan RIP como protocolo de enrutamiento.
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 trfico 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 continuacin:
Qu equipos estn generando trfico en la red 210.93.105.0 /24?

Por lo que se ve en el listado de tramas de la ventana anterior, slo hay dos equipos generando
tramas. El equipo cuya direccin MAC es la 00D058ADCD11, y el equipo cuya direccin 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 quin van dirigidas las tramas generadas en la red 210.93.105.0 /24?
La direccin MAC destino de todas las tramas es FFFFFFFFFFFF (BROADCAST), por lo que son
tramas que sern procesadas a nivel 2 por todos los equipos. Es decir, todos los equipos abrirn esas
tramas y comprobarn si deben procesar o no su contenido.
A continuacin se muestra el listado de tramas capturadas pero de forma que muestre informacin
temporal y las direcciones de red de los paquetes contenidos en las tramas:
Qu equipos estn generando paquetes IP?

Ahora ya sabemos quin est generando el trfico, pues podemos ver las direcciones IP de los
paquetes contenidos en las tramas. Son, como ya suponamos, el Router_D, con IP 210.93.105.1 y
el Router_E, con IP 210.93.105.2, los nicos en generar trfico en la red.
A quin van destinados los paquetes IP generados por el Router_D y el Router_E?
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 direccin 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 estn enviando actualizaciones RIP los routers?
Si nos fijamos en la informacin 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 peridicas 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 slo estamos viendo el listado de tramas y no el contenido de todas
ellas. No obstante, parece ser que s, pues el tamao de todas las tramas enviadas por un mismo
router es siempre el mismo. Adems, en la columna Summary de la primera de las ventanas poda
verse el nmero de entradas de enrutamiento (Routing Entries) que contena 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 aadimos que la topologa 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 continuacin 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 direccin IP
255.255.255.255, y la trama que transporta a dicho paquete tiene como destino la direccin MAC
FFFFFFFFFFFF. Sin embargo, una vez dentro del equipo, el datagrama UDP ser descartado a
menos que exista algn 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.
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/
Cmo se sabe cules son los nmeros de puerto reservados para cada uno de los protocolos?
Hasta el 1994, al organizacin IANA publicaba peridicamente la RFC Assigned Numbers, cuya
edicin ms reciente es la RFC1700, en la cual se recopilan muchas tablas con asignaciones de
parmetros 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 pgina web de la organizacin IANA, que actualmente es www.iana.org.
Cmo 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. Slo 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.
Cmo 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 descripcin del protocolo RIP?
El documento de referencia es la RFC1058, Routing Information Protocol, donde se describe la
primera versin 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
adems de detallar el funcionamiento de la primera versin, RIPv1, tambin explica el de RIPv2.
A continuacin 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
versin del protocolo RIP que se est usando, que en este caso es la 1. Los otros dos octetos no se
usan en la versin 1 del protocolo RIP, por lo que deben estar a cero.
Cuntas entradas de enrutamiento pueden aparecer en un mensaje RIPv1?
Segn se cuenta en la RFC2453, el nmero de entradas RIP (de 20 octetos de longitud), que pueden
aparecer en un mensaje RIPv1 debe estar comprendido entre 1 y 25 (ambos inclusive).
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/
Cul es la estructura de una entrada de enrutamiento de un mensaje RIPv1?
Esta es la estructura de una entrada RIPv1, segn 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 parntesis aparecen las longitudes de cada campo en octetos. Slo 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 direccin IP de la red a la que se refiere la entrada y la mtrica que le ha
asignado a esa red el router que est enviando la actualizacin.
Acerca de qu redes est informando el Router_D en su primer mensaje RIP?
Segn 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 conclusin sacan los routers (el Router_E en este caso) al recibir la informacin 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 enva el mensaje
RIP) y que llega a la red 199.6.13.0 en 2 saltos (pues es 2 la mtrica 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 grfico con la
topologa de la red, vemos que toda esta informacin que recibe el Router_E es correcta.
A continuacin 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 mscara de red tienen las redes acerca de las que est informando el Router_E en su primer
mensaje RIP?
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 mscara
de red de 24 bits de longitud, o lo que es lo mismo la mscara 255.255.255.0, puesto que en el
grfico de la topologa de la red vemos que dichas redes tienen asignada esa mscara. Sin embargo,
los mensajes RIPv1 informan exclusivamente acerca del nombre de la red, pero no de la mscara de
red. El destinatario de un mensaje RIPv1 tiene que intentar adivinar la mscara de red. Lo normal es
que le asigne la mscara de red natural, propia de la clase de direccin IP de que se trate. En este
caso, como las cinco redes son de clase C, el Router_D pensara que la mscara de red de estas
cinco redes es la 255.255.255.0, pues esa es la mscara natural o por defecto para esa clase.
Qu pasara si se utilizase RIPv1 en una internetwork en la que existiesen subredes creadas
mediante la realizacin de subnetting en una red mayor?
Esta claro que pueden darse situaciones en las que la informacin de enrutamiento no sea la
correcta. Al publicar informacin de enrutamiento acerca de una subred (red obtenida mediante
subnetting) pero sin poder decir cul es la mscara de subred, el destinatario de un mensaje RIPv1
se encuentra con un problema difcil de resolver. Si el destinatario del mensaje RIPv1 est conectado
directamente a una subred hermana de aquella acerca de la cul le estn informando, entonces s
que puede conocer la mscara de red de dicha subred, pues debe ser la misma que la de la subred a
la que est directamente conectado. Esto es correcto slo si se ha hecho subnetting con una nica
mscara de red, porque si lo que se ha hecho es subnetting con mscara de red de longitud variable
(VLSM), los routers pueden llegar a confundirse al intentar adivinar la mscara de subred. Ese es
uno de los motivos por los que se aconseja el uso de RIPv2, que si informa de la mscara 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 slo 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 hara diciendo que su mtrica
es de 3 saltos (uno ms 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 enve 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 ms que la otra). A nadie le sera
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 ms corta. Adems, no slo es intil publicar esta
informacin, sino que en ciertas circunstancias puede llegar a confundir a los otros routers. A esta
tcnica que evita que una informacin que se obtenido a travs de una red sea enviada de nuevo
hacia la misma red se la llama split horizon (horizonte dividido).
Se ha abierto una sesin 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 continuacin 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#
Cuntas redes conoce el Router_E?

El router sabe cmo llegar a nueve redes. Si nos fijamos podemos ver que todas las redes que
aparecen en el grfico con la topologa de la red tambin se encuentran en la tabla de enrutamiento
que nos ha mostrado el Router_E al ejecutar el comando show ip route.
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/
Cmo ha obtenido el Router_E la informacin acerca de las redes a las que sabe como llegar?
El Router_E tiene la interfaz s0 configurada con la direccin IP 202.2.2.1 y la mscara /24 y tiene
la interfaz e0 configurada con la direccin IP 210.93.105.2 y la mscara /24. Por eso sabe cmo
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 informacin 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 estn aplicando la tcnica del horizonte dividido. Ambos routers estn directamente
conectados a esa red. Si enviasen un mensaje RIP a esa red informando de una ruta para llegar a
ella, la mtrica sera de 1 salto, lo cual no sera de utilidad para ningn router que pudiera escuchar
este mensaje, pues slo lo escuchan los equipos directamente conectados a la red 210.93.105.0 /24.
Tiene el Router_E ms 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 slo 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 travs del router 210.93.105.1 y del router 202.2.2.2.
Cul 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 lnea 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 informacin mediante RIP. A continuacin aparece el nombre
de la red a la que se refiere la entrada y su mscara de red. El segundo nmero entre corchetes es la
distancia a la que est la red en nmero de saltos, la cual coincide con la mtrica que tena esa red
asignada en uno de los mensajes RIP que ha recibido el Router_E. El primer nmero entre
corchetes es la distancia administrativa asignada por el administrador para esa ruta, cuya misin es
ayudar al router a decidirse en el caso de que existan varias rutas hacia la misma red, cada una
aprendida mediante un mtodo diferente (RIP, IGRP, OSPF...). La IP que aparece despus de la
palabra via corresponde a la del router vecino que nos ha informado acerca de la red, el cul acta
como prximo salto en la ruta hacia la red. La hora que puede verse cerca del final de la lnea 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 acta
de prximo salto. Hay que destacar que si existiesen varias rutas con la misma mtrica hacia la
misma red, se agruparan 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 comn 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
nmero 0 (e0). Ntese que ninguna de estas redes es publicada en los mensajes RIP que el
Router_E inyecta a travs de la interfaz Ethernet e0, pues est usando la tcnica del horizonte
dividido.
Enva el Router_E actualizaciones RIP por su interfaz serie nmero 0 (s0)?
Lo lgico es que s, pues de lo contrario el Router_A no podra aprender las mejores rutas a todas
las redes de la internetwork. Lo que si es seguro es que el Router_A est envindole
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 prximo salto.
Enviar el Router_E mensajes RIP al Router_A informndole acerca de la red 199.6.13.0?
No, pues la aplicacin de la tcnica del horizonte dividido se lo impide. Ntese que de nada le servira
al Router_A saber que a travs del Router_E puede alcanzar dicha red en 3 saltos, puesto que el
Router_A puede alcanzarla en slo un salto.
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 tcnica del horizonte dividido el que tanto el Router_D como el Router_E incluyan
informacin acerca de la red 219.17.100.0 en las actualizaciones RIP que envan 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 informacin. Hay que tener en cuenta que
los routers nunca saben cuantos routers reciben los mensajes RIP que ellos envan a la direccin IP
255.255.255.255, por lo que aunque el Router_D pueda pensar que al Router_E no le interesa la
informacin 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 informacin.
Tiene el Router_E una ruta por defecto a la que enviar los paquetes que no sabe a dnde 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 cul 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.
Cmo aparecera 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 aparecera marcada con un S inicial,
indicando que es una entrada Static (esttica).
Qu ocurre cuando un router recibe un mensaje RIP en el que se dice que una determinada red
tiene una mtrica 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 cuestin. Es decir, el router que enva el mensaje est dicindole a otros
routers que la red esa es inaccesible a travs suya. La mtrica 16 se considera como infinita en el
caso del protocolos RIP.
Cmo ser la mtrica 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 mtrica de 15. Este mensaje RIP, como es lgico, ser
enviado slo por los interfaces que permita la aplicacin de la tcnica 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 tendra en cuenta los mensajes RIP que le llegasen informando acerca de redes con
mtricas de valor 16. La informacin de redes con mtricas mayores de 16 ni siquiera le llegaran,
pues ningn router genera mensajes RIP con mtricas mayores de 16.
Cmo seran los mensajes RIP que enva un router por cada una de sus interfaces si no se
emplease la tcnica del horizonte dividido?
El router enviara por sus interfaces actualizaciones peridicas idnticas informando acerca de todas
las redes que tiene anotadas en su tabla de enrutamiento. No habra diferencias entre los mensajes
RIP enviados por una interfaz y el enviado por otra, pues al no emplear la tcnica del horizonte
dividido no es necesario eliminar del mensaje RIP las referencias a redes cuya mejor ruta tiene como
prximo salto un router que pertenece a la misma red en la cual se est enviando el mensaje.
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:
Nombre del host . . . . . . . . . . . : smartin

Servidores DNS . . . . . . . . . . . . : 193.152.63.197
195.235.113.3
Id. De mbito NetBIOS . . . . . . . . :
Descripcin . . . . . . . . . .
DHCP activado . . . . . . . . .
Direccin IP . . . . . . . . . .
Servidor DHCP . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
:

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
C:\WINDOWS>ping -n 1 www.c2.com
Haciendo ping a www.c2.com [209.162.215.78] con 32 bytes de datos:


C:\WINDOWS>

00C026260D14
Cul es la direccin IP y la mscara de red de nuestro PC?
La 200.200.200.5, con mscara 255.255.255.0.
Cmo ha averiguado nuestro PC su direccin IP?
La ha obtenido de un servidor DHCP, pues la salida del comando ipconfig /all nos indica que el
DHCP est activado.
Cul es el router por defecto de la red de nuestro PC?
Es el 200.200.200.1, tambin llamado Puerta de enlace predeterminada.
Cul es el servidor DHCP del que hemos obtenido la direccin IP?
El servidor DHCP es el equipo 200.200.200.1, lo cual quiere decir que es el mismo router el que
tambin est tambin haciendo las funciones de servidor DHCP. Hay que hacer notar que esto no es
obligatorio y que dicha funcin de servidor DHCP podra haber sido implementada en cualquier otro
equipo.
Cundo obtuvimos por ltima vez permiso del servidor para usar nuestra direccin IP?
El 4 de mayo de 2002 a las cero horas, 12 minutos y 10 segundos.
Por cunto tiempo nos dieron permiso para usar nuestra direccin IP en el momento de
concedrnosla?
Por una hora, pues la salida del comando ipconfig /all nos indica que el permiso caduca justo una
hora despus 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 mquina destino del ping. Queremos hacerle ping a una
mquina llamada www dentro del dominio c2 que se encuentra a su vez dentro del dominio de
primer nivel com.
A qu direccin IP hemos dirigido el mensaje ICMP de peticin de eco?
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 direccin IP asociada al nombre de dominio www.c2.com.
A continuacin se muestra el trfico generado en la red 200.200.200.0 /24 como consecuencia de la

Cul es la direccin MAC de nuestro router por defecto?

0020EA18D151, segn se muestra en el mensaje ARP que nos ha enviado como respuesta a la
peticin ARP que hemos enviado en una trama con direccin 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.
Cmo 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?
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 descripcin a nivel de aplicacin, 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
descripcin de la trama con ID=2. La cadena aparece en color azul para indicar que el contenido
descrito es de nivel de aplicacin. La palabra DNS nos dice que los datos pertenecen al protocolo
de aplicacin 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 continuacin se muestra parte del contenido de la trama con ID=3, la cul forma parte del trfico
generado en la red 200.200.200.0 /24 a consecuencia del comando PING.
Qu equipo enva 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 direccin
MAC origen de dicha trama.
Qu equipo enva 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.
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 anlisis 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 enva 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 efecta 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 podra haberse escogido el
2444, el 3902 o cualquier otro. Cuando no tiene libertad de eleccin 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 mquinas que actan de servidor DNS para ubicar al proceso que efecta dicha labor.
A continuacin se muestra parte de la trama que contiene el mensaje ICMP de peticin de eco:
Se habra capturado en la red un trfico diferente si en lugar de haber usado el nombre de dominio
se hubiese usado la direccin IP 209.162.215.78 al hacer el PING?
Las nicas tramas que no se habran generado las tramas con ID=2 e ID=3 relacionadas con el
servidor DNS. Los mensajes ICMP habran 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 ms fcil de recordar que la IP.
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 continuacin 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 despus de arrancar para indicarle a todos los routers de la red a la que est
directamente conectado que enven un mensaje ICMP de tipo 9 (Router Advertisement), de forma
que pueda conocerlos a todos. Puede observarse que ningn router ha respondido al mensaje,
seguramente porque no tienen implementados estos dos mensajes ICMP. Ntese que la direccin IP
a la que se envan estos mensajes es una direccin IP de clase D (Multicast), concretamente la
224.0.0.2, que est asignada a todos los routers de una subred. La direccin MAC asociada a esta IP
multicast es la 01005E000002, que tambin es una direccin MAC especial, pues tiene a 1 el bit
menos significativo de su primer octeto, indicando que es una direccin MAC multicast.
Despus del proceso de arranque hemos ejecutado lo siguiente en una ventana MS-DOS:
Nombre del host . . . . . . . . . . . : PC1

Servidores DNS . . . . . . . . . . . . : 193.152.63.197
195.235.113.3
Id. De mbito NetBIOS . . . . . . . . :
Descripcin . . . . . . . . . .
DHCP activado . . . . . . . . .
Direccin IP . . . . . . . . . .
Servidor DHCP . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
:

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>
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 ttulo la palabra ICMP y
despus de un breve anlisis 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.
Cul es el servidor DHCP del que hemos obtenido la direccin IP?
El servidor DHCP es el equipo 200.200.200.1, lo cual quiere decir que es el mismo router el que
tambin est tambin haciendo las funciones de servidor DHCP. Hay que hacer notar que esto no es
obligatorio y que dicha funcin de servidor DHCP podra haber sido implementada en cualquier otro
equipo.
A continuacin 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 pgina 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.
Cul es la estructura de un mensaje BootP?
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/
Segn 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
continuacin de la cabecera UDP, hasta el campo Boot File name, ambos inclusive. La parte
opcional est pensada para que los diferentes diseadores de protocolos incluyan ah la informacin
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 nmero de 32 bits que sirve para saber de qu forma hay que
interpretar la informacin opcional que vienen a continuacin. Lo ms 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 diseado DHCP (Dynamic Host Configuration Protocol), no se trata de un
protocolo autnomo. Ha sido concebido como una extensin de un protocolo ya existente, el
BootP, que haba sido diseado de forma que fuese extensible gracias a su campo de opciones.
Dnde 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.
Cunto ocupa la parte opcional del mensaje BootP contenido en la trama con ID=0?
Segn 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.
Cuntos 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.
Cuntos 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 direccin 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 direccin MAC destino tiene la trama que contiene al mensaje DHCPDISCOVER?
BROADCAST, pues al igual por las mismas razones expuestas anteriormente.
Qu direccin IP origen tiene el paquete IP que contiene al mensaje DHCPDISCOVER?
La IP 0.0.0.0, indicando que el que lo enva no conoce su direccin IP. sta es una direccin IP
reservada que slo puede ser utilizada en el campo Source Address.
Enva el cliente DHCP su direccin 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 direccin 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 podrn enviarle al cliente mensajes DHCPOFFER
en los que le ofrecern una direccin IP.
Qu direccin IP se nos ha ofrecido?
Por el comando ipconfig /all sabemos que nuestra direccin IP es la 200.200.200.5, luego como slo
nos han ofrecido una direccin IP, debe ser esa.
Por qu hace el servidor DHCP una peticin ARP asociada a la 200.200.200.5?
Antes de ofrecrnosla a nosotros, el servidor DHCP se asegura de que nadie est utilizndola
haciendo una peticin ARP y comprobando que nadie le responde.
A continuacin se muestran las opciones DHCP del primer mensaje enviado por nuestro PC:
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 slo existe la opcin Padding (de valor 0) y la opcin End (de valor 255 en decimal). Las
opciones multiocteto son todas las dems, y se componen de un primer octeto llamado Option Tag
que indica el tipo o cdigo de la opcin, un segundo octeto que indica la longitud de la opcin en
octetos (sin contar los dos primeros octetos) y luego un nmero variable de octetos, que puede ser
cero. Un ejemplo de esto es la opcin 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 continuacin vienen los 4
octetos de la direccin IP que contiene esta opcin DHCP.
De que sirve la opcin Requested IP Address?
Permite que el cliente solicite una direccin IP concreta en su mensaje DHCPDISCOVER. Ntese que
el cliente no est obligado a solicitar una IP en concreto, ni el servidor est obligado a ofrecrsela. No
obstante el cliente suele estar interesado en que le ofrezcan la misma direccin IP que se la haya
asignado anteriormente y, normalmente, si el servidor tiene disponible dicha direccin IP, suele
satisfacer su peticin. En el caso que nos ocupa, parece ser que nuestro PC ha tenido en otra
ocasin la direccin 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 opcin Padding?
Sirve para rellenar espacio y/o separar opciones.
De qu sirve la opcin End?
Marca el fin de la informacin vlida en el campo de opciones del mensaje BootP. Despus de esta
opcin la nica opcin que puede aparecer es la opcin Padding.
Qu tamao mximo 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 ms aparte de una direccin IP?
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 opcin Parameter Request List el cliente puede solicitar al servidor una
cantidad variable de parmetros que le hagan falta para configurarse adecuadamente. En este caso
ha solicitado 9 parmetros. Cada uno de los parmetros solicitados viene identificado por un octeto,
cuyo valor debe ser el de la Option Tag de una opcin DHCP. Por ejemplo, vemos que nuestro PC
ha incluido como primer parmetro el que tiene valor 1, que corresponde a la opcin Subnet Mask,
indicando por tanto que desea que se le informe de cul es su mscara de red y poder as completar
su configuracin IP. Tambin ha incluido en la lista de parmetros requeridos el parmetro de valor 6,
correspondiente a la opcin Domain Name Server, pues desea que se le informe de cules son los
servidores DNS que puede utilizar.
A continuacin 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 enva el mensaje al cliente.
Cmo se sabe cul es el tipo de un mensaje DHCP?
Basta con mirar el contenido de la opcin DHCP Message Type cuyo Op Code es el 53. sta es
una opcin 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 opcin debe aparecer obligatoriamente
en todos los mensajes DHCP.
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 direccin 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 cunto tiempo dice que nos presta la direccin IP el servidor en su mensaje DHCPOFFER?
La opcin IP Address Lease Time nos indica que podemos disponer de la direccin durante 3600
segundos (1 hora). No obstante, lo normal es que podamos ir renovando el prstamo con el servidor
antes de que expire el tiempo lmite que ste nos indica cuando nos presta la IP.
Cmo 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 opcin Server Identifier.
Qu router podr usar el cliente, a juzgar por el contenido del mensaje DHCPOFFER?
El router con IP 200.200.200.1, segn aparece en la opcin Router Option.
Cules 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 direccin MAC del cliente del mensaje DHCPDISCOVER.
Cules son las direcciones IP origen y destino del datagrama IP que contiene al mensaje
DHCPOFFER?
En este caso se observa que la direccin IP origen es la del servidor, mientras que la direccin 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 an no tiene esa IP
asignada. Algunos clientes antiguos no son capaces de hacer esto y se hace necesario usar otra
tcnica diferente, pero no es lo habitual.
A continuacin se muestra parte del contenido del mensaje DHCPREQUEST enviado por el cliente:
Qu contiene el mensaje DHCPREQUEST?

Bsicamente 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 slo uno
de ellos. Ese es el motivo de enviar ste mensaje en BROADCAST, conseguir que llegue a todos los
servidores. La opcin 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.
Cul es la utilidad del campo Transaction Id del mensaje BootP?
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 nmero aleatorio escogido por el cliente que sirve para poder asociar las preguntas y
respuestas que se intercambian el cliente y el servidor.
A continuacin 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 dems, su contenido es idntico al del mensaje DHCPOFFER. A veces, cuando
al servidor le llega el mensaje DHCPREQUEST, puede ocurrir que la direccin ya haya sido asignada
a otro cliente, por lo que en lugar de una DHCPACK el servidor enviara un DHCPNAK para decirle al
cliente que finalmente no es posible realizar el prstamo de la IP.
Estn obligados todos los equipos de Internet a aceptar un paquete IP del tamao que tiene el
paquete IP mostrado en la ventana anterior?
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 tamao del mayor datagrama que
estn 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 opcin Padding?
No. Se puede observar en el panel inferior de la ventana de captura que detrs de la opcin End
aparecen muchos octetos de relleno (la opcin 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 tamao menor.
Qu servidores DNS le ha asignado el servidor al cliente?
Segn se observa en el interior de la opcin 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 parmetros que solicit el cliente en su mensaje
DHCPDISCOVER?
No. Por ejemplo, la opcin 44, NETBIOS over TCP/IP Name Server no est incluida entre las que ha
enviado el servidor, a pesar de que es un parmetro de los que solicit el cliente.
Por qu se ha generado la trama con ID=5?
Es una peticin ARP realizada por el cliente al que acaba de concedrsele el uso de la direccin IP
200.200.200.5, en la cual se pregunta precisamente por a direccin MAC asociada a dicha direccin
IP. Nadie ha respondido a la peticin, lo cul es una buena seal. Si alguien hubiese respondido a la
peticin ARP sera porque ya habra alguien usando esa direccin IP en la misma red que el cliente.
En ese caso el cliente no hara uso de la direccin que se le ha asignado y debera avisar de este
hecho al servidor mediante el mensaje DHCPDECLINE.
Quin ha generado un mensaje ICMP de peticin de eco y por qu?
El servidor DHCP, cuya IP es la 200.200.200.1 ha enviado un mensaje de peticin 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 direccin IP
200.200.200.5, tal y como se le ha asignado. Ntese que el cliente no dispona en su cach ARP de
la direccin MAC asociada a la IP 200.200.200.1, por lo que ha tenido que efectuar una peticin ARP.
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
mquina, desde la cual podremos enviar comandos a la mquina 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 slo 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 lnea serie. Los caracteres que llegan por la lnea serie se
muestran en la pantalla conforme van llegando. La funcin 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 slo uno.
Por ejemplo podemos usarlo para conectarnos a un router e introducir su configuracin. Otro uso
tpico 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 aplicacin de emulacin 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 hara un terminal verdadero. El uso de los
terminales plantea algunos inconvenientes. Por un lado, si queremos conectar varios usuarios
simultneamente a una mquina, necesitaremos que la mquina disponga de varios puertos de
comunicaciones serie. Adems, las tcnicas de comunicacin serie utilizadas en los terminales son
muy sencillas y no suelen alcanzar ms de unas decenas de metros de distancia, por lo que el
terminal debe estar fsicamente cerca de la mquina salvo que empleemos un par de modems que
permitan extender la distancia. El uso de modems telefnicos permite que el terminal y la mquina a
la que se conectan estn en cualquier lugar, siempre que ambos tengan acceso a una lnea
telefnica.
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 emulacin de terminal (el cliente) estn conectados a travs de una red, el
cable de comunicacin serie ya no es necesario y su funcin 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 mquina a la que se conecta, sino que en su lugar usa
una red de comunicaciones. La informacin tecleada es transportada desde el terminal virtual al
servidor a travs de la red. Anlogamente, la informacin que la mquina que hace de servidor desea
mostrar en la pantalla del terminal ser transportada tambin a travs 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 mquina (el servidor) el protocolo telnet, descrito en la RFC854 y la RFC855. El protocolo
telnet es un protocolo de nivel de aplicacin (segn la arquitectura TCP/IP), que viaja, por tanto,
sobre una conexin 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 mquina a la
que queremos conectarnos?
La RFC854, en su pgina 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).
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 continuacin podemos ver la ventana que nos muestra nuestro PC despus 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 compaa
AT&T (American Telephone and Telegraph). En la ltima lnea de la pantalla, justo despus de la
informacin 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 algn comando. Ntese que en este caso no se nos ha
pedido ningn tipo de clave para poder iniciar la sesin 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 ms adelante. A continuacin se muestra parte del trfico
generado en la red de nuestro PC como consecuencia del dilogo que ha tenido nuestro PC con el
router:
Cul es la IP de nuestro PC?

Es la 200.200.200.5, pues la IP Source de la peticin ARP contenida en la primera trama generada.
Cul es la mscara de red de nuestro PC?
Con la informacin que se nos ha dado hasta ahora es imposible saberlo.
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/
Cul es la IP del equipo que tiene por nombre route-server.ip.att.net?
Segn se ve en el listado de tramas, hay una conexin conexin 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. Ntese que una conexin TELNET es una conexin TCP por la cul viajan
datos del protocolo TELNET.
Cmo 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 peticin DNS contenida en la trama con ID=2.
cuntas 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 peticin ARP para conseguir la direccin
MAC del equipo con direccin IP 200.200.200.1, lo cul 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 peticin ARP hecha al equipo
200.200.200.1 no se habra efectuado.
Se habra efectuado una peticin ARP para averiguar la direccin MAC del servidor DNS si ste
hubiese estado en la misma red que nuestro PC?
En ese caso se habra mirado primero en la cach ARP en busca de la IP del servidor DNS y, si no se
hubiese encontrado, se habra procedido a efectuar la peticin ARP correspondiente.
Es posible que la mscara de red de nuestro PC est configurada actualmente a valor 0.0.0.0?
Si estuviese configurada a 0.0.0.0, nuestro PC creera 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 mscara de
red que tenemos asignada. Recurdese que con la mscara /0asignada, cualquier equipo
considerar que cualquier direccin 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?
Qu valor tiene en binario la IP de nuestro PC?
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.
Considerara nuestro PC que el servidor DNS forma parte de su propia red si la mscara de red
asignada a nuestro PC fuese la 224.0.0.0?
La mscara 224.0.0.0 equivale a /3, por lo que nuestro PC considerara que una IP forma parte de
su red si los tres primeros bits de dicha IP son idnticos a los tres primeros bits de su propia direccin
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 mscara nuestro PC considerara al servidor DNS como
perteneciente a su misma red.
Qu mscara de red tendra 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 mscara 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 comn. Ntese que,
como anteriormente habamos llegado a la conclusin de que esa no era la mscara 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 continuacin se muestra, de otra forma, algo del trfico contenido en el fichero captura.cap:
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/
Cul es la direccin MAC del equipo con IP 200.200.200.1?
0020EA18D151, segn se ve en la respuesta ARP.
A qu direccin MAC va dirigida la trama que contiene la peticin DNS dirigida al servidor DNS?
A la direccin MAC 0020EA18D151, que corresponde a la del equipo con IP 200.200.200.1, lo cul
nos confirma lo que ya decamos 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 continuacin 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 conexin TCP.
A qu direccin MAC va dirigida la trama que contiene el segmento TCP que sirve para abrir la
conexin con el equipo route-server.ip.att.net.
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 direccin MAC 0020EA18D151, segn poda verse en una de las ventanas anteriores, la cual
corresponde a la del equipo con IP 200.200.200.1, lo cul nos confirma lo que ya decamos 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.
Habra 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 travs de Internet se hubiese encontrado con una red cuya MTU fuese de 45
octetos?
No habra 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 habra
impedido la fragmentacin necesaria para poder atravesar la red de 45 octetos de MTU.
Cul 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 detrs de la Destinacin Address, as que la
longitud de la cabecera es de 20 octetos, la mnima posible. Otra forma de averiguarlo es localizar en
el panel inferior de la ventana de captura el octeto asociado al campo Versin/Header Length, que
en este caso vale 0x45 (hexadecimal) y est colocado en la posicin 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 habamos dicho.
Cul 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 ms de 20 octetos de cabecera es un segmento con
opciones. Segn lo que nos muestra el analizador, hay una opcin de tipo 2 (Maximum Segment
Size), dos opciones de tipo 1 (No Operation) y una opcin de tipo 4 (TCP Selective ACK Permitted).
Qu est indicando nuestro PC al usar la opcin MSS (Maximum Segment Size) con el valor 1460
en el segmento SYN que enva al 12.0.1.28 para abrir la conexin TCP?
Est informando al 12.0.1.28 de que est dispuesto a recibir segmentos TCP que contengan como
mucho 1460 octetos de datos. Ntese que esta opcin slo puede usarse en segmentos SYN. No es
obligatorio hacer uso de esta opcin, pero es muy recomendable hacerlo.
Qu est indicando nuestro PC al usar la opcin SACK-permitted (TCP Selective ACK Permitted)
en el segmento SYN que enva al 12.0.1.28 para abrir la conexin TCP?
Permitiendo al equipo 12.0.1.28 usar la opcin 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 explcitamente, dicha opcin no ser utilizada por la otra parte. Ntese que la
opcin SACK-permitted slo 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 mltiplo de 4 octetos.
Cmo 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?
Slo tiene activado (a valor 1) el bit SYN. Los otros cinco, URG, ACK, PSH, RST Y FIN estn
desactivados (a valor 0). Un segmento con el bit SYN es un segmento de sincronizacin que sirve
para abrir la conexin y comunicarle al otro host nuestro nmero de secuencia inicial.
Es posible enviar un segmento TCP cuya longitud sea mayor que la longitud mxima 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 solucin es crear un segmento TCP ms pequeo, con menos datos en su interior.
Ntese que no hay ningn inconveniente en fragmentar un datagrama IP que contenga un segmento
TCP, pues la fragmentacin de un datagrama IP no tiene nada que ver con el contenido del mismo.
Cmo se sabe cul 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 ningn 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.
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 continuacin 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 opcin TCP ha usado el equipo 12.0.1.28 en su primer segmento TCP?

nicamente ha usado la opcin MSS (Maximum Segment Size) para decir que no se le deben
enviar segmentos que contengan ms de 536 octetos de datos. Ntese que no aparece la opcin
SACK-Permitted, lo cul indica que es un host que no reconoce las opciones SACK y por tanto ni las
enviar ni deben envirsele.
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 sincronizacin. Tambin est activado el
bit ACK para indicar que el campo Acknowledgement Number es significativo y su valor debe
tenerse en cuenta.
Qu nmero 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 nmero 2221078 como nmero 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 adems de para informar al
200.200.200.5 del nmero 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 tena asociado el nmero de secuencia 2221078) y est esperando recibir el octeto de
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 nmero de secuencia 2221079. Ntese que no se est reconociendo el segmento SYN
sino el bit SYN, que tiene asociado un nmero 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 vlido como otro cualquiera. Este campo slo 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 estn usando en esta conexin?
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 ningn 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 enva el servidor van del puerto 23 hacia el 1165. La ubicacin de los servidores
en puertos bien conocidos es simplemente una cuestin prctica, pues hace muy fcil averiguar en
que puerto se encuentra esperando una conexin un determinado servidor dentro de una mquina.
A continuacin se muestra parte del contenido de la trama con ID=6:
Por qu en la ventana anterior nos muestra el analizador, justo despus 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 mnima que deben tener los datos contenidos en una trama
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 slo 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 aadir 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 misin 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 nmero 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 nmero 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
informacin 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, tambin se puede configurar el analizador de protocolos para que en la columna

Summary la informacin 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 presentacin del listado de tramas omitiendo la informacin del nivel de aplicacin hace que
podamos ver de un vistazo un resumen del los principales campos de todos los segmentos TCP y de
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 aplicacin. 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 aplicacin, TELNET y DNS en nuestro caso, lgicamente lo mejor es que se muestre la
informacin del protocolo de mayor nivel contenido en cada trama. De todas formas, se seguir
mostrando exclusivamente informacin 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 tambin 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
nmero de secuencia (SEQ), el nmero de reconocimiento (ACK), el tamao de la ventana (WS), los
flags (PSH, SYN, etc. a excepcin del ACK), la longitud de los datos contenidos en el segmento
(LEN=n) y una indicacin de si el segmento incluye opciones (OPT).
Qu se est indicando cuando se enva un segmento con el flag ACK activado?
Si el flag ACK est activado, entonces el valor del campo Acknowledgement Number est indicando
el nmero de secuencia de un octeto que an no ha sido recibido. Adems, implcitamente se est
reconociendo que han llegado correctamente todos los octetos cuyos nmeros 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 conexin, tan slo el primer segmento, enviado por el equipo 200.200.200.5, tena el
flag ACK desactivado?
En ese primer segmento, el equipo 200.200.200.5 no poda indicar qu octeto estaba esperando
recibir, pues la conexin no estaba establecida y el otro equipo no haba elegido an su nmero de
secuencia inicial, as que el campo Acknowledgement Number tena 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 saba 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. Tngase en cuenta que hacer esto no implica que el segmento tenga un mayor tamao, 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 nmero
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. Ntese que el flag SYN y el flag FIN
consumen un nmero de secuencia, igual que si fueran un octeto de datos, aunque viajen en un
segmento que no contenga datos.
A continuacin se muestra otra vez el listado de las tramas capturadas en la red de nuestro PC,
encontrndose 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 tamao de la ventana de recepcin 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 nmero de secuencia 3077941796, que es el nmero del primer octeto que el
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 recepcin de un
equipo es un intervalo de nmeros de secuencia que comprende desde el Acknowledgement
Number (inclusive) hasta el Acknowledgement Number + Window Size (exclusive). A estos
nmeros se les conoce como borde izquierdo y borde derecho de la ventana de recepcin,
respectivamente.
Ha reducido en algn momento el tamao de la ventana de recepcin 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 recepcin 12 octetos menor que la que tena antes. Se puede agrandar o
reducir la ventana de recepcin pero sin mover ninguno de sus dos bordes hacia atrs. 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 algn momento el tamao de la ventana de recepcin el equipo 12.0.1.28?
S. En la trama con ID=11 se ve que la anchura de la ventana de recepcin es de 4288 octetos,
mientras que en la trama con ID=12 la ventana de recepcin del 12.0.1.28 es de 4285 octetos, tres
menos que antes. La reduccin de la anchura se ha efectuado correctamente, pues no se ha movido
ninguno de los bordes de la ventana hacia atrs. 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 ms que antes.
A continuacin se muestran los datos contenidos en un segmento TCP enviado por el servidor
TELNET que se encuentra en la mquina 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. Ntese que la misma deduccin habra
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.
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. Ntese 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 lnea (LF, Line Feed), que tienen en
pantalla el efecto de volver el cursor a la izquierda de la ventana y dejar una lnea en blanco. Si nos
fijamos en la ventana inicial que nos mostr el programa telnet nada ms 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 presentacin y un
prompt, hemos tecleado una interrogacin ? para ver qu comandos tenemos disponibles en el
router y esto es lo que se nos ha mostrado en pantalla:
Como consecuencia de la pulsacin 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 continuacin puede verse un listado de las mismas:
Cuntos octetos de datos enva el PC al servidor TELNET, segn lo visto en la ventana anterior?
Slo un octeto, el contenido en el segmento TCP de la trama con ID=21. Ese octeto ser sin duda el
carcter ? que hemos tecleado en la ventana del terminal virtual. Los otros dos segmentos que
enva el equipo 200.200.200.5 estn vacos.
Por qu estn vacos dos de los segmentos enviados por el cliente TELNET y mostrados en la
ventana anterior?
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 vacos 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 nmeros de secuencia que van desde el 3077943310 al 3077943845. En el
cuarto segmento se ve cmo 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 nmero 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. Ntese que si por algn motivo el cuarto segmento no llegase a su destino,
bastara 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 carcter ? que
llega devuelto al cliente desde el servidor debido a que ste ltimo est haciendo eco de todos los
caracteres que le enva el cliente.
A continuacin 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 carcter ? al servidor, como puede verse en la trama con ID=21?
Porque nosotros lo hemos tecleado. La misin del cliente es enviar al servidor TELNET todos los
caracteres tecleados en la mquina en la que est el cliente, de manera que sean interpretados por el
proceso de aplicacin 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 carcter ? solicit la
realizacin de un PUSH para provocar que ese dato se enviase inmediatamente, sin esperar a que
se llenase con ms datos el segmento en el que iba a ser transportado dicho carcter.
Por qu he enviado el servidor el carcter ? 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 enve el cliente. El cliente no pinta en pantalla los caracteres tecleados,
sino que muestra slo los caracteres que llegan desde el servidor. Esto provoca que a veces exista
un retraso apreciable entre el instante en que se teclea un carcter y el instante en que lo vemos
aparecer en pantalla. Con esta tcnica el usuario est siempre seguro de que los caracteres que est
tecleando le estn llegando el servidor TELNET. Adems esto permite el servidor pueda no mostrar
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 estn cerca de nosotros.
A continuacin 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 aplicacin que acta como usuario del servidor TELNET
quiere que se muestre en la ventana del usuario del cliente TELNET como resultado de haber
pulsado el carcter ?. Dicho carcter es un comando de peticin de ayuda, por lo que la respuesta
obtenida es un listado de los comandos que podemos utilizar junto con una breve descripcin. Ntese
que, como el equipo al que le hemos hecho TELNET es un router, los comandos disponible son
comandos los comandos tpicos 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 slo?
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. Ntese tambin que el primer
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 haba 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 continuacin 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 informacin 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 enven informacin especial
al margen de los datos normales.
Cul 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 continuacin 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 cdigo 253, que indica el deseo de implementar una
determinada opcin que no forma parte del funcionamiento por defecto del protocolo TELNET. La
opcin que el servidor quiere empezar a ejecutar en este caso es el ECHO, con cdigo 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 opcin.
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 cdigo 253, asociado a la opcin
ECHO, de cdigo 1. Cuando un comando DO, referido a una cierta opcin, es enviado como
respuesta a un comando WILL referido a esa misma opcin, se entiende que se est dando permiso
al que envi el WILL para que empiece a implementar dicha opcin. 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 opcin sin
contar con la otra parte?
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 opcin hay que avisarlo a la otra parte y esperar a que
nos de permiso. Tambin 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 opcin determinada?
Efectivamente, si deseamos que la otra parte ejecute una cierta opcin, podemos pedrselo 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 WONT. 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
aadir al funcionamiento por defecto del protocolo TELNET.
A continuacin se muestra el resultado que hemos obtenido en pantalla despus de teclear el
comando ping www.dte.us.es:
Qu equipo ha generado los mensajes ICMP de peticin de eco asociados a este comando PING?
El equipo 12.0.1.28 es el que enva 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 presentacin 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 continuacin:
Qu datos TELNET contiene la trama con ID=27?
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 enva 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 continuacin se muestra la segunda de las tramas capturadas en la red del PC relacionadas con el
comando PING que se ha tecleado:
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 carcter p que le envi el cliente en el segmento
anterior. Obsrvese que la trama ha Ethernet ha sido rellenada con 5 octetos de relleno para poder
alcanzar su longitud total mnima, que son 64 octetos. Tener que enviar un segmento casi vaco para
enviar slo una letra supone un gran desperdicio, pero a veces no hay ms remedio que hacerlo.
El ltimo segmento que enva el 12.0.1.28 al 200.200.200.5 en relacin al comando PING es el que
se muestra a continuacin:
Qu datos TELNET enva el servidor al cliente en el segmento de la trama con ID=89?

Enva la ltima lnea de resultados del comando PING, en la que aparecen las estadsticas de
tiempos. Tambin enva una lnea adicional con el prompt, que es route-server>.
El ltimo segmento que enva el cliente TELNET en relacin 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 tambin puede verse que el
analizador nos dice [20 bytes of data] para indicarnos que el datagrama IP slo contiene los 20
octetos que corresponden a la cabecera TCP de tamao mnimo. Se trata, por tanto de un segmento
TCP cuya nica misin es indicarle al 12.0.1.28 que al equipo 200.200.200.5 le han llegado todos los
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 tena 90 octetos
de datos y sus nmeros de secuencia iban desde el 3077944187 al 307794276, ambos inclusive, lo
cul nos confirma que efectivamente el segmento enviado por el cliente tena 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
conexin TCP que tena 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 envo del segmento contenido en la trama con ID=102?
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 conexin y que a partir de ahora no va a enviar ningn octeto ms al cliente.
Al pulsar el botn Aceptar de la ventana en la que el programa telnet nos deca que Se perdi la
conexn con el host, se han generado dos tramas ms, con ID=104 e ID=105 respectivamente. A
continuacin 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 botn Aceptar?

Tambin le ha enviado un segmento con el flag FIN al 12.0.1.28 para indicarle que desea finalizar la
conexin y que no desea enviar ms datos.
Es posible que una entidad TCP le siga enviando datos a su interlocutor despus 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 enva el flag FIN el que no puede enviar ms
datos. Cuando los dos extremos envan el flag FIN y ambos han recibido los respectivos
reconocimientos es cuando la conexin 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 funcin es reconocer la llegada de todos
los octetos con nmeros de secuencia anteriores al 3077944284. Efectivamente el ltimo nmero de
secuencia recibido por el 200.200.200.5 era el 3077944283, pero dicho nmero de secuencia iba
asociado al flag FIN. Es decir, el flag FIN es tratado como si fuera un octeto, pues se le asigna un
nmero 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 funcin es reconocer la llegada de todos
los octetos con nmeros de secuencia anteriores al 2221132. Se est reconociendo, por tanto, la
llegada del flag FIN, cuyo nmero de secuencia es el 2221131. Ntese que el flag FIN consume el
nmero de secuencia siguiente al ltimo nmero 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
conexin.

ejerciciosC2LIBRE PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ejerciciosC2LIBRE PDF

Încărcat de

Drepturi de autor:

Formate disponibile

htt

Solicita eco al host hasta ser interrumpido.

Haciendo ping a 172.26.0.3 con 15 bytes de datos:

Respuesta desde 172.26.0.3: bytes=15 tiempo=1ms TDV=128

Estadsticas de ping para 172.26.0.3:

Qu tipo de tarjeta de red tenemos instalada?

Pgina 1 del ejercicio1.doc

Pgina 2 del ejercicio1.doc

Con qu equipo queremos comprobar si es posible intercambiar paquetes IP?

Pgina 3 del ejercicio1.doc

Pgina 4 del ejercicio1.doc

Pgina 5 del ejercicio1.doc

Pgina 6 del ejercicio1.doc

Interfaz: 172.26.0.2 on Interface 0x1000002

Haciendo ping a 172.26.0.1 con 32 bytes de datos:

Respuesta desde 172.26.0.1: bytes=32 tiempo=1ms TDV=64

Estadsticas de ping para 172.26.0.1:

Interfaz: 172.26.0.2 on Interface 0x1000002

A qu equipo le hemos hecho PING?

Pgina 1 del ejercicio2.doc

Pgina 2 del ejercicio2.doc

Pgina 3 del ejercicio2.doc

Muestra y modifica las tablas de traduccin de direcciones IP a fsicas usadas

Muestra las entradas actuales de ARP preguntando por los

.... Aade una entrada esttica.

C:\WINDOWS>arp -s 172.26.0.1 00-20-EA-18-D1-51

Interfaz: 172.26.0.2 on Interface 0x1000002

Pgina 4 del ejercicio2.doc

C:\WINDOWS>arp -s 172.26.0.1 00-20-EA-18-D1-51

Interfaz: 172.26.0.2 on Interface 0x1000002

Haciendo ping a 172.26.0.1 con 32 bytes de datos:

Estadsticas de ping para 172.26.0.1:

Interfaz: 172.26.0.2 on Interface 0x1000002

A qu equipo de nuestra red le hemos hecho PING?

Pgina 1 del ejercicio3.doc

Pgina 2 del ejercicio3.doc

Nombre del host . . . . . . . . . . . : zenith.dte.us.es

NDIS 4.0 driver

Haciendo ping a 207.70.7.168 con 32 bytes de datos:

Respuesta desde 207.70.7.168: bytes=32 tiempo=195ms TDV=235

Estadsticas de ping para 207.70.7.168:

Interfaz: 150.214.141.181 on Interface 0x1000002

Cul es nuestra red?

Pgina 1 del ejercicio4.doc

Pgina 2 del ejercicio4.doc

Pgina 3 del ejercicio4.doc

Qu ventaja tiene esta forma de ver el listado de tramas sobre la anterior?

Pgina 4 del ejercicio4.doc

Nombre del host . . . . . . . . . . . : caracola

Realtek 8139-series PCI NIC

Interfaz: 172.26.0.2 on Interface 0x1000002

Haciendo ping a 12.0.1.28 con 32 bytes de datos:

Respuesta desde 12.0.1.28: bytes=32 tiempo=190ms TDV=237

Estadsticas de ping para 12.0.1.28:

Haciendo ping a 130.94.157.169 con 32 bytes de datos:

Respuesta desde 130.94.157.169: bytes=32 tiempo=195ms TDV=45

Estadsticas de ping para 130.94.157.169:

Haciendo ping a 207.70.7.168 con 32 bytes de datos:

Respuesta desde 207.70.7.168: bytes=32 tiempo=229ms TDV=235

Estadsticas de ping para 207.70.7.168:

Interfaz: 172.26.0.2 on Interface 0x1000002

Pgina 1 del ejercicio5.doc

Qu significa la columna Elapsed [sec] que aparece en el listado de tramas?