Enunciados Preguntas nº 1 10/01/04 1. Una empresa quiere crear una red de ordenadores en un entorno TCP/IP. Para hacerlo, han decidido hacer uso de las direcciones reservadas para intranet. Concretamente querrían utilizar la red 172.20.0.0. a) ¿Cuántas estaciones podrían tener en la red 172.20.0.0? La red es de tipo B y su máscara por defecto sería 255.255.0.0. Eso nos permitiría disponer de espacio para 65536 direcciones para estaciones (realmente dos menos, porque una dirección se reserva para identificar la red y otra para el broadcast remoto). Suponemos que sólo necesitan "espacio" de direcciones para cincuenta estaciones y se plantean hacer una segmentación de la red. b) ¿Cuál sería la máscara más restrictiva para este escenario, pero que incluya las cincuenta estaciones en una subred? Si sólo queremos espacio para cincuenta estaciones, la máscara adecuada es 255.255.255.192, que da 6 bits para estaciones, o sea, 64 posibilidades. Restando la todo 0 y la todo 1, quedan 62 estaciones posibles. c) ¿Cuál sería el rango de subredes posibles para el caso anterior? La primera subred sería 172.20.0.64 y la detrás de 172.20.255.128. La que tiene todos los bits de subred en 0 y la que tiene todos los bits de subred en 1, no se consideran válidas. d) ¿Cómo se podría hacer un broadcast local? ¿Y un broadcast remoto? El broadcast local siempre es 255.255.255.255. Subred 172.20.0.64 172.20.0.128 172.20.0.192 … 172.20.255.128
Broadcast remoto 172.20.0.127 172.20.0.191 172.20.0.255 … 172.20.255.191
17/01/04 1. A continuación se presenta el volcado de un paquete IP capturado con el programa Ethereal durante una sesión en una red de área local. Escribe e interpreta cuando proceda el valor de cada campo de la cabecera IP. ¿Qué protocolo encapsula? ¿De qué aplicación se trata?
4500 0030 2521 4000 8006 04b5 c190 2cab c190 2126 0527 006e 0082 b37b 0000 0000 7002 2000 d89a 0000 0204 05b4 0101 0402 Versión IP (4 bits) Longitud cabecera (4 bits) Tipo de servicio (8 bits) Longitud total del paquete (16 bits) Identificación del paquete (16 bits)
Hexadecimal 4 5 00 0030 2521
Flags (3 bits)
40
Posición de este fragmento (13 bits)
00
TTL (tiempo de vida, 8 bits)
80
Protocolo (8 bits) Checksum (16 bits) IP Origen (32 bits) IP Destino (32 bits)
06 04b5 c1.90.2c.ab c1.90.21.26
Significado Es la versión 4 del protocolo IP. La cabecera tiene 5 palabras de 4 bytes, es decir, 20 bytes. La longitud del paquete es de 48 bytes. Si el paquete se fragmenta este identificador es el mismo para todos los fragmentos. El flag DF está puesto a 1, lo que indica que el fragmento no se puede fragmentar. MF=0, es decir, es un fragmento único. Está en la posición 0, lógicamente, ya que no se puede fragmentar. Puede pasar por 128 enrutadores antes de ser descartado. Encapsula el protocolo TCP La dirección IP origen es 193.144.44.171 La dirección IP destino es 193.144.33.38
Para saber de qué tipo de aplicación se trata, sabemos que la cabecera IP ocupa los 20 primeros bytes. A continuación viene la cabecera TCP, en la que los 16 primeros bits nos dan el puerto de origen y los 16 siguientes el puerto de destino, esto es 006e en hexadecimal, que es el puerto 110 que se corresponde con correo POP3. 24/01/04 1. La figura siguiente nos muestra una intranet usando el protocolo TCP/IP en la cual se puede acceder desde el exterior por medio de un acceso telefónico (XTC). Se supone que las LAN de la figura son de tipo Ethernet y que el acceso telefónico hace uso del protocolo PPP.
Las direcciones asignadas a cada elemento de la red son: H1 H2 Router
112.3.4.5 112.5.6.2 112.8.9.10 147.12.253.22 147.15.18.23
PC
08:30:2a:11:9b:32 a8:0a:02:1e:a7:f2 b8:05:03:1d:f7:a2 45:44:43:42:00:00 65:34:22:33:22:11
Se pide: a) Suponed que H2 quiere enviar información a H1. Especificad qué dirección IP y qué dirección MAC de destino tendrá que especificar H2. IP: 112.3.4.5 MAC: 08:30:2a:11:9b:32 b) Suponed que H1 quiere enviar información al PC. Especificad qué dirección IP y qué dirección MAC de destino tendrá que especificar H1. IP: 147.15.18.23 MAC :b8:05:03:1d:f7:a2 c) Suponed que el PC quiere enviar información al H2. Especificad qué dirección IP y qué dirección MAC de destino tendrá que especificar el PC. IP: 112.5.6.2 MAC: La proporcionada para su proveedor de servicios de Internet d) Si H2 quiere realizar un broadcast local, determinad la dirección IP y la dirección MAC que tendrá que especificar H2. IP: 255.255.255.255 MAC: ff:ff:ff:ff:ff:ff e) Si el PC quiere realizar un broadcast remoto, determinad la dirección IP que tendrá que especificar el PC. IP: 112.255.255.255 f) Suponed que desde el PC hacemos un ftp hacia el host H1. Una vez se ha establecido la conexión con el protocolo ftp, del PC se envía una información a través de la aplicación ftp hacia el host H1 que es el comando dir. Determinad la relación entre la longitud de la información que pretende enviar el nivel de aplicación y la longitud total de la trama, tanto en la trama que envía el PC como la que recibe el host H1. Se utiliza la codificación ASCII para los caracteres tecleados. Se supone que en la red de área local se utiliza el formato de trama IEEE 802.3 que permite la introducción de bits de relleno y no hay que tener en cuenta la longitud del preámbulo Ethernet. En el PC tendremos el siguiente nivel de protocolos:
TCP IP PPP Si tenemos en cuenta que el protocolo TCP introduce un overhead de 20 bytes, el protocolo IP introduce un overhead de 20 bytes, el protocolo PPP introduce un overhead de 8 bytes y enviamos 3 bytes de nivel de aplicación (el comando dir) tenemos que la relación entre la información de nivel de aplicación con respecto a la longitud de la trama enviada PPP es: 3 / (20 + 20 + 8 + 3) = 3 / 51 = 0,05882 = 5,882 % En el H1 tendremos el siguiente nivel de protocolos: TCP IP Ethernet (802.3) Si tenemos en cuenta que el protocolo TCP introduce un overhead de 20 bytes, el IP introduce un overhead de 20 bytes y la trama del protocolo Ethernet tendrá un tamaño de 64 bytes (teniendo en cuenta el rellenado, las cabeceras y que la información de 3 bytes del comando dir ya está incluida dentro de los 64 bytes de esta trama Ethernet) tenemos que la relación entre la información enviada y la información de nivel Ethernet recibido en H1 es: 3 / (20 + 20 + 64) = 3 / 104 = 0,02884= 2,884 % g) Suponed que desde el PC se quiere enviar un fichero hacia el host H2. ¿Sería suficiente la existencia del protocolo de nivel de red entre el PC y H2 para la correcta recepción del fichero o sería necesaria la inclusión de un nivel de transporte? Justificad la respuesta. Debido a que la RTC (XTC en la figura) es una red de conmutación de circuitos, nos ofrece una conexión o circuito entre los extremos, es decir, entre el PC y el router, entonces la RTC para ella sola nos garantiza la correcta secuenciación de las tramas (y paquetes de nivel de red) ya que es como una conexión punto a punto entre el PC y el Router. También debido a que la red Ethernet no es una red de conmutación de paquetes y por lo tanto, un paquete de nivel de red no puede ir por varios caminos, la red Ethernet nos garantiza también una correcta secuenciación de las tramas de nivel de red. Por lo tanto, en este caso no sería necesario un nivel de transporte y sólo haría falta un nivel de red. h) Suponed una MTU del protocolo PPP de 300 bytes y un MSS de nivel de transporte de 512 bytes. Si enviamos información de nivel de aplicación del PC hacia el H2 de 4608 bytes, determinad el número de tramas PPP enviadas por el PC. Nota: Suponed que se realiza la transmisión una vez se ha establecido la conexión.
En el PC tenemos 4608 bytes de nivel de aplicación, con un MSS de 512 bytes de nivel de transporte, entonces transmitiríamos 4608/512 = 9 paquetes de nivel de transporte. Si cada trama de nivel de TCP tiene 20 bytes de overhead, y cada paquete de nivel IP tiene 20 bytes de overhead, cada paquete de nivel IP tendría una longitud de 512 + 40 = 552 bytes. Así cada paquete IP que tiene una longitud de 552 bytes se convertiría en dos tramas de nivel PPP (ya que MTU del PPP vale 300 bytes y 552 / 300 = 2 tramas), y por lo tanto, en total se generarían 9·2 = 18 tramas de nivel PPP desde el PC. i) ¿En la configuración de red de la figura anterior, cuál se el ámbito de operación del protocolo ARP? El ámbito de operación del ARP es la red de área local que contiene H1, H2 y el router, es decir, la red 112.0.0.0. j) Escribid la tabla de encaminamiento del router. Dirección 112.8.9.10 147.12.253.22 127.0.0.0 112.0.0.0 147.0.0.0 255.255.255.255 0.0.0.0
Máscara 255.255.255.255 255.255.255.255 255.0.0.0 255.0.0.0 255.0.0.0 255.255.255.255 0.0.0.0
Encaminador 127.0.0.1 127.0.0.1 127.0.0.1 112.8.9.10 147.12.253.22 112.8.9.10 147.12.253.22
Interfaz Loopback Loopback Loopback Ether1 Ether0 Ether1 Ether0
14/06/04 1- Una empresa, a la cual se le ha asignado la red de clase C 199.134.167.0, está estructurada en 5 departamentos, y a la hora de planificar la red interna, decide hacer una subred para cada departamento.
Para hacerlo, dispone de un encaminador con 6 accesos: un para cada subred y uno para la conexión con su ISP, con ADSL. a) ¿Qué máscara deberá usar en las 5 subredes internas? Si destinamos 2 bits tenemos 22-2 = 2 subredes. Si destinamos 3 bits, tenemos 23-2 = 6 subredes. Por lo tanto, calan 3 bits. La máscara sería, pues, 255.255.255.224. b) Suponiendo que la subred que tiene todos los bits a 0 y la que los tiene todos a 1 no se usan, ¿qué podrían ser las direcciones de red de cada subred y como seria el broadcast local de cada una? ¿Cuántas subredes más podremos usar sin cambiar la máscara?
Las direcciones de red de ·/*·*/199.134.167.32 ·/*·*/199.134.167.64 ·/*·*/199.134.167.96 ·/*·*/199.134.167.128 ·/*·*/199.134.167.160 y nos queda libre la red 199.134.167.192.
las
5
subredes
serian:
El broadcast local seria 255.255.255.255 para todas. c) ¿Cuántas máquinas podrá tener a cada subred como máximo? ¿Y en toda la empresa? ¿Y cuantas podría tener si no hicieran subredes? A cada subred podemos tener 25-2 = 30 máquinas. Y en toda la empresa, 30*6 = 180 (asumiendo que usamos todas las subredes posibles). Sin hacer subredes, 28-2 = 254 máquinas. d) Suponéis que al PC1 tenemos un navegador web, y le pedimos acceder a www.uoc.edu. Suponéis también que la caché ARP de PC1 esta vacía. Describid todas las acciones que se llevan a término –desde que se pide la página hasta que se ve el monitor- a todos los niveles de la pila TCP/IP de PC1 y qué protocolos calan: como se averigua la dirección IP del servidor, qué pedido tira el protocolo HTTP, qué hacen los niveles de transporte y red, como se decide a qué máquina se envía el paquete, qué se hace a nivel de enlace, como se averigua la dirección MAC de dónde se ha de enviar la trama, etc. Decid qué tramas Ethernet saldrán de PC1, y qué paquetes IP contendrán. Podéis ilustrar todo el proceso dibujando las diferentes PDU que se van generando. Hace falta averiguar la IP de www.uoc.edu, con una petición DNS. Irá encapsulada dentro de un datagrama UDP, que irá dentro de un paquete IP con dirección destino la de nuestro servidor DNS-, que irá dentro de una trama Ethernet. Para saber la dirección Ethernet destino, se consulta la tabla de encaminamiento local, para saber como llegar al servidor DNS que nos corresponde. Con un broadcast Ethernet se hace la petición ARP para saber la dirección Ethernet del destinatario de la trama (típicamente el propio servidor DNS si está a la misma red o un encaminador). Recibimos una respuesta ARP y ya sabemos cuál es la dirección Ethernet que hace falta poner como destino de la trama que contiene la petición DNS.Enviamos la petición DNS. Recibimos la respuesta DNS, con la IP de www.uoc.edu. Entonces se tira el pedido HTTP GET, encapsulada dentro de un segmento TCP, que irá dentro de un paquete IP, que tiene como dirección destino la que nos ha suministrado el servidor DNS. Este paquete IP irá dentro de una trama Ethernet que pondremos como destino la misma dirección recibida en la respuesta ARP anterior. Recibimos una respuesta HTTP que contiene la página principal de www.uoc.edu, dentro de un segmento TCP, que está dentro de un paquete IP, que está dentro de una trama Ethernet.
19/06/04 1. Un hacker utiliza tcpdump por escuchar la red local dónde está conectado y guardar en un fichero los paquetes que circulan, para poderlos analizar posteriormente. tcpdump elimina la cabecera del nivel de enlace y graba todos los bytes que hay a continuación. Por lo tanto, cada bloque de bytes contiene la cabecera IP más sus datos, dentro las cuales habrá una cabecera TCP o UDP (según el protocolo de transporte usado) más los datos de aplicación. Este hacker utiliza tcpdump con la opción –X, que muestra hasta los 82 primeros bytes del paquete, en forma hexadecimal y en ASCII. tcpdump -X Después de estar un rato grabando paquetes, el hacker se dispone a analizarlos. Suponemos que ve los siguientes datos: 16:33:58.372378 IP 147.83.34.97.44838 > 147.83.32.82.21: P 75:81(6) ack 298 win 5840
0x0000: 4510 003a c219 4000 4006 0f3b 9353 2261 E..:..@.@..;.S"a 0x0010: 9353 2052 af26 0015 2cb7 bf02 61a0 fc28 .S.R.&..,...a..( 0x0020: 8018 16d0 d063 0000 0101 080a 009b 88f0 .....c.......... 0x0030: 04b4 f27b 4c49 5354 0d0a ...{LIST.. 16:33:58.391627 IP 147.83.32.82.21 > 147.83.34.97.44838: P 298:339(41) ack 81 win 5792 0x0000: 4500 005d 1ccd 4000 3f06 b574 9353 2052 E..]..@.?..t.S.R 0x0010: 9353 2261 0015 af26 61a0 fc28 2cb7 bf08 .S"a...&a..(,... 0x0020: 8018 16a0 c09c 0000 0101 080a 04b4 f27d ...............} 0x0030: 009b 88f0 3135 3020 4f70 656e 696e 6720 ....150.Opening. 0x0040: 4153 4349 4920 6d6f 6465 2064 6174 6120 ASCII.mode.data. 0x0050: 636f co 16:33:58.423061 IP 147.83.34.97.44838 0x0000: 4510 0034 c21a 4000 4006 0f40 0x0010: 9353 2052 af26 0015 2cb7 bf08 0x0020: 8010 16d0 7ce2 0000 0101 080a 0x0030: 04b4 f27d ...}
> 147.83.32.82.21: . ack 339 win 5840 9353 2261 E..4..@.@[email protected]"a 61a0 fc51 .S.R.&..,...a..Q 009b 88f6 ....|...........
16:33:58.423561 IP 147.83.32.82.21 > 147.83.34.97.44838: P 339:363(24) ack 81 win 5792 0x0000: 4500 004c 1cce 4000 3f06 b584 9353 2052 E..L..@.?....S.R 0x0010: 9353 2261 0015 af26 61a0 fc51 2cb7 bf08 .S"a...&a..Q,... 0x0020: 8018 16a0 adf9 0000 0101 080a 04b4 f280 ................ 0x0030: 009b 88f6 3232 3620 5472 616e 7366 6572 ....226.Transfer 0x0040: 2063 6f6d 706c 6574 652e 0d0a .complete... 16:33:58.423667 IP 147.83.34.97.44838 0x0000: 4510 0034 c21b 4000 4006 0f3f 0x0010: 9353 2052 af26 0015 2cb7 bf08 0x0020: 8010 16d0 7cc7 0000 0101 080a 0x0030: 04b4 f280
....
> 147.83.32.82.21: . ack 363 win 5840 9353 2261 E..4..@.@..?.S"a 61a0 fc69 .S.R.&..,...a..i 009b 88f6 ....|...........
a. Escribe e interpreta, cuando así proceda, el valor de cada campo de la cabecera IP del primer paquete. Versión (4bits): Hexadecimal: 4 Significado: La versión IP que se está usando es la 4 (IPv4) Longitud de la cabecera en palabras de 4 bytes (4 bits): Hexadecimal: 5 Significado: La longitud de la cabecera es 5 x 4 = 20 bytes, es decir, se trata de una cabecera IP sin opciones.
Tipos de servicio - TOS (8 bits): Hexadecimal: 10 -> Binario: 0001 0000 Significado: Los 3 primeros bits y el último bit se ignoran. Así pues, el TOS recoge realmente 4 bits (1000). Cada bit corresponde a la petición de un tratamiento especial en este sobre minimizar el retardo, maximizar el througput, maximizar la fiabilidad y minimizar el coste respectivamente. Longitud total del paquete en bytes (16 bits): Hexadecimal: 003a -> Binario: 0000 0000 0011 1010 -> Decimal: 58 Significado: El paquete IP está formato por 58 bytes, 20 de los cuales ya hemos visto que pertenecen a la parte de la cabecera y el resto (38 bytes) formarán el campo de datos. Si contamos el número de bytes que se nos muestra del paquete en formato hexadecimal vemos que efectivamente estamos observando íntegramente todo el paquete. Identificador (16 bits): Hexadecimal: c219 Significado: Indica el identificador del paquete. En caso de que un paquete se deba fragmentar en varios paquetes , todos ellos tendrán el mismo identificador. Flags (3 bits): Hexadecimal: 010 Significado: El paquete corresponde a un fragmento y después de él todavía no hay más, es decir, no es el último fragmento. Desplazamiento del fragmento (13 bits): Hexadecimal: 0000 Significado: Indica que este paquete corresponde al primer fragmento de todos. TTL (8 bits): Hexadecimal: 40 Significado: Todavía podemos atravesar 40 encaminadores hasta que el paquete sea descartado. Protocolo de nivel superior que encapsula (8 bits): Hexadecimal: 06 Significado: El paquete IP encapsula un segmento TCP. Checksum de la cabecera (16 bits): Hexadecimal: 0f3b Significado: para el control de errores. Dirección IP origen (32 bits): Hexadecimal: 9353 2261 -> Binario: 1001 0011.0101 0011.0010 0010.0110 0001
Significado: Efectivamente da 147.83.34.97 que se nos indicaba en la primera línea de salida del tcmpdump. Dirección destino (32 bits): Hexadecimal: 9353 2052 -> Binario: 1001 0011.0101 0011.0010 0000.0101 0010 Significado: Efectivamente da 147.83.32.82 que se nos indicaba en la primera línea de salida del tcmpdump. ¿Qué protocolo encapsula? Cómo hemos visto en el apartado anterior y se puede observar en el resto de paquetes, el protocolo encapsulado es TCP. c. ¿De qué aplicación se trata? Observando la primera línea del tcpdump en cada paquete vemos que existe una transferencia FTP (puerto 21) entre el cliente 147.83.34.97 y el servidor 147.83.82.21. d. Escribid e interpretad los pedidos de nivel aplicación (la que halláis creído en el apartado anterior) que causarían el intercambio de paquetes que se ha presentado. Allá dónde no tened bastantes datos, suponéis que el comportamiento es el habitual del protocolo encapsulado en los paquetes. Estos 4 paquetes corresponden a una transferencia !" entre un cliente con dirección 147.83.34.97 y un servidor !" con dirección 147.83.82.21. Como que la aplicación es !" el servidor utiliza el puerto 21 y el cliente utiliza el puerto efímero 44838 que es el que le ha asignado su sistema al establecer la conexión. La comunicación es bidireccional y la transmisión de información en ambos sentidos se realiza de forma correcta, sin pérdidas. A nivel aplicación, el cliente pide un listado de los ficheros del directorio actual al servidor. Este le devuelve los datos en una comunicación ASCII sin errores. Notas: La orden de los 3 bytes utilizados por IP a la fragmentación es: “0, DF, +” (y no “DF, +, 0”, como se menciona en la página 30 de los apuntes). El campo “control” de los paquetes TCP es actualmente de 8 bits (y no de 6 como se *menciona a la página 52 de los apuntes) Los dos primeros, de nueva especificación y no descritos a los apuntes, corresponden respectivamente a Congestion Window Reduced y ECN-Echo, y su valor es desactivado (0) o activado (1). El campo “reservado” ya se encuentra actualizado en los apuntes, y es de 4 bits. 26/06/04
1. Un hacker utiliza tcpdump por escuchar la red local dónde está conectado y guardar en un fichero los paquetes que circulan, para poderlos analizar posteriormente. tcpdump elimina la cabecera del nivel de enlace y graba todos los bytes que hay a continuación. Por lo tanto, cada bloque de bytes contiene la cabecera IP más sus datos, dentro las cuales habrá una cabecera TCP o UDP (según el protocolo de transporte usado) más los datos de aplicación. Este hacker utiliza tcpdump con la opción –X, que muestra hasta los 82 primeros bytes del paquete, en forma hexadecimal y en ASCII. tcpdump -X Después de estar un rato grabando paquetes, el hacker se dispone a analizarlos. Suponemos que ve los siguientes datos: 11:31:42.821596 IP xxxxxxx.xxx.xx.3305 > yyyy.yyyyy.yy.25: S 1947778503:1947778503(0) win 65535 (DF) 0x0000 4500 0030 2868 4000 8006 8c9b c191 2dad E..0([email protected]. 0x0010 d504 8181 0ce9 0019 7418 bdc7 0000 0000 ........t....... 0x0020 7002 ffff fe78 0000 0204 05b4 0101 0402 p....x.......... 11:31:42.841598 IP yyyy.yyyyy.yy.25 > xxxxxxx.xxx.xx.3305: S 4233416297:4233416297(0) ack 1947778504 win 1460 (DF) 0x0000 4500 002c d46b 4000 3506 2b9c d504 8181 E..,[email protected].+..... 0x0010 c191 2dad 0019 0ce9 fc54 ce69 7418 bdc8 ..-......T.it... 0x0020 6012 05b4 42fc 0000 0204 05b4 0000 2408 `...B.........$. 0x0030 406c a2a2 da3e 2408 406c 0000 0000 @l...>$.@l.... 11:31:42.841635 IP xxxxxxx.xxx.xx.3305 > yyyy.yyyyy.yy.25: . ack 1 win 65535 (DF) 0x0000 4500 0028 286b 4000 8006 8ca0 c191 2dad E..(([email protected]. 0x0010 d504 8181 0ce9 0019 7418 bdc8 fc54 ce6a ........t....T.j 0x0020 5010 ffff 606d 0000 P...`m.. ... 11:31:59.373529 IP yyyy.yyyyy.yy.25 > xxxxxxx.xxx.xx.3305: F 108:108(0) ack 9 win 33580 (DF) 0x0000 4500 0028 d474 4000 3506 2b97 d504 8181 E..([email protected].+..... 0x0010 c191 2dad 0019 0ce9 fc54 ced5 7418 bdd0 ..-......T..t... 0x0020 5011 832c dccc 0000 0000 0000 0000 12ea P..,............ 0x0030 c1ea a2a2 da3e 12ea c1ea 961c 7ced .....>......|. 11:31:59.373619 IP xxxxxxx.xxx.xx.3305 > yyyy.yyyyy.yy.25: . ack 109 win 65428 (DF) 0x0000 4500 0028 2ed2 4000 8006 8639 c191 2dad E..([email protected]. 0x0010 d504 8181 0ce9 0019 7418 bdd0 fc54 ced6 ........t....T.. 0x0020 5010 ff94 6064 0000 P...`d.. 11:31:59.374009 IP xxxxxxx.xxx.xx.3305 > yyyy.yyyyy.yy.25: F 9:9(0) ack 109 win 65428 (DF) 0x0000 4500 0028 2ed3 4000 8006 8638 c191 2dad E..([email protected]. 0x0010 d504 8181 0ce9 0019 7418 bdd0 fc54 ced6 ........t....T.. 0x0020 5011 ff94 6063 0000 P...`c.. 11:31:59.392754 IP yyyy.yyyyy.yy.25 > xxxxxxx.xxx.xx.3305: . ack 10 win 33580 (DF) 0x0000 4500 0028 d475 4000 3506 2b96 d504 8181 E..([email protected].+..... 0x0010 c191 2dad 0019 0ce9 fc54 ced6 7418 bdd1 ..-......T..t... 0x0020 5010 832c dccb 0000 0000 0000 0000 7684 P..,..........v. 0x0030 126e a2a2 da3e 7684 126e 8945 de56 .n...>v..n.E.V
a. Escribid e interpretad el valor de los campos de las cabeceras primer paquete.
y "$ /%& del
Frame 1 (62 bytes on wire, 62 bytes captured) Ethernet II, Src: 00:03:47:2a:a6:fb, Dst: 00:07:0d:52:f4:00 Internet Protocol, Src Addr: 193.145.45.173 (193.145.45.173), Dst Addr: 213.4.129.129 (213.4.129.129) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 48 Identification: 0x2868 (10344) #
Flags: 0x04 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 128 Protocol: TCP (0x06) Header checksum: 0x8c9b (correct) Source: 193.145.45.173 (193.145.45.173) Destination: 213.4.129.129 (213.4.129.129) Transmission Control Protocol, Src Port: 3305 (3305), Dst Port: 25 (25), Seq: 1947778503, Ack: 0, Len: 0 Source port: 3305 (3305) Destination port: 25 (25) Sequence number: 1947778503 Header length: 28 bytes Flags: 0x0002 (SYN) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...0 .... = Acknowledgment: Not set .... 0... = Push: Not set .... .0.. = Reset: Not set .... ..1. = Syn: Set .... ...0 = Fin: Not set Window size: 65535 Checksum: 0xfe78 (correct) Options: (8 bytes) Maximum segment size: 1460 bytes NOP NOP SACK permitted
b. ¿Qué protocolo encapsula? Es una conexión y desconexión a un servidor '( " (Puerto 25), sin incluir el intercambio de pedidos intermig. c. Escribid los segmentos (')*, '", ! * y $+) "$ asociados a cada paquete, indicando el sentido (máquina x-> máquina , o ,->x) de cada uno. Secuencia de estados TCP: X <-> Y SYN -> <- SYN, ACK ACK -> ... <- FIN, ACK ACK -> FIN, ACK -> <- ACK
d. Dibuja los diagramas de tiempos que muestren el intercambio de paquetes, incluyendo los segmentos "$ , entre los 2 sistemas, y en paralelo, los estados dónde están los dos sistemas en cada momento. ¿De qué tipo de de apertura / cierre se trata en cada sistema?
Diagrama de estados:
Apertura: x: activa, ,: pasiva Cierre: x: pasivo, ,: activo
15/01/2005 1. Una empresa compra las direcciones 11.0.0.0 y 130.1.0.0. El dominio que gestiona se denomina examen.es. La red TCP/IP está sobre el estándar IEEE 802.3 y su topología es la de la figura:
a) Asignar a todos los equipos de la red (estaciones, servidores y router U) las direcciones IP y las máscaras correspondientes. Indicar qué clases de direcciones se están usando en cada red. El router U tiene una dirección IP por cada subred a la que está conectado. La red 130.1.0.0/16 es una clase B
Máquina A (FTP) B Router U
Dir. IP 130.1.0.10 130.1.0.11 130.1.0.1
Máscara 255.255.0.0 255.255.0.0 255.255.0.0
La red 11.1.0.0/16 es una clase A en la que se hace subnetting.
Máquina E F Máquina Router U
Dir. IP 11.1.0.10 11.1.0.11 Dir. IP 11.1.0.1
Máscara 255.255.0.0 255.255.0.0 Máscara 255.255.0.0
Máquina E
Dir. IP 11.1.0.10
Máscara 255.255.0.0
La red 11.2.0.0/16 es una clase A también con subnetting.
Máquina C
Dir. IP 11.2.0.10
Máscara 255.255.0.0
D (WWW) Router U
11.2.0.11 11.2.0.1
255.255.0.0 255.255.0.0
La red 11.3.0.0/16 es una clase A con subnetting. Máquina G H (DNS) Router U
Dir. IP 11.3.0.10 11.3.0.11 11.3.0.1
Máscara 255.255.0.0 255.255.0.0 255.255.0.0
b) Para las estaciones y servidores indicar cuál sería la puerta de enlace, así como el servidor DNS, para que tengan acceso a la intranet examen.es y a Internet. Indicar cuál sería la tabla de enrutamiento del router U y del router del ISP. Describe los pasos que sigue el router U (a nivel IP) para encaminar un paquete con IP destino 11.1.0.X (siendo X una máquina en esa red), basándote en la tabla de enrutamiento que acabas de construir para dicho router. La puerta de enlace para cada máquina será la IP del router en cada subred, es decir, 130.1.0.1, 11.1.0.1, 11.2.0.1 y 11.3.0.1 y normalmente la configuramos de manera manual en cada máquina. El servidor DNS será 11.3.0.11, también configurado de forma manual en cada equipo. La tabla de enrutamiento del router U sería:
Red destino 130.1.0.0 11.1.0.0 11.2.0.0 11.3.0.0 0.0.0.0
Máscara 255.255.0.0 255.255.0.0 255.255.0.0 255.255.0.0 0.0.0.0
Encaminar por 130.1.0.1 11.1.0.1 11.2.0.1 11.3.0.1 195.10.1.2
En realidad, las cuatro primeras entradas no serían necesarias ya que el router está conectado directamente a las subredes y por la máscara sabe por qué interfaz tiene que encaminar. En el caso del router del ISP la tabla sería:
Red destino 130.1.0.0 11.0.0.0 …..
Máscara 255.255.0.0 255.0.0.0 ……
Encaminar por 195.10.1.1 195.10.1.1 ……..
Hay que resaltar que el ISP no tiene por qué saber si en la red de clase A se hace o no subnetting. Por eso la entrada para esa red es 11.0.0.0. El funcionamiento del router es el siguiente: Cuando le llega un paquete coge la IP de destino y hace un AND con la máscara de la primera entrada de su tabla de enrutamiento (aquélla que es más restrictiva). Si coincide lo dirige hacia el gateway correspondiente, si no, continúa con la siguiente entrada.
Por ejemplo, si al router U le llega un paquete con dirección de destino 11.1.0.10 haría lo siguiente: · 11.1.0.10 AND 255.255.0.0 = 11.1.0.0 · Compara la entrada con 130.1.0.0: 130.1.0.0 entrada). · 11.1.0.10 AND 255.255.0.0 = 11.1.0.0
11.1.0.0 (pasamos a la siguiente
Compara la entrada con 11.1.0.0: 11.1.0.0 = 11.1.0.0 (encaminar por la entrada correspondiente en la tabla). c) ¿Qué dirección IP y qué dirección MAC lleva el paquete cuyo origen es el ordenador E y destino el servidor FTP? ¿Por qué? ¿Y si el destino es F siendo también el origen E? ¿Qué protocolo se ha utilizado para averiguar las direcciones MAC? En el caso de que el router U deje de funcionar y E quiera enviar un paquete, ¿con qué equipos le sería todavía posible la comunicación? La dirección IP de destino será la del servidor FTP, es decir, 130.1.0.10. Sin embargo, la MAC no es la del servidor FTP, sino la de la interfaz de red que tenga el router U en la subred en la que se encuentra E. Esto es así porque en la tabla de enrutamiento del equipo E no existe una entrada que indique una ruta directa (en el mismo dominio de colisión) hasta el servidor de FTP, con lo cual se hace imprescindible el uso del gateway hacia la red de destino. Si el destino es F la dirección IP será la de F, es decir, 11.1.0.11. Del mismo modo la MAC será la de F al encontrarse en la misma subred. El router U actúa como “firewall” para los broadcast entre las subredes. El protocolo que se ha utilizado para averiguar las MAC es el ARP. Si el router deja de funcionar la comunicación dentro de cada subred es posible, sin embargo, las máquinas dejarán de tener acceso a Internet y a la intranet examen.es. d) Indicar cómo se construirían los campos Puerto Destino y Puerto Origen del primer segmento TCP, así como los campos Dirección IP Origen y Dirección IP Destino del primer datagrama IP, cuando el ordenador E ejecuta la orden: >ftp ftp.examen.es Los puertos son los puntos de acceso a la capa de transporte desde la capa de aplicación, es decir, la aplicación ftp accede a la capa de transporte a través de un puerto. Los campos se construyen de la siguiente manera: Puerto origen: Cando se inicia la aplicación cliente ftp, el SO le asigna uno de los puertos que tiene libres en ese momento, por ejemplo, el 2000 (tiene que ser un puerto mayor de 1024, por debajo están reservados). Puerto destino: Este puerto es en el que está escuchando el servidor FTP, esperando las peticiones de los clientes y pertenece a los puertos denominados bien conocidos. En el caso del FTP es el puerto 21. IP origen: La del propio host E, es decir, 11.1.0.10.
IP destino: Si se hubiese puesto ftp 130.1.0.10 ésta sería la dirección IP, pero hay que resolver el nombre de dominio, para lo cual, habrá que realizar una petición al servidor DNS que E tenga configurado. Es decir, E pregunta al ordenador con IP 11.3.0.11 si sabe cuál es la dirección IP correspondiente a ftp.examen.es. El servidor DNS mirará su fichero de DNS y resolverá la dirección IP, devolviéndosela a E. e) El ordenador E quiere enviar un fichero llamado prueba.txt de 129 KB (incluyendo datos de control e información propiamente dicha) al servidor FTP, para lo cual ejecuta la orden ftp>put prueba.txt. Explicar detalladamente: Cómo se construyen y qué valores podrían tener los segmentos TCP, así como cuántos segmentos se enviarán. Suponer que el MSS es lo más grande posible y que el tamaño máximo de un datagrama IP es de 64KB. Cómo se transmiten al otro extremo los segmentos teniendo en cuenta un tamaño de ventana de 200KB. Nota.- Ten en cuenta sólo los extremos de la conexión TCP y haz las suposiciones que creas convenientes. 1. Estamos hablando de TCP, es decir, la capa de transporte, donde la transmisión de información se realiza de extremo a extremo y no de equipo a equipo adyacente. Las entidades pares TCP se intercambian segmentos. Estos segmentos serán los datos de los datagramas IP, los datagramas IP serán los datos de la trama y la trama serán los bits. El tamaño máximo del datagrama IP es de 64KB y vamos a suponer que las cabeceras de los segmentos y datagramas no tienen opciones, es decir, cada cabecera tendrá un tamaño de 20 bytes. El campo de datos del datagrama IP es de 65.516 Bytes (= 65.536 bytes de todo el datagrama - 20 de cabecera sin opciones). De esta manera el segmento TCP puede tener un tamaño máximo de 65.516 bytes, pero también tiene 20 bytes de cabecera, es decir, quedan 65.496 bytes para guardar los datos que nos envía la aplicación FTP.
El nivel FTP envía a la capa TCP 129 KB (132.096 bytes, entre información y datos de control) tenemos como resultado 3 segmentos TCP. Los dos primeros tienen un campo de datos de tamaño 65.496 bytes y el último tiene un campo de datos de tamaño 1104 bytes. (65.496+65.496+1.104 = 132.096).
2. Cuando la entidad par TCP del host ftp.examen.es recibe el primer segmento (previamente se ha establecido la conexión siguiendo el mecanismo threehandshake) realiza un control de errores del segmento. Si no hay errores pasa los datos a la aplicación que está escuchando en el puerto 21, es decir, al servidor FTP, que será el que reciba los datos. Como TCP es confiable proporciona control de errores y solución a éstos mediante retransmisiones. Así, el receptor asiente la información recibida al transmisor o, al contrario, le dice qué información está incorrecta. Para realizar este proceso se usa el protocolo de ventana deslizante. El tamaño de la ventana deslizante se negocia en la fase de establecimiento de conexión. Como el tamaño de ventana es 200 KB, el servidor FTP no emitirá un segmento de asentimiento hacia E hasta que reciba 200 KB de E, o bien E finalice su transmisión. Cuando A reciba el tercer segmento de información (con el campo CODE-BITS indicando fin de flujo) enviará un segmento de asentimiento indicándole a E que está esperando por el byte 132.096. Con esto A quiere decir que hasta el byte 132.095 se ha recibido todo correctamente. El cliente FTP en el host E recibirá el asentimiento, así se dará cuenta de que todo se entregó correctamente. Como no tiene nada más que enviar cerrará la conexión. f) El ordenador E ejecuta la orden >ping www.uoc.edu. Describe el funcionamiento del servidor de DNS para que E obtenga la respuesta. Considera que la cache del servidor de DNS local de la intranet está vacía y que acepta peticiones en modo recursivo provenientes de los equipos que se encuentran en la intranet mientras que el resto de servidores de DNS solo aceptan peticiones en modo iterativo. La cache del servidor DNS de la intranet está vacía. Además, lo más probable es que esté configurado con un forwarding de tal forma que cuando no encuentra una dirección realiza la petición al DNS del ISP. El DNS del ISP es quien realizará las peticiones. El proceso sería el siguiente: 1. El host E enviará una petición a su servidor de DNS (H) sobre la dirección www.uoc.edu. 2. El servidor de DNS verá que no tiene la referencia, así que realizará una petición al servidor de DNS del ISP. 3. El servidor de DNS del ISP realizará una petición al servidor DNS del dominio edu para resolver la dirección del servidor de DNS del dominio uoc.edu. 4. Con la respuesta recibida, el DNS del ISP realizará una petición al DNS de uoc.edu sobre la dirección IP que tiene la máquina www.uoc.edu. 5. El DNS del ISP devolverá al cliente (servidor DNS de la intranet) la dirección IP de la máquina que, a su vez, se la enviará a E. 22/01/2005 1. Un hacker utiliza tcpdump para escuchar la red local donde está conectado y guardar en un fichero los paquetes que circulan, para poder analizarlos posteriormente. tcpdump elimina la cabecera del nivel de enlace y registra todos los bytes que hay a continuación. Por lo tanto, cada bloque de bytes contiene la
cabecera IP más sus datos, dentro de las cuales habrá una cabecera TCP o UDP (según el protocolo de transporte usado) más los datos de aplicación. Este hacker utiliza tcpdump con la opción -X, que muestra hasta los 82 primeros bytes del paquete, en forma hexadecimal y en ASCII. tcpdump –X
Después de estar un rato registrando paquetes, el hacker se dispone a analizarlos. Supongamos que, entre otros, ve los siguientes datos: 13:59:20.372871 IP xxx.xxx.xxx.3937 > chico.rediris.es.53: 15+ A? campus.uoc.es. (31) 0x0000: 4500 003b 5fe5 0000 8011 67bd c191 2dad E..;_.....g...-. 0x0010: 82ce 0103 0f61 0035 0027 f0bb 000f 0100 .....a.5.'...... 0x0020: 0001 0000 0000 0000 0663 616d 7075 7303 .........campus. 0x0030: 756f 6302 6573 0000 0100 01 uoc.es.....
a. Escribir e interpretar el valor de los campos de las cabeceras IP y TCP/UDP.
No. Time Source Destination Protocol Info 22 2.271085 193.145.45.173 130.206.1.3 DNS Standard query A campus.uoc.es Frame 22 (73 bytes on wire, 73 bytes captured) Ethernet II, Src: 00:03:47:2a:a6:fb, Dst: 00:07:0d:52:f4:00 Internet Protocol, Src Addr: 193.145.45.173 (193.145.45.173), Dst Addr: 130.206.1.3 (130.206.1.3) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 59 Identification: 0x5fe5 (24549) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 128 Protocol: UDP (0x11) Header checksum: 0x67bd (correct) Source: 193.145.45.173 (193.145.45.173) Destination: 130.206.1.3 (130.206.1.3) User Datagram Protocol, Src Port: 3937 (3937), Dst Port: 53 (53) Source port: 3937 (3937) Destination port: 53 (53) Length: 39 Checksum: 0xf0bb (correct)
b. A partir de los datos de las cabeceras IP y TCP/UDP, explicar de forma razonada qué protocolo encapsula. Es una conexión UDP al puerto 53. Encapsula datos DNS. c. ¿Qué campos hay y cuáles son sus valores en los datos del nivel de aplicación del paquete? Se trata de una consulta DNS:
ID QR OPCODE AA TC RD RA RCODE QDCOUNT ANCOUNT NSCOUNT ARCOUNT Pregunta:
QNAME QTYPE A QCLASS 1
0x000f 0 0 1 1 0 0 0 campus.uoc.es
La captura ethereal de los datos del enunciado a nivel de aplicación: Domain Name System (query) Transaction ID: 0x000f Flags: 0x0100 (Standard query) 0... .... .... .... = Response: Message is a query .000 0... .... .... = Opcode: Standard query (0) .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... .0.. .... = Z: reserved (0) .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries campus.uoc.es: type A, class inet Name: campus.uoc.es Type: Host address Class: inet
d. Explicar brevemente el significado de cada uno de los campos existentes a nivel de aplicación de la pregunta anterior, y el significado de sus valores. ID: número de 16 bits que asigna quien hace la consulta y que se copia en la respuesta para que se sepa a qué consulta corresponde. 0x000f QR (Query/Response) es un bit que indica si el mensaje es una consulta (0) o una respuesta (1). 1: Consulta (QUERY) OPCODE: código de operación de 4 bits. Actualmente están definidos los de consulta directa (QUERY, código 0), consulta inversa (IQUERY, código 1) y petición de status (STATUS, código 2). 0: QUERY AA (Authoritative Answer): un bit que informa que el mensaje es una respuesta con autoridad. --: Sin sentido en una QUERY. TC (Truncation): un bit que avisa que el mensaje ha sido truncado porque no cabe en un datagrama. Para saber cuál es su contenido completo hay que utilizar el protocolo TCP. 0: No truncado. RD (Recursion Desired): un bit que indica que el cliente solicita respuesta en modo recursivo. 1: Recursivo
RA (Recursion Available): un bit que informa que el servidor soporta el modo recursivo. Si los bits RD y RA valen 1, el mensaje es una respuesta recursiva. --: Sin sentido en una QUERY. RCODE: código de respuesta de 4 bits. Los códigos posibles son: ningún error (0), error de formato (1), error interno del servidor (2), dominio inexistente (3), operación no implementada (4) o consulta rechazada (5). --: Sin sentido en una QUERY. QDCOUNT: cuántas entradas hay en la sección pregunta del mensaje. 1 ANCOUNT: cuántas entradas hay en la sección respuesta del mensaje. 0 NSCOUNT: cuántas entradas hay en la sección autoridad del mensaje. 0 ARCOUNT: cuántas entradas hay en la sección información adicional del mensaje. 0 Entradas de Queries: QNAME: nombre de dominio del cual el cliente quiere obtener información. campus.uoc.edu QTYPE: número de 16 bits que indica el tipo de registro de recurso que el cliente quiere obtener como respuesta. A: dirección de un ordenador. QCLASS: número de 16 bits que indica la clase de registros deseados. 1: Clase Internet e. Suponiendo que la aplicación que recibe los datos tiene la información necesaria para generar una respuesta, ¿cómo sería el mensaje de respuesta? Será una respuesta DNS: ID
TC RD RA RCODE QDCOUNT ANCOUNT NSCOUNT ARCOUNT
0x000f (lo mismo que la QUERY) 1 0 ? (depende de quién conteste) 0 1 0 0 (o 1) 1 (o más) 0 (o más) 0 (o más)
Respuesta:
Dirección IP solicitada
QR OPCODE AA
Notas: · El orden de los 3 bytes utilizados por IP en la fragmentación es: "0, DF, +" (y no "DF, +, 0", como se encuentra en la página 30 de los apuntes). · El campo 'reservado' de los paquetes TCP es de 6 bits (y no de 4 como se encuentra en la página 52 de los apuntes). 15/06/05 1- Una empresa se encuentra dividida en dos departamentos, el X y el Y. La empresa tiene contratada una conexión a Internet con un *ISP, pero quiere que sólo los usuarios del dominio *Y puedan tener acceso a Internet. Para #
llevar a término este objetivo la empresa decide dividir la red corporativa en dos subredes, una para cada departamento. La red *Y tendrá direcciones públicas, mientras que la red X dispondrá de direcciones privadas. Teniendo en cuenta que el rango asignado por el *ISP es el 200.200.200.192/26, responded a las siguientes preguntas:
a) Si se quiere que las máquinas del dominio *Y tengan direcciones *IP del rango asignado por el *ISP, cuántas máquinas podrá tener como máximo la empresa en este departamento? Cuál será el rango de direcciones disponibles? Y qué serán asignables a hots? Razonad la respuesta considerando el diagrama anterior y, en especial, la presencia de un *router en el entorno. 200.200.200.11xx xxxx -> 6 bits para un hosts –> 26 hosts -> 64 address Considerando que el router necesitará tener una conexión al departamento Y y una hacia el exterior y que las direcciones de broadcast y de red no se pueden asignar, quedarán 60 direcciones disponibles para hosts del departamento Y. El rango disponible será: 200.200.200.1100 0000 -> 200.200.200.192 200.200.200.1111 1111 -> 200.200.200.255 De estas sólo se podrán asignar un host las que estén comprendidas entre: 200.200.200.1100 0001 -> 200.200.200.193 200.200.200.1111 1110 -> 200.200.200.254 b) Considerando que el rango de direcciones privado que se quiere asignar a los equipos del departamento X es el que corresponde a 192.168.10.0/24, decid qué es la subred más pequeña de este rango que se podrá asignar a este departamento teniendo en cuenta que constará de 12 máquinas? Dad las direcciones de red y de broadcast de 3 subredes consecutivas posibles que se pudieran asignar al departamento X. Razonáis la respuesta considerando el diagrama anterior y, en especial, la presencia de un router en el entorno. 12 máquinas -> 4 bits necesarios (i.e. 16 address para IP) para unir las 12 máquinas y la interfaz del router, descontando la dirección de red y de broadcast. Subredes posibles: Red: 192.168.10.16 Broadcast: 192.168.10.31 Red: 192.168.10.32 Broadcast: 192.168.10.47 Red: 192.168.10.48 Broadcast: 192.168.10.63
c) Considerando el diagrama anterior, describid qué peticiones ARP circularán por la red (hace falta especificar el contenido), y con qué direcciones MAC, en el proceso de envío de una datagrama IP desde PC1 hacia PC3, considerando que las mesas cae ARP de todos los equipos están vacías, que la dirige de cada máquina M la podéis expresar @IP/-PCM (p.ex @IP/-PC1) y que las direcciones MAC de cada equipo son las siguientes: @IP PC1 PC2 PC3 PC4 Router dept. X Router dept. Y
Address @IP-PC1 @IP-PC2 @IP-PC3 @IP-PC4 @IP-RX @IP-RY
MAC 11:11:11:11:11:11 22:22:22:22:22:22 33:33:33:33:33:33 44:44:44:44:44:44 00:00:00:00:00:11 00:00:00:00:00:22
1. PC1 envía una solicitud ARP preguntando por @IP-RX En la trama Ethernet: Address MAC origen: 11:11:11:11:11:11 Address MAC destino: FF:FF:FF:FF:FF:FF
2. Router-X envía una respuesta ARP con la MAC 00:00:00:00:00:11. En la trama Ethernet: Address MAC origen: 00:00:00:00:00:11 Address MAC destino: 11:11:11:11:11:11 3. Router-Y envía una solicitud ARP preguntando por @IP-PC3 En la trama Ethernet: Address MAC origen: 00:00:00:00:00:22 Address MAC destino: FF:FF:FF:FF:FF:FF 4. PC3 envia una resposta ARP amb la seva MAC 33:33:33:33:33:33. En la trama Ethernet: Address MAC origen: 33:33:33:33:33:33 Address MAC destino: 00:00:00:00:00:22 d) Teniendo en cuenta que la empresa quiere evitar que las máquinas del departamento X puedan conectarse a Internet, qué creéis que pasará cuando una de estas máquinas intente establecer una conexión con un equipo externo a la empresa? Argumentad vuestra respuesta. El router ISP se dará cuenta que es una dirección de las privadas y no lo dejará salir hacia el exterior. De todos modos, si el datagrama llegara a su destino, tampoco podría recibirse ninguna respuesta porque el camino de regreso sería desconocido por los equipos intermedios. 18/06/05 1. Una red local Ethernet está conectada a Internet a través de un encaminador. La dirección IP de la interfaz externa del encaminador es 12.20.45.1. La dirección de la red local es 150.23.10.0 / 25. a) Cuántos ordenadores diferentes puede haber en la red local? 27 – 2 = 126 estaciones
b) Decir el rango de direcciones IP válidas por asignar a los ordenadores de la red y a la interfaz interna del encaminador. Cómo seria la dirección de broadcast remoto? 150.23.10.1 hasta 150.23.10.126. Broadcast remoto: 150.23.10.127 c) Hay subnetting? Por qué? Sí, porque la dirección original es de clase B (16 bits red y 16 bits estación) y nos dan una máscara de 25 bits. d) Dar una posible tabla de encaminamiento del encaminador. Hace falta que tenga especificada una ruta por defecto? Por qué? Suponemos que le damos la dirección 150.23.10.1 a la interfaz interna del encaminador. Dirección 12.20.45.1 150.23.10.1 127.0.0.0 * 150.23.10.0 255.255.255.255 0.0.0.0 0.0.0.0
Máscara 255.255.255.255 255.255.255.255 255.255.255.255
Encaminado por 127.0.0.1 127.0.0.1 127.0.0.1 12.20.45.1 150.23.10.1 150.23.10.1 *
255.255.255.128 255.255.255.255 *
*: Esta línea corresponde a la red dónde está la IP 12.20.45.1. Falta saber más cosas para poder decir cómo sería esta línea. Si suponemos una máscara estándar clase A (8 bits), entonces la columna 'Dirección' sería 12.0.0.0 y la ‘máscara' 255.0.0.0. * * Aquí estaría la dirección IP del siguiente router. Hace falta que tenga una dirección por defecto para que desde dentro de la red local podamos ir a cualquier dirección de Internet. e) Suponemos que la MTU de la red local es de 1500 bytes, y que la MTU de la red a la otra banda del encaminador es de 1200 bytes. Suponemos que el nivel UDP de uno de los ordenadores (A) de la red local ha generado un datagrama de 6200 bytes. Decir cuántos paquetes IP saldrán del ordenador A, y para cada uno, decir qué valor tendrán los campos ‘Longitud', ‘Posición del fragmento' y el flag MF. No dice hacia dónde va el datagrama, ni dice si hace MTU-discovery path, por lo tanto asumimos que fragmentará según la MTU de la red local, o sea, 1500 Hacen falta 5 fragmentos. Los 4 primeros con 1480 bytes de datos y 20 de cabecera, y el quinto con 280 bytes de datos y 20 de cabecera. Fragmento 1 2 3
Longitud 1500 1500 1500
Posición 0 1480 2960
MF 1. 1. 1.
4 5
1500 300
4440 5920
1. 0.
25/06/05 1. Una empresa dispone de la dirección de red 192.168.100.0 y ha decidido aplicar subnetting con una máscara de 27 bits para repartir entre los equipos de los distintos departamentos en los que está organizada, según el gráfico que se muestra a continuación. Responded a las siguientes cuestiones:
a) ¿Cuántas subredes se pueden tener en total si aplicamos la máscara de 27 bits? ¿Cuántos equipos se pueden tener como máximo en cada subred? Indicad las direcciones de la primera y última subredes posibles. Subredes: 23 -2 = 6 subredes Equipos: 25 -2 = 30 equipos 192.168.100.32 192.168.100.192 b) Se prevé que cada departamento tenga un número de máquinas que variará entre 10 y 100. ¿Hay suficientes direcciones si se quieren asignar a cada departamento el mismo número de subredes y direcciones? Justificad la respuesta, indicando, en caso negativo, cuál debería ser la máscara de red y la primera y última subredes, para que los tres departamentos tengan el mismo número de direcciones y subredes. No, no hay suficientes, como máximo podemos asignar dos subredes que son 60 direcciones en total. Tampoco se puede poner una máscara más pequeña (26), porque solamente dispondríamos de dos subredes y tenemos 3 departamentos. c) Si en vez de un máximo de 100 máquinas por departamento se tuvieran 50, ¿cuántas subredes se tienen que asignar a cada departamento, teniendo en
cuenta la máscara inicial? Justificad vuestras respuestas, indicando, en caso negativo, cuál debería ser la máscara de red y subredes, para que los tres departamentos tengan el mismo número de direcciones y subredes. Tenemos que asignar dos subredes para cada departamento. Son 60 direcciones en total. d) Indicad cómo sería la tabla de encaminamiento del router, si a cada departamento le asignamos una única subred. ¿Cambiaría esta tabla si cada departamento tuviera un número distinto de subredes? Una subred por departamento Dirección 192.168.100.33 192.168.100.65 192.168.100.97 255.255.255.255 192.168.100.32 127.0.0.0 192.168.100.64 192.168.100.96 0.0.0.0
Máscara 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.224 255.0.0.0 255.255.255.224 255.255.255.224 0.0.0.0
Encaminador 127.0.0.1 127.0.0.1 127.0.0.1 192.168.100.33 192.168.100.33 127.0.0.1 192.168.100.65 192.168.100.97 X.Y.Z.K
Interfaz loopback loopback loopback ether0 ether0 loopback ether1 ether2 ether3
Sí, tendríamos que añadir las entradas de las nuevas subredes. 14/01/06 1. Una empresa dispone de un encaminador con la siguiente tabla de encaminamiento: =============================================================== ================ Active Routes: Network Destination Netmask Gateway Interface Metric 190.168.64.1 255.255.255.255 127.0.0.1 127.0.0.1 1 190.168.32.1 255.255.255.255 127.0.0.1 127.0.0.1 1 99.43.13.3 255.255.255.255 127.0.0.1 127.0.0.1 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 190.168.64.0 255.255.224.0 190.168.64.1190.168.64.1 1 190.168.32.0 255.255.224.0 190.168.32.1190.168.32.1 1 255.255.255.255255.255.255.255 99.43.13.1 99.43.13.3 1 0.0.0.0 0.0.0.0 99.43.13.1 99.43.13.3 1 Default Gateway: 99.43.13.1 =============================================================== ================ A partir de esta tabla, se pide: a) Dibuja el esquema donde se vea el encaminador y las redes que conecta. Dibuja al menos un ordenador en cada red y asigna direcciones IP a cada elemento que lo requiera. Para los elementos que no conozcas la dirección IP, invéntatela.
b) Para las dos subredes, di su rango de direcciones útil, la máscara de subred, la dirección de la subred y la dirección de broadcast. Subred 190.168.32.0 Rango de direcciones 190.168.32.1 – 190.168.63.254 Máscara subred 255.255.224.0 Broadcast remoto 109.168.63.255 Subred 190.168.64.0 Rango de direcciones 190.168.64.1 – 190.168.95.254 Máscara subred 255.255.224.0 Broadcast remoto 109.168.95.255 c) Cuántas subredes más del mismo tipo que las existentes en la configuración actual podría instalar la empresa con las direcciones que tiene asignadas? De cuántas direcciones útiles dispondría en total la empresa con esta configuración de subredes? De cuántas hubiese dispuesto si no se hubiese utilizado subnetting? Justifícalo todo. La dirección 190.168.0.0 es de clase B. Entonces tendríamos que tener 16 bits para redes y 16 para hosts. Como la máscara de subred utiliza 19 bits, entonces tenemos 3 bits para subredes y 13 para máquinas. Con estos números, tendríamos 4 subredes más, ya que usamos 3 bits para subredes. En este caso el máximo de 23-2 subredes = 6. Si restamos las dos anteriores, nos da 4 (quitamos las direcciones que corresponden a la dirección de red y a la de broadcast).
Máquinas por subred: Tenemos 13 bits para máquinas, lo que da un máximo de 213-2 = 8190 máquinas (quitamos las direcciones que corresponden a la dirección de red y a la de broadcast). Si no se hiciese subnetting, tendríamos 16 bits para máquinas, que hacen un total de 216-2 = 65534 estaciones. 21/01/06 1. Un usuario hace una consulta en la página web http://www.uoc.edu/web/cat/index.html. Responde a las siguientes cuestiones: a. Suponiendo que no se había conectado antes a este sitio web, indicad qué protocolos de nivel de aplicación entran en juego desde que el usuario pide la página en su navegador hasta que recibe los datos. Indicad también sobre qué protocolo de transporte viaja cada uno de los protocolos de nivel de aplicación anteriores. Protocolos de aplicación: DNS y HTTP Protocolos de transporte: UDP y TCP respectivamente b. Imaginad que la tabla ARP de la máquina del usuario está vacía. ¿Cuál sería el intercambio de mensajes ARP del ordenador del usuario para pedir acceso a la web de la UOC? Suponed que la máquina del usuario está dentro de una red de área local y que la máquina que ofrece el servicio de DNS está en esa misma red. Podéis dar las direcciones ARP que queráis a cada equipo. 1.- Petición ARP de la máquina preguntando por la dirección MAC del DNS. 2.- Respuesta ARP del DNS (11:22:33:44:55) a la máquina de usuario. 3.- Petición ARP de la máquina preguntando por la dirección MAC del router que ofrece el acceso a Internet. 4.- Respuesta ARP del router (22:33:44:55:66) a la máquina. c. Analizad el contenido del siguiente paquete IP. ¿Qué protocolo de nivel de transporte se está utilizando?¿Y de nivel de aplicación? Describid los campos de la cabecera IP. 45 00 00 3f 2e c0 00 00 80 11 23 64 c1 91 2d 5c c1 91 38 0b 05 35 00 35 00 2b d8 1f 47 06 01 00 00 01 00 00 00 00 00 00 03 77 77 77 0a 74 65 6c 65 66 6f 6e 69 63 61 02 65 73 00 00 01 00 01 Para cada campo escribimos el hexadecimal / el decimal. Versión (4 bits): 0x4 / 4 Longitud cabecera (4 bits): 0x5 / 5 --> 20 bytes ToS (8 bits): 0x00 / 0 Longitud total paquete (16 bits): 0x003f / 63 bytes Identificación (16 bits): 0x2ec0 / 11968 Indicadores (3 bits): 0x0 / 0 Posición del fragmento (13 bits): 0x0000 / 0
TTL (8 bits): 0x80 / 128 Protocolo (8 bits): 0x11 / 17 (UDP) Checksum (16 bits): 0x2364 / 9060 IP origen (32 bits): 0xc1912d5c / 193.145.45.92 IP destino (32 bits): 0xc191380b / 193.145.56.11 ... Puerto origen (16 bits): 0x0535 / 1333 Puerto destino (16 bits): 0x0035 / 53 (DNS) El protocolo de transporte utilizado es UDP y el de aplicación DNS. d. Analizad el contenido del siguiente paquete IP. ¿Qué protocolo de nivel de transporte se está utilizando? Describid los valores de los campos de la cabecera del protocolo de nivel de transporte. ¿Qué operación creéis que se está realizando en el nivel de transporte? 45 00 00 30 2e c1 40 00 80 06 e3 20 c1 91 2d 5c c2 e0 37 18 05 36 00 50 ad 3d df 59 00 00 00 00 70 02 fc 00 0c 1b 00 00 02 04 05 b4 01 01 04 02 Protocolo de transporte: 0x06 / 6 (TCP) ... Puerto origen (16 bits): 0x0536 / 1333 Puerto destino (16 bits): 0x0050 / 80 (HTTP) Núm. Secuencia (32 bits): 0xad3ddf59 / 2906513241 Núm. ACK (32 bits): 0x0 / 0 Longitud de la cabecera (4 bits): 0x7 / 7 Reservado (4 bits): 0x0 / 0 Control (8 bits): 0x02 / 2 (bit SYN activado) Ventana (16 bits): 0xfc00 / 64512 Checksum (16 bits): 0x0c1b / 3099 Urgent Pointer (16 bits): 0x0000 / 0 A nivel TCP se está realizando un establecimiento de conexión entre un cliente y un servidor. 17/06/06 1. Una universidad virtual se encuentra dividida en diferentes sedes por tal de mejorar el acceso presencial a sus alumnos independientemente de su localización. Por tal de posibilitar el trabajo de todos sus trabajadores, la universidad quiere contratar un rango de direcciones (132.175.0.0/16) que divida entre sus sedes de la manera que a continuación se detalla: • Inicialmente la universidad consta de 4 sedes diferentes (A,B,C,D). • Cada sede tiene una subred de la misma medida. • La red de cada sede debe ser tan grande como sea posible. a) ¿Qué subred corresponderá a cada una de las sedes? ¿Qué rango de direcciones para asignar a máquinas tendrá cada una de las subredes? ¿Cuántas máquinas pueden haber como máximo a cada sede?
La dirección 132.175.0.0/16 es de clase B. En consecuencia disponemos de 16 bits para hacer la distribución. Según el enunciado, lo que queremos es maximizar el número de direcciones disponibles para PCs. Por ello, buscaremos una distribución de bits para realizar el subnetting teniendo en cuenta este criterio. Para alojar las 4 sedes, necesitamos 3 bits. A modo de ejemplo, cogeremos las cuatro primeras direcciones de red útiles para asignar a las sedes. Las direcciones serán las siguientes: 132.175.00100000.0 132.175.01000000.0 132.175.01100000.0 132.175.10000000.0
132.175.32.0/19 sede A 132.175.64.0/19 sede B 132.175.96.0/19 sede C 132.175.128.0/19 sede D
El rango de direcciones útiles para cada subred y el número máximo de máquinas a alojar será: Sede A Sede B Sede C Sede D
132.175.32.1/19 132.175.64.1/19 132.175.96.1/19 132.175.128.1/19
a a a a
132.175.63.254/19 132.175.95.254/19 132.175.127.254/19 132.175.255.254/19
El número máximo de máquinas que se podrán alojar en cada una de las sedes es 213 - 2 = 8.190 máquinas Después de un tiempo de funcionamiento de la universidad, se ha podido comprobar que la suyo B es con diferencia la que mayor infraestructura contiene y ha acabado agotando las direcciones de qué disponía inicialmente. Por esta razón se ha decidido abandonar la anterior subred y comprar un nuevo rango de direcciones (137.47.0.0/16) dedicado para esta sede que permita
aumentar el número de máquinas disponibles y estructurarlas en 3 departamentos independientes.
b) Considerando el diagrama anterior, propone una división de la red de la sede B que satisfaga las necesidades de todos sus departamentos, y que permita en el futuro que nuevos departamentos sean creados e integrados en la sede B (es decir, que cada subred se ajuste tanto como sea posible a las necesidades de cada departamento). La dirección 132.47.0.0/16 es de clase B. En consecuencia disponemos de 16 bits para hacer la distribución. Viendo el dibujo, el departamento X como máximo tendrá 200 máquinas, lo que se traduce en 8 bits necesarios para la porción de hueste. Para el departamento Y, son 600 máquinas, que requieren 10 bits. Finalmente, para el departamento Z, necesitamos 9 bits para la porción de hueste. Para homogeneizar la distribución, dedicaremos 10 bits para la porción de hueste, y 6, para la porción de subred. Las direcciones serán las siguientes: 132.47.00000000.0
no es una dirección IP útil
132.47.00000100.0
132.47.4.0 /22
departamento X
132.47.00001000.0
132.47.8.0 /22
departamento Y
132.47.00001100.0
132.47.12.0 /22
departamento Z
132.47.00010000.0
132.47.16.0 /22
libre asignación
132.47.00010100.0
132.47.20.0 /22
libre asignación
Etc #
c) Qué sería el contenido de la tabla de encaminamiento del router propio de la sede B? Nota: podéis obviar las entradas de multicast, broadcast y dirección loopback, pero debéis recordar el acceso a Internet. Dirección 132.47.4.0 132.47.8.0 132.47.12.0 0.0.0.0 0.
Máscara 255.255.252.0 255.255.252.0 255.255.252.0 0.0.0 1
Encaminador 132.47.4.1 132.47.8.1 132.47.12.1 0.0.0.2
Interfaz eth0 eth1 eth2 eth3
Dónde las IPs 132.47.4.1, 132.47.8.1 y 132.47.12.1 corresponden a las interfaces eth0, eth1 y eth2 del router R2, que lo conectan con los diferentes departamentos. La IP 10.0.0.2 corresponde a la interfaz del router R1, que lo conecta con R2. Las interfaces corresponden a R1. d) ¿Creéis que el router propio de la sede B debe dejar pasar tramas ARP hacia las otras sedes de la universidad? ¿Y entre los departamentos de la misma sede? Justificad las respuestas. No, puesto que son redes diferentes y por llegar deben atravesar el router, y por lo tanto, no necesitan esta información. 27/06/06 1. Este es el resultado de la ejecución del programa 'ethereal' durante un rato en una red local. Cada grupo de bytes numerado corresponde a un paquete IP. El texto de la esquina derecha es la versión ASCII de los bytes. (1)
45 00 00 30 2a c4 40 00 80 06 c9 81 51 2b 08 28 9c 9a 10 95 04 5a 00 15 1f e2 9b 84 00 00 00 00 70 02 20 00 9c c7 00 00 02 04 05 b4 01 01 04 02
E..0*[email protected]+.( .....Z.......... p...............
(2)
45 00 00 30 00 00 40 00 35 06 3f 46 9c 9a 10 95 51 2b 08 28 00 15 04 5a 6b 05 0c 3f 1f e2 9b 85 70 12 05 b4 3f be 00 00 02 04 05 b4 01 01 04 02
[email protected].?F.... Q+.(...Zk..?.... p...?...........
(3)
45 00 00 28 2a c5 40 00 80 06 c9 88 51 2b 08 28 9c 9a 10 95 04 5a 00 15 1f e2 9b 85 6b 05 0c 40 50 10 22 38 4f fe 00 00
E..(*[email protected]+.( .....Z......k..@ P."8O...
45 00 00 3c 0a 68 40 00 35 06 34 d2 9c 9a 10 95 51 2b 08 28 00 15 04 5a 6b 05 0c 40 1f e2 9b 85 50 18 16 d0 04 3b 00 00 32 32 30 20 28 76 73 46 54 50 64 20 32 2e 30 2e 31 29 0d 0a
E..<[email protected]..... Q+.(...Zk..@.... P....;..220 (vsF TPd 2.0.1)..
45 00 00 28 2a c6 40 00 80 06 c9 87 51 2b 08 28 9c 9a 10 95 04 5a 00 15 1f e2 9b 85 6b 05 0c 54 50 10 22 24 4f fe 00 00
E..(*[email protected]+.( .....Z......k..T P."$O...
45 00 00 38 2a c9 40 00 80 06 c9 74 51 2b 08 28 9c 9a 10 95 04 5a 00 15 1f e2 9b 85 6b 05 0c 54 50 18 22 24 c8 09 00 00 55 53 45 52 20 61 6e 6f 6e 79 6d 6f 75 73 0d 0a
E..8*[email protected]+.( .....Z......k..T P."$....USER ano nymous..
45 00 00 28 0a 6a 40 00 35 06 34 e4 9c 9a 10 95 51 2b 08 28 00 15 04 5a 6b 05 0c 54 1f e2 9b 95 50 10 16 d0 5b 42 00 00
E..([email protected]..... Q+.(...Zk..T.... P...[B..
(4)
(5)
(6)
(7)
Se pide: a) Al primer paquete, decid qué vale cada campo de la cabecera IP. Versión (4 bits): 4 H = 4 Longitud de la cabecera (4 bits) 5 H = 5 * 4 B = 20 Bytes Tipo de servicio (8 bits): 00 Longitud total del paquete (2 Bytes): 00 30 H = 48 Bytes Identificador Datagrama: (2 Bytes): 2A C4 H Flags (3 bits): 4H = 010[0] -> 010 Reservado (1 bit): 0 DF ( 1 bit ): 1 MF ( 1 bit ): 0 Fragments (13 bits) 40 H = [010]0 0 00 -> 0 Time to live (TTL): (1 Byte): 80 H = 128 Protocol (1 Byte): 06 H = 6 -> TCP Checksum: (2 Bytes): C9 81 H Dirección de origen: (4 Bytes) 51 2B 08 28 Dirección de destino: (4 Bytes); 9C 9A 10 95 Opciones: -b) ¿Qué protocolo de transporte encapsula? Decid qué vale cada campo de la cabecera del protocolo de transporte. Encapsula TCP (Protocol = 6) Puerto de origen (16 bits): 04 5A H = 1114 Puerto de destino (16 bits): 00 15 H = 21 -> FTP Número de secuencia (32 bits): 1F E2 9B 84 H Número ACK (32 bits): 00 00 00 00 Longitud de la cabecera (4 bits): 7 H = 7 * 4 Bytes = 28 Bytes Reservado (6 bits) = 0 0 0000 00[00] -> 0 Control (6 bits) = 02 H = [00]00 0010 B -> 00 0010 URG: 0 ACK: 0 PSH: 0 RST: 0 SYN: 1 FIN: 0 Ventana (16 bits): 20 00 H = 8192 Bytes Checksum (16 bits): 9C C7 H Urgent Pointer (16 bits): 00 00 Opciones TCP (múltiples de 4 bytes=28-20 = 8 Bytes): 02 04 05 B4 01 01 04 02 c) ¿Qué protocolo de aplicación hay en este intercambio de paquetes? Decid los pedidos de aplicación que hay en estos paquetes y explicad sus funcionalidades. Puerto de destino: 21 -> FTP Comandos de aplicación: (4)
45 00 00 3c 0a 68 40 00 35 06 34 d2 9c 9a 10 95 51 2b 08 28 00 15 04 5a 6b 05 0c 40 1f e2 9b 85
50 18 16 d0 04 3b 00 00 32 32 30 20 28 76 73 46 54 50 64 20 32 2e 30 2e 31 29 0d 0a (6)
45 00 00 38 2a c9 40 00 80 06 c9 74 51 2b 08 28 9c 9a 10 95 04 5a 00 15 1f e2 9b 85 6b 05 0c 54 50 18 22 24 c8 09 00 00 55 53 45 52 20 61 6e 6f 6e 79 6d 6f 75 73 0d 0a
(4)
32 32 30 20 28 76 73 46 54 50 64 20 32 2e 30 2e 31 29 0d 0a 220 (vsFTPd 2.0.1)
(6)
55 53 45 52 20 61 6e 6f 6e 79 6d 6f 75 73 0d 0a USER anonymous
01/07/06 1.- Una empresa desea poner en funcionamiento una red TCP/IP sobre el estándar IEEE 802.3. Para ello, el departamento de informática compra un router y la dirección 155.100.0.0. La empresa tiene además un departamento comercial y otro de producción pero quiere implantar una subred por departamento: • Dibuja un esquema de la red de la empresa con los tres departamentos, informática, producción y comercial, indicando para cada uno de ellos el rango de direcciones IP.¿Cómo podría una máquina del departamento comercial enviar un paquete IP a todas las máquinas del departamento de producción?
Utilizamos tres bits ya que necesitamos 3 subredes. Con dos bits no llegaría porque sólo podemos disponer de dos subredes, ya que la combinación de todos los bits a 1 en los bits de estación está reservada para el broadcasting dentro de la red, y la combinación de todos los bits a 0 se usa para identificar la propia red.
Máscara subred: 255.255.224.0 Comercial: 155.100.32.0 El rango de direcciones válido iría desde 155.100.32.0 hasta la 155.100.62.255 Producción: 155.100.64.0 El rango de direcciones válido iría desde 155.100.64.1 hasta la 155.100.94.255 Informática: 155.100.96.0 El rango válido de direcciones válido iría desde 155.100.96.1 hasta la 155.100.126.255 Para que una máquina del departamento comercial pueda enviar un paquete IP a todas las máquinas del departamento de producción tendría que utilizar la dirección de broadcast remoto de la red de producción, es decir, 155.100.95.255. Esto se consigue poniendo a 1 todos los bits correspondientes a estación en la dirección. Indica cuál sería la tabla de encaminamiento del router y describe paso a paso cómo funcionaría este dispositivo a nivel IP para encaminar un paquete desde un PC de la red comercial a un PC de la red de producción. Dirección 155.100.32.0 155.100.64.0 155.100.96.0
Máscara 255.255.224.0 255.255.224.0 255.255.224.0
Gateway 155.100.32.1 155.100.64.1 155.100.96.1
Interfaz Eth0 Eth1 Eth2
El funcionamiento del router es el siguiente: Cuando le llega un paquete coge la IP de destino y hace un AND con la máscara de la primera entrada de su tabla de encaminamiento (aquélla que es más restrictiva). Compara el resultado con la columna dirección de la tabla de encaminamiento. Si coincide lo dirige hacia el gateway correspondiente, si no, continúa con la máscara de la siguiente entrada. Por ejemplo, si al router le llega un paquete con dirección de destino 155.100.64.10 haría lo siguiente: Primer paso: 155.100.64.10 AND 255.255.224.0 = 155.100.64.0 Segundo paso: ¿155.100.32.0 = 155.100.64.0? Es decir, compara la columna dirección de la primera entrada de su tabla con 155.100.64.0. Pero como 155.100.32.0 155.100.64.0 pasa a la siguiente entrada. Tercer paso: 155.100.64.10 AND 255.255.224.0 = 155.100.64.0 Cuarto paso: ¿155.100.64.0 = 155.100.64.0? Sí! (encaminar por el gateway correspondiente). • ¿Qué dirección IP y qué dirección MAC llevaría un paquete cuyo origen es un PC de la red comercial y destino un PC de la red de producción? ¿Por qué? En el caso de que el router deje de funcionar y un PC cualquiera quiera enviar un paquete, ¿podría comunicarse con algún equipo?
La dirección IP es la del PC de producción y la MAC es la del router, ya que las direcciones MAC sólo son accesibles dentro de la subred. Si el router deja de funcionar un PC podría comunicarse con los equipos que están en la misma subred. 13/01/07 1. Una empresa compra un encaminador y la IP 120.0.0.0/8 para poder conectar los ordenadores de los tres departamentos que tiene: · Dibuja un esquema de la red de la empresa indicando cuál es la dirección de red de cada departamento, así como su dirección de broadcast local y remoto. Haz las suposiciones que creas convenientes.
Nos piden 3 departamentos, utilizamos tres bits para hacer subnetting. La siguiente tabla muestra los valores de red, máscara de red y los broadcast local y remoto. Red 120.32.0.0 120.64.0.0 120.96.0.0
Máscara 255.224.0.0 255.224.0.0 255.224.0.0
Broadcast Local 255.255.255.255 255.255.255.255 255.255.255.255
Broadcast Remoto 120.63.255.255 120.95.255.255 120.127.255.255
· Indica cuántos PC pueden existir como máximo en cada departamento, así como cuántos departamentos de las mismas características podríamos tener en esta empresa. Equipos por departamento (subred): 221-2 = 2.097.150 equipos por departamento (subred) (incluyendo el router) Departamentos (subredes): 23 - 2 = 8 -2 = 6 departamentos (subredes) (incluyendo los 3 existentes)
· Escribe la tabla de encaminamiento del router que ha comprado esta empresa y explica brevemente cómo se toman las decisiones de encaminamiento cuando llega un paquete al router. Red 120.32.0.0 120.64.0.0 120.96.0.0 0.0.0.0
Máscara 255.224.0.0 255.224.0.0 255.224.0.0 0.0.0.0
Salida Eth 0 Eth 1 Eth 2 Eth 3
17/01/07 1. Queremos configurar la red de una empresa formada por tres departamentos situados en el mismo edificio, siguiendo el esquema de la figura:
Se establecen los siguientes criterios generales: El número máximo de hosts que puede tener el departamento de recursos humanos, logística y comercial es de 3, 30 y 10 respectivamente. En un futuro se prevé abrir un nuevo departamento de Contabilidad, situado en un edificio diferente, donde, como máximo, habrá 5 hosts. Para hacer la distribución de direcciones IP, sólo se dispone de la dirección IP 200.200.120.0/24 Se establece que la red del departamento de Recursos humanos tendrá asignada el primer rango de direcciones IP útiles, el de Logística, el segundo y el Comercial, el tercero. La interfaz del router que lo conecta a cada red, tendrá asignada la última IP útil disponible. Rellenad las siguientes tablas, anotando, para cada una de las redes que se deben configurar, la información que se os indica:
Recursos humanos Logística Comercial
Recursos humanos Logística Comercial
Dirección IP 200.200.120.32 200.200.120.64 200.200.120.96
Características de la Red Máscara Clase 255.255.255.224 C 255.255.255.224 C 255.255.255.224 C
Broadcast remoto 200.200.120.63 200.200.120.95 200.200.120.127
Broadcast local 255.255.255.255 255.255.255.255 255.255.255.255
. Dimensionamiento de los PCs 64Número máximo de PCs Rango de direcciones IP útiles asignables a PCs 5 2 -2= 30 200.200.120.33 - 200.200.120.62 5 2 -2= 30 200.200.120.65 - 200.200.120.94 5 2 -2= 30 200.200.120.97 - 200.200.120.126
b) Escribid la tabla de encaminamiento correspondiente al router R1. Podéis obviar las entradas de loopback y broadcast. Si necesitáis cualquier otro dato, podéis suponerlo, indicando claramente cuál es. Dirección IP
200.200.120.32 200.200.120.64 200.200.120.96
Tabla de encaminamiento R1 Máscara Encaminador
255.255.255.224 255.255.255.224 255.255.255.224
200.200.120.62 200.200.120.94 200.200.120.126
Interface
eth0 eth1 eth2
c) Suponed que el departamento de Contabilidad ya está creado. ¿Como creéis que quedaría la red físicamente? ¿Haría falta añadir algún elemento más? ¿Se produciría algún cambio de configuración? Como hemos reservado tres bits para departamentos, en principio, no se tendría que hacer nada excepto conectar los hosts de esta red a un hub o switch que al mismo tiempo se conectaría a otra boca del router. Se tendría que reconfigurar el router para que reflejara esta nueva situación. 20/01/07 1. Los ayuntamientos de 3 municipios próximos quieren interconectar sus redes para poder agilizar los trámites que requieren cooperaciones entre los tres. Con este objetivo en mente, han decidido comprar un encaminador y usarlo para esta finalidad, tal y como se muestra en el siguiente esquema:
Basándose en las características de cada municipio, se decide tomar las siguientes decisiones para asignar un rango de direcciones IP a cada municipio: El rango de direcciones IP de que disponen los municipios es el 196.220.156.0. Se espera que, dadas las dimensiones de cada ayuntamiento, la cantidad máxima de hosts que cada uno de los municipios necesite sea de 29, 14 y 6, respectivamente. Es previsible que en un futuro no muy lejano un cuarto municipio (llamado D), también próximo a los otros 3, quiera añadirse a esta red. Se trata de un municipio pequeño y, por lo tanto, se espera que con sólo 5 hosts pueda ver satisfechas sus necesidades. En la asignación de direcciones de red que se realice, se quiere tener en cuenta esta futura ampliación para hacer posible con las mínimas modificaciones.
Los rangos de direcciones se asignarán a los municipios según el orden creciente de direcciones IP necesitadas (el primer rango, para el municipio que menos direcciones necesite, y el último rango que se asigne al que más necesite). La interfaz del router que lo conecta a cada red, tendrá asignada la primera IP útil disponible. a) Completad las siguientes tablas, anotando, para cada una de las redes que se tienen que configurar, la información que se indica:
Municipio A Municipio B Municipio C
Dirección IP 196.220.156.128 196.220.156.96 196.220.156.64
Municipio A Municipio B Municipio C
Características de la Red Máscara Clase 255.255.255.224 C 255.255.255.224 C 255.255.255.224 C
Broadcast remoto 196.220.156.159 196.220.156.127 196.220.156.95
Broadcast local 255.255.255.255 255.255.255.255 255.255.255.255
. Dimensionamiento de los PCs 64Número máximo de PCs Rango de direcciones IP útiles asignables a PCs 196.220.156.130 a 196.220.156.158 29 196.220.156.98 a 196.220.156.126 29 196.220.156.66 a 196.220.156.94 29
b) Escribid la tabla de encaminamiento correspondiente al router R1. Podéis obviar las entradas loopback y broadcast. Si necesitáis cualquier otro dato, podéis suponerlo, indicando claramente la suposición. Dirección IP
196.220.156.128 196.220.156.96 196.220.156.64
Tabla de encaminamiento R1 Máscara Encaminador
255.255.255.224 255.255.255.224 255.255.255.224
196.220.156.129 196.220.156.97 196.220.156.65
Interface
eth0 eth1 eth2
c) Suponed que el municipio D ya se encuentra incorporado a la red de municipios que habéis diseñado en el apartado a. ¿Cómo creéis que quedaría la red físicamente? ¿Sería necesario añadir algún elemento más? ¿Se produciría algún cambio de configuración? Suponiendo que el router tuviera otra interface disponible, sería necesario dedicarla a esta nueva subred que tendría las características indicadas a continuación y configurarla juntamente con la tabla de encaminamiento. Dirección del municipio D 192.220.156.32 Máscara 255.255.255.255 Dirección IP nueva interface router 192.220.156.33
Enunciados Preguntas nº 2 10/01/04 2. La capa UDP de un ordenador conectado a Internet ha generado un datagrama de 7070 bytes en total. Este datagrama se entrega en la capa IP para lo cual
genera un paquete, que necesita ser fragmentado dado que pasará por una red Ethernet que admite una medida de trama máxima (MTU) de 1500 bytes. a) Decid los valores del campo "Longitud del paquete", del campo "Posición de este fragmento" y del bit "Hay más" (MF), para cada uno de los paquetes IP que se generen. Comentad las suposiciones que tenéis que hacer. Paquete
1 2 3 4 5
Longitud
1500 1500 1500 1500 1170
Posición
0 1480 2960 4440 5920
MF
1 1 1 1 0
He supuesto que la cabecera IP es de 20 bytes. b) ¿Quién puede reagrupar el datagrama original? La estación de destino. Aunque en teoría, si un encaminador recibiera todos los fragmentos y la red siguiente tuviera una MTU suficiente lo podría hacer, en la práctica lo hace la estación de destino. 17/01/04 2. Dado el esquema presentado en la siguiente figura:
a) Asigna direcciones IP a las interfaces de red que lo necesiten. PC1 y PC2 pertenecen a la LAN 192.168.5.0/24. La dirección de PC2 es 192.168.5.2. La interfaz de red de R1 a la LAN 192.168.5.0/24 es 192.168.5.3. PC3 pertenece a la LAN 192.168.7.0/24. La dirección de la interfaz de red de R2 a esta LAN es 192.168.7.2. PC4 pertenece a la LAN 192.168.9.0/24. Su dirección IP es 192.168.9.3.
b) Establece las tablas de encaminamiento de los elementos del esquema que necesites para que: - PC1 y PC3 se puedan comunicar entre sí. - PC2 se pueda comunicar con R2. - PC2 no se pueda comunicar con PC3. - PC1 no se pueda comunicar con PC4. - PC3 y PC4 se puedan comunicar con el resto de dispositivos. Las tablas de enrutamiento se muestran a continuación: Dirección 192.168.5.0 192.168.7.0
PC1 Máscara 255.255.255.0 255.255.255.0
Direccionador 192.168.5.1 192.168.5.3
Dirección 192.168.5.0 192.168.9.0
PC2 Máscara 255.255.255.0 255.255.255.0
Direccionador 192.168.5.2 192.168.5.3
Dirección 192.168.5.0 192.168.7.0 192.168.9.0
R1 Máscara 255.255.255.0 255.255.255.0 255.255.255.0
Direccionador 192.168.5.3 192.168.9.2 192.168.9.1
Dirección 192.168.5.0 192.168.7.0 192.168.9.0
R2 Máscara 255.255.255.0 255.255.255.0 255.255.255.0
Direccionador 192.168.9.1 192.168.7.2 192.168.9.2
Dirección 0.0.0.0 192.168.9.0
PC3 Máscara 0.0.0.0 255.255.255.0
Direccionador 192.168.7.2 192.168.7.1
Dirección 192.168.5.0 192.168.7.0 192.168.9.0
PC4 Máscara 255.255.255.0 255.255.255.0 255.255.255.0
Direccionador 192.168.9.1 192.168.9.2 192.168.9.3
24/01/04 2. Queremos enviar una base de datos que atraviese 8 encaminadores del tipo store and forward (i.e. una vez han recibido completamente un paquete lo reenvían hacia uno otros encaminador u ordenador) usando el protocolo TCP/IP, cada uno de los cuales está conectado a una línea telefónica de 256Kbps. Considero que los encaminadores están separados entre ellos a una distancia de 600 Km, y que la velocidad de propagación de la señal eléctrica es de 200000 Km/s. Se pide:
#
a) Calculad el volumen de información de la base de datos si la longitud del segmento de datos es de 4096 bytes (MSS) y el tiempo total de transmisión es de 265,5005 segundos. b) Utilizando el volumen de la base de datos calculado en el anterior apartado, calculad el tiempo total de transmisión si la longitud del segmento de datos es de 1024 bytes. Nota: Para resolver el problema hay que tener en cuenta el overhead introducido por el protocolo TCP/IP. También hay que utilizar la fórmula del tiempo de propagación: tp= distancia / Vpropagación
14/06/04 2- Este es el resultado de la ejecución del programa ‘ethereal’ durante un rato en una red local. Cada grupo de bytes numerado corresponde a un paquete . (1)
4510 002c 001c 0000 4006 8e2b c191 2d49 d549 2851 0400 006e c7a2 e098 0000 0000 6002 0200 fd07 0000 0204 05b4
(2)
4500 002c 3a35 4000 f906 5b21 d549 2851 c191 2d49 006e 0400 29da 77af c7a2 e099 6012 2238 3b35 0000 0204 05b4 0204
(3)
4510 0028 001d 4000 4006 4e2e c191 2d49 d549 2851 0400
006e c7a2 e099 29da 77b0 5010 7d78 f7b1 0000 (4) ...
4500 0056 3a36 4000 fb06 58f6 d549 2851 c191 2d49 006e 0400 29da 77b0 c7a2 e099 5018 2238 6ed7 0000 2b4f 4b20 5150 4f50 2028 7665 7273
(11)
4500 004e 3a39 4000 fb06 58fb d549 2851 c191 2d49 006e 0400 29da 77fd c7a2 e0a5 5018 2238 6ea1 0000 2b4f 4b20 506f 7020 7365 7276 6572
(12)
4500 0028 3a3a 4000 f906 5b20 d549 2851 c191 2d49 006e 0400 29da 7823 c7a2 e0a5 5011 2238 5272 0000 5272 0000 2078
(13)
4510 0028 0022 4000 4006 4e29 c191 2d49 d549 2851 0400 006e c7a2 e0a5 29da 7824 5010 7d78 f731 0000
(14)
4510 0028 0023 0000 4006 8e28 c191 2d49 d549 2851 0400 006e c7a2 e0a5 29da 7824 5011 7d78 f730 0000
(15)
4500 0028 3a3b 4000 f906 5b1f d549 2851 c191 2d49 006e 0400 29da 7824 c7a2 e0a6 5010 2238 5271 0000 5271 0000 d019
Se pide: a) A los 2 primeros paquetes, decid qué vale cada campo de la cabecera y de la cabecera del protocolo de transporte que trae el paquete. ¿Qué aplicación está usando estos paquetes? Paquete (1): IP 4 versión de IP 5 longitud de la cabecera 10 tipo de servicio 002c longitud total 001c identificador 0000 flags y posición del fragmento 40 TTL 06 protocolo: TCP 8e2b checksum c191 2d49 IP origen d549 2851 IP destino TCP 0400 puerto de origen 006e puerto destino(110: correo POP) c742 e098 número de secuencia 0000 0000 número ACK 6 longitud de la cabecera 002 bits de control 0200 ventana fd07 checksum 0000 urgent pointer 0204 05b4 opciones TCP
Paquete (2): IP 4 versión de IP 5 longitud de la cabecera 00 tipo de servicio 002c longitud total 3a35 identificador 4000 flags y posición del fragmento f9 TTL 06 protocolo: TCP 5b21 checksum d549 2851 IP origen c191 2d49 IP destino 006e puerto de origen 0400 puerto destino 29da 77af número de secuencia c7a2 e099 número ACK 6 longitud de la cabecera 012 bits de control 2238 ventana 3b35 checksum 0000 urgent pointer 0204 05b4 opciones TCP b) Los 4 últimos (del 12 al 15) son la fase de cierre de un diálogo "$ . Dibuja un diagrama de tiempo dónde se vea el intercambio de segmentos y en qué estado están los dos extremos en cada momento. ¿De qué tipo de cierre se trata? Es un cierre activo por parte de d549 2851 (213.73.40.81).
19/06/04 2. Una empresa dispone de una red local (147.83.2.0/24) y dos áreas de negocio diferenciadas: la de gestión y la de desarrollo. Se pretende hacer que cada una de las áreas de negocio disponga de un conjunto de direcciones a asignar a sus máquinas correspondientes. Cada una de las áreas de negocio dispondrá de un servidor web pública que se quiere hacer accesible a través de Internet. También se quiere que las dos redes tengan conectividad hacia el exterior a través de un router de una operadora de telecomunicaciones, que dispone de una interfaz que también se conectará a esta red. a) Cómo dividirías la red asumiendo que el área de gestión espera tener un máximo de 23 máquinas y la de desarrollo de 62? ¿Cuántas máquinas podría haber como máximo en cada red? Disponemos de 8 bits para huestes en la red original. Para poder disponer de una subred con 62 máquinas, como mínimo necesitamos 6 bits (64 IPs) para cada subred. Por lo tanto, y teniendo en cuenta la medida de la red del área de desarrollo, la única solución posible es: Subred 1: 147.83.2.64/26 (147.83.2.0100 0000 -> 147.83.2.0111 1111) Direcciones válidas: 147.83.2.65 -> 147.83.2.126 Subred 2: 147.83.2.128/26 (147.83.2.1000 0000 -> 147.83.2.1011 1111) Direcciones válidas: 147.83.2.129 -> 147.83.2.191 En cada red puede haber 62 máquinas. b) Haz un esquema general de como conectarías las máquinas y como asignarías las redes y las direcciones (remarcando claramente los routers y servidores web), asumiendo que puedes usar todos los routers y concentradores (hubs) que creas necesarios.
Esquema de direcciones: Área gestión (23 máquinas): 147.83.2.65/26 a 147.83.2.126/25 Área desarrollo (62 máquinas): 147.83.0.129/26 a 147.83.0.191/26 Router ISP: Interfaz a Internet: Dirección pública Interfaz a Router red gestión: 147.83.2.65/26 Interfaz a Router red desarrollo: 147.83.2.129/26 En este punto se nos presenta un problema y es que si una de las 62 direcciones disponibles para el área de gestión es asignada a una interfaz del router, nos faltará una dirección para una de las máquinas de gestión. Por lo tanto, esta red no sería configurable con los recursos disponibles y las necesidades establecidas. c) Si desde el servidor web de la red de desarrollo se quiere hacer una petición al servidor web de la red de gestión (enviar un paquete , en definitiva), qué tramas circularían por la red y con qué direcciones ( $ y origen y destino? 1. El servidor web consulta su tabla de encaminamiento y ve que la máquina destino no se encuentra en la misma subred que él mismo (el primero está a la red 147.83.0.64/26 y el segundo a la 147.83.0.128/26). Por lo tanto, decide enviar el paquete a través del router de la red (147.83.2.129), y necesita saber la MAC ARP: @ MAC origen: Servidor Web Desarrollo @ MAC destino broadcast (ff:ff:ff:ff:ff:ff) @ IP solicitada: Router (147.83.2.129) 2. El router responde a la petición: ARP: @ MAC origen: Router (interface desarrollo) @ MAC destino: Servidor Web Desarrollo @ IP respuesta: Router (147.83.2.129) 3. El router recibirá los datos del paquete a enviar, y las debe hacer llegar a una máquina de la red de gestión (147.83.2.64/26). Para encontrar la dirección MAC del servidor web de gestión necesita hacer la siguiente petición ARP: ARP: @ MAC origen: Router (interface gestión) @ MAC destino broadcast (ff:ff:ff:ff:ff:ff) @ IP solicitada: Servidor Web Gestión 4. El servidor web de gestión responde:
ARP: @ MAC origen: Servidor Web Gestión @ MAC destino: Router (interfície gestión) @ IP respuesta: Servidor Web Gestión d) Si ahora volamos añadir una tercera área de negocio con 132 máquinas, ¿qué configuración de subredes propondríais? ¿Es posible que tengamos algún problema? ¿Por qué? ¿Qué necesitaría hacer la empresa para poder asumir este crecimiento en número de máquinas? (Razonad las respuestas). El principal problema con qué nos encontraremos es que no tenemos ninguna subred disponible para poder las 132 máquinas, por lo tanto nos habremos de plantear la posibilidad de hacer una subdivisión de red diferente o pensar en adquirir más direcciones públicas. El total de máquinas que podemos asignar es de 132 + 62 + 23 = 217. Por lo tanto, de direcciones disponibles (256) tenemos suficientes si podemos hacer un buen montaje. Hace falta ver si podemos hacer una división en redes (dividiendo cada área de negocio en subredes y estela a los encaminadores la tarea de hacer la comunicación entre ellas) que permita incluir todas las máquinas de la empresa. Debemos tener en cuenta que cada subred que creamos deberá destinar una dirección para una entrada del encaminador, que dos IPs irán destinadas a la dirección de broadcast y la dirección de red y que las subredes que contengan la dirección de red y de broadcast de la red original (147.83.2.0/24) no se pueden utilizar. Por lo tanto, las diferentes opciones que tenemos son: 147.83.2.0/30: 62 redes válidas 2 IPs válidas por red 1 IP utilizable por red 62 IPs utilizables en total 147.83.2.0/29: 30 redes válidas 6 IPs válidas por red 5 IP utilizable por red 150 IPs utilizables en total 147.83.2.0/28: 14 redes válidas 14 IPs válidas por red 13 IP utilizable por red 182 IPs utilizables en total 147.83.2.0/27: 6 redes válidas 30 IPs válidas por red 29 IP utilizable por red 174 IPs utilizables en total 147.83.2.0/26: 2 redes válidas 62 IPs válidas por red 61 IP utilizable por red 122 IPs utilizables en total De forma que no hay ninguna posibilidad que nos permita asignar una a cada una de las 217 máquinas de la empresa si no podemos mezclar en una misma subred máquinas de dos áreas de negocio diferentes.
26/06/2004 2. A una empresa se le ha asignado una red de tipo C. Con las direcciones de esta red quiere crear diferentes subredes para ser utilizadas en las 3 sedes de las que dispone la empresa (sedes A, B y C). Una vez analizadas las necesidades de las diferentes sedes, se ha visto que el número máximo de direcciones que se podrían necesitar para cada una de las sedes son las siguientes: Sede A: 87 Sede B: 58 Sede C: 29 Se quiere diseñar la red con 1 central de comunicaciones que tendrá 1 única conexión con la red Internet externa y tantas conexiones con las sedes como sea necesario. Utilizaremos como encaminadores PCs con tantas tarjetas de red como sea necesario. a. ¿Cuáles serán las subredes si deseamos subredes del mismo tamaño? En las redes tipo C, se utilizan 24 bits por identificar la red, y 8 bits por identificar subredes y equipos. Para tener las subredes suficientes para soportar el número de quipos del enunciado, hace falta utilizar: 3 bits para subredes: Como no se pueden utilizar los identificadores de subred con todo 0s (000) o todo 1 (111), tendremos 2^3 - 2 = 6 subredes útiles. 5 bits para equipos en una subred. Como tampoco se puede utilizar la dirección todo 0s (00000) que corresponde al identificador de red, ni la dirección todo 1s (11111) que corresponde a la dirección de broadcast de la subred, tendremos 25 – 2 = 30 direcciones útiles por subred. Las 6 subredes útiles serán las siguientes: a.b.c.001 00000/27 (255.255.255.32/27) a.b.c.010 00000/27 (255.255.255.64/27) a.b.c.011 00000/27 (255.255.255.96/27) a.b.c.100 00000/27 (255.255.255.128/27) a.b.c.101 00000/27 (255.255.255.160/27) a.b.c.110 00000/27 (255.255.255.192/27) b. Para la primera y última subred útil, dar su rango de direcciones útil, la máscara de subred, la dirección de la subred, y la dirección de broadcast. Para las subredes, no consideramos útiles las direcciones todo 0s (00000) que corresponde al identificador de red, ni la dirección todo 1s (11111) que corresponde a la dirección de broadcast de la subred, tendremos 25 – 2 = 30 direcciones útiles por subred.
Direcciones útiles a.b.c.001 00001 - a.b.c.001 11110 (a.b.c.33 - a.b.c.62) a.b.c.110 00001 - a.b.c.110 11110 (a.b.c.193 - a.b.c.222)
Dirección subred 255.255.255.32
Dirección broadcast subred 255.255.255.63
255.255.255.192
255.255.255.223
c. Asignar las direcciones que corresponden a cada sede. Con esta distribución de las direcciones, las sedes A, B y C tendrán que tener 3,2 y 1 subredes respectivamente. Sede A: a.b.c.001 00000/27 a.b.c.010 00000/27 a.b.c.011 00000/27. Sede B: a.b.c.100 00000/27 a.b.c.101 00000/27. Sede C: a.b.c.110 00000/27. d. Hacer el dibujo donde se vean las diferentes subredes, la conexión entre ellas, la conexión con la central de comunicaciones y la conexión de ésta con la red externa. Dibujar 1 ordenador a cada subred. Asignar una dirección IP a cada uno de los elementos del dibujo que lo requieran.
22/01/2005 2. Una empresa dispone de un encaminador con la siguiente tabla de encaminamiento:
route print ... =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 81.43.13.1 81.43.13.136 1 190.168.96.1 255.255.255.255 127.0.0.1 127.0.0.1 1 190.168.64.1 255.255.255.255 127.0.0.1 127.0.0.1 1 190.168.32.1 255.255.255.255 127.0.0.1 127.0.0.1 1 81.43.13.136 255.255.255.255 127.0.0.1 127.0.0.1 1 190.168.96.0 255.255.448.0 190.168.96.1 190.168.96.1 1 190.168.64.0 255.255.448.0 190.168.64.1 190.168.64.1 1 190.168.32.0 255.255.448.0 190.168.32.1 190.168.32.1 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 255.255.255.255 255.255.255.255 81.43.13.1 81.43.13.136 1 Default Gateway: 81.43.13.1
A partir de esta tabla de encaminamiento, se pide: a. Dibujar el esquema donde se vea el encaminador y las redes que conecta. Dibujar al menos un ordenador a cada red y asignar direcciones IP a cada elemento que lo requiera. Para los elementos que no se conozca la dirección IP, inventársela.
b. Para la primera y última subred existentes, dar su rango de direcciones útil, la máscara de subred, la dirección de la subred, y la dirección de broadcast. Subred 190.168.32.0 190.168.64.0 190.168.96.0
Rango 190.168.32.1 -190.168.63.254 190.168.64.1 -190.168.95.254 190.168.96.1 -190.168.127.254
Máscara 255.255.448.0 255.255.448.0 255.255.448.0
Broadcast Remoto 190.168.63.255 190.168.95.255 190.168.127.255
c. ¿Cuántas subredes más del mismo tipo que las existentes a la configuración actual podría instalar la empresa con las direcciones que tiene asignadas? ¿Cuántas direcciones útiles dispondría en total la empresa con esta configuración de subredes? ¿Cuántas direcciones habría dispuesto la empresa si no hubiera utilizado subnetting? Justificarlo todo. Notas: La tabla se analiza de abajo hacia arriba. Es decir, la primera entrada que se analiza es la última de la tabla, mientras que la última entrada que se analiza es la primera de la tabla. Se trata de subredes de una red tipo B (190.168.x.x). Por lo tanto, la empresa dispone de 16 bits para repartir entre subredes y direcciones de equipos.
A partir de la tabla de encaminamiento se ve que la empresa actualmente está configurada con 3 subredes. A partir del 3r byte de la máscara de la tabla de encaminamiento (448), se ve que se utilizan los 3 primeros bits (448=11100000) como identificador de subredes dentro de la red. Por este motivo se podrá tener hasta 23-2=6 subredes. Se debe recordar que no se utilizan las subredes con todo 0s (000) ni todo 1s (111). Por lo tanto, se utilizan 13 bits para identificador de equipos dentro de cada subred, y por este motivo se podrá tener hasta 213-2=8190 equipos por subred. También recordar que no se utilizan los identificadores de equipos con todo 0s y todo 1s. Con esta configuración, la empresa dispondrá de 6*8190=49140 direcciones útiles. Si no hubiera hecho subnetting, la empresa hubiera tenido disponibles 216-2 = 65534 direcciones útiles. 15/06/05 2. Suponéis que un equipo descarga un fichero de 1024 bytes de un servidor. La red a la que está conectado el cliente tiene una ("% de 160 bytes y la del servidor una de 800 bytes. Una vez finalizada la fase de establecimiento de la conexión "$ , empieza la transmisión de datos, del servidor cabe al cliente. Respondéis a las siguientes preguntas: a) ¿Qué ( '' creéis que habrían de anunciar el cliente y el servidor en la fase de establecimiento de conexión? ¿Por qué? ¿Qué se utilizaría para la comunicación en estas condiciones? La cantidad máxima de datos que podrá transportar un segmento TCP en una red dada es la cantidad de datos que puede transportar una trama de nivel enlace menos el espacio ocupado por las cabeceras TCP y IP. Cliente: 160 bytes – 20 bytes capç. IP - 20 bytes capç. TCP = 120 bytes Servidor: 800 bytes – 20 bytes capç. IP - 20 bytes capç. TCP = 760 bytes Se utilizaría 120 bytes, porque es la menor de las dos. b) Asumiendo que la ( '' utilizada para la comunicación será de 100 bytes y que las ventanas de recepción anunciadas por el cliente y por el servidor serán de 210 bytes y 512 bytes respectivamente, ¿cómo será el diagrama de transmisión de los datos? (tomad como modelo el que se ve en el ejercicio 3 de autoevaluación del módulo “"$ / ”).
#
c) ¿Qué pasaría si la aplicación cliente deja de funcionar correctamente y no consume más datos de las que llegan por la red? (Es decir, si deja que se acumulen en el buffer de recepción del socket porque no hace ninguna operación de read sobre el socket) ¿Cómo se comportaría el protocolo TCP en esta situación? Describid cuál sería el intercambio de segmentos que se produciría hasta que se llegara a una situación estacionaria.
d) Dada la situación inicial (apartado b), ¿qué pasaría si se perdiera el cuarto segmento que el servidor envía al cliente? ¿Qué comportamiento observaremos entonces? Reproducirlo en un nuevo diagrama. Nota: Considerad sólo el algoritmo de slow start, sin congestion avoidance, y asumís que la ventana de congestión, durante la fase de slow start, se incrementa en uno por cada segmento reconocido y no por cada segmento de reconocimiento recibido (ACK). Los segmentos que se pierden en el buffer de recepción, pero la aplicación no los puede consumir hasta que llega el segmento que faltaba. Literalmente, hay un “agujero” en el buffer de recepción hasta que no se reciben todos los segmentos.
3. Un estudiante del campus virtual de la UOC quiere enviar un mensaje de correo electrónico a través del webmail a otro estudiante. Nota: Asumís que al inicio los equipos no tienen ninguna información de las direcciones IP de los otros sistemas con los que han de interaccionar. a) Indicad qué interacciones de los protocolos HTTP, SMTP, POP3 y DNS se darán en el proceso de envío del mensaje y en el proceso de recepción. Considera tanto las interacciones entre los equipos de los clientes como entre los servidores. Envío: 1. Petición &*' máquina www.uoc.edu 2. Conexión y entrada al campus mediante -"" 3. Entrega del mensaje mediante -"" 4. El servidor web hace una petición de &*' por conocer la dirección del servidor '(" de la UOC 5. Conexión '(" entre el servidor web y el servidor '( " de la UOC 6. Entrega del mensaje Recepción: 1. Petición DNS máquina www.uoc.edu 2. Conexión y entrada al campus mediante HTTP 3. El servidor web hace una petición de &*' por conocer la dirección del servidor POP3 de la UOC. 4. Conexión POP3 entre el servidor web y el servidor '( " de la UOC 5. Recepción del mensaje por parte del servidor web 6. Lectura del mensaje usando -"" b) Indicad qué pedidos '( " se ejecutarán para hacer el envío del mensaje - Establecimiento de la conexión con el puerto 25 (smtp) HELLO uoc.edu MAIL FROM: direcció[email protected] $ " TONO: dirige2@uoc/.edu FECHA . QUIT c) Indicad qué pedidos POP3 se ejecutarán para listar los mensajes contenidos en el servidor pop.uoc.edu y seguidamente descargar el tercero. - Establecimiento de la conexión con el puerto 110 (pop3) USER josep PASS password STAT RETR 3.
18/06/05 2. Si desde uno de los ordenadores de la red del ejercicio anterior nos queremos conectar a un servidor web externo (www.curioso.org con IP 1.2.3.4) detallar todos los paquetes IP y todas las tramas Ethernet que saldrán y entrarán del ordenador, desde que escribimos el nombre del servidor en el navegador, hasta que aparece la página web inicial de este dominio, suponiendo que la tabla caché ARP del ordenador está vacía, y que tenemos configurado como servidor de nombres el ordenador 150.23.10.10. Suponemos que este servidor de nombres trabaja en modo recursivo, y que su caché está igualmente vacía. Hace falta averiguar la IP de www.curioso.org, con una petición DNS. Ésta irá encapsulada dentro de un datagrama UDP, que irá dentro de un paquete IP –con dirección destino la de nuestro servidor DNS, 150.23.10.10-, que irá dentro de una trama Ethernet. A nivel IP, se ve que el servidor DNS está dentro de nuestra red local. Por lo tanto, le podemos enviar directamente a él la trama Ethernet. Como la tabla ARP está vacía, hacemos la petición ARP “¿quién es 150.23.10.10?” con un broadcast Ethernet. El servidor DNS nos contesta con una respuesta ARP diciendo “soy yo!”. Ya tenemos su dirección MAC. Entonces ya podemos enviarle la petición DNS. Cuando la reciba, el servidor DNS insertará en su tabla caché ARP el par MAC nuestra – IP nuestra. Ya que el servidor es recursivo sólo veremos su respuesta, una vez ha averiguado la dirección IP que le hemos pedido. No le hace falta pedirnos nuestra MAC porque ya la tiene. Por lo tanto, recibiremos una respuesta DNS (donde dice que www.curioso.org es 1.2.3.4), que va dentro de un datagrama UDP, que va dentro de un paquete IP (con nuestra dirección como dirección destino), que va dentro de una trama Ethernet (con nuestra MAC como MAC destino). Ya tenemos la IP del servidor www.curioso.org. Ya le podemos enviar la petición HTTP. Irá dentro de un segmento TCP, que irá dentro de un paquete IP –con dirección destino 1.2.3.4-. El nivel TCP ha de iniciar una conexión TCP con 1.2.3.4.80. Genera un segmento SYN y el nivel IP ve que esta máquina es de fuera de nuestra red local. Por lo tanto, lo ha de enviar al encaminador (hemos supuesto antes que es 150.23.10.1). Como no tiene su MAC, hace una petición ARP “¿quién es 150.23.10.1?” con un broadcast Ethernet. El encaminador nos contesta y ya tenemos su MAC. A continuación le enviamos la trama Ethernet (con MAC destino la suya) que contiene el paquete IP (con dirección destino 1.2.3.4) que contiene el segmento SYN hacia el puerto 80. Recibiremos la respuesta TCP (SYN, ACK) dentro de un paquete IP dentro de una trama Ethernet, y enviamos el tercer segmento TCP (ACK) igual que el primero. Ahora ya podemos enviar el comando HTTP GET, encapsulado dentro de un segmento TCP (con puerto destino 80), que irá dentro de un paquete IP (que tiene como dirección destino 1.2.3.4), que irá dentro de una trama Ethernet (con MAC destino la del encaminador). Recibimos una respuesta HTTP que contiene la página principal de www.curioso.org, dentro de un segmento TCP, que está dentro de un paquete IP, que está dentro de una trama Ethernet.
25/06/05 2. Se quiere implementar un sistema de distribución de las retransmisiones en directo y en tiempo real de un reality show, como por ejemplo Gran Hermano, para ver lo que hacen los sufridos concursantes. a) Justificad el protocolo de nivel de transporte que utilizaríais para el envío de los datos de audio y vídeo. UDP: La simplicidad de UDP hace que sea ideal para las aplicaciones que requieren pocos retardos (por ejemplo aplicaciones de tiempo real). UDP también es ideal para los sistemas que no pueden implementar un sistema tan complejo tomo TCP. b) Justificad si tendría sentido utilizar el protocolo RTPC en este sistema. En caso afirmativo, ¿para que utilizaríais este protocolo? Tanto en caso afirmativo como negativo, explicad brevemente el funcionamiento de este protocolo. Sí que tiene sentido utilizar RTPC para conseguir que el sistema reaccione ante posibles problemas en la red. RTCP proporciona información sobre la calidad de servicio de los receptores en grupos multicast y también proporciona soporte para la sincronización de distintos flujos de datos de distintos medios. RTCP lleva a cabo esta tarea definiendo unos paquetes de control que cada uno de los participantes en una sesión RTP envía periódicamente a todas las otras participantes. La información recibida se puede utilizar para el control del rendimiento, para tareas de diagnóstico o para otras funciones. RTCP da soporte a las funciones siguientes: Provisión de información a la aplicación: La principal función de la RTCP es proporcionar información a las aplicaciones sobre la calidad de la distribución de sus datos. De ahí que, cada paquete RTCP contiene informes del emisor y/o del receptor con estadísticas útiles para las aplicaciones. Estas estadísticas incluyen el número de paquetes enviados, el número de paquetes perdidos, etc. La recepción de esta información sobre la calidad de los datos es útil para las aplicaciones, puesto que pueden ir modificando los parámetros de transmisión para mejorar la calidad de su servicio. Identificación de la fuente RTP: La RTCP puerta un identificador de nivel de transporte para la fuente RTP. Este identificador sirve a los receptores para asociar diferentes flujos de datos del mismo participante, pero de sesiones RTP diferentes. Control del intervalo de transmisión RTCP: Para prevenir que el tránsito de control (paquetes RTCP) no sature los recursos de la red, se limita como máximo al 5% del total del tránsito de la sesión. Este límite se ha de conseguir ajustando el intervalo de tiempo que se deja pasar cuando se envían los paquetes RTCP. Cada participante tiene que conocer el número total de participantes y calcular el intervalo a partir de este dato. Envío de información mínima de control de sesión: Como función opcional, el RTCP se puede usar también para enviar cantidades de información pequeñas a todos los participantes de la sesión.
c) Justificad si tendría sentido utilizar el protocolo RSVP en este sistema. En caso afirmativo, ¿para qué utilizaríais este protocolo? Tanto en caso afirmativo como negativo, explicad brevemente el funcionamiento de este protocolo. Sí tiene sentido utilizar RSVP para conseguir que el sistema disponga de una conexión con unas características mínimas determinadas. Las aplicaciones utilizan RSVP para pedir una calidad de servicio de punto a punto para un flujo de datos concreto. RSVP es más útil en los sistemas en que la reserva de la calidad de servicio se lleva a cabo recolocando recursos, en vez de en los sistemas en los que se hace añadiéndolos. d) Si se quiere confirmar que se puede acceder a la retransmisión por correo electrónico, ¿qué protocolo utilizaríais para enviar el mensaje? ¿Y para recibirlo? ¿Es posible hacerlo con algún otro protocolo? Envío: SMTP Recepción: POP3. Otro protocolo para recepción: IMAP e) Si se quiere saber si se tiene acceso a la retransmisión mediante una página web, ¿qué comando http enviaría el navegador para recibirla? Justifica tu respuesta e indica las líneas de petición y respuesta http para una página que se llama “confirmacion.htm”. Comando: GET, porque no hay que enviar datos de usuario. Línea petición: GET /confirmacion.htm HTTP/1.0 Línea respuesta: HTTP/1.1 200 OK 14/01/06 2. Si desde uno de los ordenadores de la red 190.168.2.0 del ejercicio anterior nos queremos conectar a un servidor externo (www.elservidor.org con IP 10.20.30.40), detalla todos los paquetes IP y todas las tramas Ethernet que saldrán y entrarán al ordenador, desde que escribimos el nombre del servidor en el navegador hasta que aparece la página web inicial de este dominio, suponiendo que la tabla caché ARP del ordenador está vacía, y que tenemos configurado como servidor de nombres el ordenador 99.43.13.4. Supongamos que este servidor de nombres trabaja en modo recursivo, y que su caché está igualmente vacía. Propón direcciones MAC para todos los dispositivos que intervienen en la comunicación. Notas: - Es preciso tener en cuenta que antes de enviar datos a través de TCP se tiene que establecer la conexión: un intercambio de segmentos TCP con diferentes flags activados. - En los paquetes TCP y UDP indica los puertos a los cuales se envían los datos. - En la fase de conexión TCP indica los flags de los segmentos. El orden de las operaciones sería: Petición de la dirección MAC del encaminador. Como el servidor de nombres está fuera de nuestra red, usaremos ARP para pedir la dirección de nuestro encaminador. Respuesta de la dirección MAC del encaminador. Petición de la dirección de www.elservidor.org al DNS.
Respuesta DNS con la dirección de www.elservidor.org. Establecimiento de la conexión TCP con el host www.elservidor.org. Petición HTTP del recurso. Respuesta con la página HTTP del recurso. Petición ARP del encaminador que viajará en una trama ethernet con los siguientes datos: @MAC origen: 11:22:33:44:55 (PC1) @MAC destino: FF:FF:FF:FF:FF (broadcast) @IP origen: 190.168.32.10 (PC1) @IP destino: 190.168.32.1 (R) Respuesta ARP de nuestro encaminador 190.168.32.1 que viajará en una trama ethernet con los siguientes datos: @MAC origen: 22:33:44:55:66 (R) @MAC destino: 11:22:33:44:55 (PC1) @IP origen: 190.168.32.1 (R) @IP destino: 190.168.32.10 (PC1) Ahora la petición DNS de www.elservidor.org. Utilizaremos el protocolo UDP, encapsulado dentro de IP. La trama ethernet en la que viajará esta petición tendrá las siguientes características: DNS: Request A www.elservidor.org @MAC origen: 11:22:33:44:55 (PC1) @MAC destino: 22:33:44:55:66 (R) @IP origen: 190.168.32.10 (PC1) @IP destino: 99.43.13.4 (DNS) Puerto UDP: 53 Nuestro encaminador tendrá que pedir la dirección ARP de 99.43.13.4, pero esto ya no nos llegará. Nos dicen que el servidor DNS trabaja en modo recursivo. Entonces sólo recibiremos la respuesta DNS con los datos del ordenador solicitado. DNS: Standard Query Response CNAME www.elservidor.org @MAC origen: 22:33:44:55:66 (R) @MAC destino: 11:22:33:44:55 (PC1) @IP origen: 99.43.13.4 (DNS) @IP destino: 190.168.32.10 (PC1) Ahora que ya tenemos la dirección, establecemos la conexión TCP. Se han de enviar tres segmentos TCP para establecer la conexión, uno con el flag SYN activado, uno de respuesta con los flags SYN, ACK activados y un tercero que sólo tenga el flag ACK activado. Establecimiento conexión TCP Inicio del cliente @MAC origen: 11:22:33:44:55 (PC1) @MAC destino: 22:33:44:55:66 (R)
@IP origen: 190.168.32.10 (PC1) @IP destino: 10.20.30.40 (www.elservidor.org) Puerto TCP destino: 80 Flag SYN activado Respuesta del servidor @MAC origen: 22:33:44:55:66 (R) @MAC destino: 11:22:33:44:55 (PC1) @IP origen: 10.20.30.40 (www.elservidor.org) @IP destino: 190.168.32.10 (PC1) TCP: Flags SYN, ACK activados Confirmación conexión del cliente @MAC origen: 11:22:33:44:55 (PC1) @MAC destino: 22:33:44:55:66 (R) @IP origen: 190.168.32.10 (PC1) @IP destino: 10.20.30.40 (www.elservidor.org) Puerto TCP destino: 80 Flag ACK activado Sólo falta pedir el recurso con el protocolo HTTP, ya que tenemos la conexión establecida. @MAC origen: 11:22:33:44:55 (PC1) @MAC destino: 22:33:44:55:66 (R) @IP origen: 190.168.32.10 (PC1) @IP destino: 10.20.30.40 (www.elservidor.org) Puerto TCP destino: 80 HTTP: GET / HTTP/1.1 La respuesta del servidor sería el recurso y podría ser @MAC origen: 22:33:44:55:66 (R) @MAC destino: 11:22:33:44:55 (PC1) @IP origen: 10.20.30.40 (www.elservidor.org) @IP destino: 190.168.32.10 (PC1) HTTP: HTTP/1.1 200 OK (El resto sería el recurso) 21/01/06 2. Una empresa tiene un sistema de correo corporativo que solamente es accesible desde las máquinas de sus oficinas. Se quiere dar acceso remoto vía web. Responde de forma breve y razonada a las siguientes preguntas: a. ¿Qué protocolos de nivel de aplicación habrá en este nuevo sistema? Indica todos los protocolos que intervengan. HTTP, SMTP, POP3 e IMAP b. Dibujad un diagrama de los módulos que se tendrían que añadir a un sistema de correo normal para recibir correo vía web.
c. Además de la interfaz de correo, se quiere añadir un sistema de mensajería instantánea a través del protocolo UDP. ¿Qué habría que hacer en el ordenador cliente para que se puedan recibir estas notificaciones? Abrir un puerto UDP en la máquina del cliente para que pueda recibir estas notificaciones. 17/06/06 c) Un trabajador de la sede A ( $ ) quiere descargar un fichero de 850 byte desde el equipo de un compañero que trabaja en la suyo B ( $.), usando "$ como protocolo de capa transporte. Responde las cuestiones teniendo en cuenta las siguientes consideraciones: • ( "% dentro de la sede B: 200 bytes • ( "% dentro de la sede A: 400 bytes • Buffer de recepción PCA: 150 bytes • Buffer de recepción PCB: 700 bytes • Se genera un $+ por cada segmento recibido correctamente a) ¿Qué valor de ('' creéis que sería recomendable que usaran los equipos para la transmisión del fichero? ¿Creéis que esta será la medida escogida por los dos? ¿En qué os basáis? #
La cantidad máxima de datos que podrá transportar un segmento "$ en una red dada es la cantidad de datos que puede transportar una trama de nivel enlace menos el espacio ocupado por las cabeceras "$ y . $.: 200 bytes – 20 bytes cabecera IP - 20 bytes cabecera TCP = 160 bytes PCA: 400 bytes – 20 bytes cabecera. IP - 20 bytes cabecera TCP = 360 bytes Se podría utilizar 160 bytes, porque es la menor de las dos. En cualquier caso, dado que el / 00 de recepción de $ es de sólo 150 bytes, sería necesario que $. nunca enviara más de 150 bytes en un solo segmento. b) Muestra en un diagrama de tiempo (tomad como modelo el que se ve en el ejercicio 3 de autoevaluación del módulo “"$ / ”).los segmentos que intercambiarán los dos equipos para hacer la transmisión de los datos (no hace falta que consideráis el establecimiento ni el cierre de la conexión). PCB
PCA
c) ¿Qué pasaría si se perdiera el tercer segmento que el servidor envía al cliente? ¿Qué comportamiento observaremos entonces? Reproducidlo en un nuevo diagrama, indicando en cada momento el valor de la ventana de congestión de PCB. Nota: podéis asumir para los apartados b y c un MSS de 100 bytes
PCB
PCA
d) Como paso previo a la descarga del fichero del apartado anterior, PCA necesitaba conocer la dirige de *PCB.
Nota: Asumid que al inicio los equipos no tienen ninguna información de las direcciones IP de los otros sistemas con los que han de interaccionar. a) Indicáis, esquemáticamente, qué peticiones y respuestas DNS se habrán realizado entre PCA, su servidor de DNS local (DNS-A) y el resto de servidores DNS del mundo, asumiendo que el servidor DNS local soporta el modo recursivo y el resto de servidores sólo el iterativo. El proceso seria el siguiente: 1. El host $ enviará una petición a su servidor de &*' (&*'-A) sobre la dirección $.. 2. El servidor de &*' verá que tiene la referencia porque $. también pertenece al mismo dominio 3. El &*'-A devolverá al cliente ( $ ) la dirección de la máquina $. b) Si en ninguna parte se descargar un fichero desde $., $ hubiera querido ver las imágenes que $. captaba con su webcam, ¿creéis que usar TCP seria la mejor idea? ¿Qué alternativas proponéis? ¿Cuál creéis que sería la más adecuada? El protocolo más adecuado sería %& . Su simplicidad hace que sea ideal para aplicaciones en tiempo real, dónde es más importante la existencia de pocos retardos que el hecho que todos los datos lleguen en perfecto estado. 27/06/06 2. Una pequeña empresa tiene 50 PC y dos servidores, uno web y el otro de &*'. Tiene asignada la red IP 200.150.100.0/24, pero por aislar los servidores del conjunto de PC, decide crear dos redes locales independientes (la A y la B), de la misma medida, como indica la figura:
En la red A estarán todos los PC y a la red B los dos servidores. a) Proponed un esquema de subnetting. Decid cuales serian las direcciones de red de A y B, cuales serian los broadcasts remotos y cuántos PC cabrían en A.
. Máscara /24 -> Tenemos 32-24=8 bits para distribuir entre subredes y equipos. Para 50 equipos, tenemos lo suficiente con 6 bits: 26 -2 = 64 – 2 = 62 equipos Para 2 subredes, necesitamos 2 bits: 22 – 2 = 2 subredes Repartiremos los 8 bits entre: 2 bits para subredes + 6 bits por equipos dentro las subredes Subredes: 01 y 10 Red A: 200.150.100.01000000 = 200.150.100.64 Red B: 200.150.100.10000000 = 200.150.100.128 Red A: Broadcast remoto: 200.150.100.127 Hay cabrían 62 equipos, el encaminador y 61 máquinas más Red B: Broadcast remoto: 200.150.100.191 b) Asignáis direcciones IP a todas las interfaces de red que se ven en el dibujo, excepto la del puerto del encaminador que se conecta a Internet. Red A: Encaminador: 200.150.100.65 PC1: 200.150.100.66 PC2: 200.150.100.67 Dirección de red: 200.150.100.64 Direcciones validas: 200.150.100.64 - 200.150.100.126 Red B: Encaminador: 200.150.100.129 Servidor web: 200.150.100.130 Servidor DNS: 200.150.100.131 Dirección de la Red: 200.150.100.128 Direcciones validas: 200.150.100.129 - 200.150.100.190 c) Suponiendo que el puerto del encaminador que se conecta a Internet es la dirección 81.43.8.40/8, y que la del encaminador del ISP (que no aparece en la figura) es la 81.1.1.1/8, haced una tabla de encaminamiento para el encaminador de la figura. Dirección 200.150.100.65 200.150.100.129 81.43.8.40
Máscara 255.255.255.255 255.255.255.255 255.255.255.255
Encaminador 127.0.0.1 127.0.0.1 127.0.0.1
Interfície loopback loopback loopback
127.0.0.0 200.150.100.64 200.150.100.128 81.0.0.0 0.0.0.0
255.0.0.0 255.255.255.192 255.255.255.192 255.0.0.0 0.0.0.0
127.0.0.1 200.150.100.65 200.150.100.129 81.43.8.40 81.1.1.1
loopback eth0 eth1 eth2 eth2
01/07/06 2.- Un ordenador del departamento de producción quiere enviar un fichero de 100 KB (incluyendo datos de control e información propiamente dicha) a un servidor FTP del departamento de informática: • Dibuja los estados por los que pasa cada extremo de la conexión teniendo en cuenta el diagrama de estados de TCP para completar todo el proceso (se adjunta gráfico).
• Cómo se construyen los segmentos TCP y cuántos segmentos se enviarán. Supón que el MSS es lo más grande posible y que el tamaño máximo de un datagrama IP es de 64KB. El tamaño máximo del datagrama IP es de 64KB y vamos a suponer que las cabeceras de los segmentos y datagramas no tienen opciones, es decir, cada cabecera tendrá un tamaño de 20 bytes. El campo de datos del datagrama IP es de 65.516 Bytes (= 65.536 bytes de todo el datagrama - 20 de cabecera sin opciones). De esta manera el segmento TCP puede tener un tamaño máximo de
65.516 bytes, pero también tiene 20 bytes de cabecera, es decir, quedan 65.496 bytes para guardar los datos que nos envía la aplicación FTP. El nivel FTP envía a la capa TCP 100 KB (102.400 bytes, entre información y datos de control) tenemos como resultado 2 segmentos TCP. El primero tiene un campo de datos de tamaño 65.496 bytes y el último tiene un campo de datos de tamaño 36.904 bytes. (65.496 + 36.904= 102.400). • Dibuja un diagrama indicando el intercambio de segmentos teniendo en cuenta un tamaño de ventana de 150KB. Ten en cuenta sólo los extremos de la conexión TCP. La ventana no se llena, dependiendo del algoritmo tcp utilizado, enviaremos un segmento, confirmaremos y luego se enviará el otro segmento tcp. 13/01/07 2. Las siguientes líneas muestran los primeros segmentos de una conexión TCP obtenidos con el programa tcpdump: 193.144.22.80.21 > 193.144.22.100.4379: S 0:0(0) win 2 193.144.22.100.4379 > 193.144.22.80.21: S 0:0(0) ack 1 win 8192 193.144.22.80.21 > 193.144.22.100.4379: . ack 1 win 9216 193.144.22.80.21 > 193.144.22.100.4379: . 1:1461(1460) ack 1 win 9216 193.144.22.80.21 > 193.144.22.100.4379: . 1461:2921(1460) ack 1 win 9216 193.144.22.100.4379 > 193.144.22.80.21: . ack 1461 win 7168 Para las tres primeras líneas, dibuja los estados por los que ha pasado cada extremo de la conexión, según el diagrama de estados de TCP/IP. Equipo 22.80 1 CLOSE -> SYN_SENT 2 3 SYN_SENT -> ESTABLISHED
Equipo 22.100 1 2 LISTEN -> SYN_RCVD 3 SYN_RCVD -> ESTAB
¿Con qué valor de MSS intercambian segmentos? ¿Por qué? El mínimo entre los MSS que anuncian los dos equipos al inicio de la conexión. En este caso, 1460 (que es el mismo valor que anuncian ambos). ¿Cuál es el valor de la ventana de transmisión para ambas máquinas? TCP efectúa un control de flujo por ventana deslizante, con la diferencia, respeto a los protocolos del nivel de enlace, que en TCP la ventana de transmisión es variable. La idea es que cada extremo TCP regula la cantidad de datos que el otro extremo puede transmitir. Con esta finalidad, cada extremo TCP avisa, cada vez que envía un segmento, al extremo opuesto de la ventana que puede aceptar en este momento. El TCP parejo actualiza su ventana de transmisión de acuerdo con este valor.
Por este motivo, la ventana de transmisión viene fijada por el valor del campo win recibido en el último segmento. Al final de la secuencia del enunciado, las ventanas de transmisión son: 22.80: 7168 22.100: 9216 ¿Cuál es el valor de la ventana de congestión para cada máquina? Haz las suposiciones que creas convenientes. La ventana de congestión aplica a la transmisión de datos usando el mecanismo de slow-start. En el caso teórico, se inicializa a 1 segmento MSS, y se incrementa en 1 segmento por cada segmento reconocido con 1 ack, hasta llegar al valor igual a la ventana de transmisión. El equipo 22.80 ha iniciado la transmisión con 2 segmentos de tamaño MSS. Podría significar que solo tenía 2 MSS datos a transmitir y no sigue el mecanismo de slow-start, o que si lo sigue pero ha iniciado la transmisión con 2 segmentos de tamaño MSS. El equipo 22.100 solo ha transmitido un segmento de aceptación de conexión y un segmento con solo ACK. Como no ha transmitido ningún segmento de datos no podemos saber si usa el mecanismo de slow start o no, y por lo tanto en caso que siguiera éste mecanismo no podemos saber cual es su ventana de congestión. Suponiendo que ambas máquinas quieran transmitir datos, cuántos bytes podrán transmitir en este momento. Si no se usa slow-start: la ventana de transmisión 22.80: 7168 22.100: 9216 Si se usa slow-start: 22.80: 2 MSS + 1 MSS (se ha recibido 1 ack) = 3 MSS = 3 * 1460 = 4380 22.100: 1 MSS (aún no ha enviado ningún dato) = 1460 17/01/07 2. Este es el resultado de la ejecución del programa Ethereal durante un tiempo en una red local. Cada grupo de bytes numerado corresponde a un paquete IP. El texto de la parte derecha es la versión ASCII de los bytes. (1) 0010 00 3c 6f a6 00 00 40 01 1e bb c0 a8 00 83 3e 25 0020 ed 0f 08 00 bb 45 03 00 8f 16 61 62 63 64 65 66 0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 0040 77 61 62 63 64 65 66 67 68 69
45 00 E. .% .....E.. ..abcdef ghijklmn opqrstuv wabcdefg hi
(2) 0010 00 3c 0b 95 00 00 f8 01 ca cb 3e 25 ed 0f c0 a8 0020 00 83 00 00 c3 45 03 00 8f 16 61 62 63 64 65 66 0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 0040 77 61 62 63 64 65 66 67 68 69
45 00 E. .<...... ..>%.... .....E.. ..abcdef ghijklmn opqrstuv wabcdefg hi
(3) 0010 00 34 6f 12 40 00 40 06 be bd c0 a8 00 83 42 66 0020 09 63 11 cf 00 50 88 6f ae f7 00 00 00 00 80 02 0030 ff ff 18 9c 00 00 02 04 05 b4 01 03 03 02 01 01 0040 04 02
45 00 E. .4o.@.@. ......Bf .c...P.o ........ ........ ........ ..
(4) 0010 00 2c 07 65 00 00 f0 06 b6 72 42 66 09 63 c0 a8 0020 00 83 00 50 11 cf 4e 6a f5 e1 88 6f ae f8 60 12 0030 1f fe dd 58 00 00 02 04 05 ac
45 00 E. .,.e.... .rBf.c.. ...P..Nj ...o..`. ...X.... ..
(5) 0010 00 28 6f 13 40 00 40 06 be c8 c0 a8 00 83 42 66 0020 09 63 11 cf 00 50 88 6f ae f8 4e 6a f5 e2 50 10 0030 ff ff 15 0c 00 00
45 00 E. .(o.@.@. ......Bf .c...P.o ..Nj..P. ......
Fijaos en los dos primeros paquetes capturados: a) ¿Qué protocolo encapsula el paquete IP (1) y (2)? Indicad cuál es el valor de cada campo de la cabecera de este protocolo encapsulado. Los dos paquetes (1) y (2) se corresponden con el protocolo ICMP, valor 0x01 PAQUETE (1) Tipo: 08 Echo ping request Código: 00 Checksum: 0xbb45 Identificador: 0x0300 Número de secuencia: 0x8f16 Datos: 61 62 63 64 65 66... PAQUETE (2) Tipo: 00 Echo ping reply Código: 00 Checksum: 0xc345 Identificador: 0x0300 Número de secuencia: 0x8f16 Datos: 61 62 63 64 65 66... b) ¿De qué aplicación creéis que se trata? ¿Para qué puede utilizar un administrador de red esta aplicación? La aplicación es PING que permite descubrir si una estación se encuentra activa o no. Fijaos ahora en el resto de paquetes (del (3) al (5)). c) ¿De qué protocolo a nivel de transporte se trata? En los tres segmentos es TCP, valor 0x06 d) Deducid el diagrama de flujo de este intercambio de segmentos. El segmento (3) tiene el flag SYN activado, valor 0x0002. El segmento (4) tiene el flag ACK y SYN activado, valor 0x0012 El segmento (5) tiene el flag ACK activado, valor 0x0010
20/01/07 2. Responded brevemente a las siguientes preguntas: 1. ¿Cuál es la finalidad del control de congestión en TCP? Reducir el ritmo de transmisión de segmentos de un emisor para evitar la congestión de los encaminadores de la red o para paliar el efecto si ya están saturados. 2. ¿Qué podría pasar si no se dispusiera de este mecanismo? Se sobresaturaría la red sin necesidad, ya que los segmentos son descartados. 3. ¿En qué se diferencia del control de flujo? El control de flujo sirve para que un receptor avise al otro extremo (emisor) del número de bytes que puede aceptar (para no saturar sus buffers internos), mediante el mecanismo de ventana deslizante. En cambio, el control de congestión se realiza para no saturar los buffers de los encaminadores. 4. ¿Que relación tiene con el control de errores? Éste posibilita la recuperación de información que no había llegado bien mediante las retransmisiones. 5. ¿Cuántas secuencias de números de secuencia y de números de ACK se mantienen durante una comunicacióin TCP? Dos: una para cada sentido de la comunicación. Durante el establecimiento de la conexión (protocolo three-way hanshake) se determina el ISN para cada sentido. A partir de aquí el número de secuencia identificará el número del primer byte de información de cada segmento, que se asigna de manera consecutiva para cada
uno de los sentidos. El número de ACK nos indica el último byte reconocido, y por lo tanto también guardan relación. 6. ¿Cuantas las mantiene el servidor? Las mismas. 7. ¿Y cuantas el cliente? Las mismas. 8. ¿Que pasaría si un servidor TCP no hiciera la llamada bind para el socket en el que espera recibir conexiones? Los clientes no conocerían automáticamente el socket (dirección y puerto) donde se está ofreciendo el servicio. 9. ¿Pueden dos segmentes TCP consecutivos correspondientes a una misma secuencia de datos de una misma conexión llegar a su destino en un orden diferente al que tienen al ser emitidos? Sí. 10.¿Cómo se explica esto? Puede haber muchas situaciones que lo provoquen (pueden ir por caminos diferentes según el tráfico de red o la caída de algún encaminador, por ejemplo). 11.¿Que pasa cuando se reciben en el destino? ¿Por qué? Nada. Existe un buffer en el nivel de transporte que se encarga de almacenar segmentos para que se entreguen correctamente al nivel aplicación (buffer transfered), descartando las repeticiones. 12.¿Y en UDP? ¿Puede pasar que dos datagramas lleguen desordenados? ¿Es necesario hacer alguna cosa al respecto? ¿Quién debe preocuparse de ello? Sí. A nivel aplicación (en el programa cliente y servidor) deberíamos controlarlo mediante el código correspondiente.
Enunciados Preguntas nº 3 10/01/04 3. Suponed un ordenador conectado a Internet a través de línea telefónica, con el protocolo PPP (Point-to-point Protocolo). Cogemos un programa cliente FTP y le damos el nombre de un servidor para que se conecte. A continuación ponemos nuestro nombre y la palabra de paso, y después el nombre de un archivo que #
queremos bajarnos. Los diferentes componentes software que implementan la pila TCP/IP en nuestro ordenador se ponen en marcha para recibir el archivo solicitado. a) Describid todas las acciones que se llevan a cabo en todos los niveles de la pila TCP/IP y qué protocolos intervienen, desde que se pone el nombre del archivo hasta que llega a nuestro disco duro: a.1. ¿Cómo y cuando se averigua la dirección IP del servidor? En el momento que ponemos el nombre del servidor FTP donde nos queremos conectar. El programa hace una petición DNS. a.2. ¿Qué comandos envía el protocolo FTP? USER, PASS, PUERTO, RETR a.3. ¿Qué protocolo de transporte utilizará la aplicación? ¿De qué se encargará? TCP. Para que haga control de flujo y control de errores, de manera que el flujo de bytes que reciba el cliente FTP sea exactamente lo mismo que ha enviado el servidor FTP. a.4. ¿Qué hace el nivel de enlace? Conseguir que cada paquete que genere el nivel IP llegue bien, sin errores a los encaminadores correspondientes. Por eso, genera tramas, donde pone el paquete IP y una redundancia en forma de checksum, para poder hacer la detección de los errores de transmisión. Ilustrad todo el proceso con las PDU que se van generando. Poned vosotros mismos direcciones IP en cada dispositivo de la red, que pueden ser ficticias pero con coherencia. 17/01/04 3. Imaginad que una máquina con conexión a Internet a través de un ISP quiere acceder a una página de un servidor web remoto: http://www.dept_informatica.uac.edu/formularios/alta.html El protocolo a usar para la conexión es HTTP/1.0 sobre TCP/IP. Del servidor web solo conoce el nombre, pero no la dirección IP. También dispone de la dirección IP del servidor de nombres de su ISP. Podéis asumir que las memorias cache de todos los servidores de DNS están vacías en el momento de la consulta. Teniendo en cuenta estos datos, determinad: a) ¿Qué secuencia de peticiones de DNS se llevará a cabo para determinar la localización de la máquina www.dept_informatica.uac.edu, teniendo en cuenta que el cliente hará una petición en modo recursivo que le será aceptada? ¿Qué servidores de DNS se verán involucrados en la resolución de la consulta? El cliente enviara una petición a su servidor de DNS sobre la dirección del servidor web a acceder. El servidor de DNS del ISP contratado por el cliente verá que no
tiene la referencia en su cache, de manera que realizará una petición al servidor de DNS del dominio edu para resolver la dirección del servidor de DNS del dominio uac.edu. Con la respuesta en la mano, el DNS del ISP realizará una petición al servidor del DNS del dominio uac de la dirección del servidor de DNS del dominio dept_informatica.uac.edu. Con la respuesta recibida, el DNS del ISP realizará una petición al DNS de dept_informatica.uac.edu de la dirección IP que tiene la máquina www. El DNS del ISP devolverá al cliente la dirección de la máquina www.dept_informatica.uac.edu. b) ¿Qué campos contendrá el mensaje que enviará el cliente al servidor de DNS de su ISP para resolver el nombre www.dept_informatica.uac.edu? ID QR OPCODE AA
Número de 16 bits
0 0 1 1 0 0 0
TC RD RA RCODE QDCOUNT ANCOUNT NSCOUNT ARCOUNT Pregunta:
QNAME QTYPE QCLASS
www.dept_informatica.uac.edu
1 (A) 1 (Internet)
c) Dado que el dominio existe, ¿cuál será el formato de la respuesta que recibirá el cliente por parte de su servidor de DNS? ID QR OPCODE AA
Mismo Número de 16 bits
TC RD RA RCODE QDCOUNT ANCOUNT NSCOUNT ARCOUNT
1 0 ? (depende) 0 1 0 0 1 0 0
Respuesta:
Dirección IP solicitada
d) Una vez localizada la máquina en concreto, ¿cuál será la primera línea de la petición HTTP que enviará el cliente al servidor web? GET /formularios/alta.html HTTP/1.0 24/01/04 3. Disponemos de un ordenador con el sistema operativo Unix, sólo con las siguientes características de red y servicios TCP/IP configurados (ftp, www y talk): a) protocolo TCP/IP instalado b) LAN Ethernet con dirección MAC 03:a2:22:33:11:2a c) dirección IP 123.23.12.3 d) dirección Gateway 123.23.13.4 e) contiene el fichero /etc/inetd.conf con el siguiente contenido: ftp stream tcp nowait root /usr/etc/ftpd ftpd -l www stream tcp nowait root /usr/etc/apache apache talk dgram udp wait root /usr/etc/talkd talkd a) ¿Si llegan al ordenador dos peticiones de conexión TCP en el puerto 80 (www) casi en el mismo instante de tiempo, sería posible atender las dos peticiones al mismo tiempo (dos procesos paralelos) o haría falta que una petición esperara una vez finalizada la otra petición? Justificad la respuesta. Cuando llegan las peticiones TCP al puerto 80, quiere decir que llegan peticiones hacia el servicio de WWW (Web). Como la segunda línea del fichero /etc/inetd.conf contiene el campo nowait, indica que el servidor inetd continuará atendiendo peticiones de servicio y arrancando nuevos procesos para cada uno que llegue, independientemente de si los otros han acabado o no. Así las dos peticiones en el puerto 80 que llegan casi en el mismo instante de tiempo crearán cada una un nuevo proceso, y por lo tanto, tendremos dos procesos paralelos. Así se atenderán simultáneamente o paralelamente las dos peticiones que han llegado casi en el mismo instante de tiempo. b) Si al ordenador le llega un datagrama por el servicio de talk, y después (millonésima de segundo más tarde) le llega una petición para acceder en el puerto 80 del TCP, indicad qué procesos se crearán, con qué orden se ejecutarán y si alguna petición habrá o no de esperar la finalización de la otra petición. Justificad la respuesta. Como la tercera línea del fichero /etc/inted.conf lleva el campo wait, indica que una vez recibida la petición del servicio de talk, el servidor inetd se quedará esperando hasta que el proceso hijo de talk acabe. Así, primero se crearía un proceso hijo de talk y la petición en el puerto 80 se quedaría esperando. Una vez que el proceso hijo de talk hubiera acabado, entonces se atendería la petición del puerto 80 y se crearía un proceso hijo de WWW. Así la petición WWW tendría que esperar a la petición del servicio de talk: primero se crearía el proceso de talk y una vez hubiera acabado, se crearía el proceso de atención al servicio WWW. c) ¿Cuando desde el lenguaje de programación C utilizamos la función gethostbyname, en qué lugar consultaría el sistema operativo del ordenador (teniendo en cuenta sólo la configuración descrita en el enunciado) la dirección IP
del nombre del servidor que le hemos pasado como parámetro en la función gethostbyname? Cuando se usa la función gethostbyname, el sistema puede ir a buscar la información al fichero local /etc/hosts, al servicio de información distribuida local NIS o global DNS. Debido a que el enunciado nos dice que el ordenador en cuestión no tiene instalado ni configurado el servicio NIS ni el servicio DNS, el sistema iría a buscar la información al fichero local /etc/hosts. 14/06/04 En la empresa dónde trabajamos nos han pedido que instalemos un servidor de correo con apoyo para POP e IMAP. Además, quieren disponer de una página web que haga de interfaz de nuestro sistema de correo (webmail), porque nuestros usuarios puedan acceder al correo desde un navegador. a) Dibujáis un diagrama de bloques que contemple todos los elementos necesarios (clientes, servidores, módulos pasarela) y su interconexión.
b) Comparad, desde un punto de vista funcional, los tres mecanismos de acceso, para cada una de las siguientes situaciones: 1. Nuestros usuarios viajan con frecuencia y no tienen dispositivos portátiles. Su acceso a Internet se reduce a puntos de acceso público (bibliotecas, cibercafes, etc). 2. Nuestros usuarios hacen teletrabajo desde casa y una vez por semana
venden a la empresa y se conectan desde el lugar habitual de trabajo. En los dos casos necesitan un cliente de correo rápido y alta interactividad. Además, reciben a menudo correos con archivos adjuntos. 3. Nuestros usuarios se conectan desde su casa pero sólo tienen tarifa plana a partir de las 8 de la tarde, y tienen las cuentas de correo limitados a 5MB. Al primer caso, webmail parece el más adecuado. No le hace falta instalación ni configuración, mientras que POP e IMAP sí. Se debe tener la precaución de borrar las caché de los ordenadores empleados. Al segundo caso, webmail no parece adecuado si se requiere mucha interactividad, porque es más lento que los clientes específicos de POP e IMAP. Entre estos dos, hace falta tener en cuenta que IMAP se puede configurar porque no baje los adjuntos, y así optimizar el tiempo de conexión cuando estamos a casa. Además, no tendríamos problemas de inconsistencia al usar dos ordenadores. Al caso 3, claramente POP. 19/06/04 3 Queremos conectarnos a una máquina denominada salome que se encuentra en el dominio uoc.edu. Sabemos que el servidor de nombres de la uoc es la máquina ns.uoc.edu. Nosotros nos encontramos en la máquina ender del dominio vpd.edu y nuestro servidor de nombres local se denomina ns.vpd.edu. Si la memoria cae del servidor de DNS de nuestro dominio se encuentra vacía inicialmente, decid: 1. Qué pasos se seguirán para llegar a la máquina salome.uoc.edu desde nuestro equipo si nuestro servidor de DNS no acepta el modo recursivo? (detallad todas las comunicaciones entre máquinas y comentad la finalidad)
1. ¿Quién es salome.uoc.edu? 2. Dirección desconocida 3. ¿Quién es salome.uoc.edu? 4. Dirección de “edu” 5. ¿Quién es salome.uoc.edu? 6. Dirección de ns “.uoc.edu” 7. ¿Quién es salome.uoc.edu? 8. Dirección de salome.uoc.edu 9. Acceso a salome.uoc.edu 10. Respuesta de salome.uoc.edu 2. ¿Y la segunda vez que accedemos? (tened en cuenta la finalidad de las memorias cae). 1. ¿Quién es salome.uoc.edu? 2. Dirección de salome.uoc.edu 3. Acceso a salome.uoc.edu 4. Respuesta de salome.uoc.edu 4. ¿Qué creéis que pasaría si configuramos en nuestro equipo la máquina ns.uoc.edu como servidor de nombres? ¿Nos deberán dejar? ¿Qué pasará si hacemos “$ ping ns”? Esta configuración presentará, con gran probabilidad, un problema de configuración. El servidor ns.uoc.edu sólo debería servir peticiones para el dominio uoc.edu, o resolver peticiones para nombres externos si las máquinas que generan las peticiones están autorizadas a hacerlo (en principio todas aquellas que pertenezcan al rango de direcciones asignado al dominio uoc.edu, o aquello que haya configurado el administrador del dominio). Si hacemos un ping ns, se nos devolverá la dirección de la máquina ns.uoc.edu. 26/06/04 3. Disponemos de un sistema de correo basado en Web (del tipo de correo disponible en la web de la UOC). Suponemos que un usuario de este sistema quiere enviar un mensaje de correo a otro usuario cuyo servidor de correo es un servidor basado en los protocolos SMTP/POP3. a. Realizar un dibujo que incluya: El modelo (los módulos) del sistema de correo basado en Web y que permite interaccionar con servidores basados en SMTP/POP3. El modelo (los módulos) del sistema de correo basado en SMTP/POP3. El navegador web para el acceso del autor del mensaje al sistema de correo basado en Web. El cliente del sistema de correo basado en SMTP/POP3 para el acceso del receptor del mensaje a su sistema de correo, tanto por emisión como por recepción de mensajes.
Las conexiones entre los diferentes elementos del modelo. Suponer que el sistema de correo basado en Web, se encuentra conectado directamente con el sistema remoto de correo SMTP/POP3 del destinatario final del sistema. Cua de Missatges: Cola de Mensajes. Bústies dùsuari: Buzones de usuario.
Suponemos que el usuario que envía el correo ya tiene en su pantalla la página que permite escribir mensajes y que ya ha escrito el mensaje a enviar. b. Enumerar los pasos a nivel de Aplicación que se seguirán en la comunicación desde el momento que se envíe el mensaje hasta que éste sea recibido por el usuario final. Para cada paso, hay que incluir todos los métodos y mensajes de los protocolos de aplicación intercambiados (HTTP, SMTP, POP3). El mensaje es enviado desde el ordenador del emisor a su servidor de correo usando HTTP con una petición PUT o POST, en una comunicación TCP típicamente sobre el puerto 80. POST /path/script.cgi HTTP/1.0 From: [email protected] User-Agent: HTTPTool/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 116 [email protected][email protected]&subject=Xarxes de computadors&data=Aquest es un missatge de correu d’exemple.
El servidor de correo del emisor envía el mensaje al servidor de correo del receptor usando SMTP, en una comunicación TCP sobre el puerto 25. 220 peru.uoc.es SMTP/smap Ready. HELO campus.uoc.es S-250 (campus.uoc.es) pleased to meet you. HELP
214-Commands 214 HEL0 MAIL RCPT DATA RSET 214 NOOP QUIT HELP VRFY EXPN MAIL FROM: [email protected] 250 [email protected]... Sender OK RCPT TO: [email protected] 250 [email protected] OK DATA 354 Enter mail, end with “.” on a line by itself Subject.: Xarxes de computadors Date: 20 Jun 2003 Aquest es un missatge de correu d’exemple. . 250 Mail accepted QUIT Closing connection
Finalmente, el receptor transfiere el mensaje desde su servidor a su ordenador usando POP3, en una comunicación TCP sobre el puerto 110. +OK QPOP (version 2.52) at pop.uoc.es starting. USER rmarti +OK Password required for rmarti. PASS password +OK rmarti has 6 message(s) (190885 octets). STAT +OK 6 190885 LIST +OK 6 messages (190885 octets) 1 3140 2 3326 3 1911 4 180846 5 861 6 801 RETR 6 +OK 801 octets Received: from campus.uoc.es by peru.uoc.es (8.8.5/8.8.5) with ESMTP id S&A14826 for ; Fri, 27 Jun 2003 18:35:52 +0200 (MET DST) From: Jordi Inyigo Message-Id: <199809211639 .SAA20364&peru.uoc.es> To: [email protected] Subject: Xarxes de computadors Date: 27 Jun 2003 Content-Type: text Status: RO Aquest es un missatge de correu d’exemple. .Q UIT 4-OK Pop server at dns signing off
c. ¿Por qué los protocolos HTTP, SMTP, POP3, e IMAP son protocolos orientados a conexión (utilizan TCP y no UDP)? Las aplicaciones que usan estos protocolos requieren que todos los datos sean recibidos en su totalidad (sin pérdidas) y en el orden correcto. Además, normalmente el volumen de datos que se va a transferir usando estos protocolos es importante (no serán unos pocos bytes). En estas condiciones, si la aplicación usara UDP, habría que asumir la responsabilidad de las cuestiones relacionadas con la fiabilidad en la transmisión.
Esto es complejo. Es preferible dejarle las cuestiones relacionadas con la fiabilidad al especialista TCP, en lugar de que sea la propia aplicación la que proporcione los mecanismos para obtener la fiabilidad deseada. No obstante, es importante destacar que otras aplicaciones que usan UDP, como DNS, también requieren que los datos lleguen sin pérdidas. Sin embargo, en estos casos, el volumen de datos transferidos suele ser muy pequeño (es habitual tener consulta corta y respuesta corta). De esta forma, la propia aplicación puede asumir fácilmente la responsabilidad de conseguir fiabilidad. 22/01/05 3. Se desea implementar un sistema de retransmisiones en directo de conciertos de música y de su distribución en tiempo real. a. Justificar el protocolo a nivel de transporte que utilizaríais para el envío de datos audio y vídeo. UDP: La simplicidad de UDP hace que sea ideal para aplicaciones que requieren pocos retrasos (por ejemplo aplicaciones en tiempo real). UDP también es ideal para los sistemas que no pueden implementar un sistema tan complejo como TCP. b. Justificar el protocolo que utilizaríais para conseguir que los datos de vídeo y audio lleguen lo mejor posible en tiempo real y sincronizadas. Explicar brevemente el funcionamiento de este protocolo. RTP: El protocolo de transporte de tiempo real (RTP) proporciona facilidades para el transporte de datos en tiempo real. Entre las cuales, encontramos las siguientes: la reconstrucción temporal, la detección de pérdidas, la identificación de contenido y la seguridad. RTP se utiliza normalmente sobre redes de tipo UDP/IP. RTP proporciona un formato a los datos que se tienen que transmitir. En RTP se ha definido un formato que incluye una cabecera en que están los diferentes campos que proporcionan soporte para las necesidades de los datos en tiempo real: Identificación del tipo de datos: sirve para conocer el tipo de datos. Número de secuencia: permite la detección de pérdidas. Sello temporal: posibilita la reconstrucción temporal. c. Justificar el protocolo que utilizaríais para conseguir que en caso de problemas en la red el sistema reaccionara de manera que los datos se continuasen recibiendo con la mejor calidad dentro del posible. Explicar brevemente el funcionamiento de este protocolo. RTCP: RTCP proporciona información sobre la calidad del servicio de los receptores en grupos multicast, y también proporciona el soporte para la sincronización de diferentes flujos de datos de diferentes medios. RTCP lleva a cabo esta tarea definiendo unos paquetes de control que cada uno de los participantes en una sesión RTP envía periódicamente a todos los otros participantes. La información recibida se puede utilizar para el control del rendimiento, para tareas de diagnóstico o para otras funciones.
RTCP da soporte a las funciones siguientes: Provisión de información a la aplicación: RTCP proporciona información a las aplicaciones sobre la calidad de la distribución de sus datos. Cada paquete RTCP contiene informes del emisor y/o del receptor con estadísticas útiles para las aplicaciones. La recepción de esta información sobre la calidad de los datos es útil para las aplicaciones, ya que pueden ir modificando los parámetros de transmisión para mejorar la calidad del servicio. Identificación de la fuente RTP: RTCP lleva a un identificador de nivel de transporte para la fuente RTP que sirve a los receptores para asociar diferentes flujos de datos del mismo participante, pero de sesiones RTP diferentes. Control del intervalo de transmisión RTCP: Para prevenir que el tráfico de control (paquetes RTCP) no sature los recursos de la red, se limita como máximo al 5% del total del tráfico de la sesión. Se tiene que conseguir ajustando el intervalo de tiempo que se deja pasar cuando se envían los paquetes RTCP. Cada participante tiene que conocer el número total de participantes y calcular el intervalo a partir de este dato. Envío de información mínima de control de sesión: Como función opcional, RTCP se puede hacer servir también para enviar cantidades de información pequeñas a todos los participantes de la sesión. d. Justificar el protocolo que utilizaríais para conseguir que el sistema dispusiera de la conexión con unas características mínimas determinadas. Explicar brevemente el funcionamiento de este protocolo. RSVP: Las aplicaciones utilizan RSVP para pedir una calidad de servicio punto a punto para un flujo de datos concreto. RSVP es más útil en los sistemas en que la reserva de calidad de servicio se lleva a cabo recolocando recursos, que en los sistemas en que se efectúa añadiendo recursos. 18/06/05 3. Este es el resultado de la ejecución del programa ‘ethereal' durante un rato en una red local. Cada grupo de bytes numerado corresponde a un paquete IP. (1)
4510 002c 001c 0000 4006 8e2b c191 2d49 d549 2851 0400 006e c7a2 e098 0000 0000 6002 0200 fd07 0000 0204 05b4
(2)
4500 002c 3a35 4000 f906 5b21 d549 2851 c191 2d49 006e 0400 29da 77af c7a2 e099 6012 2238 3b35 0000 0204 05b4 0204
(3)
4510 0028 001d 4000 4006 4e2e c191 2d49 d549 2851 0400 006e c7a2 e099 29da 77b0 5010 7d78 f7b1 0000
(4)
4500 0056 3a36 4000 fb06 58f6 d549 2851 c191 2d49 006e 0400 29da 77b0 c7a2 e099 5018 2238 6ed7 0000 2b4f 4b20 5150 4f50 2028 7665 7273 ...
(11)
4500 004e 3a39 4000 fb06 58fb d549 2851 c191 2d49 006e 0400 #
29da 77fd c7a2 e0a5 5018 2238 6ea1 0000 2b4f 4b20 506f 7020 7365 7276 6572 (12)
4500 0028 3a3a 4000 f906 5b20 d549 2851 c191 2d49 006e 0400 29da 7823 c7a2 e0a5 5011 2238 5272 0000 5272 0000 2078
(13)
4510 0028 0022 4000 4006 4e29 c191 2d49 d549 2851 0400 006e c7a2 e0a5 29da 7824 5010 7d78 f731 0000
(14)
4510 0028 0023 0000 4006 8e28 c191 2d49 d549 2851 0400 006e c7a2 e0a5 29da 7824 5011 7d78 f730 0000
(15)
4500 0028 3a3b 4000 f906 5b1f d549 2851 c191 2d49 006e 0400 29da 7824 c7a2 e0a6 5010 2238 5271 0000 5271 0000 d019
Se pide: a) En los 2 últimos paquetes (el 14 y el 15), decir qué vale cada campo de la cabecera IP y de la cabecera del protocolo de transporte que lleva el paquete. ¿Qué aplicación está usando estos paquetes? Paquete 14: IP: 4 5 10 0028 0023 0000 40 06 8e28 c191 2d49 d549 2851 TCP: 0400 006e c7a2 e0a5 29da 7824 5 011 7d78 f730 0000
versión longitud de la cabecera IP: 5*4 = 20 bytes tipo de servicio longitud total del paquete: 40 bytes identificación del paquete indicadores y posición del fragmento tiempo de vida: 64 protocolo: 6 es TCP checksum dirección IP origen: 193.145.45.73 dirección IP destino: 213.73.40.81 (no hay opciones. Lo sabemos por el número de bytes de cabecera) puerto de origen: 1024. puerto destino: 110 (correo POP) número de secuencia número ACK longitud de la cabecera TCP: 5*4 = 20 bytes reservado y control ventana checksum urgent pointer (no hay opciones. Lo sabemos por el número de bytes de cabecera).
Paquete 15: IP: 4 versión 5 longitud de la cabecera IP: 5*4 = 20 bytes
00 0028 3a3b 4000 f9 06 5b1f d549 2851 c191 2d49 TCP: 006e 0400 29da 7824 c7a2 e0a6 5 010 2238 5271 0000
tipo de servicio longitud total del paquete: 40 bytes identificación del paquete indicadores y posición del fragmento tiempo de vida: 249 protocolo: 6 es TCP checksum dirección IP origen: 213.73.40.81 dirección IP destino: 193.145.45.73 (no hay opciones. Lo sabemos por el número de bytes de cabecera) puerto de origen: 110 (correo POP) puerto destino: 1024 número de secuencia número ACK longitud de la cabecera TCP: 5*4 = 20 bytes reservado y control ventana checksum urgent pointer
5271 0000 d019 sobran! b) Los 3 primeros (del 1 al 3) son la fase de establecimiento de un diálogo TCP. Hacer un diagrama de tiempo dónde se vea el intercambio de segmentos, el número de secuencia y el número reconocido, y en qué estado están los dos extremos en cada momento. De qué tipo de apertura se trata? Apertura activa por parte del cliente
25/06/05 3. Responded de forma razonada a las siguientes preguntas: a) Indicad que protocolo de nivel de transporte y qué servicio de nivel de aplicación hay en el siguiente paquete IP. Indicad también cuáles son los valores de los campos de la cabecera IP y de nivel de transporte que hayas encontrado. ¿A qué corresponden estos datos de nivel de aplicación?
45 00 00 3e 6b 3f 00 00 80 11 e6 e5 c1 91 2d 5c c1 91 38 0b 09 57 00 35 00 2a 6e d8 a0 8b 01 00 00 01 00 00 00 00 00 00 03 77 77 77 08 69 6e 76 65 72 74 69 61 03 63 6f 6d 00 00 01 00 01 Solución: Protocolo UDP. Aplicación DNS. Cabecera IP Versión IP: 4 Longitud cabecera: 5, 20 bytes Tipo de servicio: 0 Longitud total: 62 Id. Paquete: 27455 Flags: 000 Posición: 0 TTL: 128 Protocolo: 17, UDP Checksum: 59109 Dirección origen: 193.145.45.92 Dirección destino: 193.145.56.11 Cabecera UDP: Puerto origen: 2391 Puerto destino: 53 Longitud: 42 Checksum: 28376 Petición DNS para la máquina www.invertia.com (Sólo es necesario que sepan interpretar el bit de query / response de DNS). b) Indicad qué protocolos de nivel de transporte y de aplicación hay en el siguiente fragmento de un paquete IP. Indicad dónde empiezan los datos de nivel de aplicación, escribiendo los valores en hexadecimal de los primeros 15 bytes. 45 00 01 fd 40 ef 40 00 75 06 7c a9 d5 04 82 70 c1 91 2d 5c 00 50 09 59 b3 8d 88 6c 5b d3 8a b7 50 18 43 82 c6 4b 00 00 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 32 34 35 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 69 6d 61 67 65 2f 67 69 66 0d 0a 4c 61 73 74 2d 4d 6f 64 69 66 69 65 64 3a 20 53 75 6e 2c 20 30 37 20 41 70 72 20 32 30 30 32 20 31 38 3a 30 30 3a 35 34 20 47 4d 54 0d 0a 41 63 63 65 70 74 2d 52 61 6e 67 65 73 (Resto datos aplicación) Solución: Protocolos TCP y HTTP (Se sabe por el puerto). Respuesta HTTP, los bytes de datos son: 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b (HTTP/1.1 200 OK, pero esto no hace falta)
c) Dad los valores del máximo de campos posible (traduciéndolos a hexadecimal) de las cabeceras IP y TCP a partir de la siguiente información obtenida con el programa ethereal. 1) 62.189.244.254 192.168.1.92 TCP http > 2398 [ACK] Seq=1 Ack=394 Win=65307 Len=0 Solución: Cabecera IP: Dirección origen: 62.189.244.254 Dirección destino: 192.168.1.92 Protocolo: TCP (06) Cabecera TCP: Puerto origen: 80 (50) Puerto destino: 2398 (09 5e) Seq: 1 (01) Ack: 394 (00 00 01 8a) Win: 65307 (ff 1b) Len: 0 Bit ACK a 1 2) 62.189.244.254 192.168.1.92 TCP http > 2398 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 Solución: Cabecera IP: Dirección origen: 62.189.244.254 Dirección destino: 192.168.1.92 Protocolo: TCP (06) Cabecera TCP: Puerto origen: 80 (50) Puerto destino: 2398 (09 5e) Seq: 0 (00 00 00 00) Ack: 1 (00 00 00 01) Win: 1460 (05 b4) Len: 0 Bit ACK y SYN a 1 14/01/06 3. Supongamos que un equipo descarga un fichero de 2048 bytes de un servidor. La red a la que está conectado el cliente tiene una MTU de 220 bytes. Una vez finalizada la fase de establecimiento de la conexión TCP, empieza la transmisión de datos, del servidor hacia el cliente. Se pide: a) ¿Qué MSS crees que tendrían que anunciar el cliente y el servidor en la fase de establecimiento de conexión? ¿Por qué? ¿Cuál se utilizaría para la comunicación en estas condiciones? MSS del cliente es de 180 bytes (220 bytes MTU menos 40 bytes de las cabeceras IP y TCP), anunciaría ésta.
b) Asumiendo que la MSS utilizada para la comunicación es de 100 bytes y que la ventana de recepción anunciada por el cliente es de 240 bytes, como será el diagrama de transmisión de datos? (Toma como modelo el que se ve en el ejercicio 3 de autoevaluación del módulo “TCP/IP”).
c) Qué pasaría si la aplicación cliente deja de funcionar correctamente y no consume más datos de los que llegan por la red? (Es decir, si deja que se acumulen en el buffer de recepción del socket porque no hace ninguna operación de read sobre el socket). Cómo se comportaría el protocolo TCP en esta situación? Describe cuál sería el intercambio de segmentos que se produciría hasta que se llegue a una situación estacionaria.
Nota: Considera sólo el algoritmo slow start, sin congestion avoidance, y asume que la ventana de congestión, durante la fase de slow start, se incrementa en uno por cada segmento reconocido y no por cada segmento de reconocimiento recibido (ACK). A medida que la ventana de recepción se llenase, quedaría menos espacio libre, y la ventana de recepción que se envía iría disminuyendo el valor. Llegaría un momento en el que la ventana de recepción sería 0, momento en el cual el servidor tendría que dejar de enviar datos.
21/01/06 3. Una empresa dispone de la dirección de red 190.168.100.0/26 y la ha absorbido otra empresa que tiene el rango de direcciones 189.10.10.0/26. Responded de forma breve y razonada a las siguientes preguntas. a. Dibujad un esquema de conexión de las dos redes, indicando las direcciones de todas las interfaces. Podéis suponer que sólo existe una máquina en cada red y que tenéis que añadir un router para conectar las dos redes.
b. Describid la tabla de encaminamiento del router de la red 190.168.100.0/26. Indicad claramente qué líneas son necesarias para poder acceder a la nueva red. ¿Es necesaria la ruta por defecto si no hay conexión a Internet? Justifica tu respuesta.
c. Suponed que se pide un nuevo rango de direcciones con la dirección de red 190.83.0.0 y que se quiere hacer subnetting aplicando una máscara de 24 bits. ¿Cuántas subredes podríamos tener? ¿Cuál sería la primera posible? ¿Y la última? Indicad para las dos subredes, su dirección, su máscara de red, broadcast local y remoto. Esta dirección es de clase B, por tanto se ha aplicado subnetting utilizando 8 bits para definir la porción de subred. Podemos tener 28-2 = 254 subredes. 27/06/06 3. Desde la dirección 193.145.44.190 un internauta se quiere conectar al servidor web de la empresa del ejercicio anterior. Tened en cuenta que el servidor DNS del dominio de la empresa es el que aparece en la red B. Suponed que las madriguera ARP de todos los dispositivos que aparecen en la figura están vacías.
a) Si en uno de los PC de la red A ejecutáramos el “ethereal”, de todas las tramas y paquetes que se generarían desde que se solicita la página web hasta que esta aparece en el navegador del internauta, decid qué veríamos y qué no veríamos. No se vería nada. Todo va hacia la red B. b) Y si el “ethereal” lo ejecutáramos en un PC sito en la red B? Decid qué tramas y qué paquetes veríamos. Las órdenes de las operaciones sería: • Petición de la dirección MAC del servidor DNS. • Respuesta de la dirección MAC del servidor DNS. • Petición de la dirección del servidor web al DNS. • Respuesta DNS con la dirige del servidor web. • Petición de la dirección MAC del servidor Web.
• Respuesta de la dirección MAC del servidor Web. • Establecimiento de la conexión TCP con el servidor web. o Petición de conexión del cliente. o Aceptación de conexión del servidor. o Confirmación conexión del cliente . • Petición HTTP del recurso. • Respondida con la página HTTP del recurso. c) Para este apartado cogéis de la lista del apartado b sólo las tramas que salen del servidor web. Decid para cada trama qué valen las direcciones MAC origen y destino y qué puerta en el campo de datos cada una de estas tramas. Las que traigan paquetes IP, decid qué valen las direcciones IP origen y destino, y qué protocolo de transporte/aplicación traen. Y de los paquetes que traigan segmentos TCP, decid qué valen los puertos TCP origen y destino y qué flags TCP traen activados. Respuesta de la dirección MAC del servidor WEB que viajará en una trama ethernet con los siguientes datos: @MAC/ origen: (WEB) @MAC/ destino: (RB) @IP/ origen: (WEB) @IP/ destino: (RB) Establecimiento conexión TCP con el servidor web Petición de conexión del cliente @MAC origen: (RB) @MAC destino: (WEB) @IP origen: (PCR) @IP destino: (WEB) Puerto TCP destino: 80 Flag SYN activado Aceptación de conexión del servidor @MAC origen: (WEB) @MAC destino: (RB) @IP origen: (WEB) @IP destino: (PCR) TCP: Flags SYN, ACK activados Confirmación conexión del cliente @MAC origen: (RB) @MAC destino: (WEB) @IP origen: (PCR) @IP destino: (WEB) Puerto TCP destino: 80 Flag ACK activado Sólo falta pedir el recurso con el protocolo HTTP, puesto que tenemos la conexión establecida. @MAC origen: (RB) @MAC destino: (WEB)
@IP origen: (PCR) @IP destino: (WEB) Puerto TCP destino: 80 HTTP: GET / HTTP/1.1 La respuesta del servidor seria el recurso, y podría ser @MAC origen: (WEB) @MAC destino: (RB) @IP origen: (WEB) @IP destino: (PCR) HTTP: HTTP/1.1 200 OK (El resto sería el recurso) 01/07/06 3.- Se ha utilizado un resolvedor, como nslookup o dig, para consultar un servidor DNS sobre la dirección www.linux.org, obteniendo la siguiente salida:
• Interpreta razonadamente las diferentes secciones de la salida anterior, explicando los diferentes campos e información existente. En la cabecera vemos que los flags que están activados son qr (es una consulta), aa (es autoritativa), rd (el cliente ha solicitado respuesta en modo recursivo) ra (recursion available, es decir, el servidor soporta el modo recursivo). Sección pregunta Pido la IP asociada a www.linux.org (tipo de registro A) Sección respuesta Devuelve la IP asociada a www.linux.org, que es 198.182.196.56 Sección autoridad Devuelve dos servidores con autoridad para responder a la consulta, que son ns0.aitcom.net y ns.invlogic.com
Sección adicional Nos da las IP asociadas a los servidores con autoridad para resolver la consulta original. Detalla los pasos que serían necesarios para obtener la dirección IP de www.linux.org. Realiza las suposiciones que creas convenientes.
•
Como la consulta es de tipo recursivo, se creará un mensaje de pregunta, sobre un registro tipo A de www.linux.org. El usuario enviará a su DNS una pregunta www.linux.org. Esta consulta irá al revolvedor de .org, que preguntará por www.linux.org. La respuesta contendrá la dirección del DNS que sabe sobre linux.org. El DNS del usuario, preguntará entonces por www.linux.org al servidor de linux (dentro de org). Este servidor debe responder entonces por www.linux.org. 13/01/07 3. Contesta de forma razonada y breve a las siguientes preguntas sobre el servicio DNS: ¿Qué es un archivo de zona y cuál es su utilidad? Un archivo de zona es la base de datos del servidor con autoridad de una zona dónde se almacena toda la información DNS en lo referente a aquella zona. ¿Un servidor DNS puede responder (resolver nombres) a peticiones realizadas desde fuera de la LAN a la que está conectado? Sí. Además de las peticiones realizadas desde dentro de LAN, también recibirá peticiones de los otros equipos externos de la LAN, pero de la misma la zona. Estas peticiones en principio serán pidiendo direcciones de máquinas internas (que devolverá con respuestas con autoridad) y externas a la zona (que si el servidor actúa de forma recursiva, reenviará la petición al servidor “superior” a la jerarquía. Al recibir el resultado lo devolverá al equipo que ha hecho la petición como respuesta sin autoridad y si tiene memoria caché guardará el resultado por responder a posibles consultas posteriores). Además de los equipos de la zona pero de fuera la LAN, el servidor también recibirá peticiones externas sobre direcciones de los nodos de su zona, devolviendo respuestas con autoridad. ¿Cuál es el nombre del proceso de configuración desde un DNS primario al DNS secundario? En el argot DNS, refrescar los datos quiere decir actualizarlas haciendo consultas periódicas. Normalmente, hay un equipo que actúa como servidor primario y guarda los ficheros originales de la base de datos correspondiente a la zona, es decir, aquellos que el administrador ha de actualizar directamente cada vez que haya una modificación en sus nodos. Los otros servidores actúan como servidores secundarios y actualizan automáticamente sus bases de datos a partir de la del primario; por ejemplo, mediante consultas periódicas para saber si ha habido #
algún cambio. Así, si un servidor primario está temporalmente inaccesible (por una caída de la red, del mismo servidor, etc.), los clientes pueden enviar sus consultas a uno de los servidores secundarios. ¿Qué es la resolución inversa? ¿Qué tipo de registro DNS proporciona esta información? La resolución inversa es la obtención del nombre de un equipo a partir de su dirección. (Normalmente con DNS a partir de un nombre de equipo y un tipo de registro se obtiene su valor). DNS proporciona una operación para efectuar consultas inversas; es decir, dado un registro, devuelve el nombre de dominio a qué corresponde. Pero esta operación puede ser muy costosa para el servidor, y no se puede garantizar que la respuesta sea única o completa, porque puede haber otros servidores que contengan información relacionada. Los nombres del dominio IN-ADDR.ARPA pueden tener hasta cuatro etiquetas, que representan los valores posibles de los bytes de una dirección IP en decimal, entre 0 y 255. De estas etiquetas, la de nivel más alto corresponde al primer byte de la dirección, y la de nivel más bajo, al último byte. Así, se puede tener una estructura de zonas y autoridades delegadas semejante a la del resto de dominios. El registro de tipo PTR, sirve para relacionar un alias con un nombre de dominio. Un uso habitual de los registros PTR es facilitar la obtención del nombre de un ordenador a partir de su dirección mediante el dominio especial IN-ADDR.ARPA. Un nombre del dominio IN-ADDR.ARPA que tenga las cuatro etiquetas numéricas corresponderá a la dirección de un ordenador, y se le asociará un registro PTR que apunte al nombre de este ordenador. Así se puede obtener el nombre de un equipo a partir de su dirección, haciendo una petición (no inversa) del valor del tipo de registro PTR de un nombre de equipo del dominio IN-ADDR.ARPA. El dominio IN-ADDR.ARPA también se puede usar para obtener los valores de otros tipos de registro (p.e. NS) a partir de la dirección. Ejemplo: 99.11.32.128.IN-ADDR.ARPA. PTR servidor.acme.com. 46.52.128.IN-ADDR.ARPA. NS servidor.acme.com. NS servidor2.acme.com. ¿Qué son los registros MX y cuál es su función? MX (Mail eXchanger): nombre de un servidor de correo electrónico para un dominio. El valor tiene dos subcampos, el primero es un número que representa una preferencia (cuanto más pequeño es el número, más preferencia) y el segundo es el nombre de un ordenador que está dispuesto a aceptar mensajes destinados al dominio correspondiente al registro. El estándar RFC 974 especifica la manera como se han de utilizar los registros MX para encaminar un mensaje de correo electrónico dada la dirección del destinatario (por ejemplo, [email protected]). De esta dirección se separa la parte correspondiente al dominio de correo (uoc.edu), se consulta el sistema DNS para saber qué servidores aceptan correo para este dominio y se escoge
uno teniendo en cuenta su preferencia. Si la comunicación con este servidor no tiene éxito, se intenta con los otras por orden de preferencia. Si no hay ningún registro MX asociado al dominio, se entiende que sólo tiene un servidor de correo: el ordenador que tenga por nombre el del dominio. Un ordenador A quiere acceder a un servidor web externo www.mosaic.com. Explica los pasos necesarios a nivel DNS (capa aplicación) para ello considerando que el servidor DNS de su intranet está configurado en modo recursivo y que su caché está vacía. Haz las suposiciones que creas convenientes. A -> Servidor DNS (A) - Petición DNS (Dirección www.mosaic.com) Servidor DNS (A) -> Servidor DNS (superior) => Petición DNS (Dirección www.mosaic.com) Servidor DNS (superior) -> Servidor DNS (A) => Respuesta DNS (Dirección www.mosaic.com) Servidor DNS (A) -> A=> Respuesta DNS (Dirección www.mosaic.com) A ->www.mosaic.com => Conexión TCP A ->www.mosaic.com => Petición HTTP www.mosaic.com -> A => Respuesta HTTP (página web) 17/01/07 3. Describid las siguientes tramas capturadas con Ethereal. ¿De qué tipo de transferencia se trata? ¿Qué proceso se sigue? Razonadlo.
Se trata de una consulta a una página web mediante el protocolo HTTP. Las dos primeras tramas son una petición de resolución de nombre (DNS) de www.google.es, junto con su respuesta. El DNS es 192.168.0.1 Las tramas de la 3 a la 5 representan una conexión entre la máquina 192.168.0.131 y la 66.102.9.99 siguiendo el protocolo three-way handshake, en el puerto 80, es decir HTTP. A continuación se cierra la conexión y se vuelve a conectar con la misma dirección, esta vez en el puerto local 4561, en lugar de 4559. La trama 12 es la petición HTTP 1.1 mediante el comando GET. A continuación hay una transferencia de la página / desde el servidor 66.102.9.99 a la máquina 192.168.0.131 (tramas 13 a 16) con éxito (trama 17). 20/01/07
3. La siguiente captura hecha con Ethereal muestra los segmentos generados para el envío, mediante SMTP, de un mensaje de correo electrónico con un solo destinatario. Indicad qué mensaje SMTP creéis que habrán intercambiado entre el cliente y el servidor de correo, así como en qué segmento TCP creéis que habrá sido transportado. Nota: Para referenciar los segmentos TCP, podeis utilizar la numeración que hay en la izquierda
1. 147.83.35.5.49565 > 147.83.33.10.25: S 2423164120:2423164120(0) win 5840 2. 147.83.33.10.25 > 147.83.35.5.49565: S 3218201576:3218201576(0) ack 2423164121 win 5792 3. 147.83.35.5.49565 > 147.83.33.10.25: . ack 1 win 12
Conexión establecida
4. 147.83.33.10.25 > 147.83.35.5.49565: P 1:83(82) ack 1 win 46 5. 147.83.35.5.49565 > 147.83.33.10.25: . ack 83 win 12 220 roura.uoc.edu ESMTP Sendmail 8.13.8/8.13.8; Wed, 8 Nov 2006 22:04:06 +0100 6. 147.83.35.5.49565 > 147.83.33.10.25: P 1:18(17) ack 83 win 12 7. 147.83.33.10.25 > 147.83.35.5.49565: . ack 18 win 46
HELO uoc.edu
8. 147.83.33.10.25 > 147.83.35.5.49565: P 83:172(89) ack 18 win 46 9. 147.83.35.5.49565 > 147.83.33.10.25: . ack 172 win 12 250 roura.uoc.edu Hello [email protected] [147.83.35.5], pleased to meet you 10. 147.83.35.5.49565 > 147.83.33.10.25: P 18:48(30) ack 172 win 12 11. 147.83.33.10.25 > 147.83.35.5.49565: . ack 48 win 46
MAIL FROM: [email protected]
12. 147.83.33.10.25 > 147.83.35.5.49565: P 172:214(42) win 46 13. 147.83.35.5.49565 > 147.83.33.10.25: . ack 214 win 12 250 2.1.0 [email protected]... Sender ok 14. 147.83.35.5.49565 > 147.83.33.10.25: P 48:76(28) win 12 15. 147.83.33.10.25 > 147.83.35.5.49565: . ack 76 win 46
RCPT TO: [email protected]
16. 147.83.33.10.25 > 147.83.35.5.49565: P 214:259(45) win 46 17. 147.83.35.5.49565 > 147.83.33.10.25: . ack 259 win 12 250 2.1.5 [email protected]... Recipient ok 18. 147.83.35.5.49565 > 147.83.33.10.25: P 76:82(6) ack 259 win 12 19. 147.83.33.10.25 > 147.83.35.5.49565: . ack 82 win 46
DATA
20. 147.83.33.10.25 > 147.83.35.5.49565: P 259:309(50) ack 82 win 46 21. 147.83.35.5.49565 > 147.83.33.10.25: . ack 309 win 12 354 Enter mail, end with "." on a line by itself 22. 147.83.35.5.49565 > 147.83.33.10.25: P 82:117(3) win 12 23. 147.83.33.10.25 > 147.83.35.5.49565: . ack 117 win 46
Cabecera: hola datos útiles .
24. 147.83.33.10.25 > 147.83.35.5.49565: P 309:365(56) win 46 25. 147.83.35.5.49565 > 147.83.33.10.25: . ack 365 win 12
250 2.0.0 kA8L46sA018180 Message accepted for delivery 26. 147.83.35.5.49565 > 147.83.33.10.25: P 117:123(6) ack 365 win 12 27. 147.83.33.10.25 > 147.83.35.5.49565: . ack 123 win 46
QUIT
28. 147.83.33.10.25 > 147.83.35.5.49565: P 365:411(46) win 46 29. 147.83.35.5.49565 > 147.83.33.10.25: . ack 411 win 12
221 2.0.0 roura.uoc.edu closing connection
30. 147.83.33.10.25 > 147.83.35.5.49565: F 411:411(0) ack 123 win 46 31. 147.83.35.5.49565 > 147.83.33.10.25: F 123:123(0) ack 412 win 12 32. 147.83.33.10.25 > 147.83.35.5.49565: . ack 124 win 46
Enunciados Preguntas nº 4 10/01/04 4. ¿Por qué es importante la distinción entre transmisiones interactivas y transmisiones de datos de gran volumen en el nivel de transporte? Comentad el diferente comportamiento del protocolo TCP ante las dos situaciones. TCP se comportará de diferente manera en las dos situaciones, con el fin de aprovechar mejor las prestaciones de la red. En transmisiones interactivas, se generan paquetes pequeños que hacen falta que lleguen con un cierto ritmo. Los reconocimientos retardados y el algoritmo de Tagle permiten que la transmisión no se atasque pero, a la vez, que la eficiencia de la red no baje mucho. En transmisiones de gran volumen, se tiene que vigilar que no se saturen los encaminadores intermedios. Por eso, se implementa un protocolo de ventana, que se puede combinar con el slow-start y el congestion-avoidance. 17/01/04 4. Contestad razonadamente a las siguientes cuestiones: a) Durante el envío de un datagrama IP entre dos puntos de Internet a través de diferentes redes Ethernet, ¿cuántas direcciones origen y destino diferentes se transportarán en el datagrama IP y en las tramas Ethernet? Las direcciones IP, en una situación normal, serán siempre las mismas. Las direcciones MAC irán cambiando dependiendo del tramo de red que el datagrama recorra. La primera dirección MAC origen será la del host origen y la última dirección MAC destino será la del host destino. Las otras direcciones MAC que tome cada trama Ethernet dependerán del número de enrutadores que atraviese el datagrama. Para cada par de enrutadores que se comuniquen, la dirección origen y destino de cada trama corresponderán a la dirección MAC del router origen y destino. b) ¿Qué finalidad tiene el estado de TIME_WAIT dentro del diagrama de estados de TCP? El estado TIME_WAIT pretende controlar el efecto que tendría la pérdida del último ACK intercambiado entre dos máquinas conectadas. Sin ese ACK, la máquina que no lo recibe no daría por finalizada la conexión y en algún momento
retransmitiría su último segmento enviado para recibir la confirmación (lo enviaría cuando su timeout de transmisión expirara). El equipo que ha enviado ese último ACK debe estar preparado para procesar esa eventual retransmisión en caso de ser necesario, y por eso no debe dar la conexión por cerrada definitivamente antes de esperar un tiempo prudencial, esperando que el posible timeout de la otra máquina expire. c) ¿Cuántos procesos SMTP emisores y receptores se verán involucrados en el envío de un mensaje de correo electrónico procedente de un equipo que tiene configurado como servidor SMTP el de su ISP y destinado a una máquina de un dominio ajeno al ISP? Procesos emisores: El cliente de correo desde el que se redacta y envía el mensaje y el del servidor de SMTP del ISP. Procesos receptores: El del ISP y el del servidor de correo del dominio ajeno al que se envía el mensaje. 24/01/04 4. Tenemos un sistema donde hay un cliente (navegador), un proxy y un servidor HTTP/1.0. El servidor se llama www.servidor.com. El navegador tiene que obtener una página web protegida (requiere autenticación) del servidor llamada pagina.htm, dentro del directorio raíz del servidor. La página web contendrá un formulario, y una vez cubierto el formulario se enviará el contenido de sus respuestas hacia el servidor con el método POST ejecutando el programa del servidor alta_bd.exe. Enumerad los pasos que se seguirán en la comunicación anterior. Se tiene que incluir todos los métodos y mensajes HTTP, los campos más importantes, los códigos de retorno de las peticiones que devuelve el servidor y las URI de las peticiones que se intercambian el navegador, proxy y el servidor. El proxy sólo hace la función de retransmisión de las peticiones, y las respuestas del servidor siempre serán positivas.
a) El cliente envía una petición GET con el URL del recurso GET http://www.servidor.com/pagina.htm HTTP/1.0 al proxy. b) El proxy establece una conexión como cliente con el servidor www.servidor.com y le envía la petición GET /pagina.htm HTTP/1.0 al servidor www.servidor.com. c) El servidor detecta que el recurso tiene el acceso restringido y envía una respuesta con el código 401 y el campo WWW-Authenticate hacia el proxy. El proxy retransmite la misma respuesta hacia el navegador. d) El cliente o navegador pide al usuario que introduzca un nombre y una contraseña para acceder al recurso pagina.htm.
e) El cliente o navegador utiliza el campo Authorization y envía una nueva petición GET con el URL Get http://www.servidor.com/pagina.htm HTTP/1.0 con este campo Authorization hacia el proxy. El proxy envía hacia el www.servidor.com la petición GET /pagina.htm HTTP/1.0. El proxy actúa como cliente del www.servidor.com. f) El servidor www.servidor.com verifica los datos, y si son válidos, envía una respuesta 200 con el contenido de la página pagina.htm. Si no son válidos, envía la respuesta 401 hacia el proxy. Una vez el proxy ha recibido la respuesta (200 ó 401) la reenvía hacia el cliente o navegador. g) El cliente o navegador enviará una petición POST con el URL POST http://www.servidor.com/alta_bd.exe HTTP/1.0 con el contenido del formulario codificado hacia el proxy. El proxy retransmitirá POST /alta_bd.exe HTTP/1.0 hacia el servidor www.servidor.com. h) El servidor devolverá el código 201 hacia el proxy, y el proxy lo retransmitirá hacia el cliente o navegador.
