Escolar Documentos
Profissional Documentos
Cultura Documentos
Ejercicio 1:
do
En nuestro PC hemos abierto una ventana MS-DOS y hemos ejecutado los siguientes comandos:
C:\WINDOWS>ipconfig
AP ero u_
Configuracin IP de Windows 98
0 Ethernet adaptador :
Direccin IP . . . . . . . . . . . . . : 172.26.0.2
s
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
ra s f tig/
Opciones:
-t Solicita eco al host hasta ser interrumpido.
Para ver estadsticas y continuar: presione Ctrl-Inter.
Para interrumpir: presione Ctrl-C.
-a Resuelve direcciones a nombres de host.
-n cantidad Cantidad de solicitudes de eco a enviar.
ptu r lo f/i
-l tamao Tamao del bfer de envos.
-f No fragmentar el paquete.
-i TTL Tiempo de vida.
de ca tec n
-v TOSca rga _in Tipo de servicio.
-r cantidad Registrar la ruta para esta cantidad de saltos.
-s cantidad Registrar horarios para esta cantidad de saltos.
e
-j lista de hosts Ruta origen variable en la lista de host.
-k lista de hosts Ruta origen estricta en la lista de host.
-w tiempo Tiempo de espera agotado de respuesta en milisegundos.
de .e ra
C:\WINDOWS>ping -n 1 -l 15 172.26.0.3
Haciendo ping a 172.26.0.3 con 15 bytes de datos:
ra .us Ent
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?
p:/
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?
htt
S. Adems del router por defecto que ya conocemos, podran existir otros routers en nuestra red.
do
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
AP ero u_
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
s
de peticin de eco.
Qu significa el acrnimo ICMP?
Internet Control Message Protocol (Protocolo de Mensajes de Control de Internet).
ra s f tig/
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?
ptu r lo f/i
Datagrama IP o simplemente datagrama, si no es posible confundirse con otro tipo.
Contienen siempre los datagramas IP mensajes ICMP?
de ca tec n
No. Los datagramas IP pueden contener datos del protocolo ICMP pero tambin datos de otros
ca rga _in
muchos protocolos, siendo TCP y UDP unos de los ms habituales.
e
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?
de .e ra
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
ra .us Ent
bits 11. Lo que pasa es que Ethernet llama prembulo a esos 64 bits, mientras que IEEE 802.3 los
s
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.
s
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
ww
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?
/w
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
p:/
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
do
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
AP ero u_
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
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
/w
p:/
Con el equipo 172.26.0.3, que es la direccin IP que hemos usado en el comando PING.
do
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.
AP ero u_
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
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
ra s f tig/
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
ptu r lo f/i
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?
de ca tec n
La primera de las tramas, que es la que aparece resaltada y tiene un ID (identificador) de 0. Ntese
ca rga _in
que el analizador le asigna un ID a cada trama conforme las va capturando.
e
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?
de .e ra
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
s
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?
s
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
ww
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
/w
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
p:/
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
do
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
AP ero u_
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,
s
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).
ra s f tig/
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
ptu r lo f/i
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?
de ca tec n
No. Una cabecera IP sin opciones mide 20 octetos, que es justo lo que mide esta cabecera.
ca rga _in
Cmo sabe el analizador de protocolos que detrs de la cabecera IP viene un mensaje ICMP?
e
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?
de .e ra
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
ra .us Ent
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,
s
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
s
mismo, conteniendo menos de 46 octetos de datos. Si se le dice a la tarjeta que enve una trama
pa dte
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
.
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
/w
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.
p:/
do
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.
AP ero u_
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
s
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
ra s f tig/
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
ptu r lo f/i
destino.
Se ha fragmentado en algn momento el datagrama que hemos enviado?
de ca tec n
No. El motivo es que la MTU de la nica red que ha atravesado era una MTU suficientemente grande
ca rga _in
como para dar cabida al datagrama completo.
e
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
de .e ra
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
ra .us Ent
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.
s
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
s
de datos.
pa dte
Se la suele llamar Ethernet, a pesar de que sabemos que no son exactamente iguales.
ww
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
/w
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
p:/
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
do
En nuestro PC hemos abierto una ventana MS-DOS y hemos ejecutado los siguientes comandos:
C:\WINDOWS>ipconfig
AP ero u_
Configuracin IP de Windows 98
0 Ethernet adaptador :
Direccin IP . . . . . . . . . . . . . : 172.26.0.2
s
Interfaz: 172.26.0.2 on Interface 0x1000002
Direccin IP Direccin fsica Tipo
172.26.0.3 00-04-75-8a-77-29 dinmico
ra s f tig/
C:\WINDOWS>ping -n 1 172.26.0.1
Haciendo ping a 172.26.0.1 con 32 bytes de datos:
Respuesta desde 172.26.0.1: bytes=32 tiempo=1ms TDV=64
ptu r lo f/i
Estadsticas de ping para 172.26.0.1:
Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss),
Tiempos aproximados de recorrido redondo en milisegundos:
de ca tec n
mnimo = 1ms, mximo = 1ms, promedio = 1ms
ca rga _in
C:\WINDOWS>arp -a
e
Interfaz: 172.26.0.2 on Interface 0x1000002
Direccin IP Direccin fsica Tipo
172.26.0.1 00-20-ea-18-d1-51 dinmico
de .e ra
paquetes dirigidos a redes distintas de la nuestra. Sabemos esto porque el comando ipconfig nos
s
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.
.
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?
/w
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
p:/
anteriormente.
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.
.
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
do
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.
AP ero u_
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.
s
Campo Sender Hardware Address, 6 octetos.
Campo Sender Protocol Address, 4 octetos.
Campo Target Hardware Address, 6 octetos.
ra s f tig/
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?
ptu r lo f/i
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
de ca tec n
origen y destino, el campo Ethertype y el campo Frame Check Sequence, tenemos los 64 octetos
ca rga _in
que aparecen en la columna Size que se muestra en la parte superior de la ventana de captura.
e
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
de .e ra
carece de importancia.
Por qu llama el analizador Sender IP Address al campo Sender Protocol Address del paquete
ARP que nos est mostrando?
ra .us Ent
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
s
destinada al equipo 172.26.0.1, por lo que slo el equipo 172.26.0.1 ha respondido a nuestra peticin
pa dte
A veces no podemos acceder al exterior de nuestra red y queremos averiguar la causa. Si al hacerle
ww
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
/w
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.
p:/
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
htt
nueva al haber averiguado la direccin MAC del equipo con direccin IP 172.26.0.1.
do
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
AP ero u_
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
s
la direccin MAC 0020EA18D151, haciendo uso del comando arp s de MS-DOS.
C:\WINDOWS>arp
ra s f tig/
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]
ptu r lo f/i
ARP -a [dir_inet] [-N dir_if]
-a Muestra las entradas actuales de ARP preguntando por los
de ca tec n
datos del protocolo. Si se especifica dir_inet, se muestran
ca rga _in
las direcciones IP y Fsica slo para el equipo
especificado. Cuando ARP se utiliza en ms de una interfaz de
e
red, entonces se muestran entradas para cada tabla ARP.
-g Lo mismo que -a.
dir_inet Especifica una direccin internet.
-N dir_if Muestra las entradas de ARP para las interfaces de red
de .e ra
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
ww
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.
/w
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
p:/
diferente a la nuestra, pues no les llegaran las tramas conteniendo las peticiones ARP.
do
En nuestro PC hemos abierto una ventana MS-DOS y hemos ejecutado los siguientes comandos:
C:\WINDOWS>ipconfig
AP ero u_
Configuracin IP de Windows 98
0 Ethernet adaptador :
Direccin IP . . . . . . . . . . . . . : 172.26.0.2
s
C:\WINDOWS>arp a
Interfaz: 172.26.0.2 on Interface 0x1000002
Direccin IP Direccin fsica Tipo
ra s f tig/
172.26.0.1 00-20-ea-18-d1-51 esttico
C:\WINDOWS>ping 172.26.0.1
Haciendo ping a 172.26.0.1 con 32 bytes de datos:
ptu r lo f/i
Respuesta desde 172.26.0.1: bytes=32 tiempo=2ms TDV=64
Respuesta desde 172.26.0.1: bytes=32 tiempo<10ms TDV=64
Respuesta desde 172.26.0.1: bytes=32 tiempo<10ms TDV=64
de ca tec n
Respuesta desde 172.26.0.1:
ca rga _in bytes=32 tiempo<10ms TDV=64
Estadsticas de ping para 172.26.0.1:
e
Paquetes: enviados = 4, Recibidos = 4, perdidos = 0 (0% loss),
Tiempos aproximados de recorrido redondo en milisegundos:
mnimo = 0ms, mximo = 2ms, promedio = 0ms
de .e ra
C:\WINDOWS>arp a
Interfaz: 172.26.0.2 on Interface 0x1000002
Direccin IP Direccin fsica Tipo
ra .us Ent
El equipo 172.26.0.1 forma parte de nuestra red, por lo que es accesible directamente envindole una
pa dte
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
ww
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
/w
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.
p:/
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
ww
En nuestro PC hemos abierto una ventana MS-DOS y hemos ejecutado los siguientes comandos:
AP ero u_
C:\WINDOWS>ipconfig /all
Configuracin IP de Windows 98
s
Enrutamiento IP activado . . . . . . . : No
WINS Proxy activado . . . . . . . . . : No
Resolucin NetBIOS usa DNS . . . . . . : S
0 Ethernet adaptador :
ra s f tig/
Descripcin . . . . . . . . . . . . . : NDIS 4.0 driver
Direccin fsica . . . . . . . . . . . : 00-E0-7D-7A-5A-94
DHCP activado . . . . . . . . . . . . : No
Direccin IP . . . . . . . . . . . . . : 150.214.141.181
Mscara de subred . . . . . . . . . . : 255.255.255.0
Puerta de enlace predeterminada . . . : 150.214.141.1
ptu r lo f/i
Servidor WINS primario . . . . . . . :
Servidor WINS secundario . . . . . . . :
Permiso obtenido . . . . . . . . . . . :
de ca tec n
Permiso caduca . . . . . . . . .
ca rga _in . . . :
C:\WINDOWS>arp -a
e
No se encontraron entradas ARP
C:\WINDOWS>ping -n 2 -i 20 207.70.7.168
de .e ra
C:\WINDOWS>arp -a
C:\WINDOWS>
Porque el host destino de los PINGs est fuera de nuestra red, lo cual nos obliga a enviar los
pa dte
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.
ww
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
AP ero u_
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?
s
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
ra s f tig/
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.
ptu r lo f/i
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
de ca tec n
ca rga _in
para poder enrutar correctamente un datagrama.
Cul es el tiempo de vida de los datagramas que hemos recibido?
e
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).
de .e ra
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
ra .us Ent
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,
s
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
s
atravesar 19 routers y llegar a su destino con un tiempo de vida de 1. No es posible que el paquete
pa dte
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
.
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
Tiene la ventaja de que ahora podemos ver rpidamente las direcciones IP origen y destino de los
ww
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
/w
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?
p:/
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
do
En nuestro PC hemos abierto una ventana MS-DOS y hemos ejecutado los siguientes comandos:
C:\WINDOWS>ipconfig /all
AP ero u_
Configuracin IP de Windows 98
Nombre del host . . . . . . . . . . . : caracola
Servidores DNS . . . . . . . . . . . . : 193.152.63.197
195.235.113.3
s
0 Ethernet adaptador :
Descripcin . . . . . . . . . . . . . : Realtek 8139-series PCI NIC
ra s f tig/
Direccin fsica . . . . . . . . . . . : 00-C0-26-26-0D-14
DHCP activado . . . . . . . . . . . . : S
Direccin IP . . . . . . . . . . . . . : 172.26.0.2
Mscara de subred . . . . . . . . . . : 255.255.0.0
Puerta de enlace predeterminada . . . : 172.26.0.1
Servidor DHCP . . . . . . . . . . . . : 172.26.0.1
ptu r lo f/i
Servidor WINS primario . . . . . . . :
Servidor WINS secundario . . . . . . . :
Permiso obtenido . . . . . . . . . . . : 15 04 02 22:16:38
de ca tec n
Permiso caduca . . . . . . . . .
ca rga _in . . . :
C:\WINDOWS>arp -a
e
Interfaz: 172.26.0.2 on Interface 0x1000002
Direccin IP Direccin fsica Tipo
172.26.0.1 00-20-ea-18-d1-51 dinmico
de .e ra
C:\WINDOWS>ping -n 1 -i 25 12.0.1.28
Haciendo ping a 12.0.1.28 con 32 bytes de datos:
ra .us Ent
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
do
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
AP ero u_
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.
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
/
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?
s
No. Aunque en esta ventana de captura no se est viendo, la IP destino de los paquetes que hay
pa dte
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
ww
el listado de tramas aparecen ahora las direcciones de red en lugar de las MAC.
/w
p:/
htt
do
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,
AP ero u_
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?
s
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
ra s f tig/
salida y llegada de las tramas.
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
Cmo sabe el analizador que es correcto el campo Checksum del mensaje ICMP de esta trama?
pa dte
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,
ww
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.
/w
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).
p:/
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
htt
Type debe ser 0 (respuesta de eco) y que, como es lgico, el campo Checksum deber ser
calculado nuevamente.
do
Observe la siguiente red de ordenadores:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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
ww
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
/w
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
p:/
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.
htt
En el PC_A0_55 se ha abierto una sesin MS-DOS y se han ejecutado los comandos que aparecen
listados a continuacin:
do
Configuracin IP de Windows 98
0 Ethernet adaptador :
Direccin IP . . . . . . . . . . . . . : 192.5.5.55
AP ero u_
Mscara de subred . . . . . . . . . . : 255.255.255.0
Puerta de enlace predeterminada . . . : 192.5.5.1
C:\WINDOWS>arp a
Interfaz: 192.5.5.55 on Interface 0x1000002
s
Haciendo ping a 210.93.105.13 con 32 bytes de datos:
Tiempo de espera agotado.
ra s f tig/
Estadsticas de ping para 210.93.105.13:
Paquetes: enviados = 1, Recibidos = 0, perdidos = 1 (100% loss),
Tiempos aproximados de recorrido redondo en milisegundos:
Mnimo = 0ms, mximo = 0ms, promedio = 0ms
ptu r lo f/i
C:\WINDOWS>arp a
Interfaz: 192.5.5.55 on Interface 0x1000002
de ca tec n
Direccin IP
ca rga _in Direccin fsica Tipo
192.5.5.1 00-10-7b-81-ae-26 dinmico
e
C:\WINDOWS>
Concuerda el resultado del comando ipconfig con los datos de la red de la figura?
de .e ra
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
s
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
s
cuatro routers y tres redes intermedias (sin contar las redes origen y destino), por lo que si
pa dte
La otra direccin IP que aparece en la cach ARP es la del router por defecto de nuestra red.
ww
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
/w
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
do
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
AP ero u_
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)?
s
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
ra s f tig/
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
ptu r lo f/i
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:
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
/w
p:/
htt
do
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
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
s
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
s
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.
p:/
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?
htt
do
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
AP ero u_
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
s
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
ra s f tig/
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?
ptu r lo f/i
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
de ca tec n
ca rga _in
a confusiones es conveniente ponerlo todo a 0 o todo a 1.
e
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
de .e ra
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?
ra .us Ent
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
s
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
s
enviarlos. El Router_D al recibir el paquete con la IP destino 210.93.105.13, la cual forma parte de
pa dte
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
ww
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
/w
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?
htt
do
Observe la siguiente red de ordenadores:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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
ww
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
/w
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
p:/
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
htt
listados a continuacin:
do
Configuracin IP de Windows 98
0 Ethernet adaptador :
Direccin IP . . . . . . . . . . . . . : 192.5.5.55
AP ero u_
Mscara de subred . . . . . . . . . . : 255.255.255.0
Puerta de enlace predeterminada . . . : 192.5.5.1
C:\WINDOWS>ping
Uso: ping [-t] [-a] [-n cantidad] [-l tamao] [-f] [-i TTL] [-v TOS]
s
Para ver estadsticas y continuar: presione Ctrl-Inter.
Para interrumpir: presione Ctrl-C.
-a Resuelve direcciones a nombres de host.
-n cantidad Cantidad de solicitudes de eco a enviar.
ra s f tig/
-l tamao Tamao del bfer de envos.
-f No fragmentar el paquete.
-i TTL Tiempo de vida.
-v TOS Tipo de servicio.
-r cantidad Registrar la ruta para esta cantidad de saltos.
-s cantidad Registrar horarios para esta cantidad de saltos.
ptu r lo f/i
-j lista de hosts Ruta origen variable en la lista de host.
-k lista de hosts Ruta origen estricta en la lista de host.
-w tiempo Tiempo de espera agotado de respuesta en milisegundos.
de ca tec n
ca rga _in
C:\WINDOWS>ping -n 3 -l 22 -i 5 -f -v 64 -w 5000 210.93.105.13
e
Haciendo ping a 210.93.105.13 con 22 bytes de datos:
Tiempo de espera agotado.
Respuesta desde 210.93.105.13: bytes=22 tiempo=55ms TDV=124
de .e ra
C:\WINDOWS>arp a
p:/
C:\WINDOWS>
do
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
AP ero u_
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
s
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.
ra s f tig/
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, el cual se ha
ptu r lo f/i
almacenado en el archivo fichero55.cap:
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s /
Y 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:
s
pa dte
.
ww
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.
/w
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
htt
descartado un paquete por ese motivo. Esto puede ser sntoma de un problema o puede ser algo
do
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
AP ero u_
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
de .e ra
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,
ww
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
/w
ra s f tig/
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
ptu r lo f/i
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
de ca tec n
ca rga _in
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
e
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
de .e ra
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
ra .us Ent
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
s
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
s
ordenador hasta que pase un cierto tiempo sin ser utilizada, en cuyo caso desaparecer de la cach.
pa dte
lo cul no es lgico. No parece que sea la trama que enva el router despus de la peticin ARP la
ww
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
/w
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
p:/
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
do
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,
AP ero u_
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
s
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
ra s f tig/
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.
ptu r lo f/i
Cules son los diez primeros caracteres de los datos opcionales del primer mensaje ICMP de
peticin de eco enviado por PC_A0_55?
de ca tec n
ca rga _in
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
e
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
de .e ra
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
ra .us Ent
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?
s
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?
s
En la red del PC_A0_55 se observan dos tramas, una de 71 octetos y otra de 101 octetos, las
pa dte
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
ww
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
/w
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.
p:/
do
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:
AP ero u_
111 - Network Control
110 - Internetwork Control
101 - CRITIC/ECP
100 - Flash Override
s
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
ra s f tig/
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
ptu r lo f/i
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 ca tec n
ca rga _in
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,
e
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-To-
de .e ra
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
s
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.
s
A quin iba destinado el datagrama IP descartado a causa del TTL expirado del que se informa en el
pa dte
que se ha descartado?
ww
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
/w
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
p:/
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
do
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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?
ww
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
/w
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
p:/
antes que el otro. Un tiempo de vida de 3 hace que el mensaje slo pueda atravesar 2 routers.
do
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s /
el segundo comando PING genera mensajes ICMP con 54 octetos de datos opcionales.
ww
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
/w
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
p:/
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
do
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.
AP ero u_
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
s
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,
ra s f tig/
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
ptu r lo f/i
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
de ca tec n
ca rga _in
que se puedan detectar mediante esta sencilla tcnica de deteccin de errores.
e
A continuacin se muestra la trama con ID=9 contenida en el archivo fichero55.cap:
de .e ra
ra .us Ent
s s /
pa dte
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
ww
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
/w
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.
p:/
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
do
Observe la siguiente red de ordenadores:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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
ww
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
/w
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
p:/
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
htt
listados a continuacin:
do
Configuracin IP de Windows 98
0 Ethernet adaptador :
Direccin IP . . . . . . . . . . . . . : 192.5.5.55
AP ero u_
Mscara de subred . . . . . . . . . . : 255.255.255.0
Puerta de enlace predeterminada . . . : 192.5.5.1
C:\WINDOWS>arp a
Interfaz: 192.5.5.55 on Interface 0x1000002
s
Haciendo ping a 219.17.100.16 con 172 bytes de datos:
Respuesta desde 219.17.100.16: bytes=172 tiempo=64ms TDV=126
ra s f tig/
Estadsticas de ping para 219.17.100.16:
Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss),
Tiempos aproximados de recorrido redondo en milisegundos:
mnimo = 64ms, mximo = 64ms, promedio = 64ms
C:\WINDOWS>ping -n 1 -l 173 219.17.100.16
ptu r lo f/i
Haciendo ping a 219.17.100.16 con 173 bytes de datos:
de ca tec n
Respuesta desde 219.17.100.16: bytes=173 tiempo=73ms TDV=126
ca rga _in
Estadsticas de ping para 219.17.100.16:
e
Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss),
Tiempos aproximados de recorrido redondo en milisegundos:
mnimo = 73ms, mximo = 73ms, promedio = 73ms
de .e ra
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
ww
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.
/w
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.
p:/
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_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
Y a continuacin puede verse la ventana del analizador correspondiente al trfico capturado en la red
del ordenador PC_B_16, el cual se ha almacenado en el archivo fichero16.cap:
s
pa dte
.
ww
/w
Las dos ventanas anteriores estn mostrando en el listado de tramas informacin acerca del instante
p:/
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
htt
do
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
AP ero u_
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,
s
as que podemos decir que las todas las tramas emitidas por PC_A0_55 tienen una tamao acorde
al contenido que transportan.
ra s f tig/
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
ptu r lo f/i
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
de ca tec n
ca rga _in
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
e
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
de .e ra
por el PC_A0_55.
Cuntas tramas le enva el Router_A al PC_A0_55?
Le enva 5 tramas.
ra .us Ent
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?
s
No. Ya hemos comentado antes que la primera trama que enva PC_A0_55 contiene un datagrama
pa dte
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
ww
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.
/w
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
p:/
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
htt
IP emitido por el primer comando PING tiene 200 octetos de longitud total porque 200 es la suma de
do
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.
AP ero u_
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.
s
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
ra s f tig/
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
ptu r lo f/i
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
de ca tec n
ca rga _in
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
e
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
de .e ra
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.
ra .us Ent
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
s
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
s
datagrama se fragmenta es que sus datos son repartidos en varios datagramas llamados fragmentos.
pa dte
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
ww
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.
/w
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?
p:/
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,
htt
do
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s /
Dnde estn los dems fragmentos que derivan del mismo datagrama original del que deriva el
pa dte
fragmento puede verse que se trata del primer fragmento, pues el campo Fragment Offset vale cero
ww
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
/w
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
p:/
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.
do
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
AP ero u_
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
s
(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
ra s f tig/
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.
ptu r lo f/i
A continuacin se muestra el contenido de la trama con ID=2 del archivo fichero55.cap:
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
/w
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
p:/
do
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.
AP ero u_
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
s
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
ra s f tig/
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.
ptu r lo f/i
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
de ca tec n
ca rga _in
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
e
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
de .e ra
nicamente el trfico generado en la red del PC_A0_55 como consecuencia de la ejecucin del
s
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.
/w
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),
p:/
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
do
Observe la siguiente red de ordenadores:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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
ww
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
/w
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
p:/
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_DE_13 se ha abierto una sesin MS-DOS y se han ejecutado los comandos que aparecen
htt
listados a continuacin:
do
Configuracin IP de Windows 98
0 Ethernet adaptador :
Direccin IP . . . . . . . . . . . . . : 210.93.105.13
AP ero u_
Mscara de subred . . . . . . . . . . : 255.255.255.0
Puerta de enlace predeterminada . . . : 210.93.105.1
s
Tiempos aproximados de recorrido redondo en milisegundos:
mnimo = 98ms, mximo = 98ms, promedio = 98ms
C:\WINDOWS>ping -n 1 -l 10 -f 223.8.151.10
ra s f tig/
Haciendo ping a 223.8.151.10 con 10 bytes de datos:
Respuesta desde 223.8.151.10: bytes=10 tiempo=17ms TDV=126
ptu r lo f/i
Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss),
Tiempos aproximados de recorrido redondo en milisegundos:
mnimo = 17ms, mximo = 17ms, promedio = 17ms
de ca tec n
ca rga _in
C:\WINDOWS>ping -n 1 -l 233 223.8.151.10
e
Haciendo ping a 223.8.151.10 con 233 bytes de datos:
Respuesta desde 223.8.151.10: bytes=233 tiempo=106ms TDV=126
de .e ra
C:\WINDOWS>
ww
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?
p:/
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
htt
el mensaje ICMP de peticin de eco no pudo llegar al necesitar fragmentarse y habrselo prohibido.
do
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
almacenado en el archivo fichero13.cap:
AP ero u_
*.C ich com
s
ra s f tig/
Y a continuacin puede verse la ventana del analizador correspondiente al trfico capturado en la red
del ordenador PC_C_10, el cual se ha almacenado en el archivo fichero10.cap:
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
nicamente estn mostrando el listado con de tramas capturadas en cada una de las redes. Para
s
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.
s
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
ww
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
/w
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
p:/
la red Ethernet a la que est conectado el PC_C_10 sin necesidad de ser fragmentados.
listado de tramas se vean las direcciones de red junto con informacin temporal:
do
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
AP ero u_
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
s
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.
ra s f tig/
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
ptu r lo f/i
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
de ca tec n
ca rga _in
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?
e
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
de .e ra
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.
ra .us Ent
listado de tramas se vean las direcciones de red junto con informacin temporal:
s s
pa dte
Unicamente con el PC_DE_13, segn se puede comprobar en el listado de tramas tras analizar las
ww
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
/w
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,
p:/
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.
htt
Por qu no se aprecia en la red del PC_C_10 el efecto del cuarto y del quinto comando PING?
do
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
AP ero u_
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
s
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
ra s f tig/
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
ptu r lo f/i
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
de ca tec n
ca rga _in
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.
e
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
de .e ra
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
ra .us Ent
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
s
Se observa que el campo Unused ocupa ahora solo dos octetos y aparece un nuevo campo Next-
pa dte
Hop 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
ww
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.
/w
datagrama, al no necesitar ser fragmentado, atravesar en ambos casos dicha red sin ninguna clase
de problemas.
htt
do
Observe la siguiente red de ordenadores:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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
ww
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
/w
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
p:/
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.
htt
En el PC_A0_55 se ha abierto una sesin MS-DOS y se han ejecutado los comandos que aparecen
listados a continuacin:
do
Configuracin IP de Windows 98
0 Ethernet adaptador :
Direccin IP . . . . . . . . . . . . . : 192.5.5.55
AP ero u_
Mscara de subred . . . . . . . . . . : 255.255.255.0
Puerta de enlace predeterminada . . . : 192.5.5.1
C:\WINDOWS>arp a
Interfaz: 192.5.5.55 on Interface 0x1000002
s
Haciendo ping a 210.93.105.13 con 1000 bytes de datos:
Respuesta desde 210.93.105.13: bytes=1000 tiempo=514ms TDV=124
ra s f tig/
Estadsticas de ping para 210.93.105.13:
Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss),
Tiempos aproximados de recorrido redondo en milisegundos:
Mnimo = 514ms, mximo = 514ms, promedio = 514ms
C:\WINDOWS>
ptu r lo f/i
Se ha obtenido respuesta por parte del PC al que se le ha hecho PING?
S.
de ca tec n
ca rga _in
Cuntas redes ha atravesado el datagrama que hemos enviado con el comando PING?
e
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
de .e ra
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.
/
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
s
tramas vistas por el PC_DE_13 en su red. A continuacin se muestra una ventana de un analizador
pa dte
do
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
AP ero u_
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?
s
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:
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s /
longitud total encapsulado en una trama de 86 octetos de tamao. Todo esto concuerda, pues
pa dte
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?
/w
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
p:/
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
htt
han debido ser fragmentados nuevamente en, al menos, otro router ms.
do
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
AP ero u_
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
s
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
ra s f tig/
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
ptu r lo f/i
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
de ca tec n
ca rga _in
fragmento de 148 octetos de longitud total (128 octetos de datos). Al pasar por el Router_C los
e
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
de .e ra
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.
ra .us Ent
A continuacin se muestra parte de la cabecera IP del datagrama contenido de la trama con ID=5 del
/
fichero13.cap:
s s
pa dte
.
ww
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
/w
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
p:/
contenida en cada uno de los fragmentos, la cual sirve para saber qu lugar ocupa cada uno de ellos.
do
Observe la siguiente red de ordenadores:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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.
listado a continuacin:
ww
C:\WINDOWS>ping 210.93.105.2
Haciendo ping a 210.93.105.2 con 32 bytes de datos:
/w
C:\WINDOWS>
do
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.
AP ero u_
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
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
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
p:/
do
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,
AP ero u_
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
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
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?
htt
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
do
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
AP ero u_
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
s
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.
ra s f tig/
A continuacin se muestra parte del contenido del primer mensaje ICMP que le llega al Router_E:
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s /
A continuacin se muestra parte del contenido del segundo mensaje ICMP que le llega al Router_E:
s
pa dte
.
ww
/w
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?
p:/
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
do
Observe la siguiente red de ordenadores:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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
ww
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
/w
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
p:/
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.
dicho PC. A continuacin se muestra una ventana de captura en la que puede verse dicho trfico:
do
C:\WINDOWS>ipconfig
Configuracin IP de Windows 98
AP ero u_
0 Ethernet adaptador :
Direccin IP . . . . . . . . . . . . . : 192.5.5.55
Mscara de subred . . . . . . . . . . : 255.255.255.0
Puerta de enlace predeterminada . . . : 192.5.5.1
C:\WINDOWS>ping 200.200.200.200
s
Haciendo ping a 200.200.200.200 con 32 bytes de datos:
Respuesta desde 192.5.5.1: Host de destino inaccesible.
Respuesta desde 192.5.5.1: Host de destino inaccesible.
ra s f tig/
Respuesta desde 192.5.5.1: Host de destino inaccesible.
Respuesta desde 192.5.5.1: Host de destino inaccesible.
ptu r lo f/i
mnimo = 0ms, mximo = 0ms, promedio = 0ms
C:\WINDOWS>arp -a
de ca tec n
ca rga _in
Interfaz: 192.5.5.55 on Interface 0x1000002
Direccin IP Direccin fsica Tipo
e
192.5.5.1 00-10-7b-81-ae-26 dinmico
C:\WINDOWS>
de .e ra
De que equipo provienen los mensajes ICMP que han llegado al PC_A0_55?
s
paquete cuya IP destino es la 200.200.200.200, adjuntndonos adems una copia de parte del
pa dte
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).
ww
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.
/w
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
p:/
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
htt
son muy importantes, pues son los datos opcionales del mensaje ICMP de peticin de eco.
do
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
se ha dado cuenta de que deba descartarlo pues su destino no formaba parte de ninguna de las
ww
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.
p:/
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
do
Observe la siguiente red de ordenadores:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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
ww
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
/w
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
p:/
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.
htt
do
Haciendo ping a 200.200.200.200 con 32 bytes de datos:
Respuesta desde 201.100.11.2: Host de destino inaccesible.
Respuesta desde 201.100.11.2: Host de destino inaccesible.
Respuesta desde 201.100.11.2: Host de destino inaccesible.
AP ero u_
Respuesta desde 201.100.11.2: Host de destino inaccesible.
Estadsticas de ping para 200.200.200.200:
Paquetes: enviados = 4, Recibidos = 4, perdidos = 0 (0% loss),
Tiempos aproximados de recorrido redondo en milisegundos:
mnimo = 0ms, mximo = 0ms, promedio = 0ms
s
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.
ra s f tig/
A continuacin se muestra el trfico capturado en la red del PC_A0_55 como consecuencia de la
ejecucin del comando PING:
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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
ww
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
p:/
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?
htt
Con 255, pues llegan al PC_A0_55 con un TTL de 254 y slo han atravesado un router.
do
Observe la siguiente red de ordenadores:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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
ww
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
/w
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
p:/
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.
htt
do
Haciendo ping a 200.200.200.200 con 32 bytes de datos:
Respuesta desde 210.93.105.2: El tiempo de vida caduc en trnsito.
Estadsticas de ping para 200.200.200.200:
AP ero u_
Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss),
Tiempos aproximados de recorrido redondo en milisegundos:
mnimo = 0ms, mximo = 0ms, promedio = 0ms
C:\WINDOWS>
s
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,
ra s f tig/
as que seguramente los routers tendrn una ruta por defecto, que es la que habr seguido ste
paquete.
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
/w
p:/
htt
do
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.
AP ero u_
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.
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s /
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?
s
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:
/w
p:/
htt
do
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.
AP ero u_
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:
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:
s
pa dte
.
ww
/w
p:/
este campo el Checksum debe recalcularse tambin. El resto del datagrama no ha sufrido cambios.
do
Observe la siguiente red de ordenadores:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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
ww
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
/w
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
p:/
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.
htt
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.
do
C:\WINDOWS>ipconfig
Configuracin IP de Windows 98
AP ero u_
0 Ethernet adaptador :
Direccin IP . . . . . . . . . . . . . : 210.93.105.13
Mscara de subred . . . . . . . . . . : 255.255.255.0
s
Direccin de red Mscara de red Puerta de enlace Interfaz Mtrica
0.0.0.0 0.0.0.0 210.93.105.1 210.93.105.13 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
ra s f tig/
210.93.105.0 255.255.255.0 210.93.105.13 210.93.105.13 1
210.93.105.13 255.255.255.255 127.0.0.1 127.0.0.1 1
210.93.105.255 255.255.255.255 210.93.105.13 210.93.105.13 1
224.0.0.0 224.0.0.0 210.93.105.13 210.93.105.13 1
255.255.255.255 255.255.255.255 210.93.105.13 210.93.105.13 1
C:\WINDOWS>arp -a
ptu r lo f/i
No se encontraron entradas ARP
C:\WINDOWS>ping -n 1 -l 34 192.5.5.55
de ca tec n
ca rga _in
Haciendo ping a 192.5.5.55 con 34 bytes de datos:
e
Respuesta desde 192.5.5.55: bytes=34 tiempo=31ms TDV=126
Estadsticas de ping para 192.5.5.55:
Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss),
de .e ra
Rutas activas:
/
C:\WINDOWS>arp -a
Interfaz: 210.93.105.13 on Interface 0x1000002
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
/w
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,
p:/
0.0.0.0 muestra como puerta de enlace asociada la direccin IP 210.93.105.1, del Router_D.
do
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.
AP ero u_
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.
s
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?
ra s f tig/
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?
ptu r lo f/i
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 ca tec n
ca rga _in
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?
e
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
de .e ra
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
ra .us Ent
ejecutaron los comandos PING, segn se muestra en la salida en pantalla de dichos comandos.
s
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
htt
peticin realizada por el PC_DE_13 y resulta que la direccin MAC Source (origen) de dicha trama
do
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
AP ero u_
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?
s
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?
ra s f tig/
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.
ptu r lo f/i
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.
de ca tec n
ca rga _in
A continuacin se muestra parte del contenido de la trama que contiene el primer mensaje ICMP de
e
peticin de eco que se ha capturado en la red del PC_DE_13:
de .e ra
ra .us Ent
s s /
pa dte
A continuacin se muestra parte del contenido de la trama que contiene el segundo mensaje ICMP de
peticin de eco que se ha capturado en la red del PC_DE_13:
.
ww
/w
p:/
htt
Muestran el mismo mensaje ICMP de peticin de eco las dos ventanas anteriores?
do
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
AP ero u_
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:
cuenta de que se trata del primer datagrama enviado por el PC_DE_13 al PC_A0_55. Por otra
do
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.
AP ero u_
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
A continuacin se muestra parte del contenido de la trama que contiene el tercer mensaje ICMP de
peticin de eco que se ha capturado en la red del PC_DE_13:
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
pues tiene 54 octetos de datos opcionales. En el momento de ejecutar el segundo comando PING, el
ww
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,
/w
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
htt
ejecucin del primer PING la cach ARP estaba vaca, mientras que despus de ejecutarse los dos
do
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.
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
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
ra .us Ent
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
s
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
s
paquete contenido en la trama con ID=4 del fichero55.cap tendr un TTL de valor 30.
pa dte
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
.
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.
/w
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
htt
do
Observe la siguiente red de ordenadores:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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
ww
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
/w
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
p:/
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.
htt
Ntese que la red tiene rutas redundantes, de forma que puede existir ms de un camino para que un
paquete llegue ir a un determinado destino. Los routers usan RIP como protocolo de enrutamiento.
do
C:\WINDOWS>ping
Uso: ping [-t] [-a] [-n cantidad] [-l tamao] [-f] [-i TTL] [-v TOS]
AP ero u_
[-r cantidad] [-s cantidad] [[-j lista de host] | [-k lista de host]]
[-w Tiempo de espera agotado] lista de destino
Opciones:
-t Solicita eco al host hasta ser interrumpido.
s
-i TTL Tiempo de vida.
-v TOS Tipo de servicio.
-r cantidad Registrar la ruta para esta cantidad de saltos.
ra s f tig/
-s cantidad Registrar horarios para esta cantidad de saltos.
-j lista de hosts Ruta origen variable en la lista de host.
-k lista de hosts Ruta origen estricta en la lista de host.
-w tiempo Tiempo de espera agotado de respuesta en milisegundos.
C:\WINDOWS>ipconfig
ptu r lo f/i
Configuracin IP de Windows 98
0 Ethernet adaptador :
de ca tec n
ca rga _in
Direccin IP . . . . . . . . . . . . . : 223.8.151.10
Mscara de subred . . . . . . . . . . : 255.255.255.0
e
Puerta de enlace predeterminada . . . : 223.8.151.1
C:\WINDOWS>ping -n 1 -k 223.8.151.1 199.6.13.1 201.100.11.1 202.2.2.1 210.93.105.13
de .e ra
201.100.11.1 ->
199.6.13.1 ->
/
223.8.151.1
s
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?
s
En la red del PC_DE_13 hay dos routers. El Router_D, que tiene la interfaz Ethernet e0 en dicha
pa dte
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
ww
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
p:/
AP ero u_
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.
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
/w
p:/
do
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
AP ero u_
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
s
Length valen 0xA (hexadecimal). Quiere esto decir que la cabecera mide 10 palabras de 32 bits, o lo
que es lo mismo, 40 octetos.
ra s f tig/
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.
ptu r lo f/i
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
de ca tec n
ca rga _in
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
e
en la RFC791, correspondiente a IP, en su pgina 19, tiene la siguiente estructura:
de .e ra
que define de qu tipo de opcin se trata. Por ejemplo: 0=End of Option List, 1=No operacin,
pa dte
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,
ww
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
/w
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
do
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.
AP ero u_
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
s
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
ra s f tig/
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
ptu r lo f/i
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
de ca tec n
datagrama.
ca rga _in
Qu va a hacer el Router_B cuando reciba el datagrama IP con la opcin SSRR que le ha enviado
e
el Router_D?
Actuar de forma anloga a como lo ha hecho el Router_B. Ver que aunque la Destination
de .e ra
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
ra .us Ent
A continuacin se muestra un trozo del paquete IP conteniendo un mensaje ICMP de peticin de eco
s
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
htt
nadie ms?
do
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.
AP ero u_
A continuacin se muestra parte del contenido de la trama enviada por PC_DE_13:
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
ra .us Ent
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
s
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
htt
do
Observe la siguiente red de ordenadores:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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
ww
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
/w
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
p:/
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.
Ntese que la red tiene rutas redundantes, de forma que puede existir ms de un camino para que un
htt
paquete llegue ir a un determinado destino. Los routers usan RIP como protocolo de enrutamiento.
do
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
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
de ca tec n
ca rga _in
tramas. El equipo cuya direccin MAC es la 00D058ADCD11, y el equipo cuya direccin MAC es la
e
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.
de .e ra
A continuacin se muestra el listado de tramas capturadas pero de forma que muestre informacin
s
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
do
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
AP ero u_
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
s
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
ra s f tig/
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:
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
Qu equipos van a procesar el contenido del segmento UDP (datagrama UDP) que se muestra en la
/w
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
p:/
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
htt
dicho puerto (que es el puerto asociado a RIP) y por tanto ser el nico que procesar su contenido.
do
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)
AP ero u_
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
s
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
ra s f tig/
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?
ptu r lo f/i
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?
de ca tec n
ca rga _in
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
e
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.
de .e ra
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
htt
do
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AP ero u_
| address family identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IPv4 address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
s
Entre parntesis aparecen las longitudes de cada campo en octetos. Slo hay tres campos que no
ra s f tig/
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?
ptu r lo f/i
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.
de ca tec n
ca rga _in
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?
e
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
de .e ra
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.
ra .us Ent
/
mensaje RIP?
do
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
AP ero u_
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?
s
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
ra s f tig/
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?
ptu r lo f/i
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
de ca tec n
ca rga _in
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
e
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
de .e ra
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
ra .us Ent
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
s
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
s
Router_E#
do
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
AP ero u_
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?
s
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
ra s f tig/
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?
ptu r lo f/i
Para las redes aprendidas mediante RIP, el Router_E muestra una lnea de este estilo:
de ca tec n
R
ca rga _in
219.17.100.0/24 [120/2] via 202.2.2.2, 00:00:04, Serial0
e
La R inicial significa que ha obtenido la informacin mediante RIP. A continuacin aparece el nombre
de .e ra
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
ra .us Ent
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
s
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:
s
Son redes a las se puede llegar de forma ptima saliendo del Router_E por la interfaz Ethernet
ww
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
/w
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
do
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
AP ero u_
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.
s
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?
ra s f tig/
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
ptu r lo f/i
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
de ca tec n
ca rga _in
caso del protocolos RIP.
Cmo ser la mtrica RIP con la que publique un router una red que tiene marcada en su tabla de
e
enrutamiento como accesible en 14 saltos?
La publicar en un mensaje RIP con una mtrica de 15. Este mensaje RIP, como es lgico, ser
de .e ra
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?
ra .us Ent
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.
s
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.
s
pa dte
.
ww
/w
p:/
htt
do
En nuestro PC hemos abierto una ventana MS-DOS y hemos ejecutado los siguientes comandos:
C:\WINDOWS>ipconfig /all
AP ero u_
Configuracin IP de Windows 98
Nombre del host . . . . . . . . . . . : smartin
Servidores DNS . . . . . . . . . . . . : 193.152.63.197
195.235.113.3
s
0 Ethernet adaptador :
Descripcin . . . . . . . . . . . . . : Realtek 8139-series PCI NIC
ra s f tig/
Direccin fsica . . . . . . . . . . . : 00-C0-26-26-0D-14
DHCP activado . . . . . . . . . . . . : S
Direccin IP . . . . . . . . . . . . . : 200.200.200.5
Mscara de subred . . . . . . . . . . : 255.255.255.0
Puerta de enlace predeterminada . . . : 200.200.200.1
Servidor DHCP . . . . . . . . . . . . : 200.200.200.1
ptu r lo f/i
Servidor WINS primario . . . . . . . :
Servidor WINS secundario . . . . . . . :
Permiso obtenido . . . . . . . . . . . : 04 05 02 0:12:10
Permiso caduca . . . . . . . . . . . . : 04 05 02 1:12:10
de ca tec n
ca rga _in
C:\WINDOWS>arp -a
e
No se encontraron entradas ARP
C:\WINDOWS>ping -n 1 www.c2.com
de .e ra
C:\WINDOWS>
obligatorio y que dicha funcin de servidor DHCP podra haber sido implementada en cualquier otro
ww
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
/w
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.
p:/
do
A continuacin se muestra el trfico generado en la red 200.200.200.0 /24 como consecuencia de la
ejecucin del comando PING:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
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.
.
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.
/w
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.
p:/
do
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
AP ero u_
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.
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
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?
p:/
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?
htt
A nuestro PC.
do
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
AP ero u_
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?
s
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.
ra s f tig/
A continuacin se muestra parte de la trama que contiene el mensaje ICMP de peticin de eco:
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
Se habra capturado en la red un trfico diferente si en lugar de haber usado el nombre de dominio
/w
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?
htt
do
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:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
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
ra .us Ent
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
s
Despus del proceso de arranque hemos ejecutado lo siguiente en una ventana MS-DOS:
s
C:\WINDOWS>ipconfig /all
pa dte
Configuracin IP de Windows 98
Nombre del host . . . . . . . . . . . : PC1
Servidores DNS . . . . . . . . . . . . : 193.152.63.197
195.235.113.3
Tipo de nodo . . . . . . . . . . . . . : Difusin
.
Enrutamiento IP activado . . . . . . . : No
WINS Proxy activado . . . . . . . . . : No
Resolucin NetBIOS usa DNS . . . . . . : No
0 Ethernet adaptador :
Descripcin . . . . . . . . . . . . . : Realtek 8139-series PCI NIC
/w
C:\WINDOWS>
do
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?
AP ero u_
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.
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
/w
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
p:/
do
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
AP ero u_
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.
s
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?
ra s f tig/
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
ptu r lo f/i
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?
de ca tec n
ca rga _in
Hay dos tipos. Los mensajes de tipo BOOTREQUEST, que tienen el campo Op Code a valor 1, y los
e
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.
de .e ra
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
/w
Las opciones DHCP pueden ocupar un nico octeto o bien ser opciones multiocteto. Con un solo
s
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?
s
Permite que el cliente solicite una direccin IP concreta en su mensaje DHCPDISCOVER. Ntese que
pa dte
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
ww
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
do
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
AP ero u_
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.
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
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
p:/
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
htt
do
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.
AP ero u_
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.
s
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?
ra s f tig/
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
ptu r lo f/i
tcnica diferente, pero no es lo habitual.
A continuacin se muestra parte del contenido del mensaje DHCPREQUEST enviado por el cliente:
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
/w
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.
htt
do
A continuacin se muestra el contenido del mensaje DHCPACK:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
/w
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.
htt
Estn obligados todos los equipos de Internet a aceptar un paquete IP del tamao que tiene el
paquete IP mostrado en la ventana anterior?
do
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
AP ero u_
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?
s
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
ra s f tig/
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
ptu r lo f/i
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
de ca tec n
ca rga _in
hecho al servidor mediante el mensaje DHCPDECLINE.
e
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
de .e ra
do
En un PC conectado a una red Ethernet hemos abierto la ventana Ejecutar y hemos tecleado esto:
AP ero u_
*.C ich com
s
ra s f tig/
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?
ptu r lo f/i
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
de ca tec n
ca rga _in
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
e
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.
de .e ra
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
ra .us Ent
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
s
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
s
telefnica.
pa dte
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
ww
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.
p:/
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
htt
do
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
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
s
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:
s
pa dte
.
ww
/w
p:/
do
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.
AP ero u_
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.
s
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
ra s f tig/
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
ptu r lo f/i
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?
de ca tec n
ca rga _in
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
e
red que tenemos asignada. Recurdese que con la mscara /0asignada, cualquier equipo
considerar que cualquier direccin IP forma parte de su misma red.
de .e ra
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
ww
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:
/w
p:/
htt
do
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.
AP ero u_
A continuacin se muestra el contenido de la trama con ID=4 capturada en la red de nuestro PC:
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
do
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
AP ero u_
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.
s
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
ra s f tig/
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).
ptu r lo f/i
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
de ca tec n
ca rga _in
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).
e
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?
de .e ra
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.
ra .us Ent
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
s
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?
s
Porque el valor del campo Protocol ID del cabecera IP es 6, que es le valor que identifica al
pa dte
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.
ww
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
/w
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
p:/
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
do
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
Qu flags tiene activados el primer segmento TCP enviado por el equipo 12.0.1.28?
ww
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?
/w
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
htt
bit SYN (que tena asociado el nmero de secuencia 2221078) y est esperando recibir el octeto de
do
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
AP ero u_
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.
s
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
ra s f tig/
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.
ptu r lo f/i
A continuacin se muestra parte del contenido de la trama con ID=6:
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
/w
Por qu en la ventana anterior nos muestra el analizador, justo despus del segmento TCP, un
p:/
y campo FCS. Los 46 octetos de longitud mnima que deben tener los datos contenidos en una trama
do
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
AP ero u_
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
s
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:
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s /
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
htt
podamos ver de un vistazo un resumen del los principales campos de todos los segmentos TCP y de
do
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
AP ero u_
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
s
(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?
ra s f tig/
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
ptu r lo f/i
que ha durado la conexin, tan slo el primer segmento, enviado por el equipo 200.200.200.5, tena el
flag ACK desactivado?
de ca tec n
ca rga _in
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
e
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 .e ra
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
ra .us Ent
tanto el flag ACK como el campo Acknowledgement Number ocupan espacio en la cabecera TCP,
sea cual sea su valor.
/
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
s
el equipo 200.200.200.5:
pa dte
.
ww
/w
Qu indica el equipo 200.200.200.5 con el valor 8576 en el campo Window Size del segmento
p:/
partir del octeto con nmero de secuencia 3077941796, que es el nmero del primer octeto que el
do
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.
AP ero u_
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
s
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
ra s f tig/
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.
ptu r lo f/i
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:
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
/w
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
p:/
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?
htt
do
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
AP ero u_
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.
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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:
.
ww
/w
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
p:/
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
do
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
AP ero u_
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.
s
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
ra s f tig/
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:
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
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
ww
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
/w
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
p:/
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
htt
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
do
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?
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
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
/w
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?
p:/
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
htt
vayan a tener que fragmentarse en su camino hacia el cliente. Ntese tambin que el primer
do
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.
AP ero u_
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
s
que tipo es el comando. Dependiendo del tipo de comando, su longitud podr ser mayor o menor.
pa dte
opcin que el servidor quiere empezar a ejecutar en este caso es el ECHO, con cdigo 1. Es decir,
ww
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?
/w
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
htt
do
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
AP ero u_
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.
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s /
Qu equipo ha generado los mensajes ICMP de peticin de eco asociados a este comando PING?
s
El equipo 12.0.1.28 es el que enva los mensajes ICMP. Nosotros, desde el equipo 200.200.200.5 lo
pa dte
nico que estamos haciendo es darle al equipo 12.0.1.28 la orden de que haga el PING.
entre 27 y 90, ambas inclusive, contienen segmentos TCP relacionados con lo que se ha hecho. La
ww
do
A continuacin se muestra la segunda de las tramas capturadas en la red del PC relacionadas con el
comando PING que se ha tecleado:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s s /
pa dte
.
ww
/w
p:/
htt
do
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.
AP ero u_
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:
El ltimo segmento que enva el cliente TELNET en relacin al comando PING puede verse en la
s
pantalla siguiente:
pa dte
.
ww
/w
p:/
TCP cuya nica misin es indicarle al 12.0.1.28 que al equipo 200.200.200.5 le han llegado todos los
do
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.
AP ero u_
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:
s
pa dte
.
ww
/w
p:/
do
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:
AP ero u_
*.C ich com
s
ra s f tig/
ptu r lo f/i
de ca tec n
ca rga _in
e
de .e ra
ra .us Ent
s /
datos. Cuando los dos extremos envan el flag FIN y ambos han recibido los respectivos
pa dte
asociado al flag FIN. Es decir, el flag FIN es tratado como si fuera un octeto, pues se le asigna un
ww
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
/w
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
p:/
conexin.
htt