dilluns, 17 de maig del 2010
PRÁCTICA 3
Las siguientes entradas están dedicadas a la realización de la tercera práctica de la asignatura para la que está dedicada este blog, "Redes de ordenadores" de ITT: sonido e imagen. En esta práctica pretendemos profundizar en la capa de transporte de la arquitectura TCP/IP. Dentro de este nivel indagaremos en el formato de las estructuras de datos, así como el direcionamiento a puertos de enlace con diferentes aplicaciones. Los ejercicios desarrollados son los siguientes:
Práctica 3: Ejercicio 1-Sobre Transmisión de datos a puertos de enlace
Para el desarrollo del primero de los ejercicios de la última práctica de la asignatura, la tercera, vamos a desarrollar las dos siguientes entradas de nuestro blog. Cada una de estas entradas estarán dedicadas a cada uno de los subapartados del ejercicio.
Práctica 3: Ejercicio 1-A
1.a.Utilizar el programa udp.exe para realizar un envío de datos al puerto 7 (eco) o al puerto 13 (hora y día) del servidor Linux1 (10.3.7.0). Para ello basta especificar la dirección IP y el puerto del servidor, colocar algún texto en la ventana y pulsar el botón "Envía UDP". Con el monitor de red, analiza la secuencia de paquetes UDP que se desencadenan cuando se envía como datos una palabra, por ejemplo “hola”. Utiliza el filtro adecuado en el Monitor de Red (direcciones y protocolos).
Como podemos comprobar si mandamos al puerto 7 la frase “Hola me llamo Alejandro”, cumple su función de eco y responde con la misma frase que le ha sido enviada. Sin embargo al intentar contactar con el puerto 13 y mandarle la misma frase, o al intentar contactar con el de cualquier manera, responde con la hora. Si analizamos los puertos de los paquetes enviados poseen la misma numeración, 1663, ya que parten de la misma aplicación, sin embargo los paquetes que llegan tiene numeración distinta debido a que nacen en puertos distintos, 7 y 13.
Como podemos observar en el monitor de red aparecen dos paquetes por cada llamada que hacemos, las dos primeras corresponden a la comunicación con el puerto ‘eco’ que responde con la misma información. En cuanto a las direcciones de los mismos podemos comprobar como en el primer paquete el origen es mi máquina y el destino la 10.3.7.0 y en el segundo paquete las direcciones están a la inversa.
Si analizamos los paquetes que van al puerto 13 observamos que la información de las direcciones son las mismas, mientras que la información es distinta ya que ambos paquetes se suponen que van a contener información relativa a la fecha y hora.
Como podemos comprobar si mandamos al puerto 7 la frase “Hola me llamo Alejandro”, cumple su función de eco y responde con la misma frase que le ha sido enviada. Sin embargo al intentar contactar con el puerto 13 y mandarle la misma frase, o al intentar contactar con el de cualquier manera, responde con la hora. Si analizamos los puertos de los paquetes enviados poseen la misma numeración, 1663, ya que parten de la misma aplicación, sin embargo los paquetes que llegan tiene numeración distinta debido a que nacen en puertos distintos, 7 y 13.
Como podemos observar en el monitor de red aparecen dos paquetes por cada llamada que hacemos, las dos primeras corresponden a la comunicación con el puerto ‘eco’ que responde con la misma información. En cuanto a las direcciones de los mismos podemos comprobar como en el primer paquete el origen es mi máquina y el destino la 10.3.7.0 y en el segundo paquete las direcciones están a la inversa.
Si analizamos los paquetes que van al puerto 13 observamos que la información de las direcciones son las mismas, mientras que la información es distinta ya que ambos paquetes se suponen que van a contener información relativa a la fecha y hora.
Práctica 3: Ejercicio 1-B
1.b.Prueba de nuevo udp.exe, pero enviando un texto mucho más grande (sobre 2Kbytes). Esto se puede hacer copiando parte de algún fichero de texto en la ventana de udp.exe. ¿Se produce fragmentación IP de los paquetes UDP? Estudia las longitudes del paquete UDP y las de los paquetes IP que aparecen. Detalla los paquetes (fragmentados o no) que observas en el Monitor (indica el valor del identificador, flags, tamaño, etc…)
El texto seleccionado será la explicación del punto anterior duplicándolo para aumentar su tamaño
En total se han mando 2386 bytes de datos.
En el monitor de red observamos que hemos mandado dos partes, un paquete inicial que corresponde con la primera parte de la información y el segundo paquete corresponde con la segunda parte de la información, ya que la cantidad de datos era excesivamente grande y no cabía en una única trama. El primer paquete tendrá una longitud de 1514 bytes de los cuales 14 suponen la cabecera de Ethernet, 20 la cabecera IP y 8 la cabecera de UDP, por lo tanto nos llegan 1472 bytes de datos, el segundo paquete tendrá una longitud de 948 bytes de los cuales 14 suponen la cabecera de Ethernet y 20 la cabecera IP, por lo tanto nos llegan 914 bytes de datos, por lo tanto con la unión de ambos paquetes tendremos el total de la información, 2386 bytes de datos.
Sin embargo en la recepción recibimos muchos más, un total de 5 paquetes. Esto es debido a que el enlace físico desde el router de salida de nuestra red y el servidor 10.3.7.0 acepta únicamente un total de 514 bytes de trama, por lo tanto los paquetes a enviar se deben ajustar a ese tamaño. De aquí deducimos que: el primer paquete posee 14 bytes de la cabecera de Ethernet, 20 la cabecera IP y 8 la cabecera de UDP, por lo tanto nos llegan 472 bytes de datos, los siguientes 3 paquetes tendrán la misma estructura, tendrán una longitud de 514 bytes, de los cuales 14 son destinados a la cabecera de Ethernet y 20 a la cabecera de IP, de aquí deducimos que estos paquetes poseerán 480 bytes de datos. En cuanto al último paquete, como contiene menos datos que los anteriores, su tamaño será de 508, con 14 son destinados a la cabecera de Ethernet y 20 a la cabecera de IP, de aquí deducimos que estos paquetes poseerán 480 bytes de datos 474, por lo tanto entre todos los paquetes hemos conseguido los 2386 bytes de datos originales
En cuanto a la identificación de los paquetes, los dos primeros paquetes tendrán la misma identificación 0x4ea3, y el primer paquete tendrá el parámetro ‘flags’ activado ya que si que posee segmentación y el segundo no. En cuanto al campo ‘Header checksum’, ambos son correctos ya que la identificación de los puntos de partida y destino son correctos y accesibles.
Por otro lado, la respuesta del servidor, también tendrán la misma identificación entre ellos, 0x0411, y los cuatro primeros tendrán el campo ‘flags’ activado, ya que todos poseen segmentación posterior excepto el último. En cuanto al campo ‘Header checksum’, todos son correctos ya que la identificación de los puntos de partida y destino son correctos y accesibles.
El texto seleccionado será la explicación del punto anterior duplicándolo para aumentar su tamaño
En total se han mando 2386 bytes de datos.
En el monitor de red observamos que hemos mandado dos partes, un paquete inicial que corresponde con la primera parte de la información y el segundo paquete corresponde con la segunda parte de la información, ya que la cantidad de datos era excesivamente grande y no cabía en una única trama. El primer paquete tendrá una longitud de 1514 bytes de los cuales 14 suponen la cabecera de Ethernet, 20 la cabecera IP y 8 la cabecera de UDP, por lo tanto nos llegan 1472 bytes de datos, el segundo paquete tendrá una longitud de 948 bytes de los cuales 14 suponen la cabecera de Ethernet y 20 la cabecera IP, por lo tanto nos llegan 914 bytes de datos, por lo tanto con la unión de ambos paquetes tendremos el total de la información, 2386 bytes de datos.
Sin embargo en la recepción recibimos muchos más, un total de 5 paquetes. Esto es debido a que el enlace físico desde el router de salida de nuestra red y el servidor 10.3.7.0 acepta únicamente un total de 514 bytes de trama, por lo tanto los paquetes a enviar se deben ajustar a ese tamaño. De aquí deducimos que: el primer paquete posee 14 bytes de la cabecera de Ethernet, 20 la cabecera IP y 8 la cabecera de UDP, por lo tanto nos llegan 472 bytes de datos, los siguientes 3 paquetes tendrán la misma estructura, tendrán una longitud de 514 bytes, de los cuales 14 son destinados a la cabecera de Ethernet y 20 a la cabecera de IP, de aquí deducimos que estos paquetes poseerán 480 bytes de datos. En cuanto al último paquete, como contiene menos datos que los anteriores, su tamaño será de 508, con 14 son destinados a la cabecera de Ethernet y 20 a la cabecera de IP, de aquí deducimos que estos paquetes poseerán 480 bytes de datos 474, por lo tanto entre todos los paquetes hemos conseguido los 2386 bytes de datos originales
En cuanto a la identificación de los paquetes, los dos primeros paquetes tendrán la misma identificación 0x4ea3, y el primer paquete tendrá el parámetro ‘flags’ activado ya que si que posee segmentación y el segundo no. En cuanto al campo ‘Header checksum’, ambos son correctos ya que la identificación de los puntos de partida y destino son correctos y accesibles.
Por otro lado, la respuesta del servidor, también tendrán la misma identificación entre ellos, 0x0411, y los cuatro primeros tendrán el campo ‘flags’ activado, ya que todos poseen segmentación posterior excepto el último. En cuanto al campo ‘Header checksum’, todos son correctos ya que la identificación de los puntos de partida y destino son correctos y accesibles.
Práctica 3: Ejercicio 2-Establecimiento de conexión para transmitir datos
Las tres siguientes entradas de este blog están dedicadas al desarrollo del tercer ejercicio de la tercera práctica. En este ejercicio tratamos de entender el procedimiento para la conexión y posterior transmisión de datos TCP.
Práctíca 3: Ejercicio 2-A
2.a.Comprueba las secuencias de conexión-desconexión TCP. ¿Son similares a las que se detallan en la figura 6? (Puede que observes que el cliente contesta a una solicitud de SYN del servidor con un RST. Esto ocurre porque el servidor trata de autentificar al cliente, algo que no permite el PC).
Si coincide, primero establece la conexión entre ambos terminales, acto seguido pasa al traspaso de datos entre ellos y una vez que todos los datos han sido transmitido, finaliza la conexión y deja los recursos de conexión libre.
Si coincide, primero establece la conexión entre ambos terminales, acto seguido pasa al traspaso de datos entre ellos y una vez que todos los datos han sido transmitido, finaliza la conexión y deja los recursos de conexión libre.
Práctica 2: Ejercicio 2-B
2.b.Comprueba el valor de los puertos utilizados. Indica su valor.
Cuando nosotros mandamos los segmentos utilizamos el puerto de enlace ‘exec(512)’ que corresponde con el puerto asignado a la aplicación ‘Rexec’.
Cuando el servidor nos manda información utiliza el puerto de enlace ‘asdis(2192)’, que corresponde con el puerto de salida del servidor.
También encontramos dos puertos distintos en la conexión que nos servirá para realizar la identificiación. El puerto de identificación de nuestra máquina será el ‘gtrack-ne(3592)’ y del servidor del destino es el ‘ident(113)’
Cuando nosotros mandamos los segmentos utilizamos el puerto de enlace ‘exec(512)’ que corresponde con el puerto asignado a la aplicación ‘Rexec’.
Cuando el servidor nos manda información utiliza el puerto de enlace ‘asdis(2192)’, que corresponde con el puerto de salida del servidor.
También encontramos dos puertos distintos en la conexión que nos servirá para realizar la identificiación. El puerto de identificación de nuestra máquina será el ‘gtrack-ne(3592)’ y del servidor del destino es el ‘ident(113)’
Práctica 3: Ejercicio 2-C
2.c.Analizar los valores de la ventana de receptor. ¿Cuál es más grande?
La ventana más grande corresponde con el paquete identificado como 0x5c94 y pose un tamaño de ventana de 65535
La ventana más grande corresponde con el paquete identificado como 0x5c94 y pose un tamaño de ventana de 65535
Práctica 3: Ejercicio 3-Protocolo TCP
4.Utiliza el programa rexec para ejecutar el comando ‘cat file1.txt’ en el servidor 172.20.43.232(Linux2). La información recibida es de varios miles de bytes y se recibirá en segmentos TCP de gran tamaño. ¿IP ha fragmentado estos segmentos? ¿Por qué ocurre esto? ¿Cuál es el tamaño de los segmentos TCP?
No estos paquetes no han sido fragmentados porque son del protocolo TCP. Este protocolo es un protocolo seguro y no permite fragmentación, como podemos comprobar, el bit de ‘no fragmentación de segmento’ esta activo.
El protocolo TCP tiene esta condición para que no se pueda perder información por un paquete mal recibido, no tendría mucho sentido que invirtamos tiempo de codificación y decodificación de seguridad para que luego llegasen paquetes fragmentados con posibles errores.
El tamaño del MSS de la conexión es de 1460 bytes(2014 bytes de Ethernet,menos 14 cabecera Ethernet, menos 20 bytes de cabecera de IP y 20 bytes más de cabecera de TCP).
No estos paquetes no han sido fragmentados porque son del protocolo TCP. Este protocolo es un protocolo seguro y no permite fragmentación, como podemos comprobar, el bit de ‘no fragmentación de segmento’ esta activo.
El protocolo TCP tiene esta condición para que no se pueda perder información por un paquete mal recibido, no tendría mucho sentido que invirtamos tiempo de codificación y decodificación de seguridad para que luego llegasen paquetes fragmentados con posibles errores.
El tamaño del MSS de la conexión es de 1460 bytes(2014 bytes de Ethernet,menos 14 cabecera Ethernet, menos 20 bytes de cabecera de IP y 20 bytes más de cabecera de TCP).
Práctica 3: Ejercicio 4-
4.Utiliza el programa rexec para ejecutar el comando ‘cat file1.txt’ en el servidor 10.3.7.0. ¿Qué valor de MSS se negocia entre los extremos de la comunicación? ¿Cuál es el tamaño de los segmentos TCP transportados dentro de los paquetes IP? ¿Qué diferencia existe respecto al caso anterior?
¿Qué valor de MSS se negocia entre los extremos de la comunicación? ¿Cuál es el tamaño de los segmentos TCP transportados dentro de los paquetes IP? ¿Qué diferencia existe respecto al caso anterior?
El valor de MSS negociado entre nuestra máquina y el servidor 10.3.7.0 es de 460 bytes. Esto es debido a que el MTU de la conexión entre nuestro router de encaminamiento y el router la maquina con la que queremos contactar es 514 bytes, por lo tanto el MSS será de 460 bytes como ya hemos dicho.
El protocolo TCP usará un tamaño de segmento de 480 bytes contando la cabecera, ya que la longitud del segmento será el MSS más los 20 bytes de cabecera.
Que MTU de cada red varían y por lo tanto la negociación del MSS entre nuestra máquina y la maquina exterior debe adaptarse al caso más restrictivo de la conexión.
¿Qué valor de MSS se negocia entre los extremos de la comunicación? ¿Cuál es el tamaño de los segmentos TCP transportados dentro de los paquetes IP? ¿Qué diferencia existe respecto al caso anterior?
El valor de MSS negociado entre nuestra máquina y el servidor 10.3.7.0 es de 460 bytes. Esto es debido a que el MTU de la conexión entre nuestro router de encaminamiento y el router la maquina con la que queremos contactar es 514 bytes, por lo tanto el MSS será de 460 bytes como ya hemos dicho.
El protocolo TCP usará un tamaño de segmento de 480 bytes contando la cabecera, ya que la longitud del segmento será el MSS más los 20 bytes de cabecera.
Que MTU de cada red varían y por lo tanto la negociación del MSS entre nuestra máquina y la maquina exterior debe adaptarse al caso más restrictivo de la conexión.
Práctica 3: Ejercicio 5-Tranferencia de datos FTP
5.Realiza una conexión FTP a la máquina de un compañero de clase. ¿Qué obtienes en el Monitor de Red al intentar realizar esta conexión?
Nuestro ordenador intenta conectar 3 veces con la máquina de nuestro compañero, mi máquina es la 147.20.43.207 y la de nuestro compañero es la 172.20.43.208. Al intentar contactar con esta máquina recibimos tantos errores como intentos realizamos debido a que las máquinas de los alumnos tienen desactivada esta opción.
Nuestro ordenador intenta conectar 3 veces con la máquina de nuestro compañero, mi máquina es la 147.20.43.207 y la de nuestro compañero es la 172.20.43.208. Al intentar contactar con esta máquina recibimos tantos errores como intentos realizamos debido a que las máquinas de los alumnos tienen desactivada esta opción.
Práctica 3: Ejercicio 6-Análisis práctico del cálculo de MSS
Ejecuta el comando route delete 172.20.41.241 y a contintinuación route add 172.20.41.241 172.20.43.231.
Todo seguido activa el monitor de red y captura la secuencia de tramas mandadas al ejecutar:
C:\ftp 172.20.41.241
Usuario: alumnos
Contraseña: alumnos
Bin
Put p3.txt
quit
¿Cuál es el MSS de la red?
Inicialmente se realiza la conexión entre nuestra máquina y la máquina deseada. Negocian su MSS para la conexión, inicialmente será de 460 bytes, ya que es la más restrictiva de las dos redes. Una vez que ya se ha establecido la conexión, nuestra máquina envía dos paquetes de TCP para comenzar la información, pero al intentar pasar por el router, este da un error ya que su MTU es de 400 bytes, por lo tanto, no permite la conexión. Nuestra máquina al recibir el mensaje de error cambia su MSS a 360 bytes que será el tamaño correcto de conexión que mantendrá hasta que termine la transferencia de datos.
Todo seguido activa el monitor de red y captura la secuencia de tramas mandadas al ejecutar:
C:\ftp 172.20.41.241
Usuario: alumnos
Contraseña: alumnos
Bin
Put p3.txt
quit
¿Cuál es el MSS de la red?
Inicialmente se realiza la conexión entre nuestra máquina y la máquina deseada. Negocian su MSS para la conexión, inicialmente será de 460 bytes, ya que es la más restrictiva de las dos redes. Una vez que ya se ha establecido la conexión, nuestra máquina envía dos paquetes de TCP para comenzar la información, pero al intentar pasar por el router, este da un error ya que su MTU es de 400 bytes, por lo tanto, no permite la conexión. Nuestra máquina al recibir el mensaje de error cambia su MSS a 360 bytes que será el tamaño correcto de conexión que mantendrá hasta que termine la transferencia de datos.
dilluns, 26 d’abril del 2010
PRÁCTICA 2
A continuación se va a realizar la práctica 2 de la asignatura de Redes de ordenadores. En esta práctica se desea profundizar en el protocolo de contro y error ICMP. También se analizarán las cabeceras de estos mensajes y estudiaremos la creación de subredes a partir de un direccionamiento IP
Práctica 2: Ejercicio 1-Sobre mensajes ICMP del “Ping”
Para empezar esta práctica vamos a didicar las dos siguientes entradas a la realización del primer ejercicio de la práctica dos. En esta estudiaremos el comando Ping. Para ello ejecutaremos las siguientes instrucciones:
Inicia el programa Monitor de Red en modo captura. A continuación ejecuta el comando:
C:\>ping –n 1 172.20.43.230 (…la opción –n especifica el número de peticiones “echo” que se lanzan al medio)
Una vez hecho esto, detener la captura en el Monitor de Red (filtrar únicamente tramas del alumno) y visualizar los paquetes capturados. En base a los paquetes capturados determinar:
Inicia el programa Monitor de Red en modo captura. A continuación ejecuta el comando:
C:\>ping –n 1 172.20.43.230 (…la opción –n especifica el número de peticiones “echo” que se lanzan al medio)
Una vez hecho esto, detener la captura en el Monitor de Red (filtrar únicamente tramas del alumno) y visualizar los paquetes capturados. En base a los paquetes capturados determinar:
Práctica 2: Ejercicio 1-A
1.a. ¿Cuántos y qué tipos de mensajes ICMP aparecen? (tipo y código)
Echo (ping) request: type: 8 (Echo (ping) request) Code: 0
Echo (ping) reply: type: 8 (Echo (ping) reply) Code: 0
Echo (ping) request: type: 8 (Echo (ping) request) Code: 0
Echo (ping) reply: type: 8 (Echo (ping) reply) Code: 0
Práctica 2: Ejercicio 1-B
1.b. ¿Crees que las direcciones IP origen y MAC origen del mensaje ICMP “Reply” hacen referencia a la misma máquina o interfaz de red?
Si porque el router con IP 172.20.43.230 corresponde con el router cisco_8c_:8c:ff de dirección MAC 00:07:0e:8c:8c:ff
Si porque el router con IP 172.20.43.230 corresponde con el router cisco_8c_:8c:ff de dirección MAC 00:07:0e:8c:8c:ff
Práctica 2: Ejercicio 2-Sobre la fragmentación de datagramas IP
Para el desarrollo de del ejercicio dos de la segunda práctica, hemos ejecutado las siguientes instrucciones:
Empleando el programa Monitor de Red de la misma forma que en la situación anterior, ejecutar:
C:\>ping –n 1 –l 2000 172.20.43.230 (…la opción –l especifica la cantidad de datos a enviar)
A partir de las capturas obtenidas, contestaremos a las siguientes ejercicios:
Empleando el programa Monitor de Red de la misma forma que en la situación anterior, ejecutar:
C:\>ping –n 1 –l 2000 172.20.43.230 (…la opción –l especifica la cantidad de datos a enviar)
A partir de las capturas obtenidas, contestaremos a las siguientes ejercicios:
Práctica 2: Ejercicio 2-A
2.a. Filtra los paquetes en los que esté involucrada tu dirección IP. A continuación, describe el número total de fragmentos correspondientes al datagrama IP lanzado al medio, tanto en la petición de ping como en la respuesta. ¿Cómo están identificados en el Monitor de Red todos estos paquetes (ICMP, IP, HTTP, TCP…)? ¿Qué aparece en la columna ‘info” del Monitor de Red?
Se mandan 2 paquetes y se reciben otros 2 paquetes, los dos paquetes mandados van de mi máquina al router de encaminamiento exterior de la red, y los dos paquetes recibidos hacen el camino inverso.
Como el paquete enviado es demasiado grande, 2000 bytes, se debe truncar en dos paquetes, el primero será el que tenga el protocolo ICMP correspondiente al “ping” y el segundo paquete IP corresponde con el resto del paquete truncado. En la información del paquete ICMP es un “Echo (ping) request” y la información del paquete IP es “Fragmented IP Protocol (proto=ICMP 0x01, off=1480, ID=3170)”, este informa de que la información que tiene es el resto del paquete ICMP.
En cuanto al paquete recibido estamos en el mismo caso anterior, nos llega primero un paquete ICMP con información “Echo (ping) reply”, que es las primera parte del mensaje ICMP, mientras que el paquete IP contiene una información de “Fragmented IP Protocol (proto=ICMP 0x01, off=1480, ID=3170)”, que informa de que el paquete contiene el resto de la información del mensaje ICMP
Se mandan 2 paquetes y se reciben otros 2 paquetes, los dos paquetes mandados van de mi máquina al router de encaminamiento exterior de la red, y los dos paquetes recibidos hacen el camino inverso.
Como el paquete enviado es demasiado grande, 2000 bytes, se debe truncar en dos paquetes, el primero será el que tenga el protocolo ICMP correspondiente al “ping” y el segundo paquete IP corresponde con el resto del paquete truncado. En la información del paquete ICMP es un “Echo (ping) request” y la información del paquete IP es “Fragmented IP Protocol (proto=ICMP 0x01, off=1480, ID=3170)”, este informa de que la información que tiene es el resto del paquete ICMP.
En cuanto al paquete recibido estamos en el mismo caso anterior, nos llega primero un paquete ICMP con información “Echo (ping) reply”, que es las primera parte del mensaje ICMP, mientras que el paquete IP contiene una información de “Fragmented IP Protocol (proto=ICMP 0x01, off=1480, ID=3170)”, que informa de que el paquete contiene el resto de la información del mensaje ICMP
Práctica 2: Ejercicio 2-B
2.b. ¿En cuántos fragmentos se ha “dividido” el datagrama original?
En dos paquetes cada uno, el Echo request y el Echo reply. Como ambos paquetes originales tenían 2000 bytes cada uno se han truncado en dos paquetes, un paquete ICMP de 1514 y otro paquete IP de 562 bytes cada uno.
En dos paquetes cada uno, el Echo request y el Echo reply. Como ambos paquetes originales tenían 2000 bytes cada uno se han truncado en dos paquetes, un paquete ICMP de 1514 y otro paquete IP de 562 bytes cada uno.
Práctica 2: Ejercicio 2-C
2.c. Analiza la cabecera de cada datagrama IP de los paquetes relacionados con el “ping” anterior.
Observa el campo “identificación”, “Flags” y “Fragment offset” de los datagramas. ¿Qué valor tienen en estos campos en los datagramas anteriores? Indica en la columna “dirección” si son de petición o respuesta. Muestra los datagramas en el orden de aparición del Monitor de Red.
Datos IPCM
Datos IP
Observa el campo “identificación”, “Flags” y “Fragment offset” de los datagramas. ¿Qué valor tienen en estos campos en los datagramas anteriores? Indica en la columna “dirección” si son de petición o respuesta. Muestra los datagramas en el orden de aparición del Monitor de Red.
Datos IPCM
Datos IP
Práctica 2: Ejercicio 2-D
2.d. ¿Qué ocurre en la visualización de los fragmentos de datagramas si introduces un filtro para ver únicamente paquetes de “icmp” en el Monitor de Red? ¿qué fragmentos visualizas ahora?
Veremos los mismos paquetes, ya que todos los paquetes capturados corresponden con el protocolo ICMP. Curiosamente, los paquetes truncados están construidos con protocolo IP, obviamente esto sucede por el truncamiento de los paquetes ICMP, al ser estos demasiado grandes, generan los paquetes IP necesarios para transmitir el resto del mensaje.
Veremos los mismos paquetes, ya que todos los paquetes capturados corresponden con el protocolo ICMP. Curiosamente, los paquetes truncados están construidos con protocolo IP, obviamente esto sucede por el truncamiento de los paquetes ICMP, al ser estos demasiado grandes, generan los paquetes IP necesarios para transmitir el resto del mensaje.
Práctica 2: Ejercicio 2-E
2.e. ¿Para qué se pueden emplear los campos “Identificación”, “Flags” y “Fragment offset” de los datagramas IP?
El campo “Identificación” corresponde con la identificación del paquete emitido, es decir, corresponde con “el número de serie” del paquete, todos los paquetes emitidos tendrán una identificación distinta. En este caso, como trabajamos con paquetes ICMP y nos sirven para realizar el control de la conexión tanto los paquetes “Echo request” y “Echo reply” tienen la misma identificación para que se interpreten como si fuesen el mismo.
El campo “Flags” corresponde con la información del truncamiento del mensaje, este parámetro informa sobre: el primer bit estará reservado para aplicaciones futuras, el segundo bit informará si el paquete se puede truncar o no, a 0 si se puede truncar, a 1 si no se puede truncar, el tercer bit informa si vienen más paquetes truncados relacionados con este mismo paquete después.
El campo “Fragment offset” informa sobre el número de bits que anteceden a la información de este paquete, si es el primer paquete, obviamente, este parámetro valdrá cero, en caso contrario informará del número de bits de datos que le preceden.
El campo “Identificación” corresponde con la identificación del paquete emitido, es decir, corresponde con “el número de serie” del paquete, todos los paquetes emitidos tendrán una identificación distinta. En este caso, como trabajamos con paquetes ICMP y nos sirven para realizar el control de la conexión tanto los paquetes “Echo request” y “Echo reply” tienen la misma identificación para que se interpreten como si fuesen el mismo.
El campo “Flags” corresponde con la información del truncamiento del mensaje, este parámetro informa sobre: el primer bit estará reservado para aplicaciones futuras, el segundo bit informará si el paquete se puede truncar o no, a 0 si se puede truncar, a 1 si no se puede truncar, el tercer bit informa si vienen más paquetes truncados relacionados con este mismo paquete después.
El campo “Fragment offset” informa sobre el número de bits que anteceden a la información de este paquete, si es el primer paquete, obviamente, este parámetro valdrá cero, en caso contrario informará del número de bits de datos que le preceden.
Práctia 2: Ejercicio 2-F
2.f. A continuación, se pretende observar que los datagramas pueden fragmentarse en unidades más pequeñas si tienen que atravesar redes en las que la MTU es menor a la red inicial en la que se lanzaron los paquetes originales.
Inicia el Monitor de Red y captura los paquetes IP relacionados con el siguiente comando:
C:\>ping –n 1 –l 1600 10.3.7.0
(antes de contestar debes confirmar que en MSDOS el resultado del ping es correcto: paquetes enviados:1 , paquetes recibidos:1)
Indica el número total de datagramas en la red e identifica si son de petición o de respuesta (dirección):
Como la conexión del router de enlace al exterior de nuestra LAN con la máquina 10.3.7.0 sólo puede hacer con paquetes de 500 bytes, ya que MTU de esa red es de 500 bytes y el primer paquete ICMP es de 1514 bytes, el router truncará los datos de llegada en varios paquetes para poder adaptar los datos a la red. Estos paquetes truncados no los observaremos en nuestro monitor de red ya que se producen en otra LAN independiente. Sin embargo, los paquetes que van de la maquina 10.3.7.0 al router de enlace y de este último a nuestra máquina, serán con el MTU de la red externa ya que no se producirá el ensamblamiento de los paquetes hasta que llegue a nuestra máquina y por esa razón recibimos 4 paquetes de información.
Inicia el Monitor de Red y captura los paquetes IP relacionados con el siguiente comando:
C:\>ping –n 1 –l 1600 10.3.7.0
(antes de contestar debes confirmar que en MSDOS el resultado del ping es correcto: paquetes enviados:1 , paquetes recibidos:1)
Indica el número total de datagramas en la red e identifica si son de petición o de respuesta (dirección):
Como la conexión del router de enlace al exterior de nuestra LAN con la máquina 10.3.7.0 sólo puede hacer con paquetes de 500 bytes, ya que MTU de esa red es de 500 bytes y el primer paquete ICMP es de 1514 bytes, el router truncará los datos de llegada en varios paquetes para poder adaptar los datos a la red. Estos paquetes truncados no los observaremos en nuestro monitor de red ya que se producen en otra LAN independiente. Sin embargo, los paquetes que van de la maquina 10.3.7.0 al router de enlace y de este último a nuestra máquina, serán con el MTU de la red externa ya que no se producirá el ensamblamiento de los paquetes hasta que llegue a nuestra máquina y por esa razón recibimos 4 paquetes de información.
Práctica 2: Ejercicio 3-Mensaje ICMP “Destination Unreachable”
Para la elavoración del tercer ejercicio de la práctica 2 vamos a desarrollar dos dos siguientes entradas en este blog. Para ello vamos a realizar los siguientes pasos:
Dentro del mensaje ICMP Destination Unreachable se analizará el de código 4: Fragmentation Needed and Don't Fragment was Set (3/4). En primer lugar ejecuta el comando:
C:\>route delete 10.3.7.0 ( si ya ha sido borrada la ruta, avisa con un error)
¿Porqué ejecutar este comando? En MS Windows, con route se modifican las tablas de encaminamiento de una máquina. Con la opción delete eliminamos un camino o ruta a la dirección especificada. Al eliminarlo, borramos también cualquier información asociada a esa dirección, incluida la información sobre errores previos al acceder a ese destino.
A continuación, poner en marcha el Monitor de Red en modo captura y ejecutar el comando ping:
C:\>ping -n 1 –l 1000 -f 10.3.7.0
(…la opción –f impide la fragmentación de los datagramas en la red)
En base a los paquetes capturados, indicar:
Dentro del mensaje ICMP Destination Unreachable se analizará el de código 4: Fragmentation Needed and Don't Fragment was Set (3/4). En primer lugar ejecuta el comando:
C:\>route delete 10.3.7.0 ( si ya ha sido borrada la ruta, avisa con un error)
¿Porqué ejecutar este comando? En MS Windows, con route se modifican las tablas de encaminamiento de una máquina. Con la opción delete eliminamos un camino o ruta a la dirección especificada. Al eliminarlo, borramos también cualquier información asociada a esa dirección, incluida la información sobre errores previos al acceder a ese destino.
A continuación, poner en marcha el Monitor de Red en modo captura y ejecutar el comando ping:
C:\>ping -n 1 –l 1000 -f 10.3.7.0
(…la opción –f impide la fragmentación de los datagramas en la red)
En base a los paquetes capturados, indicar:
Práctica 2: Ejercicio 3-A
3.a. Identifica las direcciones IP/MAC de los paquetes IP involucrados. ¿A qué equipos pertenecen? (identifica la máquina con la topología del anexo)
Como podemos observar, el primer paquete de información corresponde a la petición de ping de nuestra máquina con la máquina que posee la IP 10.3.7.0, con un mensaje de una longitu de 1028 bytes sin fraccionar.
Esta es la contestación del router 10.4.2.5 que es la puerta de enlace de nuestra red local con la red de la máquina con la que deseábamos hacer ping. Esta máquina al no poder fraccionar nuestra petición de ping, y esta petición excede el MTU de la red a la que deseamos acceder, por lo tanto el mensaje no podrá pasar y nos contestarán con el mensaje de error. Podemos identificar que el error reconocido es de tipo 3 [Type 3 (destination unrechable)] y corresponde con el código 4 [code 4(fragmentation needed)]. En el monitor de red podemos observar que el error que produce este mensaje es exactamente el mensaje de ping enviado en la petición anterior ya que el mensaje tiene la misma identificación en ambos casos [0x3436 (13416)].
Como podemos observar, el primer paquete de información corresponde a la petición de ping de nuestra máquina con la máquina que posee la IP 10.3.7.0, con un mensaje de una longitu de 1028 bytes sin fraccionar.
Esta es la contestación del router 10.4.2.5 que es la puerta de enlace de nuestra red local con la red de la máquina con la que deseábamos hacer ping. Esta máquina al no poder fraccionar nuestra petición de ping, y esta petición excede el MTU de la red a la que deseamos acceder, por lo tanto el mensaje no podrá pasar y nos contestarán con el mensaje de error. Podemos identificar que el error reconocido es de tipo 3 [Type 3 (destination unrechable)] y corresponde con el código 4 [code 4(fragmentation needed)]. En el monitor de red podemos observar que el error que produce este mensaje es exactamente el mensaje de ping enviado en la petición anterior ya que el mensaje tiene la misma identificación en ambos casos [0x3436 (13416)].
Práctica 2: Ejercicio 4-Mensaje ICMP “Redirect”
Ahora trataremos de explicar el mensaje ICMP Redirect, para ello hemos desarrollado las siguientes entradas. Para realizar esta parte de la práctica dos, debemos hacer lo siguiente:
Inicia el Monitor de Red. A continuación ejecutar los comandos:
C:\>route delete 10.4.2.1 (si ya ha sido borrada la ruta, avisa con un error)
C:\>ping -n 1 10.4.2.1
(antes de contestar debes confirmar que en MSDOS el resultado del Ping es correcto: paquetes enviados:1 , paquetes recibidos:1, sino debes repetir los dos comandos anteriores y el proceso de captura en el Monitor de Red)
En base a los paquetes capturados, filtra sólo los datagramas que contengan tu dirección IP y contesta a las siguientes preguntas:
Inicia el Monitor de Red. A continuación ejecutar los comandos:
C:\>route delete 10.4.2.1 (si ya ha sido borrada la ruta, avisa con un error)
C:\>ping -n 1 10.4.2.1
(antes de contestar debes confirmar que en MSDOS el resultado del Ping es correcto: paquetes enviados:1 , paquetes recibidos:1, sino debes repetir los dos comandos anteriores y el proceso de captura en el Monitor de Red)
En base a los paquetes capturados, filtra sólo los datagramas que contengan tu dirección IP y contesta a las siguientes preguntas:
Práctica 2: Ejercicio 3-B
3.b. ¿Qué máquina de la red envía el mensaje ICMP “Fragmentation Needed and Don't Fragment was Set” (3/4)? (identifica la máquina con la topología del anexo)
Como ya hemos dicho, este mensaje de error que se envía será producido por el router de acceso a la red local de la máquina 10.3.7.0, más concretamente al router que responde a la dirección IP 10.4.2.5, ya que es esta máquina la encargada de adaptar los paquetes que le llegan a la red. Por lo tanto esta sería la encargada de coger el paquete de 1028 bytes y fraccionarlo en los necesarios para adaptar el paquete a la red, pero como nosotros hemos activado el bit que imposibilita el fraccionamiento del paquete original, el router no puede fraccionarlo y produce el error nombrado.
Como ya hemos dicho, este mensaje de error que se envía será producido por el router de acceso a la red local de la máquina 10.3.7.0, más concretamente al router que responde a la dirección IP 10.4.2.5, ya que es esta máquina la encargada de adaptar los paquetes que le llegan a la red. Por lo tanto esta sería la encargada de coger el paquete de 1028 bytes y fraccionarlo en los necesarios para adaptar el paquete a la red, pero como nosotros hemos activado el bit que imposibilita el fraccionamiento del paquete original, el router no puede fraccionarlo y produce el error nombrado.
Práctica 2: Ejercicio 4-A
4.a. ¿Cuántos datagramas IP están involucrados en todo el proceso? Descríbelos…(tipo, código y tamaño)
En este proceso intervienen tres tramas de Ethernet, en el monitor de red aparecen 4 ya que el primer paquete, por un problema de configuración en el monitor de red, se dobla automáticamente. Estos mensajes corresponden: el primero corresponde con nuestra petición de ping a través del la puerta de enlace predeterminada, el segundo paquete corresponde con el mensaje de error del router de la puerta de enlace predeterminada, que nos informa de que este no es el camino más oportuno para llegar a la máquina 10.4.2.1. El tercer mensaje corresponde con la respuesta de la puerta de enlace secundaría por la que llegaremos a la máquina 10.2.4.1.
En este proceso intervienen tres tramas de Ethernet, en el monitor de red aparecen 4 ya que el primer paquete, por un problema de configuración en el monitor de red, se dobla automáticamente. Estos mensajes corresponden: el primero corresponde con nuestra petición de ping a través del la puerta de enlace predeterminada, el segundo paquete corresponde con el mensaje de error del router de la puerta de enlace predeterminada, que nos informa de que este no es el camino más oportuno para llegar a la máquina 10.4.2.1. El tercer mensaje corresponde con la respuesta de la puerta de enlace secundaría por la que llegaremos a la máquina 10.2.4.1.
Práctica 2: Ejercicio 4-B
4.b. ¿Las direcciones MAC e IP de todas las tramas capturadas con el Monitor de Red hacen referencia al mismo interfaz de red? Indica en qué casos la respuesta es afirmativa y en qué casos la dirección IP especifica un interfaz de red que no se corresponde con el mismo interfaz indicado por la MAC.
El primer y segundo paquetes si corresponde a la misma interfaz, debido a que es la misma máquina la que responde, respondiendo con su dirección IP y su MAC. Sin embargo, el último paquete del conjunto, no lo es, ya que la dirección IP y la MAC no corresponden con la misma máquina, la dirección IP corresponde con la dirección deseada, mientras que la dirección MAC es la dirección de la puerta de enlace a través de la que debemos pasar para llegar a la máquina deseada, esto es así porque la máquina en cuestión está fuera de nuestra red local.
El primer y segundo paquetes si corresponde a la misma interfaz, debido a que es la misma máquina la que responde, respondiendo con su dirección IP y su MAC. Sin embargo, el último paquete del conjunto, no lo es, ya que la dirección IP y la MAC no corresponden con la misma máquina, la dirección IP corresponde con la dirección deseada, mientras que la dirección MAC es la dirección de la puerta de enlace a través de la que debemos pasar para llegar a la máquina deseada, esto es así porque la máquina en cuestión está fuera de nuestra red local.
Práctica 2: Ejercicio 4-C
4.c. ¿Qué máquina o interfaz de red envía el mensaje ICMP Redirect?
El router que realiza la conexión entre nuestra red local y la red de la máquina con la que queríamos contactar debido a que en sus tablas de direccionamiento indica que para llegar a la máquina que nos interesa, en la red local donde se encuentra existe otra puerta de enlace, por el cual el camino de conexión es más optimo debido a que será más corto, por lo tanto, informa a nuestra máquina que la próxima vez que desee contactar con la máquina 10.4.2.1 lo realice por la otra puerta de enlace.
El router que realiza la conexión entre nuestra red local y la red de la máquina con la que queríamos contactar debido a que en sus tablas de direccionamiento indica que para llegar a la máquina que nos interesa, en la red local donde se encuentra existe otra puerta de enlace, por el cual el camino de conexión es más optimo debido a que será más corto, por lo tanto, informa a nuestra máquina que la próxima vez que desee contactar con la máquina 10.4.2.1 lo realice por la otra puerta de enlace.
Práctica 2: Ejercicio 4-D
4.d. ¿Qué dato importante para tu PC transporta en su interior ese mensaje de Redirect?
Dentro de este se encuentra la dirección IP de la otra puerta de enlace por la que el camino de conexión con la máquina deseada es el más óptimo. Este campo aparece dentro de la información del mensaje como (Gateway address: 172.20.43.231)
Dentro de este se encuentra la dirección IP de la otra puerta de enlace por la que el camino de conexión con la máquina deseada es el más óptimo. Este campo aparece dentro de la información del mensaje como (Gateway address: 172.20.43.231)
Práctica 2: Ejercicio 4-E
4.e. Observa los campos “Identificación”, “TTL” y “Cheksum” del datagrama que se envió originalmente. A continuación, analiza el contenido del mensaje Redirect. ¿Puedes encontrar la misma identificación dentro de los datos (no cabecera) del mensaje ICMP Redirect? ¿Qué ocurre con los campos TTL y Cheksum del datagrama transportado por el Redirect?
Mensaje enviado por mi (ping)
Estos son los parámetros que observamos en los dos paquetes. En el paquete “ICMP Redirect” podemos encontrar: la dirección del nuevo router para que sea más eficiente la transmisión y la misma cabecera del mensaje que había sido enviado inicialmente. La información de la cabecera se encuentra dentro del campo del mensaje del protocolo de Internet. Aparece, en primer lugar, el tipo de mensaje, código y cheksum, y acto seguido, el nuevo enrutamiento y los datos del mensaje anterior. Esta información, redundante del mensaje anterior, se trasmite en los datos del mensaje, para que la máquina receptora tenga constancia del mensaje exacto que ha producido el error.
Mensaje enviado por mi (ping)
Estos son los parámetros que observamos en los dos paquetes. En el paquete “ICMP Redirect” podemos encontrar: la dirección del nuevo router para que sea más eficiente la transmisión y la misma cabecera del mensaje que había sido enviado inicialmente. La información de la cabecera se encuentra dentro del campo del mensaje del protocolo de Internet. Aparece, en primer lugar, el tipo de mensaje, código y cheksum, y acto seguido, el nuevo enrutamiento y los datos del mensaje anterior. Esta información, redundante del mensaje anterior, se trasmite en los datos del mensaje, para que la máquina receptora tenga constancia del mensaje exacto que ha producido el error.
Práctica 2:Ejercicio 5-Mensaje ICMP “Time Exceeded"
Las tres entradas sucesivas estarán dediacas a la realización del ejercicio 5 de la práctica 2. Dentro de estos apartados inntaremos comprender el contendio del mensaje ICMP "Time Exceeded". Se analizará el de código 0: Time to Live exceeded in Transit (11/0). Para ello en cada subapartado habrá unas indicaciones que necesitaremos ejecutar para contestar las posteriores preguntas. Los ejercicios són:
Práctica 2: Ejercicio 5-A
5.a. En primer lugar, inicia el monitor de red para capturar paquetes IP relacionados con la máquina del alumno y ejecuta el comando:
C:\> ping –i 1 –n 1 10.3.7.0
Finaliza la captura e indica máquina que envía el mensaje “ICMP Time to Live exceeded in Transit”… ¿Puedes saber su IP y su MAC? (identifica la máquina en la topología del anexo)
La máquina de la que procede en mensaje de tiempo excedido es el router con ip 172.43.20.230 (MAC 00:07:0e:8c:8c:ff), ya que es la maquina en la que el contador de nuestro datagrama a expirado. Esta máquina concretamente es la que sirve como la puerta de enlace de nuestra red local y es por la primera máquina por la que ha pasado el mensaje desde que lo hemos emitido.
C:\> ping –i 1 –n 1 10.3.7.0
Finaliza la captura e indica máquina que envía el mensaje “ICMP Time to Live exceeded in Transit”… ¿Puedes saber su IP y su MAC? (identifica la máquina en la topología del anexo)
La máquina de la que procede en mensaje de tiempo excedido es el router con ip 172.43.20.230 (MAC 00:07:0e:8c:8c:ff), ya que es la maquina en la que el contador de nuestro datagrama a expirado. Esta máquina concretamente es la que sirve como la puerta de enlace de nuestra red local y es por la primera máquina por la que ha pasado el mensaje desde que lo hemos emitido.
Práctica 2: Ejercicio 5-C
5.c. Por último, inicia de nuevo la captura y realiza un ping a la siguiente dirección:
C:\> ping –i 50 –n 1 10.3.7.12
Finaliza la captura y observa el mensaje de error ICMP que aparece en el monitor de red. ¿Qué tipo y código tiene asociado ese mensaje? ¿Qué crees que está sucediendo al intentar conectarte a esa máquina y obtener ese mensaje de error? ¿En qué subred estaría ubicada?
De nuevo se está produciendo un error de expiración del tiempo de vida del datagrama. El problema reside en que estamos intentando contactar con una máquina inexistente. Como el ordenador debería estar ubicado en una red externa, nuestra petición viaja hasta la red en concreto y allí busca a la máquina en cuestión, este mensaje se repite tantas veces como para que se extinga su vida. Cuando esto sucede la máquina en la que el tiempo expira definitivamente manda un mensaje de error a la máquina que solicito la petición de ping.
C:\> ping –i 50 –n 1 10.3.7.12
Finaliza la captura y observa el mensaje de error ICMP que aparece en el monitor de red. ¿Qué tipo y código tiene asociado ese mensaje? ¿Qué crees que está sucediendo al intentar conectarte a esa máquina y obtener ese mensaje de error? ¿En qué subred estaría ubicada?
De nuevo se está produciendo un error de expiración del tiempo de vida del datagrama. El problema reside en que estamos intentando contactar con una máquina inexistente. Como el ordenador debería estar ubicado en una red externa, nuestra petición viaja hasta la red en concreto y allí busca a la máquina en cuestión, este mensaje se repite tantas veces como para que se extinga su vida. Cuando esto sucede la máquina en la que el tiempo expira definitivamente manda un mensaje de error a la máquina que solicito la petición de ping.
Práctica 2: Ejercicio 5-B
5.b. Inicia de nuevo la captura y ejecuta a continuación el comando:
C:\> ping –i 2 –n 1 10.3.7.0
Finaliza la captura y determina qué máquina envía ahora el mensaje “ICMP Time to Live exceded in Transit”… Averigua y anota la IP y la MAC origen de este mensaje de error. ¿Pertenecen ambas direcciones a la misma máquina? (identifica las máquinas en la topología del anexo)
La máquina de la que procede en mensaje de tiempo excedido es el router con IP 10.4.2.5 que corresponde con el segundo router de encaminamiento de nuestra red local. La dirección MAC de la que procede es la 00:07:0e:8c:8c:ff que corresponde con la de la puerta de enlace. En este punto de la conexión el contador de nuestro datarama a expirado sin llegar a el lugar debido, más en concreto hemos llegado hasta el segundo router para finalizar espirando su tiempo de vida produciendo un mensaje de error.
C:\> ping –i 2 –n 1 10.3.7.0
Finaliza la captura y determina qué máquina envía ahora el mensaje “ICMP Time to Live exceded in Transit”… Averigua y anota la IP y la MAC origen de este mensaje de error. ¿Pertenecen ambas direcciones a la misma máquina? (identifica las máquinas en la topología del anexo)
La máquina de la que procede en mensaje de tiempo excedido es el router con IP 10.4.2.5 que corresponde con el segundo router de encaminamiento de nuestra red local. La dirección MAC de la que procede es la 00:07:0e:8c:8c:ff que corresponde con la de la puerta de enlace. En este punto de la conexión el contador de nuestro datarama a expirado sin llegar a el lugar debido, más en concreto hemos llegado hasta el segundo router para finalizar espirando su tiempo de vida produciendo un mensaje de error.
Práctica 2: Ejercicio 6
Las dos siguiente entradas se pasará a realizar el sexto ejercicio de la segunda práctica. Para ello hemos de realizar los siguientes pasos:
En esta cuestión se analizará el mensaje ICMP tipo 11 código 1. Para ello, se va a intentar “saturar” a una determinada máquina del laboratorio enviándole un número elevado de peticiones Ping. Este elevado número de peticiones puede producir un error si la máquina destino tiene que realizar un reensamblado excesivo de paquetes en un tiempo limitado.
Iniciar el programa monitor de red. A continuación ejecutar el comando “Ping” en varias ventanas (en paralelo) de MSDOS, así lograrás mayor número de peticiones:
C:\>ping -n 80 -l 20000 10.3.7.0
Una vez detenida la captura del monitor tendremos una captura como la que se muestra abajo, a partir de ella determinar los distintos apartados:
En esta cuestión se analizará el mensaje ICMP tipo 11 código 1. Para ello, se va a intentar “saturar” a una determinada máquina del laboratorio enviándole un número elevado de peticiones Ping. Este elevado número de peticiones puede producir un error si la máquina destino tiene que realizar un reensamblado excesivo de paquetes en un tiempo limitado.
Iniciar el programa monitor de red. A continuación ejecutar el comando “Ping” en varias ventanas (en paralelo) de MSDOS, así lograrás mayor número de peticiones:
C:\>ping -n 80 -l 20000 10.3.7.0
Una vez detenida la captura del monitor tendremos una captura como la que se muestra abajo, a partir de ella determinar los distintos apartados:
Práctica 2: Ejercicio 6-A
6.a. ¿De que máquina proceden los mensajes ICMP “Fragment Reassembly Time Exceded”? (identifica la máquina en la topología del anexo)
La máquina de la que proceden es la máquina con la que deseábamos hacer el ping. El error que causa este datagrama es por exceder el tiempo de reconstrucción de un datagrama en concreto. Esto es, cada petición que le hemos mandado ha iniciado un contador pequeño que va desde el momento de emisión hasta que la tarjeta de red es capaz de reconstruir el mismo, si excedemos este contador y su tiempo expira, el ordenador interpretará que el mensaje posee errores.
Como hemos mandado muchos mensajes muy largos, estos han sido fraccionados, pero como eran tantos mensajes eran demasiados fragmentos y se han producido retardos en la conexión. Por eso se manda este mensaje.
La máquina de la que proceden es la máquina con la que deseábamos hacer el ping. El error que causa este datagrama es por exceder el tiempo de reconstrucción de un datagrama en concreto. Esto es, cada petición que le hemos mandado ha iniciado un contador pequeño que va desde el momento de emisión hasta que la tarjeta de red es capaz de reconstruir el mismo, si excedemos este contador y su tiempo expira, el ordenador interpretará que el mensaje posee errores.
Como hemos mandado muchos mensajes muy largos, estos han sido fraccionados, pero como eran tantos mensajes eran demasiados fragmentos y se han producido retardos en la conexión. Por eso se manda este mensaje.
Práctica 2: Ejercicio 6-B
6.b. ¿Por qué crees que pueden proceder de esa máquina y no de otra?
El error es producido por la máquina con la que deseábamos realizar ping. Esto es debido a que hemos mandado demasiados paquetes y la tarjeta no ha sido capaz de reconstruirlos a tiempo. Es la máquina receptora del datagrama la encargada de producir el mensaje de “imposible reensamblar el mensaje que me has mandado, tiempo excedido”.
El error es producido por la máquina con la que deseábamos realizar ping. Esto es debido a que hemos mandado demasiados paquetes y la tarjeta no ha sido capaz de reconstruirlos a tiempo. Es la máquina receptora del datagrama la encargada de producir el mensaje de “imposible reensamblar el mensaje que me has mandado, tiempo excedido”.
Práctica 2: Ejercicio 7-Cuestión 7-Sobre direccionamiento IP y creación de subredes
En las dos siguientes entradas se van a tratar de explicar los apartados del séptimo ejercicio de la segunda práctica:
Práctica 2: Ejercicio 7-A
7.a Dada la dirección de clase B 145.65.0.0, se desean 6 subredes. ¿Cuántos bits se tendrán que reservar para crear las subredes? Indica el valor decimal de las subredes, así como el valor de la nueva máscara de subred.
La dirección IP 145.65.0.0 es la dirección de red de esta subred y su máscara, al especificar que es de clase B, por lo tanto es una red mediana, es 255.255.0.0, o lo que es lo mismo en binario:11111111.11111111.00000000.00000000 . Si deseamos crear 6 subredes más debemos ocupar 3 bits para realizar todas las combinaciones necesarias. Por lo tanto la nueva máscara de red para las 6 subredes debe ser, en binario: 11111111. 11111111.11100000. 00000000, o lo que es lo mismo en decimal: 255.255.224.0. Las nuevas subredes se repartirán las distintas direcciones IP, en un principio en partes iguales, para formar las seis subredes.
La dirección IP 145.65.0.0 es la dirección de red de esta subred y su máscara, al especificar que es de clase B, por lo tanto es una red mediana, es 255.255.0.0, o lo que es lo mismo en binario:11111111.11111111.00000000.00000000 . Si deseamos crear 6 subredes más debemos ocupar 3 bits para realizar todas las combinaciones necesarias. Por lo tanto la nueva máscara de red para las 6 subredes debe ser, en binario: 11111111. 11111111.11100000. 00000000, o lo que es lo mismo en decimal: 255.255.224.0. Las nuevas subredes se repartirán las distintas direcciones IP, en un principio en partes iguales, para formar las seis subredes.
Práctica 2: Ejercicio 7-B
7.b Sea la dirección de red IP 125.145.64.0 con máscara asociada 255.255.254.0. Ampliar la máscara de subred en dos bits, indicando el nuevo valor. Determina el rango de direcciones IP que puede emplearse para numerar máquinas en cada una de las subredes obtenidas en la ampliación.
Si la máscara de red que tenemos es la 255.255.254.0, significa que estamos ante una red que tiene la siguiente notación decimal: 11111111.11111111.11111110.00000000 . Si ampliamos en 2 bits la máscara para tener hasta 4 subredes, el valor de la nueva máscara será 11111111.11111111.11111111.10000000 y su valor en notación decimal es: 255.255.255.128. Por lo tanto esta máscara dará lugar a otras 4 posibles máscaras. Sus posibles combinaciones podrían ser:
Si la máscara de red que tenemos es la 255.255.254.0, significa que estamos ante una red que tiene la siguiente notación decimal: 11111111.11111111.11111110.00000000 . Si ampliamos en 2 bits la máscara para tener hasta 4 subredes, el valor de la nueva máscara será 11111111.11111111.11111111.10000000 y su valor en notación decimal es: 255.255.255.128. Por lo tanto esta máscara dará lugar a otras 4 posibles máscaras. Sus posibles combinaciones podrían ser:
dijous, 18 de març del 2010
PRÁCTICA 1
A continuación de realizará unas entradas para explicar los ejercicios que se han realizado para la primera práctica de la asignatura "Redes de Ordenadores".
El objetivo de esta práctica es realizar un estudio de una Red de Área Local (LAN) en la cual se implementa una arquitectura TCP/IP. Una razón para análizar este tipo de red es que se ha convertido en un estándar a global.
Con esta práctica intentaremos comprender conceptos básicos como, los niveles de la arquitectura TCP/IP. Aprender a interpretar protocolos de Enthernet II, más en concreto ARP e IP a través de un software que actuará como monitor de red. También explicaremos el esquema empleado por el protocolo IP. Consiguiendo así, analizar los diferentes paquetes que se capturen con el monitor de red
El objetivo de esta práctica es realizar un estudio de una Red de Área Local (LAN) en la cual se implementa una arquitectura TCP/IP. Una razón para análizar este tipo de red es que se ha convertido en un estándar a global.
Con esta práctica intentaremos comprender conceptos básicos como, los niveles de la arquitectura TCP/IP. Aprender a interpretar protocolos de Enthernet II, más en concreto ARP e IP a través de un software que actuará como monitor de red. También explicaremos el esquema empleado por el protocolo IP. Consiguiendo así, analizar los diferentes paquetes que se capturen con el monitor de red
Practica 1: Ejercicio 1-Iniciación al monitor de red. Visualización general de protocolos en la red
Las cuatro siguietes entradas tienen el proposito de explicar el desarrollo del primer ejercio de la práctica 1. Para la ejecución de este ejercicio, se debe realizar lo sieguiente:
Activa el monitor de red y captura todo tipo de tráfico en la red durante unos segundos. Paraliza la captura y visualiza…
Una vez hecho esto, pasamos a la realización de los ejercicios:
Activa el monitor de red y captura todo tipo de tráfico en la red durante unos segundos. Paraliza la captura y visualiza…
Una vez hecho esto, pasamos a la realización de los ejercicios:
Práctica 1: Ejercicio 1-A
1.a Del conjunto de datos adquiridos, filtrar los que estén dirigidas a la máquina del alumno. ¿Cuántas tramas aparecen?
Como podemos observar, durante el tiempo de captura del programa la red ha trabajado con 797 paquetes de red, pero solo 360 contienen información dirigida nuestra máquina, los otros 437 son paquetes de protocolo “nbns”, que corresponde con unas tramas que genera los ordenadores internamente, o paquetes que se dirigen a otras máquinas dentro de la red.
Somos capaces de distinguir cuantos paquetes recibimos en nuestra máquina, ya que utilizamos el filtro: “ip.dst==direcciónIP” que sólo nos mostrará la cantidad de paquetes que van dirigidas a nuestra máquina.
Como podemos observar, durante el tiempo de captura del programa la red ha trabajado con 797 paquetes de red, pero solo 360 contienen información dirigida nuestra máquina, los otros 437 son paquetes de protocolo “nbns”, que corresponde con unas tramas que genera los ordenadores internamente, o paquetes que se dirigen a otras máquinas dentro de la red.
Somos capaces de distinguir cuantos paquetes recibimos en nuestra máquina, ya que utilizamos el filtro: “ip.dst==direcciónIP” que sólo nos mostrará la cantidad de paquetes que van dirigidas a nuestra máquina.
Práctica 1: Ejercicio 1-B
1.b Del conjunto de datos adquiridos, filtrar los que proceden de la máquina del alumno. ¿Cuántas tramas visualizas ahora?
Del total de los 797 paquetes que han sido capturados sólo 320 del total de los paquetes son enviados por el usuario a la red. Esto lo podremos saber utilizando el comando “ip.src==direcciónIP”, que nos mostrará sólo los paquetes que estemos enviado nosotros.
Del total de los 797 paquetes que han sido capturados sólo 320 del total de los paquetes son enviados por el usuario a la red. Esto lo podremos saber utilizando el comando “ip.src==direcciónIP”, que nos mostrará sólo los paquetes que estemos enviado nosotros.
Práctica 1: Ejercicio 1-C
1.c Ahora filtra los datos cuyo origen o destino sea la máquina del alumno. ¿Qué número de tramas se visualizan? ¿Es coherente este valor con los resultados anteriores?
Para saber el números de tramas que entran y salen de nuestra máquina, debemos usar el filtro “ip.addr==direcciónIP”, el cual nos facilitará la información deseada en este propósito. En nuestro caso, el total de las tramas que entran y salen de nuestro ordenador durante el tiempo de captura es de 680 y es un valor totalmente lógico ya que supone la suma de los paquetes de entrada y de salida de nuestro ordenador.
Para saber el números de tramas que entran y salen de nuestra máquina, debemos usar el filtro “ip.addr==direcciónIP”, el cual nos facilitará la información deseada en este propósito. En nuestro caso, el total de las tramas que entran y salen de nuestro ordenador durante el tiempo de captura es de 680 y es un valor totalmente lógico ya que supone la suma de los paquetes de entrada y de salida de nuestro ordenador.
Practica 1: Ejercicio 1-D
1.d A continuación, filtra los datos en los que esté presente el protocolo HTTP. ¿Qué otros protocolos observas en el interior de la trama además del HTTP?
Utilizando el filtro del programa, utilizando el comando “http”, aparecen la siguiente lista de protocolos: Enthernet II, Internet Protocol (IP) y Transmission Control Protocol (TCP) e Hypertext Tranfer Protocol. Estos corresponden con los diferentes niveles o protocolos que usaríamos para la configuración de la trama de datos, desde el nivel de enlace, “Enthernet II”, hasta la aplicación, que sería “http”, Hypertext tranfer protoco.
Utilizando el filtro del programa, utilizando el comando “http”, aparecen la siguiente lista de protocolos: Enthernet II, Internet Protocol (IP) y Transmission Control Protocol (TCP) e Hypertext Tranfer Protocol. Estos corresponden con los diferentes niveles o protocolos que usaríamos para la configuración de la trama de datos, desde el nivel de enlace, “Enthernet II”, hasta la aplicación, que sería “http”, Hypertext tranfer protoco.
Práctica 1: Ejercicio 2-Análisis estadístico de una captura de datos
Las cuatro siguientes 4 entradas están dedicadas a la ejecución del segundo ejercicio de la práctica 2. Para la realización de este ejerciocio debemos ejecutar las siguientes insturcciones:
A partir de una conexión y descarga de datos en la red se determinará cierta información que aparece en la misma. En primer lugar se iniciará el monitor de red y se realizarán las siguientes acciones para generar tráfico:
Con el navegador, realiza la descarga del programa PUTTY:
http://tartarus.org/~simon/putty-snapshots/x86/putty.zip
A continuación, una vez paralizada la captura. Con los datos obtenidos debes responder a las siguientes cuestiones:
Una vez realizado todo esto, pasamos al desarrollo de los ejercicios:
A partir de una conexión y descarga de datos en la red se determinará cierta información que aparece en la misma. En primer lugar se iniciará el monitor de red y se realizarán las siguientes acciones para generar tráfico:
Con el navegador, realiza la descarga del programa PUTTY:
http://tartarus.org/~simon/putty-snapshots/x86/putty.zip
A continuación, una vez paralizada la captura. Con los datos obtenidos debes responder a las siguientes cuestiones:
Una vez realizado todo esto, pasamos al desarrollo de los ejercicios:
Práctica 1: Ejercicio 2-A
2.a Calcula el porcentaje de paquetes IP existentes en la captura. (Paquetes IP / tramas totales *100).
El número total de paquetes de la captura es 4277. En total, los paquetes IP lanzados a la red son 3783 lo que supone un 91.11% de los paquetes en la captura. El resto de paquetes que han sido recibidos durante la captura serán paquetes de información creados por la propia tarjeta de red (nbns!).
Para conseguir visualizar únicamente los paquetes de IP hemos usado el filtro:
‘ip.addr== “direcciónIP” && !nbns’.
El número total de paquetes de la captura es 4277. En total, los paquetes IP lanzados a la red son 3783 lo que supone un 91.11% de los paquetes en la captura. El resto de paquetes que han sido recibidos durante la captura serán paquetes de información creados por la propia tarjeta de red (nbns!).
Para conseguir visualizar únicamente los paquetes de IP hemos usado el filtro:
‘ip.addr== “direcciónIP” && !nbns’.
Práctica 1: Ejercicio 2-B
2.b Calcula el porcentaje de paquetes IP enviados por la máquina del alumno.
Del total de paquetes capturados, tan sólo 2102 han sido enviados por nuestra máquina. Esto supone que el 49,14% del total de los paquetes obtenidos. Hemos conseguido diferenciar los paquetes enviados por el alumno utilizando el filtro ‘ip.src== “dirercciónIP” && !nbns’.
Del total de paquetes capturados, tan sólo 2102 han sido enviados por nuestra máquina. Esto supone que el 49,14% del total de los paquetes obtenidos. Hemos conseguido diferenciar los paquetes enviados por el alumno utilizando el filtro ‘ip.src== “dirercciónIP” && !nbns’.
Práctica 1: Ejercicio 2-C
2.c Calcula el porcentaje de segmentos TCP recibidos por la máquina del alumno.
De todos los paquetes enviados a la red durante el tiempo de captura han sido enviados 1674 paquetes de TCP a la máquina del alumno. Esto supone que el alumno ha recibido un 39,13% de paquetes TCP. Esto lo hemos conseguido introduciendo el filtro ‘ip.dst== “direcciónIP” && !nbns && TCP”.
De todos los paquetes enviados a la red durante el tiempo de captura han sido enviados 1674 paquetes de TCP a la máquina del alumno. Esto supone que el alumno ha recibido un 39,13% de paquetes TCP. Esto lo hemos conseguido introduciendo el filtro ‘ip.dst== “direcciónIP” && !nbns && TCP”.
Práctica 1: Ejercicio 2-D
2.d. Calcula el porcentaje de paquetes que contengan el protocolo DNS en su interior.
De los 4277 paquetes que han sido utilizados durante el tiempo de captura del ejercicio, únicamente 26 han sido enviados con el protocolo DNS. Esto supone que del total de paquetes, los paquetes suponen un 0,6%. Para obtener esto hemos utilizado, dentro del monitor de red, el filtro ‘ip.addr== “direcciónIP” && !nbns && DNS’.
De los 4277 paquetes que han sido utilizados durante el tiempo de captura del ejercicio, únicamente 26 han sido enviados con el protocolo DNS. Esto supone que del total de paquetes, los paquetes suponen un 0,6%. Para obtener esto hemos utilizado, dentro del monitor de red, el filtro ‘ip.addr== “direcciónIP” && !nbns && DNS’.
Práctica 1: Ejercicio 3-Tramas del nivel de Enlace (Ethernet)
Las dos siguientes entradas están dedicadas a la realización del tercer ejercicio de la primera práctica. Para su realización debíamos seguir estas indicaciones inicialmente:
A partir de una conexión y descarga de datos en la red se determinará cierta información que aparece en la misma. En primer lugar se iniciará el monitor de red y se realizarán las siguientes acciones para generar tráfico:
Con el navegador, realiza la descarga del programa PUTTY:
http://tartarus.org/~simon/putty-snapshots/x86/putty.zip
A continuación, una vez paralizada la captura. Con los datos obtenidos debes responder a las siguientes cuestiones:
Una vez realizado esto, pasamos al desarrollo de los ejercicios:
A partir de una conexión y descarga de datos en la red se determinará cierta información que aparece en la misma. En primer lugar se iniciará el monitor de red y se realizarán las siguientes acciones para generar tráfico:
Con el navegador, realiza la descarga del programa PUTTY:
http://tartarus.org/~simon/putty-snapshots/x86/putty.zip
A continuación, una vez paralizada la captura. Con los datos obtenidos debes responder a las siguientes cuestiones:
Una vez realizado esto, pasamos al desarrollo de los ejercicios:
Práctica 1: Ejercicio 3-A
3.a. ¿Qué tipo de filtro has empleado?. Indica la dirección MAC de tu máquina.
El filtro utilizado es el “eth.scr==IPdelaFuente”, consiguiendo así quedarnos sólo con las tramas de Ethernet que salgan de nuestra máquina, es decir, nos quedamos con las tramas que genera nuestro ordenador.
Dentro del monitor de red podemos observar que si pinchamos sobre cualquier paquete que proceda de nuestra máquina aparecerá la descomposición de la trama en los distintos niveles, donde podremos encontrar Frame, Ethernet II, Internet Protocol y Transmisión Control Protocol.
Si desglosamos el apartado dedicado al nivel de enlace, Ethernet II, comprobamos que nos aparecen varios subapartados con la información contenida en esta cabecera. En estos sub-apartados encontramos: “Destination”, que hace referencia a la máquina de destino de la trama de red y su dirección MAC, “Soucer”, que hace referencia a la máquina emisora de la trama de red. La dirección MAC que muestre el apartado “Soucer” corresponde exactamente con la dirección MAC de nuestra tarjeta de red, en este caso específico 00:0a:5e:76:fd:56.
También la podemos obtener esta información del icono del sistema. Si introducimos el comando “ipconfig/all” se nos facilitarán los datos de la configuración de la red, en concreto debemos consultar el dato que aparece como “dirección física” en el cual se nos informa de la dirección MAC de la tarjeta.
El filtro utilizado es el “eth.scr==IPdelaFuente”, consiguiendo así quedarnos sólo con las tramas de Ethernet que salgan de nuestra máquina, es decir, nos quedamos con las tramas que genera nuestro ordenador.
Dentro del monitor de red podemos observar que si pinchamos sobre cualquier paquete que proceda de nuestra máquina aparecerá la descomposición de la trama en los distintos niveles, donde podremos encontrar Frame, Ethernet II, Internet Protocol y Transmisión Control Protocol.
Si desglosamos el apartado dedicado al nivel de enlace, Ethernet II, comprobamos que nos aparecen varios subapartados con la información contenida en esta cabecera. En estos sub-apartados encontramos: “Destination”, que hace referencia a la máquina de destino de la trama de red y su dirección MAC, “Soucer”, que hace referencia a la máquina emisora de la trama de red. La dirección MAC que muestre el apartado “Soucer” corresponde exactamente con la dirección MAC de nuestra tarjeta de red, en este caso específico 00:0a:5e:76:fd:56.
También la podemos obtener esta información del icono del sistema. Si introducimos el comando “ipconfig/all” se nos facilitarán los datos de la configuración de la red, en concreto debemos consultar el dato que aparece como “dirección física” en el cual se nos informa de la dirección MAC de la tarjeta.
Práctica 1: Ejercicio 3-B
3.b. ¿Con qué otra dirección MAC se comunica la tarjeta de red Ethernet de tu máquina en bastantes ocasiones? ¿Sabes identificar el equipo al que pertenece esa otra dirección MAC?
Como estamos realizando una conexión a Internet para la descarga de un archivo, principalmente aparece la dirección MAC que utiliza el router de encaminamiento hacia el exterior de la red LAN, en este caso el router del laboratorio. Este router tiene una dirección MAC (00:07:0e:0c:ff) que corresponde con el “Cisco_8c:8c:ff” o lo que es lo mismo, “Cisco 140.140.255”
Como estamos realizando una conexión a Internet para la descarga de un archivo, principalmente aparece la dirección MAC que utiliza el router de encaminamiento hacia el exterior de la red LAN, en este caso el router del laboratorio. Este router tiene una dirección MAC (00:07:0e:0c:ff) que corresponde con el “Cisco_8c:8c:ff” o lo que es lo mismo, “Cisco 140.140.255”
Práctica 1: Ejercicio 4-Sobre el protocolo ARP
Las siguientes seis entradas están dedicadas a la realización del 4º ejercicio de la primera práctica de la asignatura:
Práctica 1: Ejercicio 4-A
4.a Visualiza la dirección MAC e IP de la máquina de ensayos, ejecutando el siguiente comando en una ventana de MSDOS:
ipconfig /all
Anota los valores de IP y MAC que obtienes. Con ello sabrás el direccionamiento IP y MAC de tu PC en la red local.
A continuación, activa la captura de tramas en el programa monitor de red.
En la máquina del alumno se lanzarán peticiones ‘echo’ a través del programa ping a la dirección IP 172.20.43.230, borrando previamente de la tabla ARP local la entrada asociada a esa dirección IP:
arp –a (Visualiza la tabla ARP)
arp –d (Borra una dirección IP en la tabla ARP)
ping 172.20.43.230 (Muestra la conectividad de la máquina 172.20.43.230)
En el monitor de red debes detener la captura y visualizarla. Introduce un filtro para visualizar sólo tramas ARP asociadas a la máquina del alumno…
• ¿Cuántas tramas Ethernet intervienen en el protocolo ARP?
El protocolo ARP es un conjunto de instrucciones que se utilizan dentro de una red de ordenadores a nivel de enlace. Este protocolo está pensado para que una máquina pueda conocer las direcciones MAC de las otras máquinas de la red en la que está. Existen básicamente 2 instrucciones dentro del protocolo ARP: ARP request y ARP response. ARP request es la instrucción que ejecutaría la máquina que desea saber la dirección MAC de alguna otra máquina, esta trama tiene la particularidad de dirigirse a todas las máquinas de la red, utilizando la dirección broadcast de todas ellas, y en esta trama se dice algo así como “El dispositivo que tenga la dirección IP ‘X’, por favor, comuníqueme su dirección MAC”. La otra instrucción que se utiliza en el protocolo ARP es ARP response, que corresponde con la respuesta de la comunicación, es decir, sería la contestación a la petición anterior. Esta instrucción sólo se mandará a la máquina que ejecutó el ARP request. En esta instrucción se vendría a decir algo así como “Yo soy la máquina con dirección IP ‘X’ y mi dirección MAC es ‘xx:xx:xx:xx:xx:xx’.
Tras ejecutar los comandos pedidos en el ejercicio, obtenemos en el monitor de red 3 tramas ARP. Estas 3 tramas se dividen de la siguiente manera, 2 tramas de ARP request, que corresponde con la trama que utiliza el protocolo ARP cuando una máquina pide una dirección MAC a un red, y una trama ARP response, que corresponde con la respuesta a la pregunta anterior, su dirección MAC. En realidad el protocolo ARP sólo lanza dos tramas ARP por cada petición de red, pero nuestra red, o el monitor de red, tiene un defecto y la trama de ARP request la duplica, cuando en realidad sólo se ha utilizado una vez.
• ¿Cuál es el estado de la memoria caché de ARP una vez se ha ejecutado el protocolo ARP para la resolución de una dirección?
Como podemos observar la memoria caché dedicada al almacenamiento de las direcciones IP y MAC de otras máquinas se llena rápidamente con las direcciones solicitadas. Esta memoria está pensada para que no tengamos que pedir continuamente la dirección MAC del ordenador con el que deseamos contactar. Aunque está muy bien poseer las direcciones de otros ordenadores, esta memoria se debe regenerar cada poco ya que si fuese una memoria fija tendríamos problemas si una dirección MAC con la que deseamos contactar cambiase.
• Sin que haya transcurrido mucho tiempo, captura de nuevo tramas con el monitor de red. Vuelve a ejecutar el comando ping (con la misma dirección IP destino). Paraliza la captura y observa la secuencia de tramas ARP. ¿Aparecen las mismas tramas ARP asociadas con tu máquina?
Sí, debido a que este conjunto de instrucciones se realiza constantemente para saber las direcciones como ya hemos comentado anteriormente. Este protocolo se ejecutará tantas veces como sea necesario.
ipconfig /all
Anota los valores de IP y MAC que obtienes. Con ello sabrás el direccionamiento IP y MAC de tu PC en la red local.
A continuación, activa la captura de tramas en el programa monitor de red.
En la máquina del alumno se lanzarán peticiones ‘echo’ a través del programa ping a la dirección IP 172.20.43.230, borrando previamente de la tabla ARP local la entrada asociada a esa dirección IP:
arp –a (Visualiza la tabla ARP)
arp –d
ping 172.20.43.230 (Muestra la conectividad de la máquina 172.20.43.230)
En el monitor de red debes detener la captura y visualizarla. Introduce un filtro para visualizar sólo tramas ARP asociadas a la máquina del alumno…
• ¿Cuántas tramas Ethernet intervienen en el protocolo ARP?
El protocolo ARP es un conjunto de instrucciones que se utilizan dentro de una red de ordenadores a nivel de enlace. Este protocolo está pensado para que una máquina pueda conocer las direcciones MAC de las otras máquinas de la red en la que está. Existen básicamente 2 instrucciones dentro del protocolo ARP: ARP request y ARP response. ARP request es la instrucción que ejecutaría la máquina que desea saber la dirección MAC de alguna otra máquina, esta trama tiene la particularidad de dirigirse a todas las máquinas de la red, utilizando la dirección broadcast de todas ellas, y en esta trama se dice algo así como “El dispositivo que tenga la dirección IP ‘X’, por favor, comuníqueme su dirección MAC”. La otra instrucción que se utiliza en el protocolo ARP es ARP response, que corresponde con la respuesta de la comunicación, es decir, sería la contestación a la petición anterior. Esta instrucción sólo se mandará a la máquina que ejecutó el ARP request. En esta instrucción se vendría a decir algo así como “Yo soy la máquina con dirección IP ‘X’ y mi dirección MAC es ‘xx:xx:xx:xx:xx:xx’.
Tras ejecutar los comandos pedidos en el ejercicio, obtenemos en el monitor de red 3 tramas ARP. Estas 3 tramas se dividen de la siguiente manera, 2 tramas de ARP request, que corresponde con la trama que utiliza el protocolo ARP cuando una máquina pide una dirección MAC a un red, y una trama ARP response, que corresponde con la respuesta a la pregunta anterior, su dirección MAC. En realidad el protocolo ARP sólo lanza dos tramas ARP por cada petición de red, pero nuestra red, o el monitor de red, tiene un defecto y la trama de ARP request la duplica, cuando en realidad sólo se ha utilizado una vez.
• ¿Cuál es el estado de la memoria caché de ARP una vez se ha ejecutado el protocolo ARP para la resolución de una dirección?
Como podemos observar la memoria caché dedicada al almacenamiento de las direcciones IP y MAC de otras máquinas se llena rápidamente con las direcciones solicitadas. Esta memoria está pensada para que no tengamos que pedir continuamente la dirección MAC del ordenador con el que deseamos contactar. Aunque está muy bien poseer las direcciones de otros ordenadores, esta memoria se debe regenerar cada poco ya que si fuese una memoria fija tendríamos problemas si una dirección MAC con la que deseamos contactar cambiase.
• Sin que haya transcurrido mucho tiempo, captura de nuevo tramas con el monitor de red. Vuelve a ejecutar el comando ping (con la misma dirección IP destino). Paraliza la captura y observa la secuencia de tramas ARP. ¿Aparecen las mismas tramas ARP asociadas con tu máquina?
Sí, debido a que este conjunto de instrucciones se realiza constantemente para saber las direcciones como ya hemos comentado anteriormente. Este protocolo se ejecutará tantas veces como sea necesario.
Subscriure's a:
Missatges (Atom)
