ANEXO

En una ventana de MS-DOS y dentro del directorio raíz emplea el programa ftp para enviar el fichero C:\p3.txt al servidor 172.20.41.241. Para ello, utiliza la siguiente secuencia de comandos:

C:\ftp 172.20.41.241

Connectado a 172.20.41.241

220 Linux1.disc.ua.es FTP server (Version wu-2.4.2-academ[BETA-18-VR12](1)

Wed Jan 27 22:19:46 CST 1999) ready.

Usuario (172.20.41.241:(none)):alumnos

331 Password required for alumnos.

Contraseña:alumnos

230 User alumnos logged in.

ftp> bin

200 Type set to I

ftp> put p3.txt

200 PORT command successful.

150 Opening BINARY mode data connection for rfc1191.txt

226 Transfer complete

ftp: 48730 bytes sent in 24.28 segundos 2.01 KB/s

ftp> quit

221-You have transferred 48730 bytes in 1 files.

221-Total traffic for this session was 49154 bytes in 1 transfers.

221-Thank you for using the FTP service on Linux1.disc.ua.es.

221 Goodbye.

a) Determina con el monitor de red qué valor de MSS se ha negociado en la conexión TCP. Para ello visualiza TODOS los paquetes IP intercambiados entre tu PC y el servidor 172.20.41.241.

Al principio lo empieza a transmitir con 460 pero se da cuenta que el nuevo servidor solo permite una MTU DE 400, por lo que luego cambia y nos quedamos con:MSS=360

b) ¿Hay paquetes ICMP “fragmentation needed and the bit don't fragment was set”? Si la respuesta es afirmativa, ¿qué máquina envía el mensaje de error?

Si. Uno de Destino inalcanzable y lo envía la máquina 172.20.43.231

c) ¿Cómo afecta este mensaje ICMP al tamaño de los paquetes TCP intercambiados entre tu PC y el servidor 172.20.41.241 ?

Pues que ahora solo se podrán enviar paquetes de 400 bytes y MSS de 360 bytes.

d) ¿Reenvía tu PC algún paquete TCP al servidor?

Si para decirle a 172.20.41.241 que el tamaño de los paquetes no puede ser el que ha indicado y que lo reduzca.

e) ¿Fragmenta IP algún paquete TCP ?

No

Cuestión 7.c

Una vez determinada la MTU del camino, mostrar la longitud total de cada paquete TCP construido en la fragmentación al mandar un paquete TCP original con 1500 bytes de datos. Indicar la estructura (cabeceras incluidas) de la trama Ethernet en la que se encapsulan los paquetes.

---

Cuestión 7.b

Indica la MTU del camino de camino completo.

---

La MTU del camino completo es de 500 bytes. Siempre es la menor MTU por donde tiene que pasar cada paquete. En este caso, de B a D hay una MTU de 500.

Cuestión 7.a

Número, tipo y código de paquetes ICMP.

---

1 paquete, Tipo 3 y Código 4. (Teníamos que haber visto 2 paquetes de error pero en el monitor de red solo se ve 1)

CUESTIÓN 7

En base a la topología que se muestra a continuación:

Considerando que todos los equipos presentes en dicha topología cumplen la RFC 1191. Determina el número de segmentos que se generan al mandar un paquete TCP con 1500 bytes de datos desde la máquina ‘A’ a la máquina ‘E’:

CUESTIÓN 6

Determinar el número de paquetes UDP que se generan (indicando el formato de los paquetes: cabeceras, etc…), cuando el nivel de transporte envía 1000 bytes de datos en una red Ethernet con MTU de 500 bytes. Hacer lo mismo considerando que el nivel de transporte utilizado fuera TCP.

---

Sabiendo que tiene que pasar por una MTU de 500 bytes, las cabeceras + los datos tienen que sumar un total de 500 bytes. Veamos que pasa en cada caso:

Para UDP:
Sabemos que UDP si se puede fragmentar. La cabecera de UDP solo se envía la primera vez. Por tanto, tenemos:

Para TCP:
Sabemos que TCP no se puede fragmentar. Hay que enviar siempre la cabecera de IP y de TCP. Por tanto, tenemos:

CUESTIÓN 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?

---

Para realizar la conexión FTP a la maquina de un compañero vamos a MC-DOS e introducimos ftp junto con la IP de tu compañero/a. Ej: ftp 172.20.43.205. Para quitar este comando introducimos “quit”.

FTP es del protocolo TCP y no permite fragmentación. Aparecen peticiones desde mi máquina reiterativamente (3 en concreto y 3 respuestas de su máquina).

CUESTIÓN 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?

---

Ahora el tamaño de los TCP que hay dentro de los fragmentos IP pasan por una MTU de 500 bytes y por tanto el valor de MSS es 460 bytes (20 de cabecera IP y 20 de cabecera TCP).

TCP = 48 bytes
TCP = 44 bytes
TCP = 40 bytes
EXEC = 74 bytes
TCP = 44 bytes
TCP = 60 bytes
TCP = 40 bytes
EXEC = 41 bytes
TCP = 40 bytes
EXEC = 500 bytes
EXEC = 500 bytes
TCP = 40 bytes
EXEC = 500 bytes
TCP = 40 bytes
EXEC = 500 bytes
EXEC = 500 bytes
TCP = 40 bytes
EXEC = 500 bytes
TCP = 40 bytes
EXEC = 500 bytes
EXEC = 66 bytes
TCP = 40 bytes
TCP = 40 bytes
TCP = 40 bytes
TCP = 40 bytes
TCP = 40 bytes

CUESTIÓN 3

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?

---

Hemos cambiado el comando ‘cat file 1.txt’ por el comando ‘cat capturaexamen’ debido a que no existía el archivo en algunos PC’s

No existen IP fragmentados sino muchos TCP porque este tipo de protocolo no permite la fragmentación.

TCP = 48 bytes
TCP = 48 bytes
TCP = 40 bytes
EXEC = 76 bytes
TCP = 40 bytes
TCP = 60 bytes
TCP = 40 bytes
EXEC = 41 bytes
EXEC = 1500 bytes
TCP = 40 bytes
EXEC = 1500 bytes
EXEC = 1500 bytes
TCP = 40 bytes
EXEC = 1500 bytes
EXEC = 1500 bytes
TCP = 40 bytes
EXEC = 1500 bytes
EXEC = 1500 bytes
TCP = 40 bytes
EXEC = 1022 bytes
TCP = 40 bytes
TCP = 40 bytes
TCP = 40 bytes

Se van enviando TCP hasta un MTU de 1500

Cuestión 2.c

Analizar los valores de la ventana de receptor. ¿Cuál es más grande?

---

Ventana del receptor = 5840
Ventana del emisor = 65535

Cuestión 2.b

Comprueba el valor de los puertos utilizados. Indica su valor.

---

Los puertos son:

1211 - grooke-dopp. Puerto local
512 - exec. Puerto del servidor
113 - ident2053

2053 - lot105-ds-udp

Cuestión 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).

---

Fijaos como son casi los mismos datagramas que en el esquema de la figura teórica.

CUESTIÓN 2

Rexec. Remote Shell es un servicio presente en un S.O. UNIX con TCP/IP que atiende el puerto TCP 512 en espera de peticiones de ejecución de comandos desde procesos remotos clientes. Utiliza TCP, por lo que trabaja con conexión. Para las prácticas se dispondrá de un programa para MS Windows (rexec.exe) que actúa como cliente. En una sesión de rexec.exe se pide inicialmente un nombre de usuario y password en la máquina servidora, y tras introducir estos, se pueden ejecutar comandos UNIX en dicha máquina. Nos servirá para estudiar una conexión TCP. Dentro de una máquina UNIX, el cliente es un programa de línea de comandos con esta sintaxis básica:

rsh -IP_SERVIDOR>

Emplear el programa rexec para ejecutar el comando ‘ls –l’ en la maquina con dirección 172.20.43.232 (Linux2). Utiliza para ello el usuario ‘alumnos’ y la clave ‘alumnos’. Con el monitor de red, analizar y estudiar la secuencia de paquetes TCP intercambiados en el establecimiento de la conexión entre la máquina del alumno y la 172.20.43.232. Utilizar para ello el filtro adecuado (direcciones y protocolos).

Cuestión 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…)

---

Hemos enviado un texto que nos ha ocupado 2136 bytes, esto se puede ver en el udp.exe. El envío se hace con un UDP de 2144 bytes ya que se suman 8 de cabecera pero es necesaria una fragmentación que tendrá como máximo 500 bytes ya que en algún momento cruza algún enlace con la MTU de 500 bytes. Por tanto se fragmentará en 4 partes:

Cuestión 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).

---

Vamos a probar con los dos puertos. El puerto 13 devuelve la fecha del día en que nos encontramos. Primero vamos a probar con el puerto 7 y tenemos lo siguiente:

Y para el puerto 13 tenemos.

Como vemos, en los dos casos hay una pregunta y una respuesta que vemos en el monitor de red.

CUESTIÓN 1

Udp.exe. Este sencillo programa para MS Windows nos permitirá enviar y recibir paquetes UDP, especificando también su contenido, a un número de puerto y una IP destinos especificados para comprobar el funcionamiento de este protocolo.

PRACTICA 3. PROTOCOLOS DE NIVEL DE TRANSPORTE TCP/IP

Los objetivos de la práctica 3 de la asignatura Redes es profundizar en el funcionamiento de los protocolos de transporte en la arquitectura de red. En particular, se pretende conocer las características del nivel de transporte, así como el formato de las estructuras de datos que circulan en este nivel. Se implementará una aplicación cliente/servidor que incorpore las funciones más típicas exigibles a un nivel de transporte TCP/IP.

Cuestión Tracert. "Rutas de los paquetes en la red (3)"

Repite el ejercicio, pero esta vez solicita la conexión con la web del Gobierno federal de Argentina

http://www.argentina.gov.ar/ desde Paris (Eu.org). ¿Qué proveedor de red se encarga de encaminar los datos en la mayor parte del camino? Compara los resultados si accedes desde Paris (Eu.org) al diario http://www.clarin.com/ Dibuja los caminos.

---

Desde http://www.argentina.org.ar/ a Paris (Eu.org). Con proveedor la mayor parte del tiempo Telefonica. (GE5-0-0-0-grtwaseq2.red.telefonica-wholesale.net)
1- París (Francia)
2-París (Francia)
3- París (Francia)
4- París (Francia)
5-París (Francia)
6-París (Francia)
7-Oeste, Galicia (España)
8- Oeste, Galicia (España)
9-Miami (EE.UU)
10-Brasil
11-Argentina
12-Alem, Buenos Aires (Argentina)
13- Alem, Buenos Aires (Argentina)
14-Distrito Federal, Buenos Aires (Argentina)
15- Distrito Federal, Buenos Aires (Argentina)

Puede que algún was que aparece sea de Washington DC!!!

Ahora desde http://www.clarin.com/ hasta Paris para compararlos.
1- París (Francia)
2- París (Francia)
3- París (Francia)
4- París (Francia)
5- Washington DC (EE.UU)
6- Washington DC (EE.UU)
7- Atlanta (EE.UU)
8- Charlotte (EE.UU)
9- Charlotte (EE.UU)
10- Miami (EE.UU)
11- Miami (EE.UU)
12- Miami (EE.UU)
13- Distrito Federal, Buenos Aires (Argentina)
14- Distrito Federal, Buenos Aires (Argentina)
15- Distrito Federal, Buenos Aires (Argentina)

Cuestión Tracert. "Rutas de los paquetes en la red (2)"

Realiza una petición de traza desde Rusia hasta la web de www.sony.com Indica la ubicación de los routers por los que pasan los paquetes hasta que llegan al servidor web. Para traducir las abreviaturas por los nombres de ciudades o aeropuertos ayúdate de la web http://www.sarangworld.com/TRACEROUTE/showdb-2.php3

---

Desde Rusia hasta la web de www.sony.com. è IP = 64.37.182.61
1-Novosibirsk (Rusia)
2-Novosibirsk (Rusia)
3-Novosibirsk (Rusia)
4-Novosibirsk (Rusia)
5-Moscow City (Rusia)
6-Frankfurt Am Main (Alemania)
7-Frankfurt Am Main (Alemania)
8-Amsterdam (Holanda)
9-Amsterdam (Holanda)
10-La Guardia, Nueva York (EE.UU)
11-Chicago (EE.UU)
12-San José (EE.UU)
13-San José (EE.UU)
14-Los Ángeles (EE.UU)
15-Los Ángeles (EE.UU)
16-San Diego, California
17-San Diego, California
18-San Diego, California

Cuestión Tracert. "Rutas de los paquetes en la red"

En este ejercicio se pretende que el alumno descubra la ruta que siguen los paquetes que desde un nodo origen a un nodo destino con la información proporcionada por la herramienta de trazado de rutas. Debido a las limitaciones que posee el comando tracert o traceroute desde la ubicación del laboratorio, vamos a hacer uso de servidores de rutas externos, desde los que calcularemos la ruta a una nuestra máquina o a cualquier otro nodo mundial.
Accede a la web http://tracert.com/trace_exe.html Desde este sitio podemos lanzar la petición de traza de rutas desde diferentes servidores de la red.

• Realiza una petición de traza desde Australia (red de Telstra.net) hacia la dirección www.ua.es ¿Qué ciudades recorren los paquetes hasta que llegan a la Universidad de Alicante? ¿Cuantos routers son atravesados por paquetes (aproximadamente)?

---

Para ir de Australia hacia la dirección ww.ua.es:
1-Melbourne (Australia)
2- Melbourne (Australia)
3- Sydney (Australia)
4- Sydney (Australia)
5- Sydney (Australia)
6-(Distrito Central) Hong Kong
7-(Distrito Central) Hong Kong
8-(Distrito Central) Hong Kong
9- Maine (EE.UU)
10-Kansas (EE.UU)
11- Miami (EE.UU)
12- Madrid (España)
13- Valencia (España)
14- Alicante (España)

Para realizar este estudio hemos tenido que utilizar la página: http://www.geoiptool.com

Anexo 2 "Herramientas de rutas de paquetes – Tracert / Traceroute"

Una de las curiosidades más llamativas de la red es saber la ruta que siguen los paquetes o datagramas hasta que llegan a su destino. Por ejemplo, si realizamos una petición de acceso a Japón, los paquetes, salen de Alicante, pasando por Valencia, Madrid, ¿y luego? ¿pasarán por París o Londres … Traceroute es una herramienta de diagnóstico de redes que permite visualizar la ruta de los paquetes que se dirigen desde un equipo a otro. Con esta herramienta se obtiene además una estadística o latencia de red de esos paquetes, lo que viene a ser una estimación de la distancia a la que están los extremos de la comunicación. El comando se denomina traceroute en UNIX y linux, mientras que en Windows recibe el nombre de tracert.

Funcionamiento
El funcionamiento del comando es sencillo. Se basa en un error ICMP TTL excedido en tránsito.
Recordamos de la práctica 2 que el campo TTL sirve para que un paquete no permanezca en la red de forma indefinida (por ejemplo, debido a la existencia en la red de un bucle cerrado en la ruta).

Ejemplo de ejecución del comando “tracert” en Windows:
http://www.google.com "C:\>tracert www.google.com"
Traza a la dirección www.google.com [216.239.59.147]
sobre un máximo de 30 saltos:
1 52 ms 59 ms 59 ms 192.168.153.1
2 55 ms 59 ms 47 ms 210.Red-81-46-52.staticIP.rima-tde.net [81.46.52.210]
3 78 ms 83 ms 83 ms 29.Red-81-46-5.staticIP.rima-tde.net [81.46.5.29]
4 * * * Tiempo de espera agotado para esta solicitud.
5 80 ms 83 ms 83 ms GE4-0-0-0-grtmadrr1.red.telefonica-wholesale.net [213.140.51.9]
6 113 ms 119 ms 107 ms So6-0-0-0-grtlontl1.red.telefonica-wholesale.net [213.140.38.26]
7 197 ms 119 ms 119 ms 195.66.226.125
8 114 ms 131 ms 119 ms 72.14.238.246
9 138 ms 143 ms 143 ms 216.239.49.254
10 138 ms 131 ms 131 ms 216.239.48.158
11 138 ms 131 ms 155 ms 216.239.49.126
12 138 ms 131 ms 143 ms 216.239.59.147

Tracert funciona enviando mensajes ICMP de solicitud de eco con distintos TTL; Traceroute, en cambio, envía mensajes UDP. El campo TTL de la cabecera IP de los paquetes es un número entero que se decrece en cada nodo por el que pasa el paquete. De esta forma, cuando el campo TTL llega al valor 0 ya no se reenviará más, sino que el nodo que lo esté manejando en ese momento lo descartará. Lo que hacen los comandos de traza de rutas es mandar paquetes a la red de forma que el primer paquete posea un valor TTL=1, el segundo un TTL=2, etc. De esta forma, el primer paquete será eliminado en el primer nodo al que llegue (ya que éste nodo decrementará el valor TTL, valiendo cero). Cuando un nodo elimina un paquete, envía al emisor un mensaje de error indicando la incidencia. Tracert usa esta respuesta para averiguar la dirección IP del nodo que desechó el paquete, que será el primer nodo de la red. La segunda vez que se manda un paquete, el TTL vale 2, por lo que pasará el primer nodo y llegará al segundo, donde será descartado, devolviendo de nuevo un mensaje de error. Esto se hace de forma sucesiva hasta que el paquete llega a su destino.

Otras aplicaciones
Existen otras aplicaciones como “VisualRoute” que se basan en Traceroute / Tracert para obtener una información gráfica de la ruta que siguen los paquetes desde el origen hasta su destino. En estos casos, se emplea la información generada por la orden Traceroute / Tracert junto con la información de los nodos obtenida de bases de datos públicas como RIPE (foro colaborativo de redes IP).
En Internet existen una serie de lugares que proporcionan servidores de traceroute, y que nos informan de los resultados de la ejecución de una orden traceroute desde ese host hasta el nuestro u otro que se especifique. A estos servidores se les suelen llamar Looking Glass. Esto es de gran ayuda a la hora de realizar mapas de caminos para los paquetes desde cualquier ubicación del mundo. En el sitio web de traceroute (http://www.traceroute.org) se encuentran recogidos algunos de los sitios web que ofrecen la posibilidad de realizar trazas al sitio que se les indique.

De la información que obtenemos de los programas de rutas hay que tener en cuenta lo siguiente:
* Cada proveedor de red puede tener su propio sistema de código de máquinas.
* Los routers pueden describir en su nombre la topología o infraestructura en la que están ubicados (T1, T3, FDDI, ATM, HSSI, ETH, etc…).
* Los códigos de nombres de los routers suelen tener 3 letras, como el código del aeropuerto más cercano. (Base de datos de código de aeropuertos:

(http://www.airportcitycodes.com/codewisecodes.aspx).
* Los nombres de los routers también pueden incluir la dirección IP, una abreviatura especial, o seguir un código de nombres ya extendido como los que se encuentran en la siguiente web: (http://www.sarangworld.com/TRACEROUTE/showdb-2.php3)

Cuestión 5.d

Repite el ejercicio pero esta vez eleva el tiempo de vida del paquete a 220. ¿Observas el mismo resultado con la misma rapidez? ¿En cuál de los dos casos ha tardado más la respuesta del ping (en MSDOS)?

---

El resultado es el mismo que en el caso anterior.
En el de 150 porque hay mayor tiempo de vida y puede saltar más veces entre los routers.
Hemos introducido 150 porque 220 es excesivo para el router Linux al que enviamos la petición.

Cuestión 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?

---

Dentro del mensaje de error que es de tipo 11 y código 0 está el mensaje de petición (que tiene tipo 8 y código 0). Se queda con IP: 10.3.2.0 que es la salida de CISCO 2513 ya que se van pasando la información sin éxito (ya que no existe tal IP) de CISCO 2513 a Linux 1.

Cuestión 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)

---

IP y MAC del mensaje de error:
IP = 10.4.2.5
MAC = 00:07:0e:8c:8c:ff
La MAC es la misma que antes porque es donde queremos dirigirnos:
La IP corresponde a Serial 1 del ruter CISCO 2513

Cuestión 5.a

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)

---

Mensaje “ICMP Time t olive exceded in transit”
IP: 172.20.43.230
MAC: 00:07: 0e:8c:8c:ff
Tipo: 11
Código: 0

Código 0. Time to Live exceeded in Transit. Este mensaje ICMP es enviado al origen por un router cuando el valor del campo TTL (Tme to live) en la cabecera IP de un
datagrama toma el valor 0.
Como no hay TTL no envía redirect porque se queda en el Ruter CISCO 1720 que es nuestra puerta de enlace

CUESTIÓN 5. "Mensaje ICMP Time Exceded”

Dentro del mensaje ICMP Time Exceeded se analizará el de código 0: Time to Live exceeded in Transit (11/0). 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

Cuestión 4.g

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?

---

Datagrama original:
Identificación: 0x0a7c (2684)
Cheksum: 0x4c5f
TTL: 128

Datagrama Redirect:
Identificación: 0x0a7c (2684)
Cheksum: 0x4d5f
TTL: 127

Como a atravesado un router el TTL decrementa una unidad (de 128 a 127). Cheksum es una suma de control y suma todos los valores del campo de la cabecera. Aquí observamos como varía en una letra.

0x4c5f

0x4d5f

Cuestión 4.f

¿Qué dato importante para tu PC transporta en su interior ese mensaje de Redirect? ¿Transporta algún otro tipo de información extra?

---

Nos avisa de la ruta que deberemos seguir para encontrar el destino que hemos pedido con un menaje de redirección porque la puerta de enlace establecida recibe directamente la petición ping (172.20.43.230). Contiene la misma información solo que con una cabecera distinta y, de hecho, nos aparece como que dentro del mensaje de redirección hay otro ICMP que es la información que hay que transmitir (todos los mensajes de error transportan dentro otro datagrama ICMP que es el causante del error).

Cuestión 4.e

¿Qué máquina o interfaz de red envía el mensaje ICMP Redirect?

---

El router CISCO 1720

Cuestión 4.d

¿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 que casos la dirección IP especifica un interfaz de red que no se corresponde con el mismo interfaz indicado por la MAC.

---

Cuestión 4.c

¿Observas los mismos datagramas en el Monitor de Red con respecto a los se comentan en la explicación teórica del Redirect? ¿Por qué puede suceder esto?

---

No. Porque la información que se envía desde la maquina Cisco 1720 a la cisco 1601 no se ve porque es interna entre la red del laboratorio y nosotros no podemos verla. Sería el punto 2 del dibujo de la figura 7 de la práctica.

Cuestión 4.b

Dibujar gráficamente el origen y destino de cada datagrama (como se ha realizado en la figura 7, pero incorporando el direccionamiento IP correcto de las máquinas involucradas).

---

1. Suponemos que el PC 1 envía el datagrama IP que tiene como destino el PC 2 al router 1. La decisión de encaminamiento es coherente puesto que el router 1 está definido como puerta de enlace por defecto en esta máquina.
2. El router 1 percibe que la interfaz de salida para el mensaje es la misma por la que se recibió el datagrama procedente del PC 1. Emite el mensaje al PC 2 como si procediera del PC 1, es decir, la dirección IP origen del mensaje es la del PC 1.
3. A su vez, el router 1 emite un error de redirección ICMP hacia el PC 1, informándole que actualice su tabla de encaminamiento y que envíe directamente los próximos datagramas con ese mismo destino al router 2 sin pasar por el router 1.
4. Por último, el destino final (PC 2) responde a través del router 2 al emisor del mensaje original.

Cuestión 4.a

¿Cuántos datagramas IP están involucrados en todo el proceso? Descríbelos…(tipo, código y tamaño)

---

3 Datagramas que tienen las siguientes características:

CUESTIÓN 4 "Mensaje ICMP Redirect”

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)
Para borrar de la tabla de rutas.
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 debesrepetir 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:

Cuestión 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)

---

La CISCO 2513

Cuestión 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)

---

Están involucradas las IP y MAC de mi máquina que son las siguientes:
IP:172.20.43.205
Mi MAC: 00:0a:5e:76:ff:99

Se envía a 10.3.7.0 pero se queda en 10.4.2.5 porque la subred del CISCO 2513 A Linux 1 tiene un MTU de 500 bytes y yo envio 1000 y lo obligo a que no se pueda fragmentar.
IP: 10.4.2.5MAC: 00:07:0e:8c:8c:ff

CUESTIÓN 3. Mensaje ICMP “Destination Unreachable”

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)
Dibujo7
¿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)

Cuestión 2.i

En relación a los datos de la pregunta 2.h. obtenidos del Monitor de Red, contesta:
¿Por qué se observan más fragmentos IP de “vuelta” (respuesta) que de “ida” (petición)?

Indica en que subred del laboratorio el número de fragmentos que circulan por el medio es el mismo tanto en la petición como en la respuesta. Deduce en que otra subred no sucede esto.

Señala (en la topología del laboratorio adjunta), la MTU de cada una de las subredes por las que circulan los datagramas que salen de tu máquina hacia la dirección 10.3.7.0. ¿Cuántas subredes se atraviesan?

---

Porque al volver pasa por una red que tiene menor MTU

La subred del laboratorio en la que el número de fragmentos que circulan por el medio es el mismo tanto en la petición como en la respuesta es la 10.4.2.4/30, mientras que la subred en la que no sucede esto es la 10.3.0.0/16

"Se atraviesan 3 subredes"

Cuestión 2.h

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):

---

Cuestión 2.g

Repite el ejercicio lazando una petición de ping con un mayor número de datos y al destino “.195”: C:\>ping –n 1 –l 3000 172.20.43.195
Indica el número total de datagramas en la red e identifica si son de petición o de respuesta (dirección):

---

Al principio vemos que el mensaje se pierde, por lo que continuamos hasta conseguir que lo reciba