Página 1 del ejercicio1.doc

Transcripción

1 Ejercicio 1: En nuestro PC hemos abierto una ventana MS-DOS y hemos ejecutado los siguientes comandos: C:\WINDOWS>ipconfig Configuración IP de Windows 98 0 Ethernet adaptador : C:\WINDOWS>ping Dirección IP : Máscara de subred : Puerta de enlace predeterminada... : Uso: ping [-t] [-a] [-n cantidad] [-l tamaño] [-f] [-i TTL] [-v TOS] [-r cantidad] [-s cantidad] [[-j lista de host] [-k lista de host]] [-w Tiempo de espera agotado] lista de destino Opciones: -t Solicita eco al host hasta ser interrumpido. Para ver estadísticas y continuar: presione Ctrl-Inter. Para interrumpir: presione Ctrl-C. -a Resuelve direcciones a nombres de host. -n cantidad Cantidad de solicitudes de eco a enviar. -l tamaño Tamaño del búfer de envíos. -f No fragmentar el paquete. -i TTL Tiempo de vida. -v TOS Tipo de servicio. -r cantidad Registrar la ruta para esta cantidad de saltos. -s cantidad Registrar horarios para esta cantidad de saltos. -j lista de hosts Ruta origen variable en la lista de host. -k lista de hosts Ruta origen estricta en la lista de host. -w tiempo Tiempo de espera agotado de respuesta en milisegundos. C:\WINDOWS>ping -n 1 -l Haciendo ping a con 15 bytes de datos: Respuesta desde : bytes=15 tiempo=1ms TDV=128 Estadísticas de ping para : Paquetes: enviados = 1, Recibidos = 1, perdidos = 0 (0% loss), Tiempos aproximados de recorrido redondo en milisegundos: Mínimo = 1ms, máximo = 1ms, promedio = 1ms C:\WINDOWS> Qué tipo de tarjeta de red tenemos instalada? Ethernet Cuál es la IP de nuestro PC? Nuestra dirección IP es la A que clase de red pertenece nuestra IP? A una red de clase B, pues en binario nuestra IP empieza por 10 Se ha hecho subnetting en nuestra red? No, pues la máscara de subred es , que es lo normal en las redes de tipo B. Cuál es el rango de direcciones IP válidas (asignables a estaciones) de nuestra red? Del al , que son en total. Puede tener un host de nuestra red la IP ? No. La dirección IP con el campo de host completamente a cero es una dirección reservada para nombrar a la red a la que pertenecemos. Puede tener un host de nuestra red la IP ? No. La dirección IP con todos los bits a 1 en el campo de host es la dirección de broadcast dirigido. Si enviamos un datagrama a esa dirección queremos expresar que ese datagrama está dirigido a todas las direcciones que forman parte de dicha red. Cuál es nuestro router por defecto? El Es obligatorio que el router tenga asignada la dirección IP válida más baja del la red? No. En nuestra red se ha hecho así, pero es una costumbre y no algo obligatorio. Puede que existan otros routers en nuestra red? Sí. Además del router por defecto que ya conocemos, podrían existir otros routers en nuestra red. Página 1 del ejercicio1.doc

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16 A continuación se muestra otra vez la ventana de captura del analizador, conteniendo las mismas seis tramas que antes, pero habiéndole indicado en el cuadro de diálogo Capture View Display Options que debía mostrar las direcciones de red ( Display Network Address ): Qué ventaja tiene esta forma de ver el listado de tramas sobre la anterior? Tiene la ventaja de que ahora podemos ver rápidamente las direcciones IP origen y destino de los datagramas IP contenidos en las tramas. La otra visión nos mostraba siempre las direcciones MAC, por lo que solo veíamos direcciones origen y destino pertenecientes a la misma red en la que se habían capturado las tramas. Antes, si el tráfico era externo a la red siempre una de las direcciones MAC era la dirección MAC de un router de la red en la que nos encontrabamos. Si el contenido de la trama es un paquete ARP y no un paquete IP, el analizador muestra ahora las direcciones IP del Sender y del Target de dicho paquete ARP, permitiendo ver rápidamente quién está intentando comunicarse con quién a nivel de red. De qué sirven los campos Identified y Sequence Number en los mensajes ICMP de petición de eco y de respuesta de eco? Sirven para que el receptor de las respuestas de eco pueda asociarlas a las peticiones de eco que ha realizado. Nótese que los valores de los campos Identified y Sequence Number de la petición de eco de la trama con ID=2 son los mismos que los de la respuesta de eco de la trama con ID=3. Página 4 del ejercicio4.doc

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

18 A qué dirección MAC se habrán dirigido todas las tramas que contenían los paquetes con mensajes ICMP que hemos enviado? A la dirección MAC del router. Al ser hosts que están fuera de nuestra red, los paquetes deben llegarles pasando a través de un router. Es imposible que una trama que nosotros enviemos salga fuera de nuestra red. ha sido necesario generar una petición ARP para obtener la dirección MAC del router por defecto de nuestra red, el ? No. La caché ARP ya contenía esa información, pues seguramente habrá habido recientemente alguna comunicación entre el router y nosotros. A continuación se muestra una ventana de un analizador de protocolos en la que aparece el tráfico que se ha generado en nuestra red debido a los comandos PING que acabamos de ejecutar. Qué significa la columna Elapsed [sec] que aparece en el listado de tramas? Son los segundos que han transcurrido desde que se capturó la primera trama hasta que se ha capturado la trama en cuestión. Por ejemplo, la trama con ID=3 se ha capturado 1, segundos después de que se capturase la primera trama. Qué equipos están intercambiando tramas? El nuestro, con IP , que sabemos que tiene la MAC 00C026260D14 gracias al comando ipconfig /all y el router, con IP , que sabemos que tiene la dirección MAC 0020EA18D151 pues así nos lo ha mostrado el comando arp a que ejecutamos anteriormente. Van dirigidos a la IP del router los paquetes encapsulados en las tramas que le estamos enviando? No. Aunque en esta ventana de captura no se está viendo, la IP destino de los paquetes que hay encapsulados en las tramas que estamos enviando será la IP de los equipos a los que les queremos hacer llegar los mensajes ICMP de petición de eco. No le estamos haciendo PING al router, simplemente estamos haciendo uso del router para que nos enrute los paquetes con destino externo a nuestra propia red. A continuación se muestra la misma ventana de captura de antes pero configurada de forma que en el listado de tramas aparecen ahora las direcciones de red en lugar de las MAC. Página 2 del ejercicio5.doc

19 Es más clara ahora la información de la ventana de captura? Sí. A pesar de que el panel central está casi cerrado y de que el panel inferior está completamente cerrado, el hecho de que aparezcan las direcciones IP origen y destino de los paquetes contenidos en las tramas hace que, en este ejemplo concreto se vea mejor lo que está ocurriendo. De un vistazo nos damos cuenta que desde el host se ha enviado un mensaje ICMP de petición de eco Echo Request a otros tres hosts, con direcciones IP , y , respectivamente. También se observa cómo esos tres host han respondido al host con los correspondientes mensajes ICMP de respuesta de eco Echo Reply. Cuánto tiempo ha tardado en llegar el mensaje de respuesta del host , contado desde que le enviamos el mensaje ICMP de petición de eco? Pues la diferencia entre 3, segundos y 2, segundos, que son 0, segundos. Nótese que esto concuerda aproximadamente con los 229 milisegundos que ha calculado el programa PING como tiempo de recorrido redondo (ida y vuelta). Lógicamente éste es un poco superior porque el programa PING empieza a contar cuando le pasa el mensaje de petición de eco al nivel de red y deja de contar cuando el nivel de red le pasa al programa PING el mensaje de respuesta de eco, mientras que el cálculo que nosotros hemos hecho se basa en los tiempos de salida y llegada de las tramas. A continuación se muestra el contenido de la trama con ID=4. Cómo sabe el analizador que es correcto el campo Checksum del mensaje ICMP de esta trama? Lo calcula nuevamente y comprueba que coincide con el que ha recibido. Para calcularlo realiza la suma de todas las palabras de 16 bits del mensaje ICMP, salvo el propio checksum, que no es sumado. En nuestro caso la suma es A + 6B6C + 6D6E + 6F = 7239D. Si el número que hemos obtenido fuese mayor de 16 bits, cogeríamos los bits sobrantes y los volveríamos a sumar a los 16 bits menos significativos, lo que en nuestro caso sería 239D + 7 = 23A4. Por último, el resultado de 16 bits así obtenido se complementa a uno para obtener el cheksum. En nuestro caso el complemento a uno de 23A4 es DC5B, que coincide exactamente con el checksum que hemos recibido. Quiere esto decir que el mensaje ICMP no tiene errores, o al menos que no tiene errores que puedan detectarse con esta sencilla técnica de detección de errores. Qué significa la anotación que pone el analizador al lado de campo Code del mensaje ICMP de petición de eco? La anotación Not used (MBZ) significa que como el campo Code no se usa en este tipo de mensaje, su valor debe ser cero (MBZ = Must Be Zero). Cómo es el mensaje ICMP de respuesta de eco que devuelve un host al recibir el correspondiente mensaje de petición de eco? Debe ser idéntico en todo al mensaje de petición de eco que acaba de recibir, salvo que el campo Type debe ser 0 (respuesta de eco) y que, como es lógico, el campo Checksum deberá ser calculado nuevamente. Página 3 del ejercicio5.doc

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