Práctica 3 Cuestión 7

Práctica 3
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’:

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

Se genera un mensaje de error ICMP >> Tipo: 3 (destino inaccesible) | Código: 4 (se necesita fragmentación)

b. Indica la MTU del camino de camino completo.

Según la norma RFC 1191, la MTU será la menor de las MTU del camino recorrido. Par averiguar esto, el emisor envía dos o tres paquetes tcp, investigando las MTU intermedias. Si se reciben mensajes de error ICMP se cambiará la forma de actuación respecto al tamaño futuro de los paquetes TCP. En esta topología, una vez realizados los envíos de prueba y recorrido todo el camino tendremos una MTU=500 bytes.

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.

Trama CAB. Ethernet CAB. IP CAB. TCP DATOS

1 14 20 20 460

2 14 20 20 460

3 14 20 20 460

4 14 20 20 120

Práctica 3 Cuestión 6

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.

Para calcular el número de paquetes UDP primero debemos conocer el MSS, que es el tamaño máximo de los datos de aplicación que el nivel de transporte acepta para evitar la fragmentación que, evidentemente, dependerá del valor de la MTU.

MSS = MTU – Cab IP – Cab UDP MSS = MTU – Cab IP – Cab UDP

500 – 20-8 = 472 bytes 500 –20-20 = 460 bytes

Datagrama Datagrama

1 472 Bytes 1 460 Bytes

2 472 Bytes 2 460 Bytes

3 64 Bytes 3 460 Bytes

4 20 Bytes

Práctica 3 Cuestión 5

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?

Lo hacemos mediante MS DOS escribiendo:

C:\>ftp 172.20.43.201

Conectado a 172.20.43.201.

Conexión cerrada por el host remoto.

Es debido a que el Windows tiene las opciones FTP deshabilitadas y parece que se quede colgado intentado conectar con las maquinas de mis compañeros. Se conecta físicamente pero no consigue una comunicación TCP.

En el capturador podemos observar como se realizan 3 peticiones de SYN y se nos devuelven 3 RST/ACK, solicitando un reconexión.

Práctica 3 Cuestión 4

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?

En este caso tampoco se produce una fragmentación debido al estrechamiento de la subred aunque ahora la MSS vale 460 (ya que la MTU es de 500 Bytes).

Práctica 3 Cuestión 3 b)

¿Cuál es el tamaño de los segmentos TCP?

Hay de varios tamaños, de 60 bytes, de 62 bytes, de 70 bytes, de 74 bytes y de 54 bytes.

Práctica 3 Cuestión 3 b)

¿Por qué ocurre esto?

TCP impide la fragmentación, crea los segmento de tamaño adecuado a la red, calcula el MSS. Los segmento tienen una estructura de datos TCP.

Práctica 3 Cuestión 3 a)

¿IP ha fragmentado estos segmentos?

No ha fragmentado.

Práctica 3 Cuestión 3

Cuestión 3
Utiliza el programa rexec para ejecutar el comando ‘cat file1.txt’ en el servidor 172.20.43.232
(Linux2). La información recibida es de varios miles de bytes y se recibirá en segmentos TCP de gran tamaño.

Práctica 3 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).

Si nos fijamos en las secuencias de conexión desconexión TCP con la máquina 172.20.43.232 tenemos el siguiente diagrama.

Vemos como dice el enunciado que en la transmisión de datos nuestra máquina contesta a una solicitud de SYN del servidor con un RST (Restart - Solicita un reinicio de la conexión y se usa cuando ha habido un problema en la secuencia de bytes, cuando falla un intento de iniciar conexión opara rechazar paquetes no válidos). Esto es debido a que el servidor trata de identificarnos, pero nuestra máquina no le deja.

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

Básicamente utiliza el 1467 salvo para la orden RST ACK y su SYN anterior en los que emplea el 2692.

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

La más grande es de tamaño 64986 y corresponden a la parte de liberar conexión aproximadamente.

Introducción Práctica 3

En esta práctica profundizaremos en ele funcionamiento de los protocolos de transporte en la arquitectura de red. Conoceremos las características y el formato de las estructuras de datos de el nivel de transporte.

Por último se implementará una aplicación cliente/servidor que incorpore las funciones más típicas xigibles a un nivel de transporte TCP/IP.

Práctica 3 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).

Estas son las tramas capturadas, se puede apreciar en la imagen como al enviar datos al puerto 7 lo que recibimos es una repuesta de eco que contiene los mismos datos que enviamos. Si hubiéramos enviado los mismos datos hacia el puerto 13 habríamos recibido la información de el día y la hora.

b. Prueba de nuevo udp.exe, pero enviando un texto mucho más grande (sobre 2Kbytes). Esto se uede hacer copiando parte de algún fichero de texto en la ventana de udp.exe. ¿Se produce ragmentació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 el identificador, flags, tamaño, etc…)

Como se puede ver en la captura, enviando un texto de aproximadamente 2 Kilobytes solamente tenemos un paquete fragmentado con un identifiacador 0xa0ff (41215), un fragment offset de 1480 y con 784 bytes de datos.

Cuestión 5

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 maquina que envia el mensaje de tiempo excedido es el router de la puerta de enlace, en este caso si que podemos saber su direccion Ip y MAC

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 la

s máquinas en la topología del anexo)

Podemos observar como ahora no coinciden las direcciones MAC –IP, ya que la direccion ip es la del siguiente punto a partir de la puerta de enlace, mientras que la direccion MAC es la de nmuestra puerta de enlace.

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?

Tipo 11 Codigo 0

¿Qué crees que está sucediendo al intentar conectarte a esa máquina y obtener ese mensaje de error?

Se esta produciendo un bucle cerrado entre las maquinas Cisco 2513 y LINUX 1

¿En qué subred estaría ubicada?

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?

No

¿En cuál de los dos casos ha tardado más la respuesta del ping (en MSDOS)?

En este nuevo caso tarda mas la respuesta

Cuestión 4

Cuestión 4. Mensaje ICMP “Redirect”
Inicia el Monitor de Red. A continuación ejecutar los comandos:
C:\>route delete 10.4.2.1
C:\>ping -n 1 10.4.2.1

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…(tipo, código y tamaño)

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?

El datagrama que no aparece es la copia del echo que realiza el router uno (puerta de enlace predeterminada 172.20.43.230), esto es debido a que el switch realiza un filtrado por seguridad que consiste en que los mensajes entre routers no puedan ser visualizados por el resto de equipos de la red.


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.

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?

Contiene un campo de 32 bits llamado direccion de internet del encaminador que contiene la IP de salida correcta para la maquina 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?

El TTL se modifica siendo en el ping 128 y en el ICM redirect 255, y el cheksum tambien se ve modificado ya que es una suma de control

Cuestión 3

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)
Paquete (protocolo/info) Direccione IP/MAC Equipo
ICMP(ping request) Source 172.20.43.207 Destination 10.3.70 PC –LINUX1
Src: 3com_76:ff:a6 (00:0a:5e:76:ff:a6), Dst: Cisco_8c:8c:ff (00:07:0e:8c:8c:ff)

ICMP(destination unreachable)Source 10.4.2.5 Destination 172.20.43.207 cisco 2513 - PC
Src: Cisco_8c:8c:ff (00:07:0e:8c:8c:ff), Dst: 3com_76:ff:a6 (00:0a:5e:76:ff:a6)

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)
CISCO 2513

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

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

Esta divido en dos fragmentos el primero ocupa un total de 1472 bytes de tipo ICMP y el segundo tiene un total de 528 bytes de tipo IP.

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.

Datagrama
Protocolo
Dirección
Flags
Frag. offset
Identification
1
ICMP
172.20.43.230
0/0/1
0
0X236f
2
IP
172.20.43.230
0/0/0
1480
0X236f
3
ICMP
172.20.43.208
0/0/1
0
0X236f
4
IP
172.20.43.208
0/0/0
1480
0X236f

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 observan el datagrama de peticion y los dos de respuesta, los datos dejan de ser ICMP a partir del segundo fragmento siendo ip

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 patir de la cual deben introducirse los datos de esa trama, se utiliza para el reensamblado.

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

La MTU de la red son 1500 bytes (ETHERNET).

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

Datagrama
Protocolo
Dirección
Flags
Frag. offset
1
ICMP(request)
172.20.43.195
0/0/1
0
2
IP
172.20.43.195
0/0/1
1480
3
IP
172.20.43.195
0/0/0
2960
4
ICMP(reply)
172.20.43.208
0/0/1
0
5
IP
172.20.43.208
0/0/1
1480
6
IP
172.20.43.208
0/0/0
2960

C:\>ping –n 1 –l 1600 10.3.7.0

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

Porque hay una subred cuya MTU es menor de 1500 y debe de fragmentarse en mas datagramas.
Indica en que subred del laboratorio el número de fragmentos que circulan por el medio es el mismo tanto en la petición como en la respuesta. Deduce en que otra subred no sucede esto.
Señala (en la topología del laboratorio adjunta), la MTU de cada una de las subredes por las que
circulan los datagramas que salen de tu máquina hacia la dirección 10.3.7.0.

¿Cuántas subredes se atraviesan?

Practica 2

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)

Como podemos observar aparecen dos mensajes icmp uno es un echo request y otro es un echo reply.

Los tipos asignados a dichos mensajes son los siguientes:

Respuesta eco (Echo reply) Tipo 0 Código 0

Solicitud eco (Echo request) Tipo 8 Código 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?

Las direcciones MAC e IP origen, hacen referencia a la misma máquina ya que tanto la dirección MAC como la Ip son las pertenecientes al router del laboratorio sobre el que se ha ejecutado el ping

IP 172.20.43.230

MAC 00:07:0E:8C:8C:FF

En este caso la la ip coincide con la mac porque la llamada es al router, si ejecutásemos el ping a una dirección fuera del laboratorio, la dirección ip del mensaje sería la de la fuente pero la dirección mac seria la de la puerta de enlace.

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 los paquetes IP son 74 bytes, los cuales se dividen de la siguiente forma

| CAB. ETHER.14 bytes | CAB IP 20 bytes | CAB ICMP 8 bytes | DATOS ICMP 32 bytes |

Para averiguar los datos de la cabeceras, vamos pinchando en las diferentes líneas de la ventana de información, pudiendo comprobar así, los bytes de la trama total que pertenecen a cada línea, averiguando así el número de bytes de cada cabecera y de los datos.

PRACTICA 1

Desarrollo de la práctica:
Cuestión 1. Iniciación al monitor de red. Visualización general de protocolos en la red
Activar el monitor de red y capturar todo tipo de tramas en la red durante unos segundos. Paraliza la captura y visualiza.

La realización de la práctica se realizará con el PROGRAMA WHIRESHARK: http://www.wireshark.org/
1.a Del conjunto de tramas adquiridas filtrar las que estén dirigidas a la máquina del alumno. ¿Cuántas tramas aparecen?
Filtro:
ip.dst == 172.20.43.207
Explicación:
ip.dstàlas tramas que salen de nuestra máquina (destino).
172.20.43.207àsubred del PC de nuestro puesto, para obtenerlo basta con poner en MSDOS el comando ipconfig.
TRAMAS ADQUIRIDAS
TRAMAS DIRIGIDAS
8278
938
1.b Del conjunto de tramas adquiridas filtrar las que proceden de la máquina del alumno. ¿Cuántas tramas visualizas ahora?
Filtro:
ip.src == 172.20.43.207
Explicación:
ip.srcàlas tramas que llegan a nuestra máquina (origen).

TRAMAS ADQUIRIDAS
TRAMAS ENVIADAS
8278
1008
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?
ip.addr == 172.20.43.207

Explicación:
ip.addràlas tramas que salen y llegan a nuestra máquina.

TRAMAS ADQUIRIDAS
TRAMAS ENVIADAS y recibidas
8278
1946

CONCLUSIÓN:
Sí que es coherente, ya que si nos fijamos, el resultado obtenido en este apartado tiene que ser igual a la suma de las tramas enviadas y recibidas
938 + 1008 = 1946 Esta correcto

Cuestión 2. Análisis estadístico de una captura de datos
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.
2.a Calcula el porcentaje de tramas Ethernet de difusión existentes en la captura. (tramas de difusión/tramas totales *100).
Filtro
eth.addr == FF-FF-FF-FF-FF-FF

Total tramas
Tramas difusión
% tramas difusión ethernet
6428
6134
(6134/6428)*100= 95.42 %
2.b Calcula el porcentaje de paquetes IP existentes en la captura.
Filtro
ip

Total tramas
Tramas difusión
% tramas difusión Ethernet
6428
6402
(6402/6428)*100= 99.59 %
2.c Calcula el porcentaje de paquetes IP enviados por la máquina del alumno.
Filtro
ip.src == 172.20.43.207

Total tramas
Tramas difusión
% tramas difusión ethernet
6428
468
(468/6428)*100= 7.28%
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”)
FILTRO
ip contains “abcd”

NUMERO PAQUETES CON ABCD 8
La aplicación que ha generado esos datos es: ping
ICPM
INTERNET CONTROL MESSAGE PROTOCOL, perteneciente a la capa INTERNET IP la cual se ocupa de encaminar los paquetes de la forma más conveniente para que lleguen a su destino, y de evitar que se produzcan situaciones de congestión en los nodos intermedios.
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”)
ip.ttl == 1

NUMERO IP “TTL” igual a 1 =3
La aplicación que ha generado esos datos es:
ICPM
INTERNET CONTROL MESSAGE PROTOCOL, perteneciente a la capa INTERNET IP la cual se ocupa de encaminar los paquetes de la forma más conveniente para que lleguen a su destino, y de evitar que se produzcan situaciones de congestión en los nodos intermedios.
2.f Determina en cuantos paquetes aparece la cadena “aula24”. ¿A qué aplicación están asociados?
http://www.aula24horas.com/
FILTRO
ip contains “aula24″

CUATRO TRAMAS
TRAMA 1:
Nº
Time
Source
Destination
Protocol
Info
6197
238.106887
172.20.43.207
172.25.40.81
DNS
Standard query A

DOMAIN NAME SYSTEM ( SERVIDOR DE NOMBRES), protocolo de alto nivel que se utiliza para ofrecer servicio al usuario, perteneciente a la capa de aplicación.
TRAMA 2:
Nº
Time
Source
Destination
Protocol
Info
6198
238.108632
172.25.40.81
172.20.43.207
DNS
Standard query response CNAME aula24horas.com A 72.32.4.173
DOMAIN NAME SYSTEM ( SERVIDOR DE NOMBRES), protocolo de alto nivel que se utiliza para ofrecer servicio al usuario, perteneciente a la capa de aplicación.
TRAMA 3:
Nº
Time
Source
Destination
Protocol
Info
6210
238.292744
172.20.43.207
72.32.4.173
HTTP
GET / HTTP/1.1
HTTP (WEB), protocolo de alto nivel que se utiliza para ofrecer servicio al usuario, perteneciente a la capa de aplicación.
TRAMA 4:
Nº
Time
Source
Destination
Protocol
Info
6235
238.858431
72.32.4.173
172.20.43.207
TCP
[TCP segment of a reassembled PDU]
A la capa de transporte corresponde el protocolo TCP (TRANSMISION CONTROL PROTOCOL), el cual ofrece un servicio fiable, con lo que los paquetes llegan ordenados y sin errores, además de ocuparse también del control de flujo extremo a extremo.
Cuestión 3. Sobre el protocolo ARP
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.
MI dirección Ip es : 172.20.43.207
Mi dirección mac es: 00-0A-5E-76-FF-A6
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?
FILTRO:arp && eth.addr==00-0A-5E-76-FF-A6
Explicación:Como las tramas ARP están asociadas a nuestra red local debemos especificar en el filtro que queremos las tramas de la red Ethernet. Y como las que queremos son las de nuestro pc ponemos nuestra dirección MAC. Intervienen dos tramas
¿Cuál es el estado de la memoria caché de ARP cuando se ejecuta el protocolo ARP?
Ejecutando el comando arp -a obtenemos la memoria cache de ARP
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 en este caso no aparecen tramas ARP, ya que al encontrarse la dirección mac en memoria cache, no es necesario iniciar el protocolo.

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 primer lugar en MSDOS realizamos los siguientes pasos:Ping 172.20.43.204Ping 172.20.43.206Ping 172.20.43.208 Con estos tres comandos estamos realizando peticiones a los ordenadores de nuestros compañeros mediante su dirección IP. Seguidamente miramos la memoria cache ARP, en la cual podemos ver las correspondientes direcciones MAC de los ordenadores de nuestros compañeros. Es conveniente decir que esto es posible porque los ordenadores están conectados en red local, si no fuera así tendríamos la dirección MAC de un router que haría de enlace entre redes.

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? En primer lugar tenemos que borrar la memoria cache ARP con el comando arp –d

Va aumentando, pudiendo apreciar sus direcciones IP y MAC

Las tramas que aparecen son ARP de petición y respuesta entre los ordenadores
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’?
La explicación de que coincidan es porque en el primer ping estamos haciendo una llamada al mismo router, y en el segundo y tercer caso es porque hacemos una llamada a equipos fuera de nuestra red local y como sabemos el protocolo ARP nos devuelve una respuesta una vez realizada una petición (difusión).

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).
COMANDO
ORIGEN MAC
ORIGEN IP
DESTINO MAC
DESTINO IP
ARP PETICION
Mac1
5.1.2.0
Mac2
5.1.1.0
ARP RESPUESTA
Mac2
5.1.1.0
Mac1
5.1.2.0
ARP PETICION
Mac 3
5.2.1.0
Mac 4
5.2.2.0
ARP RESPUESTA
Mac4
5.2.2.0
Mac 3
5.2.1.0

Cuestión 4. Sobre TCP/IP
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.
Mascara original
255.255.254.0 11111111.11111111.11111110.00000000
Ampliamos mascara desubred en 2 bits
11111111.11111111.11111111.10000000 255.255.255.128
Direccion IP
125.145.64.0 11111101.10010001.100000000.00000000
Nuevas subredes Direcines Ip subredes
1ª Subred 011111101.10010001.010000000.00000000 125.145.64.0
2ª Subred 011111101.10010001.010000000.10000000 125.145.64.128
3ª Subred 011111101.10010001.010000001.00000000 125.145.65.0
4ª Subred 011111101.10010001.010000001.10000000 125.145.65.128

Subred
Primera maquina
Ultima maquina
125.145.64.0
125.145.64.1
125.145.64.127
125.145.64.128
125.145.64.129
125.145.64.254
125.145.65.0
125.145.65.1
125.145.65.127
125.145.65.128
125.145.65.129
125.145.65.254
4.b Analizar al azar varios datagramas IP capturados con el monitor de red.
De los datagramas visualizados, indica cuál es su longitud.

La longuitud no es fija, para visualizarla , algunos valores son los siguientes:
Total Length: 237 bytes
Total Length: 78 bytes
Total Length: 132 bytes
Total Length: 1443 bytes
¿Qué aparece en el campo de Protocolo de cada datagrama?
Como se observa en esta captura,

Al desplegar las propiedades de internet protocol , observamos que el protocolo utilizado es:
Protocol: UDP (0×11)
Identifica la CLASE de dirección asociada a cada dirección IP fuente o destino.
DIRECCION IP
172.20.43.228
172.20.43.205
Son direcciones de clase B
4.c Empleando el monitor de red, averigua las direcciones IP de los siguientes servidores web:

Redes de ordenadores

Este blog nace a partir de la asignatura de Redes de ordenadores de la universidad de Alicante (UA), donde colocaremos las distintas memorias y respuestas a los ejercicios que hagamos en prácticas, intentando agregar ilustraciones e imágenes a modo de ejemplo en los casos que creamos conveniente. Esta asignatura, es una asignatura optativa de la titulación de Ingeniería Técnica de Telecomunicaciones en la especialidad de imagen y sonido.