A su derecha podran pinchar en cada una de las 3 prácticas que se han hecho durante el curso, asi como el tutorial sobre el manejo de Traceroute.

Dentro de cada categoria se han dividido los post por cada sesion de clase.

Un saludo.

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 vemos en la imagen se producen tres intentos de conexion fallidos, ya que la máquina destino no tiene habilitado un servidor FTP.

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

En UDP:

Se generan 3 paquetes.

El primero de los paquetes tendra esta estructura:

[20 bytes de cabecera IP] – [8 bytes cabecera UDP] – [472 bytes de datos]

El segundo paquete tendra esta estructura:

[20 bytes de cabecera IP] – [480 bytes de datos]

El tercer paquete tendrá esta estructura:

[20 bytes de cabecera IP] – [48 bytes de datos]

En TCP:

Se generan 3 paquetes:

El primero de ellos tendrá la siguiente estructura:

[20 bytes de cabecera IP]-[20 bytes de cabecera TCP]-[460 bytes de datos]

El segundo de ellos tendrá la siguiente estructura:

[20 bytes de cabecera IP]-[20 bytes de cabecera TCP]-[460 bytes de datos]

El tercero de ellos tendrá la siguiente estructura:

[20 bytes de cabecera IP]-[20 bytes de cabecera TCP]-[80 bytes de datos]

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

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

Se generaran uno o varios mensajes ICMP (aunque todos iguales) que provienende la máquina C.

b. Indica la MTU del camino de camino completo.

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.

Paquetes TCP generados:

1.[20 bytes cabecera IP]-[20 bytes cabecera TCP]-[460 bytes de datos]

2.[20 bytes cabecera IP]-[20 bytes cabecera TCP]-[460 bytes de datos]

3.[20 bytes cabecera IP]-[20 bytes cabecera TCP]-[460 bytes de datos]

4.[20 bytes cabecera IP]-[20 bytes cabecera TCP]-[120 bytes de datos]

Cuestion 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 vemos en la imagen en el monitor de redes aparecen dos mensajes ECHO que contienen en su interior la trama UDP que hemos enviado con el programa udp.exe.

Uno de ellos es dirigido a la máquina 10.3.7.0 con nuestro mensaje “holaaa DA” y el otro es dirigido hacia nuestra propia ip con el mismo mensaje retornado.

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

He enviado un fichero de texto de 2kb de longitud. Como vemos el paquete llega a su destino fragmentado en 2 fragmentos, debido a que mi red local es de 1500 MTU.

Sin embargo al devolver mi mensaje a mi máquina llegan 6 mensajes, debido a que la red de destino tiene un MTU de 500. El MTU de la red de destino lo podemos averiguar viendo el offset que se ha incluido al fragmentar los paquetes:

Como es obvio, todos excepto el último (con Offset=2400) tiene flags 0×02(más fragmentos).

Cuestion 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> <COMANDO_A_EJECUTAR>

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 monitorde 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 estructura de conexion-desconexion del servidor es muy similar a la de la figura 6, al menos en la parte inicial y final, es decir, en lo relativo a la conexion y desconexion.

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

Los puertos utilizados en la conexion son:

512 (Exec)

113 (auth)

138 (netbios-dgm)

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

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

No hay segmentacion IP.

El tamaño de los segmentos TCP es de 60 bytes.

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

Se negocia un MSS de 460, por lo tanto los segmentos TCP tendran ese tamaño.

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

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

El mensaje ICMP Redirect lo envia a mi máquina el router que tenia por defecto mi tabla de rutas.

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

Si, aporta informacion para actualizar mi tabla de rutas, en concreto me aporta la IP del router que me lleva hasta el destino por el cual he “preguntado” antes, de tal forma que la próxima vez que intente acceder a ese destino, mi máquina sepa cual es la ruta para llegar hasta él.

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

En el ICMP del mensaje Redirect aparece otro mensaje ICMP dentro. Dentro de ese mensaje podemos ver, de nuevo, los campos identificacion y cheksum:

El TTL ha pasado de 128 en el mensaje original a 255 en el “redirect”.

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

Cuestion 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 me manda el mensaje 172.20.43.230 que es el router cisco 1720, con direccion MAC 00-07-0e-8c-8c-ff.

Inicia de nuevo la captura y ejecuta a continuación el comando:
C:\> ping –i 2 –n 1 10.3.7.0

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

Como podemos ver en la imagen ahora la direccion que me manda el mensaje TTL Exceeded es la máquina con direccion IP 10.4.2.5 que corresponde al cisco 2513, la MAC del mensaje de error es 00-07-0e-8c-8c-ff que corresponde al Cisco 1720.

Como vemos las direcciones IP y MAC no coinciden, puesto que son de dos máquinas diferentes, debido a que la IP que ha causado el TTL Exceeded esta fuera de nuestra red local, con lo cual no podemos ver su MAC.

La MAC que recibimos es la que corresponde a nuestro router.

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

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

Es un mensaje TTL Exceeded. El mensaje se ha enviado a la direccion IP 10.3.7.12 que es una máquina que no existe en nuestra red.

El mensaje llega a la direccion 10.3.7.0 (que si existe), y empieza a buscar la máquina, pero al no encontrarla y gastarse su TTL, devuelve un mensaje de error a mi máquina.

La máquina estaria ubicada en la subred 10.3.7.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)?

La respuesta del ping ha sido mayor en este último caso, aunque el resultado es similar, un TTL Exceeded.

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

Cuestion 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

Cuestion 2.i.

En relación a los datos de la pregunta 2.g. obtenidos del Monitor de Red, contesta:

¿Por qué se observan más fragmentos IP de “vuelta” (respuesta) que de “ida” (petición)?

Por que el MTU de la red de destino (10.3.7.0) es menor que el de la red de origen.

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.

En la subred de los PC’s de los alumnos el medio de la red es el mismo.(172.20.43.0)
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?

Se atraviesan 3 subredes.

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:

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

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

El mensaje “Fragmentation Needed and Don’t Fragment was Set” se manda desde la direccion 10.4.2.5, que corresponde al router 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:

Cuestion 4.a.

¿Cuántos datagramas IP están involucrados en todo el proceso?

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

[HACER DIBUJO]

Cuestion 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, en la explicacion teórica tenemos un Echo’ (2) que tiene que circular desde mi puerta de enlace predeterminada hasta el router que conecte con el destino.

Sin embargo ese datagrama no sera visible por mi pc, debido a que los datagramas que circulen entre 2 routers no son visibles para el resto de la red.

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

PROTOCOLO DE MENSAJES DE CONTROL DE INTERNET (ICMP)

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:

¿Cuántos y qué tipos de mensajes ICMP aparecen? (tipo y código)Aparecen 2 mensajes ICMP.

• Echo Request

• Echo Reply
  

Justifica la procedencia de cada dirección MAC e IP. ¿Crees que las direcciones IP origen y MACorigen del mensaje ICMP “Replay” hacen referencia a la misma máquina o interfaz de red?

Las direccion IP y MAC de la máquina origen en el mensaje ICMP “Reply” son las mismas en este caso, puesto que hemos hecho un ping a una direccion local dentro de nuestro laboratorio.

Cuestion 1.c.

Justifica la longitud de los paquetes IP. ¿Cuál es el tamaño total del ICMP? ¿Por qué tienen esa longitud?¿Cuántos datos se han transportado en el mensaje “ping”? Dibuja la encapsulación del protocolo ICMP?

La longitud total de la trama es 74 bytes, y su composicion es la siguiente:

14 bytes de la cabecera Ethernet

20 bytes de la cabecera IP

8 bytes de la cabecera ICMP

32 bytes de los datos ICMP

Encapsulacion del protocolo ICMP:

X X X X X X X X-XXXXXXXXXXXXXXXXXXXXXXXXXXXX]

[CABEC. ICMP]-[..............................DATOS ICMP.......................]

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)

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

Hay paquetes de diferentes tipos:

TCP, HTTP, ICMP, IP

En la columna “info” de los paquetes IP aparece : Fragmented IP protocol

Cuestion 2.b.

Se ha dividido en 2 fragmentos

¿En cuantos fragmentos se ha “dividido” el datagrama original?

Cuestion 2.c.

[HACER TABLA CON LA FIGURA ANTERIOR]

Cuestion 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? ¿por qué puede suceder esto?

Solo visualizas los 2 paquetes ICMP (un request y un reply), esto es asi, por que en realidad solo has efectuado dos peticiones ICMP, aunque se haya tenido que fragmentar para no superar el MTU del protocolo Ethernet.

Cuestion 2.e.

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

Para ordenar los datagramas y recuperar su forma original.

Cuestion 2.f.

En función de los datos anteriores, indica el valor de la MTU de la red.

El fragment offset es de 1480, por lo tanto el MTU tiene que ser 1500, debido a la siguiente operacion:

Cabecera IP (20) + ICMP (Datos + Cabecera, 1480) = 1500.

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 cache de ARP? ¿Qué tramas de ARP aparecen en la captura del monitor de red?

Aparecen las siguientes tramas

En mi cache ARP aparece la direccion IP de quien me ha enviado el “ping”.

C:>arp -a

Interfaz: 172.20.43.203 — 0×2
Dirección IP Dirección física Tipo
172.20.43.201 00-0a-5e-76-8f-6f dinámico
172.20.43.230 00-07-0e-8c-8c-ff dinámico

Cuestion 3.d

Borra el contenido de tu caché ARP. Ejecutar el comando ping con las siguientes direcciones IP:

• 172.20.43.230
• 10.3.7.0
• 10.4.2.5

¿Qué ocurre con la memoria caché de ARP? ¿Qué diferencia existe con respecto a la cuestión ‘3.b’?

C:>arp -a

Interfaz: 172.20.43.203 — 0×2
Dirección IP Dirección física Tipo
172.20.43.230 00-07-0e-8c-8c-ff dinámico

Lo que ocurre es que solo se añade al protocolo ARP el ping realizado a la primera direccion, es decir a la direccion local. Las otras direcciones del ping al ser externas a la red local no se añaden a la cache ARP.

http://www.social-bookmark-script.com/joomla.htm

Cuestion 3.e

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 (figura 23).

[TEORIA]

Cuestion 4.a

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.

La máscara de subred 255.255.254.0 en binario seria la siguiente:

11111111. 11111111.11111110.00000000

Si la ampliamos 2 bits quedaria de la siguiente forma:

11111111. 11111111.11111111.10000000

Con lo cual tendriamos 126 direcciones IP asignables para numerar las máquinas, puesto que la direccion todo 0′s es para identificar la primera subred, y la todo 1′s es para broadcast.

Analizar al azar varios datagramas IP capturados con el monitor de red.

De los datagramas visualizados, indica cuál es su longitud.

• Datagrama 1: Protocolo TCP, Longitud=1500 bytes
• Datagrama 2: Protocolo HTTP, Longitud = 20 bytes
• Datagrama 3: Protocolo Ripv2, Longitud = 20 bytes
• Datagrama 4: Protocolo DNS, Longitud = 59 bytes

¿Qué aparece en el campo de Protocolo de cada datagrama?

Como ya he especificado antes, he buscado datagramas de cuatro diferentes protocolos: TPC, HTTP, RIPv2 y DNS.

Identifica la CLASE de dirección asociada a cada dirección IP fuente o destino.

• En el datagrama 1: Direccion origen (87.248.221.156) es clase A y direccion destino es clase B (la ip de mi equipo)
• En el datagrama 2: Direccion origen (212.227.65.101) es clase C y direccion destino es también clase B (la ip de mi equipo)
• En el datagrama 3: Direccion origen (172.20.43.231) es clase C y direccion destino (224.0.0.9) es clase D.
• En el datagrama 4: Direccion origen(172.20.43.203) es clase B y direccion destino (172.25.40.81) es clase B

Cuestion 4.c

Empleando el monitor de red, averigua las direcciones IP de los siguientes servidores web: (indica a que CLASE de dirección pertenecen).

http://www.infocampus.es -> Direccion IP: 217.76.156.115 -> Clase C

http://www.ono.es -> Direccion IP:62.42.230.18 -> Clase A

http://www.ua.es -> Direccion IP:212.227.65.101 -> Clase C

Localiza los paquetes que tengan el campo de la cabecera IP “TTL” igual a 1. Para ello introducimos el filtro “ip.ttl == 1″

¿Cuántos aparecen? 2

¿Qué aplicación puede haberlos generado?

Cuestion 2.f

Determinar los paquetes donde aparece la palabra “abcd”.

En este caso introducimos el siguiente filtro en el Wireshark:

ip contains “abcd”

Cuestion 3

Cuestion 3.a

Estado de la direccion arp.

C:>arp -a

Interfaz: 172.20.43.203 — 0×2
Dirección IP Dirección física Tipo
172.20.43.230 00-07-0e-8c-8c-ff dinámico

¿Cuántas tramas intervienen en la resolución ARP? 2 tramas

¿Cuál es el estado de la memoria caché de ARP cuando se ejecuta el protocolo ARP?

C:>arp -a

Interfaz: 172.20.43.203 — 0×2
Dirección IP Dirección física Tipo
172.20.43.230 00-07-0e-8c-8c-ff dinámico

Sin que haya transcurrido mucho tiempo, vuelve a ejecutar el comando ping en la misma máquina y observa la secuencia de tramas ARP. ¿Aparecen las mismas tramas ARP?

No, ya no aparecen tramas ARP nuevas al ejecutar el comando ping.

Cuestion 3.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?

Se van añadiendo esas direcciones a la memoria caché de ARP.

C:>arp -a

Interfaz: 172.20.43.203 — 0×2
Dirección IP Dirección física Tipo
172.20.43.210 00-0a-5e-77-00-58 dinámico
172.20.43.214 00-0a-5e-76-fe-4b dinámico
172.20.43.230 00-07-0e-8c-8c-ff dinámico

Cuestion 1.a

Del conjunto de tramas adquiridas filtrar las que estén dirigidas a la máquina del alumno. ¿Cuántas tramas aparecen?

2490 tramas

Cuestion 1.b

Del conjunto de tramas adquiridas filtrar las que proceden de la máquina del alumno. ¿Cuántas tramas visualizas ahora?

4009 tramas

Cuestion 1.c

Por último, filtra las tramas 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?

7160 tramas

Si sumamos las tramas destino y origen de los aparatados 1.a y 1.b nos salen 6499 tramas, lo cual es coherente con el resultado del apartado 1.c dado que en el momento de capturar los datos del apartado 1.c habia transcurrido algo más de tiempo con lo cual es lógico que aparezcan algunas tramas más.

Cuestion 2

Cuestion 2.a

Calcula el porcentaje de tramas Ethernet de difusión existentes en la captura. (tramas de difusión/tramas totales *100).

Tramas de difusion=1273

Tramas totales=1372

Por lo tanto el porcentaje será el siguiente: 1273/1372*100= 92.78%

Cuestion 2.b

Calcula el porcentaje de paquetes IP existentes en la captura.

Si introducimos el filtro: ip.addr==172.20.43.202 nos salen 158 paquetes.

Por lo tanto el porcentaje de paquetes es 158/1372*100= 11.5%

Cuestion 2.c

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

Nos salen 126 paquetes enviados desde mi máquina, con lo cual el porcentaje total será:

126/1372*100=9.18%