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. 

Figura 10

Figura 11

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. 

Filtro utilizado ip.addr== 172.20.41.241 && !nbns

MSS = 460 bytes

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 que la hay.

La maquina que envía el error es la 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 ? 

Variando la MSS de 460 bytes a 360 bytes

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

Reenvía los dos primeros ya que los había enviado antes con una MSS de 460 bytes  y estos no han alcanzado el destino. 

e) ¿Fragmenta IP algún paquete TCP ? 

NO ya que los paquetes TCP tiene activado el bit don´t fragment lo cual impide que IP los pueda fragmentar.

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

En primer lugar se envía un paquete de 1500 byts ya que la primera red que atraviesa este si que admite el tamaño después el router B envía un mensaje de error con Fragmentation Need de tipo 3 y código 4, y dentro de este mensaje se envía la MTU máxima que se permite la cual es de 500.

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

Tipo 3 y codigo 4

b. Indica la MTU del camino de camino completo.

MTU = 500

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.

Figura 9

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.

Figura 7

Figura 8

En la figura 7 se pueden apreciar los 3 paquetes de UDP generados así como su estructura. Y en la figura 8 se aprecian los 3 paquetes de TCP y su estructura, para calcular los paquetes de TCP se ha tendido en cuenta que: MSS = (MTU-Cabecera de Ip – Cabecera de TCP) = 500 -20 -20 = 460.

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?

Figura 5

Figura 6

Como se puede apreciar en la figura 6 mi maquina intenta realizar la conexión FTP a la maquina 172.20.43.218 y esta deniega la conexión ya que las maquinas de laboratorio no tienen activado este tipo de conexión. Este proceso se repite tres veces.

Mi maquina lanza dos paquetes para intentar establecer la conexión.

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?

El MSS de los TCP es de 460 de datos y 480 incluyendo la cabecera de TCP

En el anterior era de 1460 esto es debido al a MTU máxima de la red por la cual debe pasar el segmento.

Cuestión 3.

Utiliza el programa rexec para ejecutar el comando “cat captura examen” 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?

Figura 4

Ip no fragmenta los datos, esto ocurre porque TCP no permite la fragmentación de los segmentos ya que incluye seguridad en el envió de estos, y la fragmentación la eliminaría.

Los segmentos TCP son creados al tamaño máximo que permite la red por lo cual en el envió de los datos, que es el momento en el que se envían los segmentos de mayor tamaño es de 1514 en el nivel físico, por lo tanto una vez descontados los 14 byts de cabecera de Ethernet los 20 de IP y los 20 de TCP nos quedan 1460 byts de datos.

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 .

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

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

La secuencia de conexiones que aparece en el monitor de red es muy parecida a la de la figura de arriba.

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

Puerto de mi maquina : 1216

Puerto de Linux 2: 512

Esto varía en dos segmentos que es en los que se realiza la identificación, la cual se realiza por un puerto más seguro

Puerto de mi maquina : 113

Puerto de Linux 2: 2091

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

El valor más grande es 65535

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.

a. 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).

Filtro utilizado: ip.addr== 10.3.7.0

Figura 1

Aparece un mensaje de envío y otro de respuesta.

El puerto de mi maquina es 1209

El puerto genérico de Linux 1 es 7

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

Filtro utilizado: ip.addr== 10.3.7.0

Figura 2

En el envío el paquete se ha fragmentado una vez, y después para poder acceder a Linux 1 se ha fragmentado en 5 partes, por lo cual a mi pc han llegado 5 paquetes de respuesta. Con lo cual se puede decir que el protocolo UDP deja la fragmentación a cargo del protocolo IP. Tan solo el primer fragmento aparece identificado como UPD ya que es el que contiene la cabecera de este, el resto aparecen como IP

El tamaño de los fragmentos a nivel físico es el siguiente:

Envío:

Fragmento 1 (identificado como UDP) = 1514

Fragmento 2 (identificado como IP) = 612

Recepción:

Fragmento 1 (identificado como UDP) = 514

Fragmento 2 (identificado como IP) = 514

Fragmento 3 (identificado como IP) = 514

Fragmento 4 (identificado como IP) = 514

Fragmento 5 (identificado como IP) = 172

En cada fragmento de nivel físico aparecen 20 byts de cabecera IP y 14 de Ethernet, y además en el primero 8 de la cabecera de UDP.

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

Este es el resultado mostrado por la pagina:

traceroute to cervantes.cpd.ua.es (193.145.233.8), 30 hops max, 40 byte packets
1  vlan250.lon-service6.Melbourne.telstra.net (203.50.2.177)  0.28 ms  0.345 ms  0.229 ms
2  TenGigabitEthernet0-12-0-2.exi-core1.Melbourne.telstra.net (203.50.80.1)  0.355 ms  0.398 ms  0.388 ms
3  Bundle-POS1.chw-core2.Sydney.telstra.net (203.50.6.13)  14.999 ms  14.905 ms  14.893 ms
4  Bundle-Ether1.oxf-gw2.Sydney.telstra.net (203.50.6.90)  15.016 ms  14.956 ms  15.358 ms
5  TenGigabitEthernet6-0.sydo-core01.Sydney.reach.com (203.50.13.38)  15.386 ms  15.269 ms  15.32 ms
6  i-10-0-0.syd-core03.bi.reach.com (202.84.221.85)  15.272 ms  15.183 ms  15.176 ms
7  i-14-1-0.sydp-core01.bi.reach.com (202.84.249.13)  15.129 ms  15.191 ms  15.176 ms
8  i-10-2-1.wil-core03.bx.reach.com (202.84.140.29)  163.589 ms  163.489 ms  163.573 ms
9  i-2-2.tlot03.bi.reach.com (202.84.251.189)  163.18 ms  163.155 ms  163.171 ms
10  gblx-peer.tlot03.pr.reach.com (134.159.62.170)  293.78 ms  187.408 ms  228.809 ms
11  te1-1-10G.ar2.MAD1.gblx.net (67.17.108.161)  323.218 ms  323.273 ms  359.762 ms
12  162.97.119.18 (162.97.119.18)  329.667 ms  324.413 ms  326.494 ms
13  XE4-0-0.EB-IRIS4.red.rediris.es (130.206.250.2)  323.796 ms  324.055 ms  323.585 ms
14  NAC.XE0-1-0.EB-Valencia0.red.rediris.es (130.206.250.34)  329.663 ms  329.139 ms  329.034 ms
15  ua-router.red.rediris.es (130.206.211.30)  332.191 ms  333.379 ms  332.132 ms

Como se pude apreciar en los resultados obtenidos los paquetes han efectuado 15 saltos.
Estos saltos se han producido entre routers situados en las siguientes localizaciónes:

Melbourne - Sydney - Hong Kong - Dos routers en Estados Unidos que no podemos localizar correctamente - Miami - Madrid - Valencia - Alicante.

• 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. Dibuja en el mapa de la Figura el camino de los paquetes.

Este es el resultado mostrado por la pagina de tracert.com:

traceroute to www.sony.com (64.37.182.61), 64 hops max, 40 byte packets
1  ats23-1.risp.ru (212.20.0.103)  2.558 ms  1.063 ms  0.949 ms
2  mts-1.risp.ru (212.164.0.105)  1.449 ms  0.973 ms  5.497 ms
3  a229.sinor.ru (217.70.107.229)  1.647 ms  1.828 ms  1.411 ms
4  81.176.209.49 (81.176.209.49)  2.157 ms  1.671 ms  1.238 ms
5  lnd-bgw1-ge3-0-0-0.rt-comm.ru (217.106.1.25)  119.096 ms lnd-bgw1-ge4-0-0-0.rt-comm.ru (217.106.6.146)  119.730 ms lnd-bgw1-ge5-0-0-0.rt-comm.ru (217.106.1.13)  120.427 ms
6  tge5-4.fr3.frf.llnw.net (80.81.192.221)  137.736 ms  144.067 ms  137.339 ms
7  ve5.fr4.frf.llnw.net (69.28.172.106)  151.399 ms  141.075 ms  152.209 ms
8  tge1-2.fr4.ams.llnw.net (69.28.171.54)  149.817 ms  149.959 ms  142.943 ms
9  ve5.fr3.ams.llnw.net (69.28.172.113)  156.500 ms  167.199 ms  156.812 ms
10  tge5-1.fr4.lga.llnw.net (69.28.171.86)  229.351 ms  227.960 ms  227.721 ms
11  tge8-4.fr3.ord.llnw.net (69.28.172.198)  256.404 ms  251.657 ms  251.292 ms
12  tge1-3.fr4.sjc.llnw.net (69.28.171.66)  301.778 ms  305.412 ms  301.326 ms
13  ve5.fr3.sjc.llnw.net (69.28.171.209)  303.716 ms  300.584 ms  307.176 ms
14  tge1-1.fr4.lax.llnw.net (69.28.171.117)  309.358 ms  309.256 ms  308.570 ms
15  sony.ge4-6.fr4.lax.llnw.net (68.142.78.86)  316.986 ms  359.520 ms  309.550 ms
16  vl882.laeqnx3sw-2.sonyonline.net (64.37.128.6)  309.947 ms  310.557 ms  310.265 ms

Como se pude apreciar en los resultados obtenidos los paquetes han efectuado 16 saltos.
Estos saltos se han producido entre routers situados en las siguientes localizaciónes:

Rusia (una ciudad no concretada) - Moscú - Frankfurt - Ámsterdam - Nueva York - San José - Los Ángeles.

A continuación se muestra el mapa con las locazalicaciónes de lo routers indicados arriba:

• Repite el ejercicio, pero esta vez solicita la conexión con la web del Gobierno federal de Argentina 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 www.clarin.com . Dibuja los caminos.

Paris - Gobierno de argentina

Este es el resultado mostrado por la pagina de tracert.com:

traceroute to www.argentina.gov.ar (200.1.116.61), 64 hops max, 40 byte packets
1  giga-2.enst.fr (137.194.2.254)  0.367 ms  0.359 ms  0.339 ms
2  gw-enst-itix2-1g.enst.fr (137.194.4.252)  0.368 ms  0.291 ms  0.300 ms
3  * gi9-48.228.ccr01.par04.atlas.cogentco.com (149.6.164.1)  1.423 ms *
4  te1-3.mpd02.par01.atlas.cogentco.com (130.117.2.94)  2.986 ms
te3-3.mpd02.par01.atlas.cogentco.com (130.117.1.61)  3.062 ms
te2-4.ccr01.par02.atlas.cogentco.com (130.117.48.149)  2.895 ms
5  te1-2.ccr01.par05.atlas.cogentco.com (130.117.1.22)  3.688 ms  5.070 ms  4.722 ms
6  GE7-3-0-0-grtparix1.red.telefonica-wholesale.net (213.140.52.209)  5.320 ms
GE1-0-0-0-grtparix1.red.telefonica-wholesale.net (213.140.52.133)  4.526 ms  2.812 ms
7  So4-1-0-0-grtwaseq3.red.telefonica-wholesale.net (213.140.36.130)  85.215 ms  83.199 ms  83.674 ms
8  Xe0-1-0-0-grtmiabr4.red.telefonica-wholesale.net (84.16.13.54)  146.899 ms  148.425 ms  144.798 ms
9  So6-3-0-0-grtsanem1.red.telefonica-wholesale.net (213.140.38.142)  255.722 ms
So5-0-0-0-grtsanem1.red.telefonica-wholesale.net (213.140.38.206)  239.744 ms  241.357 ms
10  So6-3-0-0-grtbueba2.red.telefonica-wholesale.net (213.140.36.245)  287.783 ms  263.479 ms
So6-1-0-0-grtbueba2.red.telefonica-wholesale.net (84.16.12.189)  264.048 ms
11  TEArgentina-2-3-1-0-grtbueba2.red.telefonica-wholesale.net (213.140.50.2)  272.840 ms *  271.459 ms
12  200-26-75-69.advance.com.ar (200.26.75.69)  273.907 ms  270.098 ms  267.105 ms
13  host230.advance.com.ar (200.51.196.230)  262.737 ms  261.856 ms  272.819 ms
14  200.16.206.18 (200.16.206.18)  256.324 ms  266.353 ms  252.883 ms

Este es el camino grafico seguido por el paquete de datos:


Paris -Diario Clarin

Este es el resultado mostrado por la pagina de tracert.com:

traceroute to www.clarin.com (200.42.136.212), 64 hops max, 40 byte packets
1  giga-2.enst.fr (137.194.2.254)  0.445 ms  0.361 ms  0.348 ms
2  gw-enst-itix2-1g.enst.fr (137.194.4.252)  0.673 ms  0.784 ms  1.418 ms
3  gi9-48.228.ccr01.par04.atlas.cogentco.com (149.6.164.1)  11.615 ms * *
4  te3-3.mpd02.par01.atlas.cogentco.com (130.117.1.61)  8.852 ms
  te4-3.ccr01.par01.atlas.cogentco.com (130.117.2.21)  7.090 ms
  te1-3.mpd02.par01.atlas.cogentco.com (130.117.2.94)  7.513 ms
5  * te8-4.mpd01.iad01.atlas.cogentco.com (130.117.1.173)  81.560 ms *
6  te4-2.mpd01.dca01.atlas.cogentco.com (154.54.26.113)  89.598 ms
  te3-2.ccr02.dca01.atlas.cogentco.com (154.54.26.133)  90.734 ms
  te7-2.mpd01.dca02.atlas.cogentco.com (154.54.1.77)  88.990 ms
7  te8-2.mpd01.dca01.atlas.cogentco.com (154.54.6.197)  88.551 ms
  te8-3.ccr01.atl01.atlas.cogentco.com (154.54.24.154)  106.129 ms
  154.54.28.18 (154.54.28.18)  100.968 ms
8  te3-1.ccr01.mia01.atlas.cogentco.com (154.54.24.162)  114.474 ms
  154.54.28.18 (154.54.28.18)  133.381 ms
  te7-1.ccr01.mia01.atlas.cogentco.com (154.54.3.26)  138.298 ms
9  te3-3.ccr01.mia03.atlas.cogentco.com (154.54.1.186)  144.859 ms
  te3-1.ccr01.mia01.atlas.cogentco.com (154.54.24.162)  135.954 ms
  te7-1.ccr01.mia01.atlas.cogentco.com (154.54.3.26)  147.050 ms
10  gblx.mia03.atlas.cogentco.com (154.54.12.70)  135.782 ms  138.118 ms  136.714 ms
11  * gblx.mia03.atlas.cogentco.com (154.54.12.70)  114.944 ms  114.073 ms
12  * * rdp-hornos7-pc20.prima.net.ar (200.42.42.122)  244.710 ms
13  rdp-hornos7-pc20.prima.net.ar (200.42.42.122)  247.410 ms
  200-42-42-82.dup.prima.net.ar (200.42.42.82)  245.061 ms  249.238 ms
14  200-42-42-82.dup.prima.net.ar (200.42.42.82)  246.758 ms  245.488 ms *

Este es el camino grafico seguido por el paquete de datos:

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

Figura 18

Figura 19

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)

IPà172.20.43.230

MACà00:07:0e:8c:8c:ff

router cisco 1720

Inicia de nuevo la captura y ejecuta a continuación el comando:

C:\> ping –i 2 –n 1 10.3.7.0

Figura 20

Figura 21

5.b. 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à10.4.2.5

MACà00:07:0e:8c:8c:ff

La IP y MAC no pertenecen a la misma maquina la IP pertence al cisco 2513 y la MAC al cisco 1720

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

Figura22

Figura 23

5.c. 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?

Tipo: 11 (Time-to-live exceded)

Codigo: 0 (Time-to-live exceded in transit)

Se esta produciendo un bucle cerrado entre las maquinas LINUX 1 u LINUX 2

Subred 10.3.0.0

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

Figura 24

En lugar de poner 220 se tiene que poner 150 porque el 220 no son capaces de aceptarlos los Linux utilizados en el laboratorio.

NO se observa la misma rapidez en el caso de poner 150 tarda mas, ya que el bucle cerrado entre LINUX 1 Y LINUX 2 tarda mas tiempo en terminar.

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)

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:

Filtro utilizado à ip.src==172.20.43.219 || ip.dst==172.20.43.219

Figura15

Figura16

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

Datagrama nº	Tipo y código ICMP	Tamaño del paquete ICMP	Origen IP Destino IP
1	Tipo 8 Codigo 0	32 bytes Trama 72	Origen: 172.20.43.219 Destino: 10.4.2.1
2	Tipo 5 Codigo 1	32 bytes Trama 70	Origen: 172.20.43.219 Destino: 172.20.43.219
3	Tipo 0 Codigo 0	Trama 72	Origen: 10.4.2.1 Destino: 172.20.43.219

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

Figura 17

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 se observan los mismos en la explicación teórica aparecen 4 datagramas mientras que en el monitor de red solo aparecen 3, ya que en la red del laboratorio se utiliza un swicth el cual tiene un filtrado MAC y solo te permite ver las Tramas en las cuales esta involucrada tu dirección MAC, y en la copia echa entre los dos Router del laboratorio mi MAC no esta involucrada y por esa razón no aparece.

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.

Datagrama nº	Tipo y código ICMP	Origen MAC	Origen IP	¿representan al mismo interfaz?
1	Tipo 8 Codigo 0	00:0a:5e:76:ff:b8	172.20.43.219	Si
2	Tipo 5 Codigo 1	00:07:0e:8c:8c:ff	172.20.43.230	Si
3	Tipo 0 Codigo 0	00:d0:ba:e0:6a:3d	10.4.2.1	NO

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

El mensaje ICMP redirect es enviado al origen (PC alumno) desde la puerta de enlace predeterminada (172.20.43.230) router cisco 1720

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?

Cada mensaje de redireccionamiento contiene un campo de 32 bits llamado dirección de internet del encaminador o puerta de enlace alternativa que contiene la IP de salida correcta para la máquina emisora.

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:

TTL: 128

Cheksum: 0x485cc [correct]

Datagrama Rdirect:

TTL:127

Cheksum:0x485c [incorrect, should be 0xf2ff]

El TTL disminuye una unidad, y el Cheksum que es una suma de campos también lo hace.