SOLUCIONES — Examen de Desarrollo de Redes

Un /22 tiene 22 bits de red y 32 − 22 = 10 bits de host → 2¹⁰ = 1024 direcciones totales (1022 útiles si se usara plano).

El bloque abarca 172.20.8.0 – 172.20.11.255 (los octetos 8, 9, 10 y 11: cuatro «/24 enteros», porque 2 bits libres en el tercer octeto = 4 valores).

Regla para cada subred: buscar el menor n tal que 2ⁿ − 2 ≥ hosts; el prefijo es 32 − n. Justificación de que la máscara es la mínima: con un bit menos de host no cabría.

Consumo: 512+256+128+32+4+4 = 936 ≤ 1024 → cabe, y quedan libres 172.20.11.168 – 172.20.11.255 para crecer.

Clave: el siguiente salto de una ruta estática debe ser una IP del enlace directamente conectado (la del otro extremo): por eso hacia LAN2 es .162 y hacia todo lo del edificio 3 es .166.

Constantes en todo el camino: IP origen 172.20.8.10 e IP destino 172.20.11.140. Cambian en cada salto: las dos MAC (nueva trama por tramo), el TTL (−1 por router: 2 routers → TTL llega con −2), el checksum IP y el FCS de la trama.

Datos del original: 4020 − 20 = 4000 B. Con MTU 1500 caben 1500 − 20 = 1480 B de datos; como el campo Fragment Offset se mide en unidades de 8 bytes, el trozo de datos de todo fragmento no final debe ser múltiplo de 8. 1480 = 8 × 185 ✓ → se usan 1480 B por fragmento.

Comprobación: 1480 + 1480 + 1040 = 4000 ✓. Los tres llevan la misma Identification (0x2B3C) y cabecera de 20 B cada uno.

Con MTU 620 caben 620 − 20 = 600 B de datos, y 600 = 8 × 75 ✓. R2 refragmenta cada fragmento por separado, conservando Identification y sumando offsets sobre el offset que ya traía cada uno:

Comprobaciones: datos = 600·5 + 280·2 + 440 = 3000 + 560 + 440 = 4000 ✓ · offsets en bytes 0, 600, 1200, 1480, 2080, 2680, 2960, 3560: cada uno empieza donde acaba el anterior (sin huecos ni solapes) ✓ · todos múltiplos de 8 ✓ · un único MF=0 ✓.

Solo reensambla el host destino (nunca los routers intermedios). Usa: Identification (+ IP origen/destino y protocolo) para agrupar fragmentos del mismo datagrama, Offset para ordenarlos y colocarlos, y MF=0 para saber cuál es el último (con su offset+longitud conoce el tamaño total). Si el original llevara DF=1, R1 no podría fragmentar: descartaría el datagrama y devolvería un ICMP «Destination Unreachable – Fragmentation needed» (base del Path MTU Discovery).

Paquete IP de 80 B ≥ 46 B → no necesita relleno. La trama (destino = el gateway, no el servidor):

Las MAC cambian porque la trama vive solo dentro de un tramo de capa 2: cada router la desencapsula, enruta el paquete y construye una trama nueva con las MAC de ese enlace. Las IP no cambian porque identifican los extremos de la comunicación (capa 3, extremo a extremo). Además, en cada salto se recalcula el FCS (la trama es nueva y su contenido cambió: MACs y TTL/checksum del IP interior).

El mínimo de 64 B existe por la detección de colisiones de la Ethernet clásica (CSMA/CD): la trama debe seguir transmitiéndose cuando la posible colisión regresa.

Datos = 40 B < 46 B → la NIC añade relleno de 46 − 40 = 6 B (ceros). Trama: 6+6+2+(40+6)+4 = 64 B, justo el mínimo. El receptor sabe cuánto es relleno porque el Total Length del IP interior dice 40.

Regla del switch: aprende siempre (MAC origen → puerto de entrada); para decidir, busca la MAC destino: si no está → inunda por todos los puertos menos el de entrada; si está en otro puerto → reenvía solo por ese; si está en el mismo puerto de entrada → filtra (descarta). El broadcast FF:…:FF siempre se inunda.

Un hub (capa 1) no aprende nada ni decide: repite la señal por todos los puertos siempre — los 6 envíos habrían llegado a todos los equipos, con un único dominio de colisión. El switch segmenta: tras aprender, el tráfico unicast solo sale por el puerto correcto.

Condición de subredes: 2^b ≥ 5 → b = 3 (2²=4 < 5 → 2 bits no bastan). Quedan 8−3 = 5 bits de host: 2⁵−2 = 30 ≥ 25 ✓. Con b = 4 quedarían 4 bits de host → 2⁴−2 = 14 < 25 ✗. Única solución: 3 bits prestados.

Salto = 256 − 224 = 32 (o 2⁵): .0, .32, .64, .96, .128, .160, .192, .224 (todas /27).
La tercera (contando .0 como primera) es 192.168.100.64/27: rango útil 192.168.100.65 – 192.168.100.94, broadcast 192.168.100.95.

77 AND 224 = 64 → subred 192.168.100.64/27, rango útil 192.168.100.65 – 192.168.100.94, broadcast 192.168.100.95. (Coincide con la 3ª del apartado c.)

Cada subred pierde 2 (red + broadcast): 8 × 2 = 16. La /24 plana perdía 2. Coste del subnetting: 16 − 2 = 14 direcciones extra perdidas (quedan 8×30 = 240 útiles frente a 254).

Para cada destino, el router calcula destino AND máscara para cada entrada; entre todas las entradas que coinciden con su red gana la de prefijo más largo (la más específica). La ruta 0.0.0.0/0 coincide con todo (AND con máscara 0 da siempre 0.0.0.0), pero su prefijo es 0: solo gana si ninguna otra encaja.

/13 deja 32−13 = 19 bits de host; en el 2º octeto la máscara es 248 → bloques de 8: 10.24.0.0 – 10.31.255.255. 10.30.15.9 está dentro (24 ≤ 30 ≤ 31) ✓; 10.32.0.1 queda fuera (32 > 31: pertenece al bloque siguiente, 10.32.0.0/13) → para él solo encajaría la /8.

Encapsulación: datos → segmento → paquete → trama → bits (cada capa envuelve lo de la superior). En el receptor, el proceso inverso (desencapsulación).

El switch procesa hasta la capa 2: lee MAC destino y reenvía; el paquete IP es para él «datos opacos» — por eso no mira IPs. El router desencapsula hasta la capa 3: lee la IP destino, consulta su tabla y reencapsula en una trama nueva; no necesita los puertos TCP porque el transporte es extremo a extremo (solo lo procesan los hosts finales).

Aplicación+Presentación+Sesión (7-6-5) → Aplicación · Transporte (4) → Transporte · Red (3) → Internet · Enlace+Física (2-1) → Acceso a la red.

Petición del cliente: 500 B con seq 4001 (bytes 4001…4500). El servidor asiente con ack = 4001 + 500 = 4501 («he recibido hasta el 4500, espero el 4501»). Respuesta del servidor: 1200 B con seq 9001 (bytes 9001…10200) → el cliente responde ack = 9001 + 1200 = 10201.

• Consulta DNS: UDP (puerto 53): un mensaje corto pregunta-respuesta; el coste del handshake no compensa (TCP se usa para transferencias de zona o respuestas grandes).
• Descarga de fichero: TCP: hace falta que llegue todo, en orden y sin errores.
• Videollamada en directo: UDP: importa la latencia; retransmitir un frame viejo no sirve (RTP sobre UDP).
• HTTP: TCP (80/443): la página debe llegar íntegra y ordenada.

Servicios de TCP que UDP no da: fiabilidad (retransmisiones con ACK), entrega en orden (números de secuencia), control de flujo (ventana), control de congestión y conexión establecida (handshake). UDP solo aporta puertos y un checksum.

El cliente emite en broadcast porque aún no tiene IP (usa origen 0.0.0.0) y no conoce la dirección del servidor. Transporte: UDP, servidor puerto 67, cliente puerto 68. Datos mínimos entregados: IP + máscara + gateway por defecto + servidor DNS (y la duración del lease).

DHCP → ARP al gateway → DNS → handshake TCP → HTTP. No puede alterarse porque cada paso necesita el resultado del anterior: sin IP/máscara/GW/DNS (DHCP) no se puede enviar nada enrutado; para mandar la consulta DNS fuera de la LAN hace falta la MAC del gateway (ARP); sin la IP del servidor (DNS) no se puede abrir la conexión; y HTTP viaja dentro de una conexión TCP ya establecida (SYN, SYN+ACK, ACK) hacia el puerto 443/80.