Cuestión 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 los paquetes UDP que se desencadenan cuando se envía como datos, por ejemplo “Hola a todos mis compañeros de Redes”. Utiliza el filtro adecuado en el Monitor de Red (direcciones y protocolos).
El filtro que empleo es el habitual ip.addr==172.20.43.203 && ip.addr==10.3.7.0 con lo que, en el Analizador de Protocolos, sólo se nos muestra el tráfico de paquetes entre máquina fuente y destino predeterminados; amen de añadir !nbns para limpiar la información generada con ocasión del sistema operativo. En ambos casos de generación de datagramas UDP el servidor Linux 1 nos responde; para el primer envío, al puerto 7, nos reenvía lo que le hemos enviado y; para el segundo envío, al puerto 13, hora y fecha del sistema.
Cuestión 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…).
Cuestión 2. Emplear el programa rexec para ejecutar el comando <ls -l>
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). Comprueba el valor de los puertos utilizados. Indica su valor. Analizar los valores de la ventana de receptor. ¿Cuál es más grande?.
En la ventana del Analizador de Protocolos podemos observar bajo la columna info que la secuencia de conexión/desconexión TCP es la que sigue: SYN·SYN,ACK·ACK·Session Establishment· ACK· SYN· RST,ACK·Client Data·ACK·Client Data· ACK·FIN,ACK·ACK, que si la comparamos con la del guión de esta misma práctica es muy similar; sobretodo si nos centramos en el establecimiento de conexión.
En cuanto a la respuesta RST del cliente con motivo de la solicitud SYN del servidor; para tratar de autentificar al cliente, los puertos empleados en la Transmission Control Protocol son: Src Port: ident (113), Dst Port: gris (2135). Los puertos son identificadores de 16 bits que permiten identificar los procesos origen y destino, a nivel de aplicación, de las máquinas origen y destino, respectivamente. Un valor de puertos distinto al empleado para el resto de flujo de bytes, a los que no acceden el resto de aplicaciones, por motivos de seguridad.
Analizando la ventana de receptor podemos observar dos valores para window size: 65535 (para los paquetes cuyo origen es la máquina del alumno, con puerto 1766 y destino Linux 2, con puerto 512) y 5840 (viceversa, para los paquetes cuyo origen es la máquina Linux 2 y destino la máquina del alumno). Excepcionalmente, window size toma valor 0 para la transmisión RST de la máquina del alumno, ahora con puerto 113 como respuesta a la solicitud SYN de la máquina Linux 2, ahora con puerto 2135.
Cuestión 3. Utiliza el programa rexec para ejecutar el comando cat ifconfig.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 fragmenta paquetes TCP. En primer lugar, se puede comprobar con el Analizador de Protocolos que para cualquier paquete de los enviados/recibidos en la conexión TCP que nos ocupa, el primer bit del campo Flag, se corresponde con don´t fragment que nos indica la inexistencia de paquetes fragmentados; en caso contrario, nos aparecería more fragments. Y, en segundo lugar, como una de las principales características del TCP, en dicho protocolo se trabaja con un flujo de bytes de tamaño adecuado a la MTU de la red para mejorar el rendimiento y evitar la fragmentación a nivel IP. Puede leerse en la infomación de los segmentos que el tamaño del paquete TCP es de 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?
Encontramos valores de MSS de 1460 y de 460. Es este último valor el que ha de negociarse entre los extremos de las máquinas. El tamaño de los segmentos TCP es de 480 bytes (460 de datos y 20 de cabecera TCP). La diferencia la encontraremos en que, en este caso, los segmentos TCP contendrán menos datos.
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?.
Nos disponemos a iniciar un Protocolo de Transferencia de Ficheros con el terminal del compañero cuya máquina tiene asociada la IP 172.20.43.202. El Analizador de Protocolos, después de ejecutar el filtro correspondiente nos muestra los siguientes paquetes:
Se comprueba como la máquina fuente solicita establecimiento de conexión con Flag: SYN. Sin embargo, como respuesta, la máquina destino solicita un reinicio de la conexión con Flag: RST/ACK debido a: 1. un problema en la secuencia de bytes, 2. un fallo en el intento de iniciar la conexión o 3. un rechazo de paquetes no válidos. En la figura se puede entrever que se efectúan tres solicitudes de establecimiento de conexión SYN aunque queda asociada a una respuesta RST para solicitar un reinicio de la conexión, ya que la imposibilidad de la conexión se debe a que el servicio TCP está deshabilitado en los ordenadores del alumno.
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.
Datagrama 1: Ethernet header: 14 bytes, IP header: 20 bytes, UDP header: 8 bytes = 42 bytes ······ 472 bytes.
Datagrama 2: Ethernet header: 14 bytes, IP header: 20 bytes = 34 bytes ····································· 480 bytes.
Datagrama 3: Ethernet header: 14 bytes, IP header: 20 bytes = 34 bytes ····································· 048 bytes.
Como en el caso del protocolo TCP se trabaja con flujos de bytes, la cabecera de cada uno de esos flujos siempre se encontrará dentro de la IP; por consiguiente:
Paquete 1: Ethernet header: 14 bytes, IP header: 20 bytes, TCP header: 20 bytes = 54 bytes ·········· 460 bytes.
Paquete 2: Ethernet header: 14 bytes, IP header: 20 bytes, TCP header: 20 bytes = 54 bytes ·········· 460 bytes.
Paquete 3: Ethernet header: 14 bytes, IP header: 20 bytes, TCP header: 20 bytes = 54 bytes ·········· 080 bytes.
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. b. Indica la MTU del camino completo. 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.Cualquiera de los recorridos tomados hubiera provocado la aparición de un mensaje ICMP type 3 y code 4: Destination unreachable, fragment needed; lo que significa que el paquete IP no ha alcanzado su destino (type 3) porque necesita ser fragmentado (code 4) ya que la MTU del enlace entre las máquinas B y D es menor que el tamaño de datos que contiene el paquete TCP; así como la del camino entre las máquinas B y el destino final E.
Para saber la MTU del camino completo basta con fijarnos que camino presenta el menor valor del máximo que puede contener el campo de datos de la trama Ethernet, y en este caso es de 500 bytes.
Los paquetes que se generan con esta alternativa entre las máquinas A y E se presentan a continuación:
Paquete 1: Ethernet header: 14 bytes, IP header: 20 bytes, TCP header: 20 bytes = 54 bytes ·········· 460 bytes.
Paquete 2: Ethernet header: 14 bytes, IP header: 20 bytes, TCP header: 20 bytes = 54 bytes ·········· 460 bytes.
Paquete 3: Ethernet header: 14 bytes, IP header: 20 bytes, TCP header: 20 bytes = 54 bytes ·········· 460 bytes.
Paquete 4: Ethernet header: 14 bytes, IP header: 20 bytes, TCP header: 20 bytes = 54 bytes ·········· 120 bytes.
Cuestión Anexa. 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.
a) Determina con el monitor de red qué valor de MSS se ha negociado en la conexión TCP. Para ello visualiza todos los paquetes IP intercambiados entre tu PC y el servidor 172.20.41.241.
El criterio sigue siendo válido para un MSS de menor valor, pues está sujeto a la MTU que presente el enlace entre dos máquinas. Así pues, el menor valor que se ha podido observar en los paquetes es de 460 bytes.
b) ¿Hay paquetes ICMP “fragmentation needed and the bit don't fragment was set”? Si la respuesta es afirmativa, ¿qué máquina envía el mensaje de error?.
Como se puede leer, la máquina fuente de dicho mensaje de error se corresponde con la de IP 172.20.43.231; que pertenece, conforma a la configuración de red del laboratorio, a Cisco 1601. La máquina de destino se corresponde con la del alumno.
c) ¿Cómo afecta este mensaje ICMP al tamaño de los paquetes TCP intercambiados entre tu PC y el servidor 172.20.41.241 ? .
El número de MSS disminuye (FTP data: 360 bytes), lo que significa que el mensaje debe de fragmentarse aún más y, con ello, el tamaño de los paquetes TCP es menor.
d) ¿Reenvía tu PC algún paquete TCP al servidor?.
Sí, en el frame 246; en cuya info se puede leer here-im > ftp [ACK] Seq=76 Ack=271 Win=65265 Len=0
e) ¿Fragmenta IP algún paquete TCP ?.
No. El protocolo TCP trabaja con grupo de bytes individuales precisamente para evitar la fragmentación de IP. Aparecen paquetes FTP-DATA de 360 bytes de datos.
Entradas
