You are on page 1of 96

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 Broadcast remoto


172.20.0.64 172.20.0.127
172.20.0.128 172.20.0.191
172.20.0.192 172.20.0.255
… …
172.20.255.128 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

Hexadecimal Significado
Versión IP (4 bits) 4 Es la versión 4 del protocolo IP.
Longitud cabecera (4 bits) 5 La cabecera tiene 5 palabras de 4
bytes, es decir, 20 bytes.
Tipo de servicio (8 bits) 00
Longitud total del paquete (16 bits) 0030 La longitud del paquete es de 48 bytes.
Identificación del paquete (16 bits) 2521 Si el paquete se fragmenta este
identificador es el mismo para todos los
fragmentos.
Flags (3 bits) 40 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.
Posición de este fragmento (13 bits) 00 Está en la posición 0, lógicamente, ya
que no se puede fragmentar.
TTL (tiempo de vida, 8 bits) 80 Puede pasar por 128 enrutadores antes
de ser descartado.
Protocolo (8 bits) 06 Encapsula el protocolo TCP
Checksum (16 bits) 04b5
IP Origen (32 bits) c1.90.2c.ab La dirección IP origen es 193.144.44.171
IP Destino (32 bits) c1.90.21.26 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 112.3.4.5 08:30:2a:11:9b:32
H2 112.5.6.2 a8:0a:02:1e:a7:f2
Router 112.8.9.10 b8:05:03:1d:f7:a2
147.12.253.22 45:44:43:42:00:00
PC 147.15.18.23 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 Máscara Encaminador Interfaz
112.8.9.10 255.255.255.255 127.0.0.1 Loopback
147.12.253.22 255.255.255.255 127.0.0.1 Loopback
127.0.0.0 255.0.0.0 127.0.0.1 Loopback
112.0.0.0 255.0.0.0 112.8.9.10 Ether1
147.0.0.0 255.0.0.0 147.12.253.22 Ether0
255.255.255.255 255.255.255.255 112.8.9.10 Ether1
0.0.0.0 0.0.0.0 147.12.253.22 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 las 5 subredes serian:
·/*·*/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.

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
<nop,nop,timestamp 10193136 78967419>
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


<nop,nop,timestamp 78967421 10193136>
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 > 147.83.32.82.21: . ack 339 win 5840
<nop,nop,timestamp
10193142 78967421>
0x0000: 4510 0034 c21a 4000 4006 0f40 9353 2261 E..4..@.@..@.S"a
0x0010: 9353 2052 af26 0015 2cb7 bf08 61a0 fc51 .S.R.&..,...a..Q
0x0020: 8010 16d0 7ce2 0000 0101 080a 009b 88f6 ....|...........
0x0030: 04b4 f27d ...}
16:33:58.423561 IP 147.83.32.82.21 > 147.83.34.97.44838: P 339:363(24) ack 81 win 5792
<nop,nop,timestamp 78967424 10193142>
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 > 147.83.32.82.21: . ack 363 win 5840
<nop,nop,timestamp
10193142 78967424>
0x0000: 4510 0034 c21b 4000 4006 0f3f 9353 2261 E..4..@.@..?.S"a
0x0010: 9353 2052 af26 0015 2cb7 bf08 61a0 fc69 .S.R.&..,...a..i
0x0020: 8010 16d0 7cc7 0000 0101 080a 009b 88f6 ....|...........
0x0030: 04b4 f280 ....

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 <mss 1460,nop,nop,sackOK> (DF)
0x0000 4500 0030 2868 4000 8006 8c9b c191 2dad E..0(h@.......-.
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 <mss 1460> (DF)
0x0000 4500 002c d46b 4000 3506 2b9c d504 8181 E..,.k@.5.+.....
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..((k@.......-.
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..(.t@.5.+.....
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..(..@....9..-.
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..(..@....8..-.
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..(.u@.5.+.....
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 y "$ /%& del
primer paquete.

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 Dir. IP Máscara


A (FTP) 130.1.0.10 255.255.0.0
B 130.1.0.11 255.255.0.0
Router U 130.1.0.1 255.255.0.0

La red 11.1.0.0/16 es una clase A en la que se hace subnetting.

Máquina Dir. IP Máscara


E 11.1.0.10 255.255.0.0
F 11.1.0.11 255.255.0.0
Máquina Dir. IP Máscara
Router U 11.1.0.1 255.255.0.0

Máquina Dir. IP Máscara


E 11.1.0.10 255.255.0.0

La red 11.2.0.0/16 es una clase A también con subnetting.

Máquina Dir. IP Máscara


C 11.2.0.10 255.255.0.0
D (WWW) 11.2.0.11 255.255.0.0
Router U 11.2.0.1 255.255.0.0

La red 11.3.0.0/16 es una clase A con subnetting.

Máquina Dir. IP Máscara


G 11.3.0.10 255.255.0.0
H (DNS) 11.3.0.11 255.255.0.0
Router U 11.3.0.1 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 Máscara Encaminar por


130.1.0.0 255.255.0.0 130.1.0.1
11.1.0.0 255.255.0.0 11.1.0.1
11.2.0.0 255.255.0.0 11.2.0.1
11.3.0.0 255.255.0.0 11.3.0.1
0.0.0.0 0.0.0.0 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 Máscara Encaminar por


130.1.0.0 255.255.0.0 195.10.1.1
11.0.0.0 255.0.0.0 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 11.1.0.0 (pasamos a la siguiente
entrada).
· 11.1.0.10 AND 255.255.0.0 = 11.1.0.0

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 three-
handshake) 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 0x000f
QR 0
OPCODE 0
AA -
TC -
RD 1
RA -
RCODE -
QDCOUNT 1
ANCOUNT 0
NSCOUNT 0
ARCOUNT 0
Pregunta: QNAME campus.uoc.es
QTYPE A
QCLASS 1
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 0x000f (lo mismo que la
QUERY)
QR 1
OPCODE 0
AA ? (depende de quién
conteste)
TC 0
RD -
RA 1
RCODE 0
QDCOUNT 0 (o 1)
ANCOUNT 1 (o más)
NSCOUNT 0 (o más)
ARCOUNT 0 (o más)

Respuesta: Dirección IP solicitada

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 Address MAC


PC1 @IP-PC1 11:11:11:11:11:11
PC2 @IP-PC2 22:22:22:22:22:22
PC3 @IP-PC3 33:33:33:33:33:33
PC4 @IP-PC4 44:44:44:44:44:44
Router dept. X @IP-RX 00:00:00:00:00:11
Router dept. Y @IP-RY 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 Máscara Encaminado por


12.20.45.1 255.255.255.255 127.0.0.1
150.23.10.1 255.255.255.255 127.0.0.1
127.0.0.0 255.255.255.255 127.0.0.1
* 12.20.45.1
150.23.10.0 255.255.255.128 150.23.10.1
255.255.255.255 255.255.255.255 150.23.10.1
0.0.0.0 0.0.0.0 * *

*: 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 Longitud Posición MF


1 1500 0 1.
2 1500 1480 1.
3 1500 2960 1.
4 1500 4440 1.
5 300 5920 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 Máscara Encaminador Interfaz


192.168.100.33 255.255.255.255 127.0.0.1 loopback
192.168.100.65 255.255.255.255 127.0.0.1 loopback
192.168.100.97 255.255.255.255 127.0.0.1 loopback
255.255.255.255 255.255.255.255 192.168.100.33 ether0
192.168.100.32 255.255.255.224 192.168.100.33 ether0
127.0.0.0 255.0.0.0 127.0.0.1 loopback
192.168.100.64 255.255.255.224 192.168.100.65 ether1
192.168.100.96 255.255.255.224 192.168.100.97 ether2
0.0.0.0 0.0.0.0 X.Y.Z.K 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.32.0/19 sede A


132.175.01000000.0 132.175.64.0/19 sede B
132.175.01100000.0 132.175.96.0/19 sede C
132.175.10000000.0 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 132.175.32.1/19 a 132.175.63.254/19


Sede B 132.175.64.1/19 a 132.175.95.254/19
Sede C 132.175.96.1/19 a 132.175.127.254/19
Sede D 132.175.128.1/19 a 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 Máscara Encaminador Interfaz


132.47.4.0 255.255.252.0 132.47.4.1 eth0
132.47.8.0 255.255.252.0 132.47.8.1 eth1
132.47.12.0 255.255.252.0 132.47.12.1 eth2
0.0.0.0 0. 0.0.0 1 0.0.0.2 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.

45 00 00 30 2a c4 40 00 80 06 c9 81 51 2b 08 28 E..0*.@.....Q+.(
(1) 9c 9a 10 95 04 5a 00 15 1f e2 9b 84 00 00 00 00 .....Z..........
70 02 20 00 9c c7 00 00 02 04 05 b4 01 01 04 02 p...............

45 00 00 30 00 00 40 00 35 06 3f 46 9c 9a 10 95 E..0..@.5.?F....
(2) 51 2b 08 28 00 15 04 5a 6b 05 0c 3f 1f e2 9b 85 Q+.(...Zk..?....
70 12 05 b4 3f be 00 00 02 04 05 b4 01 01 04 02 p...?...........

45 00 00 28 2a c5 40 00 80 06 c9 88 51 2b 08 28 E..(*.@.....Q+.(
(3) 9c 9a 10 95 04 5a 00 15 1f e2 9b 85 6b 05 0c 40 .....Z......k..@
50 10 22 38 4f fe 00 00 P."8O...

45 00 00 3c 0a 68 40 00 35 06 34 d2 9c 9a 10 95 E..<.h@.5.4.....
(4) 51 2b 08 28 00 15 04 5a 6b 05 0c 40 1f e2 9b 85 Q+.(...Zk..@....
50 18 16 d0 04 3b 00 00 32 32 30 20 28 76 73 46 P....;..220 (vsF
54 50 64 20 32 2e 30 2e 31 29 0d 0a TPd 2.0.1)..

45 00 00 28 2a c6 40 00 80 06 c9 87 51 2b 08 28 E..(*.@.....Q+.(
(5) 9c 9a 10 95 04 5a 00 15 1f e2 9b 85 6b 05 0c 54 .....Z......k..T
50 10 22 24 4f fe 00 00 P."$O...

45 00 00 38 2a c9 40 00 80 06 c9 74 51 2b 08 28 E..8*.@....tQ+.(
(6) 9c 9a 10 95 04 5a 00 15 1f e2 9b 85 6b 05 0c 54 .....Z......k..T
50 18 22 24 c8 09 00 00 55 53 45 52 20 61 6e 6f P."$....USER ano
6e 79 6d 6f 75 73 0d 0a nymous..

45 00 00 28 0a 6a 40 00 35 06 34 e4 9c 9a 10 95 E..(.j@.5.4.....
(7) 51 2b 08 28 00 15 04 5a 6b 05 0c 54 1f e2 9b 95 Q+.(...Zk..T....
50 10 16 d0 5b 42 00 00 P...[B..
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:

45 00 00 3c 0a 68 40 00 35 06 34 d2 9c 9a 10 95
(4) 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

45 00 00 38 2a c9 40 00 80 06 c9 74 51 2b 08 28
(6) 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 Máscara Gateway Interfaz


155.100.32.0 255.255.224.0 155.100.32.1 Eth0
155.100.64.0 255.255.224.0 155.100.64.1 Eth1
155.100.96.0 255.255.224.0 155.100.96.1 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 Máscara Broadcast Local Broadcast Remoto


120.32.0.0 255.224.0.0 255.255.255.255 120.63.255.255
120.64.0.0 255.224.0.0 255.255.255.255 120.95.255.255
120.96.0.0 255.224.0.0 255.255.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 Máscara Salida


120.32.0.0 255.224.0.0 Eth 0
120.64.0.0 255.224.0.0 Eth 1
120.96.0.0 255.224.0.0 Eth 2
0.0.0.0 0.0.0.0 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:

Características de la Red
Dirección IP Máscara Clase Broadcast remoto Broadcast local
Recursos humanos 200.200.120.32 255.255.255.224 C 200.200.120.63 255.255.255.255
Logística 200.200.120.64 255.255.255.224 C 200.200.120.95 255.255.255.255
Comercial 200.200.120.96 255.255.255.224 C 200.200.120.127 255.255.255.255

. Dimensionamiento de los PCs


64Número máximo de PCs Rango de direcciones IP útiles asignables a PCs
5
Recursos humanos 2 -2= 30 200.200.120.33 - 200.200.120.62
5
Logística 2 -2= 30 200.200.120.65 - 200.200.120.94
5
Comercial 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.
Tabla de encaminamiento R1
Dirección IP Máscara Encaminador Interface
200.200.120.32 255.255.255.224 200.200.120.62 eth0
200.200.120.64 255.255.255.224 200.200.120.94 eth1
200.200.120.96 255.255.255.224 200.200.120.126 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:

Características de la Red
Dirección IP Máscara Clase Broadcast remoto Broadcast local
Municipio A 196.220.156.128 255.255.255.224 C 196.220.156.159 255.255.255.255
Municipio B 196.220.156.96 255.255.255.224 C 196.220.156.127 255.255.255.255
Municipio C 196.220.156.64 255.255.255.224 C 196.220.156.95 255.255.255.255

. Dimensionamiento de los PCs


64Número máximo de PCs Rango de direcciones IP útiles asignables a PCs
Municipio A 29 196.220.156.130 a 196.220.156.158
Municipio B 29 196.220.156.98 a 196.220.156.126
Municipio C 29 196.220.156.66 a 196.220.156.94

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.

Tabla de encaminamiento R1
Dirección IP Máscara Encaminador Interface
196.220.156.128 255.255.255.224 196.220.156.129 eth0
196.220.156.96 255.255.255.224 196.220.156.97 eth1
196.220.156.64 255.255.255.224 196.220.156.65 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 Longitud Posición MF


1 1500 0 1
2 1500 1480 1
3 1500 2960 1
4 1500 4440 1
5 1170 5920 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:

PC1
Dirección Máscara Direccionador
192.168.5.0 255.255.255.0 192.168.5.1
192.168.7.0 255.255.255.0 192.168.5.3

PC2
Dirección Máscara Direccionador
192.168.5.0 255.255.255.0 192.168.5.2
192.168.9.0 255.255.255.0 192.168.5.3

R1
Dirección Máscara Direccionador
192.168.5.0 255.255.255.0 192.168.5.3
192.168.7.0 255.255.255.0 192.168.9.2
192.168.9.0 255.255.255.0 192.168.9.1

R2
Dirección Máscara Direccionador
192.168.5.0 255.255.255.0 192.168.9.1
192.168.7.0 255.255.255.0 192.168.7.2
192.168.9.0 255.255.255.0 192.168.9.2

PC3
Dirección Máscara Direccionador
0.0.0.0 0.0.0.0 192.168.7.2
192.168.9.0 255.255.255.0 192.168.7.1

PC4
Dirección Máscara Direccionador
192.168.5.0 255.255.255.0 192.168.9.1
192.168.7.0 255.255.255.0 192.168.9.2
192.168.9.0 255.255.255.0 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 Dirección subred Dirección broadcast subred
a.b.c.001 00001 - a.b.c.001 11110 255.255.255.32 255.255.255.63
(a.b.c.33 - a.b.c.62)
a.b.c.110 00001 - a.b.c.110 11110 255.255.255.192 255.255.255.223
(a.b.c.193 - a.b.c.222)

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 Rango Máscara Broadcast Remoto


190.168.32.0 190.168.32.1 -190.168.63.254 255.255.448.0 190.168.63.255
190.168.64.0 190.168.64.1 -190.168.95.254 255.255.448.0 190.168.95.255
190.168.96.0 190.168.96.1 -190.168.127.254 255.255.448.0 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ón@uoc.edu
$ " TONO: dirige2@uoc/.edu
FECHA
<contenido del mensaje, incluyente cabeceras *MIME, separando la
cabecera del cuerpo con una línea en blanco (*CR-*CR)>
.
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 Máscara Encaminador Interfície


200.150.100.65 255.255.255.255 127.0.0.1 loopback
200.150.100.129 255.255.255.255 127.0.0.1 loopback
81.43.8.40 255.255.255.255 127.0.0.1 loopback
127.0.0.0 255.0.0.0 127.0.0.1 loopback
200.150.100.64 255.255.255.192 200.150.100.65 eth0
200.150.100.128 255.255.255.192 200.150.100.129 eth1
81.0.0.0 255.0.0.0 81.43.8.40 eth2
0.0.0.0 0.0.0.0 81.1.1.1 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 <mss 1460>


193.144.22.100.4379 > 193.144.22.80.21: S 0:0(0) ack 1 win 8192 <mss 1460>
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 Equipo 22.100


1 CLOSE -> SYN_SENT 1
2 2 LISTEN -> SYN_RCVD
3 SYN_SENT -> ESTABLISHED 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) 45 00 E.
0010 00 3c 6f a6 00 00 40 01 1e bb c0 a8 00 83 3e 25 .<o...@. ......>%
0020 ed 0f 08 00 bb 45 03 00 8f 16 61 62 63 64 65 66 .....E.. ..abcdef
0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 ghijklmn opqrstuv
0040 77 61 62 63 64 65 66 67 68 69 wabcdefg hi

(2) 45 00 E.
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 .....E.. ..abcdef
0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 ghijklmn opqrstuv
0040 77 61 62 63 64 65 66 67 68 69 wabcdefg hi
(3) 45 00 E.
0010 00 34 6f 12 40 00 40 06 be bd c0 a8 00 83 42 66 .4o.@.@. ......Bf
0020 09 63 11 cf 00 50 88 6f ae f7 00 00 00 00 80 02 .c...P.o ........
0030 ff ff 18 9c 00 00 02 04 05 b4 01 03 03 02 01 01 ........ ........
0040 04 02 ..

(4) 45 00 E.
0010 00 2c 07 65 00 00 f0 06 b6 72 42 66 09 63 c0 a8 .,.e.... .rBf.c..
0020 00 83 00 50 11 cf 4e 6a f5 e1 88 6f ae f8 60 12 ...P..Nj ...o..`.
0030 1f fe dd 58 00 00 02 04 05 ac ...X.... ..

(5) 45 00 E.
0010 00 28 6f 13 40 00 40 06 be c8 c0 a8 00 83 42 66 .(o.@.@. ......Bf
0020 09 63 11 cf 00 50 88 6f ae f8 4e 6a f5 e2 50 10 .c...P.o ..Nj..P.
0030 ff ff 15 0c 00 00 ......

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 Número de 16 bits
QR 0
OPCODE 0
AA -
TC -
RD 1
RA -
RCODE -
QDCOUNT 1
ANCOUNT 0
NSCOUNT 0
ARCOUNT 0

Pregunta: QNAME www.dept_informatica.uac.edu


QTYPE 1 (A)
QCLASS 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 Mismo Número de 16 bits


QR 1
OPCODE 0
AA ? (depende)
TC 0
RD -
RA 1
RCODE 0
QDCOUNT 0
ANCOUNT 1
NSCOUNT 0
ARCOUNT 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: frog@jmarshall.com
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 116

from=jinyigo@uoc.edu&to=rmarti@uoc.edu&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: jinyigo@uoc.edu
250 jinyigo@uoc.edu... Sender OK
RCPT TO: rmarti@uoc.edu
250 rmarti@uoc.edu 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 <rmarti@uoc.edu>; Fri, 27 Jun 2003 18:35:52
+0200 (MET DST)
From: Jordi Inyigo <jinyigo@uoc.edu>
Message-Id: <199809211639 .SAA20364&peru.uoc.es>
To: rmarti@uoc.edu
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 versión
5 longitud de la cabecera IP: 5*4 = 20 bytes
10 tipo de servicio
0028 longitud total del paquete: 40 bytes
0023 identificación del paquete
0000 indicadores y posición del fragmento
40 tiempo de vida: 64
06 protocolo: 6 es TCP
8e28 checksum
c191 2d49 dirección IP origen: 193.145.45.73
d549 2851 dirección IP destino: 213.73.40.81
(no hay opciones. Lo sabemos por el número de bytes de cabecera)

TCP:
0400 puerto de origen: 1024.
006e puerto destino: 110 (correo POP)
c7a2 e0a5 número de secuencia
29da 7824 número ACK
5 longitud de la cabecera TCP: 5*4 = 20 bytes
011 reservado y control
7d78 ventana
f730 checksum
0000 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 tipo de servicio
0028 longitud total del paquete: 40 bytes
3a3b identificación del paquete
4000 indicadores y posición del fragmento
f9 tiempo de vida: 249
06 protocolo: 6 es TCP
5b1f checksum
d549 2851 dirección IP origen: 213.73.40.81
c191 2d49 dirección IP destino: 193.145.45.73
(no hay opciones. Lo sabemos por el número de bytes de cabecera)

TCP:
006e puerto de origen: 110 (correo POP)
0400 puerto destino: 1024
29da 7824 número de secuencia
c7a2 e0a6 número ACK
5 longitud de la cabecera TCP: 5*4 = 20 bytes
010 reservado y control
2238 ventana
5271 checksum
0000 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, usuario@uoc.edu). 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 dcarrera@pcbosch.uoc.edu [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: consultor@uoc.edu

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 consultor@uoc.edu... 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: estudiant@uoc.edu

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 estudiante@uoc.edu... 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.

You might also like