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

Envío de datos al puerto 7:

Cuando realizamos la peticion al puerto 7, el servidor nos devuelve un echo respuesta con los mismos datos que se le han enviado.

Envío de datos al puerto 13:

En este caso, cuando realizamos la peticion al puerto 13, el servidor nos devuelve el día y hora.

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

Sí q se produce fragmentación.


nº paquetes              length                identificador     flag       offset

1(echo request)        2109(1500)           0x4688      0x01            0

2(fragmented ip)     649(con cabecera)    0x4688       0x00        1480

3(echo response)       2109 (500)           0x0121       0x01           0

4(fragmented ip)            500                  0x0121        0x01        480

5(fragmented ip)             500                 0x0121        0x01         960

6(fragmented ip)            500                  0x0121        0x01       1440

7(fragmented ip)            209                 0x0121         0x00       1920

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

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

Captura del monitor de red:

Las secuencias sí que son similares.

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

Puerto destino 512

Puerto origen : 2386

Cuestión 3

Utiliza el programa rexec para ejecutar el comando ‘cat 1720intf.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?

TCP no fragmenta ya que es seguro y fiable; por lo que si dejara que el nivel inferior (IP) fragmentara ya no sería fiable.

Teniendo en cuenta que el MTU=1500
El tamaño de los segmentos TCP es:
MTU-cabecera IP - cabecera TCP =1500-20-20=1460 bytes

Cuestión 4

Utiliza el programa rexec para ejecutar el comando ‘cat ifconfig.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?

Petición: 1460 bytes
Respuesta: 460 bytes

Tamaño de los segmentos TCP transportados dentro de los paquetes IP es 480, ya que son 20 más de la cabecera

La única diferencia con la cuestión 3 es que la MSS que se determina es mas pequeña(460) ya que la MTU es más pequeña (500).

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?

Como podemos observar en el monitor de red, ha intentado conectarse 3 veces sin obtener respuesta.

Cuestión 6

Dictada por el profesor:

1º: Cambiar la ruta para ir a Linux 1

Route delete 172.20.41.241
Route add 172.20.41.241 172.20.43.231

2º: c:\ ftp 172.20.41.241
Ejecutamos una serie de comandos que se pueden visualizar en la siguiente imagen:

En el Monitor de red podemos observar como empieza con una MSS de 460 pero le da error ya que el próximo “host” tiene una MTU máxima de 400; por eso a continuación cambia a una MSS de 360 en los próximos envíos.

Cuestión 1. Sobre mensajes ICMP del “Ping”

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)


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:

1.a. ¿Cuántos y qué tipos de mensajes ICMP aparecen? (tipo y código)
Aparecen 2, los cuales se muestran a continuación:

Cuestión 1b

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?

Las direcciones MAC e IP origen, si que hacen referencia a la misma máquina ya que ambas son las pertenecientes al router del laboratorio sobre el que se ha ejecutado el ping.

Cuestión 2. Sobre la fragmentación de datagramas IP

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)


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?

En la siguiente imagen se puede apreciar que aparecen dos fragmentos para la petición y otros dos para la respuesta.

Cuestión 2b

2.b. ¿En cuántos fragmentos se ha “dividido” el datagrama original?

Si son 2000 datos puros se ha dividido en dos fragmentos: el primero con un tamaño de 1472 bytes de datos icmp,(1480 – 8 para la cabecera) y el siguiente con 528 datos ip.

Cuestión 2c

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.

nºDatagrama      Protocolo       Dirección      Flags        F.offset          Identificación
1                            ICMP               ida              0x01             0                   0x2a3a
2                               IP                   ida             0x00          1480                0x2a3a
3                            ICMP            vuelta           0x01            0                    0x2a3a
4                               IP                vuelta            0x00         1480                0x2a3a

Cuestión 2d

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?

Solo uno de ida y uno de respuesta. Esto sucede porque en la fragmentación sólo hay una cabecera ICMP que se sitúa en el primer fragmento, por lo que los demás son considerados datos IP ya que no tienen la cabecera ICMP.

Cuestión 2e

2.e. ¿Para qué se pueden emplear los campos “Identificación”, “Flags” y “Fragment offset” de los datagramas IP?

La identificación se utiliza para saber si los datos pertenecen a un mismo datagrama.
Los flags se utilizan para saber si quedan más bloques o ese es el último.
El fragment offset indica el índice a partir del cual empieza la división. Se utiliza en el reensamblado.

Cuestión 2f

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
Indica el número total de datagramas en la red e identifica si son de petición o de respuesta (dirección):


nºDat      Protocolo                   Dirección      Flags      F.offset       Identificación
1        ICMP(ping request)         10.3.7.0          0x0x1          0                 0x437b
2           IP(fragmented)               10.3.7.0          0x0x0       1480              0x437b
3           IP(fragmented)         172.20.43.218      0x0x0       1440              0x00ac
4           IP(fragmented)         172.20.43.218      0x0x1         960              0x00ac
5           IP(fragmented)         172.20.43.218      0x0x1         480              0x00ac
6            ICMP(reply)            172.20.43.218      0x0x1            0                0x00ac

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


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)

Paquetes capturados:

Equipos a los que pertenecen:

Cuestión 3b

3.b. ¿Qué máquina de la red envía el mensaje ICMP “Fragmentation Needed and Don't Fragment wasSet” (3/4)? (identifica la máquina con la topología del anexo)

Cisco 2513

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:

Cuestión 4a

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




nºDat.     Tipo y código ICMP    Tamaño del paquete     Origen IP      Destino IP


1                tipo 8; código 0                   60bytes              172.20.43.218         10.4.2.1


2                tipo 5; código 1                   56bytes              172.20.43.230     172.20.43.218


3                tipo 0; código 0                   60bytes                  10.4.2.1           172.20.43.218

Cuestión 4b

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

nºdat    Tipo y código ICMP    Origen MAC – Origen IP    ¿representan mismo interfaz?

1       tipo 8; cód 0(echo request)    00:0a:5e:76:8c:4c --172.20.43.218               SI


2       tipo 5; cód 1 (redirect)             00:07:0e:8c:8c:ff--172.20.43.230                 SI


3       tipo 0; cód 0 (echo reply)       00:d0:ba:e0:6a:3d -- 10.4.2.1                      NO

cuestión 4c

4.c. ¿Qué máquina o interfaz de red envía el mensaje ICMP Redirect?
La puerta de enlace predeterminada (172.20.43.230) router cisco 1720 es la encargada de enviar el mensaje ICMP redirect al origen, PC del alumno.

Cuestión 4d

4.d. ¿Qué dato importante para tu PC transporta en su interior ese mensaje de Redirect?
Contiene un campo de 32 bits llamado direccion de internet del encaminador que contiene la IP de salida correcta para la maquina emisora.

Cuestión 4e

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?

La identificación si que es la misma; sin embargo tanto el checksum como el tiempo de vida se ven modificados. El TTL tiene un decremento en una unidad del origen, que es 128 y en el de vuelta es 127.

Cuestión 5. Mensaje ICMP “Time Exceeded”

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

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)

La máquina que envía el mensaje es el router de la puerta de enlace siendo su dirección IP: 172.20.43.230 y la MAC: 00:07:0e:8c:8c:ff.

Cuestión 5b

Inicia de nuevo la captura y ejecuta a continuación el comando:
C:\> ping –i 2 –n 1 10.3.7.0
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)

En esta ocasión las direcciones IP y MAC no coinciden. La IP es la de la subred 10.4.2.5 y la MAC es la de nuestra puerta de enlace.

Cuestión 5c.

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

El mensaje tiene asociado un tipo 11 y un código 0.
Lo que ocurre es que nos estamos intentando conectar con una maquina que no existe (10.3.7.12). Por lo que desde la que se envía la petición (10.3.2.0), es decir, la cisco 2513 se conecta a la destino, Linux 1 y se produce un bucle cerrado entre las 2.

Cuestión 6. Mensaje ICMP “Fragment Reassembly Time Exceeded”

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
Detener la captura y determinar:

 6.a. ¿De que máquina proceden los mensajes ICMP “Fragment Reassembly Time Exceded”? (Identifica la máquina en la topología del anexo)

Máquina 10.3.7.0, es decir a la máquina Linux 1 de nuestra subred.

Cuestión 6b

6.b. ¿Por qué crees que pueden proceder de esa máquina y no de otra?

Porque el reensamblado siempre se produce en la máquina de destino, es decir en la máquina en la que nos encontramos (10.3.7.0).

Cuestión 7: Sobre direccionamiento IP y creación de subredes

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.

Si deseamos crear 6 subredes el número de bits que tendremos que reservar será 3.
Al decirnos que la dirección es de clase B, sabemos que la máscara asociada es la: 255.255.0.0

Primera subred:

145.65. 00000000.00000000 --> 145.65.0.0

Segunda subred:

145.65. 00100000.00000000 --> 145.65.32.0


Tercera subred:

145.65. 01000000.00000000 --> 145.65.64.0

Cuarta subred:

145.65. 01100000.00000000 --> 145.65.96.0

Quinta subred:

145.65. 10000000.00000000 --> 145.65.128.0

Sexta subred:

145.65. 10100000.00000000 --> 145.65.160.0

Nueva máscara:

11111111.11111111.11100000.00000000 --> 255.255.224.0

Cuestión 7b

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.

Dirección de red IP 125.145.64.0:
01111111.10010001.00100000.00000000

Máscara asociada 255.255.254.0:
11111111.11111111.11111110.00000000

Los dos bits con los que ampliaré la mascara de subred son los que se encuentran resaltados en rojo; ya que son los dos primeros que no perteneces a la parte de red. Al ampliarlo en 2 bits el número de subredes que se podrán crear será 4, las cuales las muestro a continuación:


1ª subred:
01111111.10010001.00100000.00000000 --> 125.145.64.0


2ª subred:
01111111.10010001.00100000.10000000 --> 125.145.64.128

3ª subred:
01111111.10010001.00100001.00000000 --> 125.145.65.0

4ª subred:
01111111.10010001.00100001.10000000 --> 125.145.65.128

Así, el valor de la nueva máscara de subred será:
11111111.11111111.11111111.10000000 --> 255.255.255.128


Rango de direcciones de máquinas en cada subred:

Subred                             1ª máquina                    última máquina

125.145.64.0                  125.145.64.1               125.145.64.126
125.145.64.128              125.145.64.129           125.145.64.254
125.145.65.0                  125.145.65.1               125.145.65.126
125.145.65.128              125.145.65.129           125.145.65.254

Cuestión 5. Sobre direccionamiento IP y máscaras de subred

5.a Analizar al azar varios DATAGRAMAS IP (4 ó 5) capturados con el monitor de red.
• De los datagramas visualizados, indica cuál es su longitud.
• ¿Qué aparece en el campo “PROTOCOL” de cada datagrama?
• Identifica la CLASE de dirección asociada a cada dirección IP fuente o destino.



1)


Longitud total: 793
Protocol: TCP
Clase: B


2)


Longitud total: 40
Protocolo: TCP
Clase: B


3)


Longitud total: 78
Protocolo: UDP
Clase: B


4)


Longitud total: 191
Protocolo: TCP
Clase: B


5.b Empleando el monitor de red, averigua las direcciones IP de los siguientes servidores Web, indicando la CLASE de dirección a la que pertenecen (A, B ó C):

• http://www.ibm.com --> 129.42.58.216 --> media, clase B


• http://www.ono.es --> 62.42.230.18 --> grande, clase A


• http://www.ua.es --> 193.145.233.8--> pequeña, clase C

5.c (ejercicio teórico) Sea una máquina con dirección IP 145.34.23.1 y máscara de subred asociada 255.255.192.0. Determina si los siguientes destinos IP de un datagrama que se envíe a la red serán locales o remotos:

• 145.34.23.9 --> destino IP local
• 145.21.1.2 --> destino IP remoto
• 65.33.123.87 --> destino IP remoto
• 145.34.200.34 --> destino IP remoto
• 145.34.128.200 --> destino IP remoto

¿A qué máquina de la red local se enviará la trama Ethernet que transportará al datagrama IP si el destino es remoto?

Al elemento que tengas que haga de puerta de enlace. Por ejemplo sabemos que si se tratara del laboratorio sería un router.

Cuestión 4. Sobre el protocolo ARP

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?
2 tramas: petición y respuesta

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

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?

No. Porque se quedan cargadas en la memoria virtual. Si borramos con el comando
arp –d la memoria virtual, o dejamos pasar mucho tiempo, volveremos a obtener tramas ARP.


4.b Ejecuta el comando ping con diferentes direcciones IP de los compañeros asistentes a prácticas. ¿Qué ocurre con la memoria caché de ARP de tu máquina?

Se van añadiendo en lista a mi dirección ip.

4.c. Borra el contenido de tu caché ARP. A continuación, activa el Monitor de red y pide a tus compañeros del aula más cercanos a ti que te envíen comandos ping. Tú no debes enviar ningún comando. Pasados unos segundos… ¿Qué ocurre con tu caché de ARP?
¿Qué tramas de ARP aparecen en la captura del monitor de red?

Mi caché de ARP estaba vacío y se le ha añadido la dirección ip de mi compañero y la de la puerta de enlace. Esas son las tramas que aparecen en la captura del monitor de red.

4.d Borra el contenido de tu caché ARP. Ejecutar el comando ping con las siguientes
direcciones IP externas a tu red local:
• 172.20.41.241
• 10.3.2.0
• 10.3.7.0
• 10.4.2.5
¿Qué ocurre con la memoria caché de ARP en este caso? Especifica cuál es la máquina de tu red local de la que proceden las tramas que transportan los mensajes de respuesta al haber ejecutado el comando ping a los anteriores destinos.

Por mucho que intentemos acceder a los host indicados, solo obtenemos la dirección física de los routers que permiten la conexión a dichas redes.




4.e (ejercicio teórico) Describe la secuencia de tramas ARP generadas cuando la máquina 5.1.2.0 ejecuta el comando 'ping 5.2.2.0', teniendo en cuenta que las tablas ARP de todas las máquinas están vacías.

Comando de ARP dir. origen MAC dir. origen IP dir. destino MAC dir. destino IP
Peticion_arp mac1 5.1.2.0 broadcast 5.1.1.0
Respuesta_arp mac2 5.1.1.0 mac1 5.1.2.0
Peticion_arp mac3 5.2.1.0 broadcast 5.2.2.0
Respuesta_arp mac4 5.2.2.0 mac3 5.2.1.0

4.f (ejercicio teórico) ¿Qué sucedería con el protocolo ARP si, a diferencia de la red representada en la cuestión anterior, tenemos tres segmentos de red y dos routers que los enlazan? En este caso, la máquina con IP 5.1.2.0 realiza un ping a la máquina 5.3.2.0. (Todas las tablas ARP están vacías)

Comando de ARP dir. origen MAC dir. origen IP dir. destino MAC dir. destino IP

Peticion_arp mac1 5.1.2.0 broadcast 5.1.1.0
Respuesta_arp mac2 5.1.1.0 mac1 5.1.2.0
Peticion_arp mac3 5.2.1.0 broadcast 5.2.3.0
Respuesta_arp mac5 5.2.3.0 mac3 5.2.1.0
Peticion_arp mac6 5.3.1.0 broadcast 5.3.2.0
Respuesta_arp mac7 5.3.2.0 mac6 5.3.1.0

Cuestión 3. Tramas del nivel de Enlace (Ethernet)

A partir de la captura del ejercicio anterior, debes analizar ahora la cabecera del nivel de enlace. Para ello, realiza un filtrado para visualizar TRAMAS que procedan de tu máquina. 3.a. ¿Qué tipo de filtro has empleado?. Indica la dirección MAC de tu máquina.

El tipo de filtro puede observarse en la imagen capturada. La dirección MAC se muestra en la línea azul. Para verificar que es la MAC adecuada de nuestra máquina, se ha empleado el comando ipconfig.


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?

Con la dirección MAC: 00:07:0e:8c:ff. Sospechamos que hace referencia a la puerta de enlace del laboratorio (en nuestro caso un router).

Cuestión 2. Análisis estadístico de una captura de datos.

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:
2.a Calcula el porcentaje de paquetes IP existentes en la captura. (Paquetes IP / tramas totales *100).

El porcentage de paquetes IP es del 99'8 %.

2.b Calcula el porcentaje de paquetes IP enviados por la máquina del alumno.


El porcentaje de paquetes IP enviados es de 30'8 %.

2.c Calcula el porcentaje de segmentos TCP recibidos por la máquina del alumno.


El porcentaje de paquetes TCP recibidos es del 59'2 %.

2.d. Calcula el porcentaje de paquetes que contengan el protocolo DNS en su interior.


El porcentaje de paquetes DNS es menor del 0'3 %.

Cuestión 1. Iniciación al monitor de red. Visualización general de protocolos en la red

Activa el monitor de red y captura todo tipo de tráfico en la red durante unos segundos. Paraliza la captura y visualiza…

1.a Del conjunto de datos adquiridos, filtrar los que estén dirigidas a la máquina del alumno. ¿Cuántas tramas aparecen?

Como puede observarse en la imagen adjunta, se muestran 45 tramas.


1.b Del conjunto de datos adquiridos, filtrar los que proceden de la máquina del alumno.
¿Cuántas tramas visualizas ahora?


En este caso, se visualizan 69 tramas que cumplen las condiciones de las 447 tramas recibidas.


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 este caso, se compone de 114 tramas. Es coherente, dado que la suma de las tramas de los 2 apartados anteriores es 114 tramas (45 + 69 = 114).

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?


Se pueden observar tramas Ethernet (lógico), y protocolos IP, TCP y HTP (ver imagen adjunta).

PRÁCTICA 1

En este apartado, se mustran los resultados de la práctica 1 de la asignatura de redes, asignatura optativa perteneciente a la titulación de Ingeniería Técnica de Telecomunicaciones de la Universidad de Alicante.

Alumna:
- Patricia Del Castillo Hernández