Tuesday, May 12, 2009

Protocolo FTP - Anexo, practica 3

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.



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

    Se empieza a trasmitir con 460 bytes però el servidor solo permite una MTU de 400 bytes. Al final el valor MSS negociado en la conexion TCP es de 360 bytes.


  2. ¿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, la maquina que envia este mensaje de error es 172.20.43.231


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

    Los paquetes se enviaran con un tamaño de 400 bytes y MSS de 360 bytes.


  4. ¿Reenvía tu PC algún paquete TCP al servidor?

    Si porque el tamaño de los paquetes es demasiado grande y tiene que reducirlo a 360 bytes.


  5. ¿Fragmenta IP algún paquete TCP ?

    no, IP no fragmenta algun paquete TCP.

Tipologia de red - Cuestión 7, Practica 3

En base a la topología que se muestra a continuación:
Ejemplo de topologia de red

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

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

  2. Indica la MTU del camino de camino completo.

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



  1. Mensaje ICMP “Fragmentation Needed”, tipo: 3 , código: 4.

  2. La MTU del camino completo es 500, porque es el valor mas pequeno de la redes donde los paquetes tienen que atraversar.


  3. Tabla que describe la fragmentacion al mandar un paquete TCP de 1500 bytes




Formato de los paquetes - Cuestión 6, Practicas

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.

Nivel de transporte UDP:

Tabla que rapresenta el nivel de transporte UDP

Nivel de transporte TCP:
Tabla que rapresenta el nivel de transporte TCP

La diferencia es que con el nivel de transporte TCP todos los paquetes mantienen la cabecera TCP, mientras en UDP hay la cabecera UDP solo en el primero fragmento.




Monday, May 11, 2009

Conexión FTP - Cuestión 5, Practica 3

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?

la conexion FTP no se he realizada

Valor de MSS - Cuestión 4, Practica 3

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?

Maximun Segment size: 460 bytes (MSS = MTU - 20 - 20)
Tamaño del los segmentos TCP transportados dentro los paquete IP es: 500, en la cuestion 3 era de 1500

screenshot wireshark que describe el tamaño de los segmentos TCP transportados dentro de los paquetes IP

Tamaño grande TCP - Cuestión 3, Practica 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?

Ip no ha fragmentado los segmentos porqué el protocol TCP no lo permite. Los segmentos TCP tenien un tamaño de 1500.

screenshot wireshark que describe como el IP no se es fragmentado

Rexec - Cuestión 2, Practica 3

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

    Las secuencias de conexion-desconexion TCP se parecen a las que salen en la figura 6. El cliente contesta a la solecitud de SYN del servidor con un RST.


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

    Puertos utilizado:
    Source exec (512)
    Destination florence (1228)


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

    Client: 65535
    Servidor: 5840
    Entonces el Client es el mas grande



screenshot de wireshark que describe las secuencias de conexión-desconexión TCP


Udp.exe - Cuestión 1, Practica 3

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

screenshot de wireshark que describe la secuencia de paquetes UDP y la palabra enviada

b Prueba de nuevo udp.exe, pero enviando un texto mucho más grande (sobre 2 Kbytes). 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…)

screenshot de wireshark que describe la fragmentacion de IP de los paquetes cuando se invia un texto muy largo



Sunday, April 5, 2009

Rutas de los paquetes en la red - Cuestión Tracert, Practica 2

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 tracert.com. Desde este sitio podemos lanzar la petición de traza de rutas desde diferentes servidores de la red.

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

Las ciudades que recorren los paquetes son:

Melbourne => Sidney => Hong Kong => Maine(USA) => Kansas => Florida => Madrid => Valencia => Alicante

Es importante subrayar que no es coerente que los paquetes pasan por el Maine porque es en la costa est de los USA. Es mas coerente que los paquetes pasan por la California.

Son atraversados aproximamente 10 routers.

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

Los paquetes pasan por:

Novosibirsk(RUS) => Moscow => Frankfurt(GER) => Amsterdam => New York (USA) => Chicago => San Jose (California) => Los Angeles => San Diego

Mapa de Mondo con camino paquete

3 Repite el ejercicio, pero esta vez solicita la conexión con la web del Gobierno federal de Argentina 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.

primero caso (desde Paris hasta Gobierno federal de Argentina)

Paris => Oeste (España) => Alem (ARG) => Buenos Aires

el proveedor de red que se encarga de encaminar los datos es "Telefonica".

Mapa de Mondo con camino paquete

segundo caso (desde Paris hasta www.clarin.com)

Paris => Washington(USA) => Atlanta => Charlotte => Miami => Buenos Aires

Mapa de Mondo con camino paquete

Mensaje ICMP “Time Exceded” - Cuestión 5, Practica 2

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)

IP: 172.20.43.230
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

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


Si, ambas las direcciones pertenecer a la misma máquina.

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?

Type 11 (Time to live exceeded)
code 0 (Time to live exceeded in transit)

no existe la direccion IP 10.3.7.12 en la red.

5.d ping -i 220 -n 1 10.3.7.0
Tempo de ida y vuelta: 53 ms
Ha tardado mas nel segundo caso

Saturday, April 4, 2009

Mensaje ICMP “Redirect” - Cuestión 4, Practica 2

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:

4.a ¿Cuántos datagramas IP están involucrados en todo el proceso? Descríbelos

Tabla sobre los datagramas IP

4.b Dibujar gráficamente el origen y destino de cada datagrama

Schema de el camino de el datagrama

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?

nos vedemos solo 3 mensajes: ida, error, ICMP reply. En teoria los mensajes que estan son 4, falta la copia del mensaje original con las direccion MAC cambiadas.

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.

direcciones MAC e IP de todas las tramas capturadas

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

IP: 172.20.43.230 Maquina: Cisco 1601

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?

Type 5(Redirect) Codigo 1(Redirect for host)

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 originario:
ICMP request x 2
Identificacion: 0x1f70(8048)
TTL: 128 --> 128 * 2 = 256
checksum: 0x3761

Redirect
Identificacion: 0x02d7(727)
TTL: 255
checksum: 0x0908

No es posible que tengon el mismo campo identificacion.
El TTL del redirect tiene un bit in meno por que toda las veces que un paquete viene redirect en otra direccion perde un bit.

Friday, April 3, 2009

Mensaje ICMP “Destination Unreachable” - Cuestión 3, Practica 2

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)

MAC: 00:07:0e:8c:8c:ff ==> IP: 10.3.7.0

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)

IP: 10.4.2.5 ==> Maquina: Cisco 1601

Thursday, April 2, 2009

Sobre la fragmentación de datagramas IP - Cuestión 2, Practica 2

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?

Screenshot Wireshark. Resumen sobre fragmentos IP

El numero total de los fragmentos son 3.
En la columna info aparece: Fragmented IP potocol (protocol ICMP 0x01, off=0)

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

Se ha dividido en 2 segmentos.

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.

datagramas en el orden de aparición del Monitor de Red

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?

Se vee solo el primero paquete de los fragmentos. Todos los otros tengon protocol IP.

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

El campo “Identificacion” permite de identificar su hermanos, cada paquete del mismo datagrama tien lo mismo id de identificacion.
El campo “Flags” indica si hay mas paquete y permite de reensamblar el datagrama.
El campo “Fragmet Offset” permite al destino de reensamblar el datagrama.

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

La MTU se determina mirando el tamaño total IP del primero fragmento del datagrama que equiivale a 1500bytes.

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

datagramas en la red, identificados para petición o para respuesta

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

datagramas en la red, identificados para petición o para respuesta

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

Se observan mas paquetes de vuelta que de ida porquè el tamaño MTU de una de las subredes es menor de la MTU 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.

El route antes de 10.3.7.0 ha ip 10.4.2.5. Si haco ping -n 1 -l 1600 10.3.7.0 el datagrama se framenta en dos a la ida y en dos a la vuelta. Entonses la subred donde la MTU es egual a 500 es la 10.3.7.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 atraversan 3 subredes

Esquema de subredes

Wednesday, April 1, 2009

Sobre mensajes ICMP del “Ping” - Cuestión 1, Practica 2

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 3 mensajes ICMP:
Request type 8 code 0
Request type 8 code 0
Reply type 0 code 0

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

Request Source: 172.20.43.211 MAC: 00:0a:5e:76:ff:bc
Destination: 172.20.43.230 MAC: 00:07:0e:8c:8c:ff

Request Source: 172.20.43.211 MAC: 00:0a:5e:76:ff:bc
Destination: 172.20.43.230 MAC: 00:07:0e:8c:8c:ff

Reply Source: 172.20.43.230 MAC: 00:07:0e:8c:8c:ff
Destination: 172.20.43.211 MAC: 00:0a:5e:76:ff:bc

Si, las direcciones IP origen y MAC origen del mensaje ICMP reply hace referencia a la misma maquina.

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.

Total length: 60
Tamaño total: 60 * 3 = 180
data: 32 Bytes

Un datagrama IP

Mensaje ICMP ==> Type(8 bits) | codigo(8 bits) | SVT(16 bits) | segun el tipo de codigo

Wednesday, March 4, 2009

Sobre TCP/IP - Cuestión 4, Practica 1

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.

Máscara

255.255.254.0 => 11111111. 11111111. 11111110. 00000000

255.255.255.128 => 11111111. 11111111. 11111111. 10000000

Subredes

125.145.64.0 =>   01111101. 10010001. 01000000. 00000000
125.145.64.128 =>   01111101. 10010001. 01000000. 10000000
125.145.65.0 =>   01111101. 10010001. 01000001. 00000000
125.145.65.128 =>  01111101. 10010001. 01000001. 10000000


Rango

rango de direcciones IP

4.b Analizar al azar varios datagramas IP capturados con el monitor de red.
De los datagramas visualizados, indica cuál es su longitud.

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

DNS header length: 20 bytes
total length: 59

TCP header length: 20 bytes
total length: 52

ICMP header length: 20 bytes
total length: 84

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


Clase de dirección asociada a cada dirección IP

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   82.194.85.170   clase A

http://www.ono.es   62.42.230.18   clase A

http://www.ua.es   193.145.233.8   clase C

Sobre el protocolo ARP - Cuestión 3, practica 1

3.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 que obtienes para saber “quien eres“ 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 detener la captura y visualizarla. Introducir un filtro para visualizar sólo tramas ARP asociadas SÓLO a la máquina del alumno
¿Cuántas tramas intervienen en la resolución ARP?

intervienen 6 tramas


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

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 aparece ninguna trama ARP


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?

en la memoria cache vien agregado la maquina del compañero.

172.20.43.230    00-07-0e-8c-8c-ff     dinámico
172.20.43.214    00-0a-5e-76-fe-4b    dinámico

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

aparece el siguiente:

172.20.43.214     00-0a-5e-76-fe-4b   dinámico

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

vien agregado solo esta direccion IP

172.20.43.230    00-07-0e-8c-8c-ff     dinámico

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

Tu respuesta:
una secuencia de tramas ARP

Análisis estadístico de una captura de datos - Cuestión 2, Pratica 1

A partir de un fichero de captura de tráfico en la red se determinará cierta información que aparece en la misma. Pare ello se necesita generar tráfico para poder obtener un fichero con información capturada. En primer lugar se iniciará el monitor de red y se realizarán las siguientes acciones para generar tráfico:

Conéctate con el navegador a http://www.ua.es
Desde la ventana de MSDOS ejecuta el comando ping 172.20.43.230 que permite comprobar la conectividad en red de una máquina remota.
En la misma ventana ejecutamos ahora el comando tracert 193.145.233.8 que es muy útil para visualizar los saltos que recorren paquetes IP hasta que llegan a su destino.
Por último, introducimos la palabra “aula24” en el buscador GOOGLE.

A continuación, una vez paralizada la captura de datos, guárdala con el nombre LAB24_P2.cap.
Con la captura anterior, debes responder a las siguientes cuestiones:


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

eth.dst == FF:FF:FF:FF:FF:FF
paquetes 510 displayed 311
entonces: 311/510 * 100 = 60,98%


2.b Calcula el porcentaje de paquetes IP existentes en la captura.

Ip
paquetes 510 displayed 458
entonces: 458/510 * 100 = 89,90%


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

ip.src == 172.20.43.214
paquetes 510 displayed 169
entonces: 169/510 * 100 = 33,14%


2.d Indica el número de los paquetes IP que contengan la cadena “abcd” en su interior. ¿Qué aplicación ha podido generar esos datos? (Visualiza el campo “Protocol”)

0 (tracert)


2.e Localiza los paquetes que tengan el campo de la cabecera IP “TTL” igual a 1. ¿Cuántos aparecen? ¿Qué aplicación puede haberlos generado? (Visualiza el campo “Protocol”)

el filtro es:ip.ttl == 1


2.f Determina en cuantos paquetes aparece la cadena “aula24”. ¿A qué aplicación están asociados?

el filtro es:ip contains “aula24”
2 paquetes, Google

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

Activar el monitor de red y captura todo tipo de tramas en la red durante unos segundos. Paraliza la captura y visualiza…

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

filter: ip.dst == 172.20.43.214
linea debajo: paquetes 546 aparecen 180
entonces las tramas son 180


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

filter: ip.dst == 172.20.43.214
linea debajo: paquetes 546 aparecen 320
entonces las tramas son 320


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?

filter: ip.src == 172.20.43.214 II ip.dst == 171.20.43.214
paquetes 546 aparecen 46
entonces las tramas total son 500 y 46 son de otros, el resultado es coherente
(180 + 320 = 500) + 46 = 546