SOLUCIONES · Examen Maestro de Redes

Opción correcta + desarrollo completo + trampas típicas · Todos los cálculos verificados con Python (_verif_redes.py, módulo ipaddress): 122 comprobaciones, todas OK.

Clave rápida:
1b · 2c · 3a · 4d · 5b · 6a · 7c · 8b · 9d · 10a
11c · 12b · 13a · 14d · 15b · 16a · 17c · 18d
19d · 20b · 21a · 22c · 23b · 24d · 25a · 26c · 27b · 28d
29b · 30c · 31a · 32d · 33b · 34a
35c · 36b · 37a · 38d · 39c · 40b
41a · 42c · 43b · 44d · 45a · 46b · 47c · 48d · 49b · 50a · 51c · 52d · 53a · 54b
55c · 56b · 57d · 58a · 59c
60b · 61c · 62a · 63d · 64a · 65c · 66b · 67d · 68a · 69b · 70c · 71d · 72a · 73b · 74d · 75c · 76a
77b · 78c · 79a · 80d · 81b · 82a · 83c · 84d · 85b · 86a · 87c · 88d
89b · 90c · 91a · 92d · 93b · 94a · 95c · 96d
97b · 98a · 99c · 100d · 101b · 102a
103c · 104b · 105a · 106d · 107b

Bloque 1 · Modelos OSI y TCP/IP

1.b) 7.
Física, Enlace, Red, Transporte, Sesión, Presentación, Aplicación. Truco: «Fíjate En Redes: Todo Se Puede Aprender».
2.c) Trama.
Capa 2 = trama; es la unidad que maneja el switch y la que lleva MAC + FCS.
3.a) Paquete o datagrama.
Capa 3 = paquete IP. Serie completa: datos → segmento (L4) → paquete (L3) → trama (L2) → bits (L1).
4.d) Switch.
Decide con la MAC de destino. El router es de capa 3; hub y repetidor, de capa 1.
5.b) 3 (red).
Su trabajo es enrutar paquetes IP entre redes distintas mirando su tabla de rutas.
6.a) 1 (física).
El hub no entiende de MAC ni tramas: solo repite la señal eléctrica por todos los puertos.
7.c) Aplicación, presentación y sesión.
TCP/IP condensa las tres capas superiores de OSI en su capa de Aplicación.
8.b) Transporte.
Comunican procesos mediante puertos; TCP añade fiabilidad, UDP no.
9.d) Datos → segmento → paquete → trama → bits.
Cada capa envuelve a la anterior añadiendo su cabecera (encapsulación).
Trampa: la opción (a) intercambia segmento y paquete; es el distractor clásico.
10.a) La capa de red.
Direccionamiento lógico (IP) + enrutamiento extremo a extremo. El enlace solo entrega dentro del mismo medio local.

Bloque 2 · Nivel físico

11.c) Par trenzado apantallado (Cat 6A F/UTP o S/FTP).
90 m ≤ 100 m, así que el cobre llega; la EMI obliga a blindaje. La fibra también valdría técnicamente, pero la pregunta pide el medio adecuado y económico dentro del alcance del cobre.
12.b) Fibra monomodo.
Kilómetros → monomodo. La multimodo es para cientos de metros (la opción c la describe mal a propósito).
13.a) 100 m.
Límite clásico del par trenzado en Ethernet. Memoriza: «el cobre muere a 100 m».
14.d) 160 ms.
4 MB = 4·106·8 = 32·106 bits. ttx = 32·106 / 200·106 = 0,16 s = 160 ms.
Trampa: olvidar el ×8 (bytes→bits) da 20 ms, que es la opción (a).
15.b) 0,3 ms.
tprop = 60 000 m / 2·108 m/s = 3·10−4 s = 0,3 ms.
16.a) La transmisión.
160 ms ≫ 0,3 ms. La propagación solo domina en enlaces largúsimos (satélite) o con muy poco que transmitir.
17.c) 24 000 bps.
Nyquist: C = 2·B·log₂(M) = 2·4000·log₂(8) = 2·4000·3 = 24 000 bps.
18.d) No: 32 000 bps < 33 238 bps.
Nyquist con M=16: 2·4000·4 = 32 000 bps. Shannon (SNR 25 dB → S/N = 102,5 ≈ 316,2) da ≈33 238 bps y es el techo absoluto: no se supera añadiendo niveles.

Bloque 3 · Trama Ethernet

19.d) El EtherType.
Indica el protocolo encapsulado: 0x0800 IPv4, 0x0806 ARP, 0x86DD IPv6.
20.b) 6 bytes (48 bits).
Formato XX:XX:XX:XX:XX:XX; los 3 primeros bytes son el OUI del fabricante.
21.a) CRC-32 que solo detecta; la trama corrupta se descarta.
Ethernet no corrige ni retransmite; recuperar los datos perdidos es tarea de capas superiores (TCP).
Trampa: «checksum TCP» y «retransmisión en capa 2» mezclan capas: distractores habituales.
22.c) 46 bytes.
Si hay menos datos, se rellena con padding hasta 46.
23.b) 64 bytes.
14 (cabecera: 6+6+2) + 46 (payload mínimo) + 4 (FCS) = 64. Herencia del slot-time de CSMA/CD.
24.d) 1518 bytes.
14 + 1500 (MTU) + 4 = 1518 (sin preámbulo/SFD).
25.a) Se añaden 24 bytes de padding.
46 − 22 = 24. La trama sale con el mínimo total de 64 B.
26.c) Longitud (IEEE 802.3).
0x05DC = 5·256 + 13·16 + 12 = 1500. Regla del umbral: ≤1500 → longitud; ≥1536 (0x0600) → EtherType. 1500 es justo el caso límite.
27.b) Un datagrama IPv4.
0x0800 = IPv4. Compáralo con 0x0806 (ARP) y 0x86DD (IPv6): se parecen a propósito.
28.d) Sincronización del receptor.
7 B de preámbulo + 1 B de SFD = 8 B de patrón alterno 10101010... que no cuentan en los 64–1518.

Bloque 4 · Switch y tabla MAC

29.b) La reenvía solo por P1.
AA...34 → P1 está en la tabla: envío selectivo, sin molestar al resto de puertos.
30.c) Que AB:AB:AB:AB:00:90 está en P2.
El switch aprende siempre de la MAC de origen de las tramas que entran, nunca de la de destino.
Trampa: la opción (a) pone la MAC de destino: es el fallo más repetido.
31.a) Inundación (flooding): por todos los puertos excepto P2.
Destino desconocido → flooding. Cuando la impresora responda, el switch aprenderá su puerto y dejará de inundar.
32.d) Por todos los puertos excepto P1.
FF:FF:FF:FF:FF:FF es la MAC de difusión: se reenvía a todos menos al puerto de entrada.
33.b) No modifica nada.
El switch conmuta tramas tal cual. Quién sí reescribe las MAC (al crear una trama nueva por cada tramo) es el router.
34.a) El switch separa dominios de colisión y reenvía de forma selectiva.
Un puerto = un dominio de colisión. Ojo: los dominios de difusión los separan los routers, no los switches (por eso (c) es falsa).

Bloque 5 · ARP

35.c) Averiguar la MAC que corresponde a una IP local.
Necesaria para poner la MAC de destino en la trama. (a) es DHCP y (b) es DNS.
36.b) Por 10.20.0.1, su gateway.
10.20.1.10 ∉ 10.20.0.0/24 → el siguiente salto es el gateway, y el ARP se hace por el siguiente salto, nunca por el destino remoto.
Trampa: responder «por el destino final» es el error clásico de este tema.
37.a) En broadcast a FF:FF:FF:FF:FF:FF.
No se conoce la MAC buscada, así que se pregunta a todos los equipos de la LAN.
38.d) En unicast al solicitante.
El que responde sí conoce la MAC del preguntante (iba en la Request), así que contesta solo a él.
39.c) 3, una por tramo.
PC origen → su gateway; router 1 → router 2; router 2 → host destino. Cada tramo resuelve la IP de su propio siguiente salto.
40.b) Guarda pares IP→MAC ya resueltos.
Evita repetir el broadcast en cada envío; las entradas caducan pasado un tiempo.

Bloque 6 · Direccionamiento IPv4 y subnetting

41.a) 26 bits de red → 255.255.255.192.
/26 = 11111111.11111111.11111111.11000000. Quedan 6 bits de host.
42.c) /26.
4 subredes → s bits con 2s ≥ 4 → s = 2 → 24+2 = 26.
Trampa: no confundir «4 subredes» (2 bits más de red) con «4 bits».
43.b) 62.
Bits de host = 32−26 = 6 → 26−2 = 62 (se restan red y broadcast). Verificado con ipaddress.
44.d) 10.20.3.64/26.
Bloque = 256−192 = 64 → subredes: .0, .64, .128, .192. La segunda es la .64.
45.a) 10.20.3.191.
Broadcast = red + bloque − 1 = 128 + 64 − 1 = 191. Verificado: ip_network('10.20.3.128/26').broadcast_address = 10.20.3.191.
46.b) /27 → 255.255.255.224.
8 subredes → 2³ → 3 bits → 24+3 = 27. Bloque 32, 30 hosts útiles por subred.
47.c) 192.168.24.64/27.
Bloque de /27 = 32 → fronteras 0, 32, 64, 96... 77 cae entre 64 y 95 → red = .64. En binario: 77 = 01001101; con 5 bits de host a 0 queda 01000000 = 64.
48.d) 192.168.24.65 – 192.168.24.94.
Red .64 y broadcast .95 no se asignan; el rango de hosts va de red+1 a broadcast−1. Verificado con Python.
Trampa: las otras tres opciones incluyen la red o el broadcast.
49.b) /26 (62 hosts).
Busco 2h−2 ≥ 50 → h = 6 (62). /27 solo da 30: no llega.
50.a) /25 (126 hosts).
27−2 = 126 ≥ 100; /26 da 62: insuficiente.
51.c) /23 (510 hosts).
29−2 = 510 ≥ 500. /24 da 254: no llega. Verificado con Python.
52.d) No.
Con /25 el bloque es 128: .100 cae en 10.20.1.0/25 (0–127) y .130 en 10.20.1.128/25 (128–255). Redes distintas → necesitan router para hablarse.
53.a) Sí.
Bloque de /27 = 32 → 172.16.5.192/27 abarca .192–.223. Tanto 200 como 220 caen dentro. Verificado: ambas devuelven red 172.16.5.192.
Trampa: a ojo parecen «lejanas», pero lo único que cuenta es el bloque. 224 ya sería la siguiente subred.
54.b) Es la dirección de red de 192.168.24.96/27.
96 es múltiplo de 32 → todos los bits de host a 0 → identifica la subred y no se asigna a hosts (el broadcast sería .127).

Bloque 7 · VLSM

55.c) De mayor a menor.
Así los bloques grandes quedan alineados a sus fronteras naturales y no se solapan con los pequeños.
56.b) 10.20.4.0/25.
100 hosts → 27−2 = 126 → /25. Ocupa .0–.127.
57.d) 10.20.4.128/26.
50 → 62 → /26. Empieza justo después del /25: .128–.191 (broadcast .191).
58.a) 10.20.4.192/27.
20 → 30 → /27. Ocupa .192–.223 (rango útil .193–.222).
59.c) 10.20.4.224/30.
2 hosts → 2²−2 = 2 → /30. Ocupa .224–.227; hosts .225 y .226. Libre desde .228. Las cuatro subredes verificadas sin solapamiento con ipaddress.

Bloque 8 · El campus: viaje del paquete

60.b) 10.20.0.34 → 10.20.1.10.
Las IP identifican los extremos y no cambian en ningún tramo (salvo NAT, que aquí no hay).
61.c) A1:00:00:00:00:01 (lan0 de R-A).
Destino en otra red → siguiente salto = gateway → su MAC en la LAN A. La IP de destino sigue siendo la de SRV-B.
62.a) A1:00:00:00:00:02 (wan0 de R-A).
Cada router construye una trama nueva y firma con la MAC de su interfaz de salida. La MAC de PC-A desapareció al cruzar R-A.
63.d) B1:00:00:00:00:01 (wan0 de R-B).
El siguiente salto en ese tramo es la interfaz 172.16.0.2 de R-B; R-A obtuvo su MAC por ARP en el enlace /30.
64.a) B1...02 (lan0 de R-B) → CC:CC:CC:CC:00:10 (SRV-B).
Último tramo: origen = interfaz de salida de R-B en la LAN B; destino = el host final.
TramoMAC origenMAC destinoIP origen → destino
LAN AAA...34 (PC-A)A1...01 (R-A lan0)10.20.0.34 → 10.20.1.10 (constante)
Backbone A–BA1...02 (R-A wan0)B1...01 (R-B wan0)
LAN BB1...02 (R-B lan0)CC...10 (SRV-B)
65.c) En ninguno.
Lo único que cambia por el camino: MACs (cada tramo), TTL (−1 por router) y checksum IP (se recalcula).
66.b) 62.
Atraviesa R-A y R-B → 64 − 2 = 62. Los switches no tocan el TTL (son capa 2).
67.d) 10.20.1.0/24 → 172.16.0.2 por wan0.
10.20.1.10 encaja en 10.20.1.0/24 (más específica que la default). El next hop es la interfaz vecina de R-B en el /30.
68.a) 172.16.0.6 por wan1.
En R-B, 10.20.2.77 encaja en 10.20.2.0/24 (prefijo 24) y en 0.0.0.0/0 (prefijo 0): gana /24 → next hop 172.16.0.6 (wan0 de R-C). Verificado con Python (longest prefix match).
69.b) 0.0.0.0/0 → 172.16.0.5.
8.8.8.8 no encaja en 10.20.2.0/24 ni en 172.16.0.4/30; solo la default lo cubre. R-C manda todo lo desconocido hacia R-B.
70.c) 203.0.113.2.
En R-B tampoco hay ruta específica para 8.8.8.8 → default de R-B → el router del ISP por wan2.
71.d) Longest prefix match.
A igualdad de coincidencia, gana la máscara más larga (más específica). El orden de las filas y la cercanía del next hop no influyen.
72.a) Porque 10.20.1.10 no está en 10.20.0.0/24.
El host compara (IP destino AND máscara) con su propia red: si difiere, envía al gateway. Cambiar de red exige un dispositivo de capa 3.
73.b) Una IP directamente alcanzable (vecino en un enlace común).
El router debe poder resolverla por ARP en ese enlace. Un next hop a varios saltos no servía: no se podría construir la trama.
74.d) El ARP por 10.20.0.254 queda sin respuesta y el paquete no sale de la LAN A.
Nadie responde a esa IP → PC-A no obtiene MAC de siguiente salto → no puede ni construir la trama. Ni el switch (capa 2) ni R-A (que nunca recibe nada) pueden arreglarlo.
75.c) 10.20.2.255.
LAN C = 10.20.2.0/24 → bits de host todos a 1 → .255. Verificado con Python.
76.a) Los routers.
Un broadcast (FF:FF... / 10.20.0.255) inunda su LAN a través de los switches, pero los routers no lo reenvían: cada LAN es un dominio de difusión.

Bloque 9 · Fragmentación IPv4

77.b) Sí.
4500 > 1000 (MTU de salida) y DF=0 permite fragmentar. Los routers IPv4 sí fragmentan (en IPv6 no: allí solo el origen).
78.c) 976 bytes.
MTU − cabecera = 1000 − 20 = 980; el payload debe ser múltiplo de 8 → ⌊980/8⌋×8 = 122×8 = 976.
Trampa: quedarse en 980 (no es múltiplo de 8) es el fallo típico.
79.a) 5.
Datos = 4500 − 20 = 4480 → ⌈4480/976⌉ = ⌈4,59⌉ = 5.
80.d) 122.
El fragmento 2 empieza en el byte 976 → offset = 976/8 = 122.
Frag.Datos (B)Total LengthOffset (×8 B)MF
197699601
29769961221
39769962441
49769963661
55765964880
Comprobación: 4×976 + 576 = 4480 ✓. Todos con Identification = 555. Verificado con Python.
81.b) 488.
Bytes previos = 4×976 = 3904 → 3904/8 = 488.
82.a) 0.
MF = «vienen más fragmentos»: 1 en los cuatro primeros, 0 en el último.
83.c) 596 bytes.
Datos restantes = 4480 − 4×976 = 576; + 20 de cabecera = 596.
84.d) El campo solo tiene 13 bits.
Total Length usa 16 bits (hasta 65535), pero el offset dispone de 13. Contando en bloques de 8: 2¹³×8 = 65536 → alcanza cualquier posición. Por eso el payload de cada fragmento (salvo el último) debe ser múltiplo de 8.
85.b) El destino final.
Los routers intermedios reenvían fragmentos sueltos (incluso por caminos distintos); solo SRV-B reensambla usando Identification + offsets + MF.
86.a) Descartar + ICMP «Fragmentation needed».
DF=1 prohíbe fragmentar. El aviso ICMP permite al origen bajar el tamaño (así funciona el descubrimiento de MTU del camino, Path MTU Discovery).
87.c) 3 fragmentos.
Payload = ⌊(1500−20)/8⌋×8 = 1480 (ya múltiplo de 8). Datos = 3000 → ⌈3000/1480⌉ = 3: 1480 + 1480 + 40.
88.d) 370.
Bytes previos = 2×1480 = 2960 → 2960/8 = 370. (185 es el offset del segundo; 2960 son bytes, no unidades de 8.)

Bloque 10 · TCP y UDP

89.b) TCP fiable y orientado a conexión; UDP sin conexión ni garantías.
Por eso TCP paga con más cabecera (20 B vs 8 B) y más latencia (handshake).
90.c) SYN → SYN-ACK → ACK.
Segmentos 3, 4 y 5 de la captura: cliente propone, servidor acepta y propone, cliente confirma.
91.a) 12001.
Ack = seq del SYN + 1 (el SYN consume un número de secuencia aunque no lleve datos): 12000 + 1.
92.d) 12351.
Ack = seq + bytes recibidos = 12001 + 350 = 12351 («el siguiente byte que espero»).
Trampa: 12350 (olvidar que se apunta al siguiente byte) es el distractor clásico.
93.b) 46201.
45001 + 1200 = 46201. Verificado con Python.
94.a) SRV-B es un servidor HTTP en su puerto bien conocido (80).
El cliente usa un puerto efímero alto (52344). HTTPS sería 443.
95.c) MTU 1500 − 20 (IP) − 20 (TCP) = 1460.
MSS = datos máximos de un segmento para que el paquete quepa justo en la MTU sin fragmentar.
96.d) UDP puerto 53.
Las consultas DNS normales van en UDP (rápidas, un solo datagrama); el 53000 es el puerto efímero del cliente.

Bloque 11 · DNS, DHCP e ICMP

97.b) Traducir nombres de dominio a IP.
(a) es DHCP; (d) es ARP. Tres protocolos que el examen adora confundir.
98.a) Discover → Offer → Request → Ack.
DORA: el cliente busca en broadcast, el servidor ofrece, el cliente pide formalmente, el servidor confirma y fija el lease.
99.c) Máscara, gateway y DNS.
Todo lo necesario para funcionar en la red. La MAC nunca: viene de fábrica en la tarjeta.
100.d) ICMP Echo Request / Echo Reply.
ICMP viaja dentro de IP (Protocol = 1). No usa puertos: no es TCP ni UDP.
101.b) TCP.
Protocol: 1 = ICMP, 6 = TCP, 17 = UDP. ARP no aparece nunca ahí: no viaja dentro de IP, sino directamente en la trama (EtherType 0x0806).
102.a) Descarte + ICMP «Time Exceeded» al origen.
El TTL evita que los paquetes circulen en bucles eternos. Traceroute envía TTL = 1, 2, 3... y va cosechando los avisos de cada router del camino.

Bloque 12 · RIP

103.c) El número de saltos.
Sin importar el ancho de banda: un salto por fibra de 10 Gb/s cuenta igual que uno por un enlace lento (su gran limitación).
104.b) 16.
Máximo utilizable 15 saltos; 16 = inalcanzable. Limita el tamaño de red pero acota el count-to-infinity.
105.a) Cada 30 segundos.
Envía la tabla completa a los vecinos aunque no haya cambios (los triggered updates añaden avisos inmediatos).
106.d) No anunciar una ruta por la interfaz por la que se aprendió.
R2 no anuncia la Red X hacia R1 (se la enseñó R1). Evita que R1 crea que hay un camino alternativo vía R2 cuando la red cae.
107.b) Count-to-infinity.
R1 pierde la red, pero R2 sigue anunciándosela con métrica 1; R1 la readopta con 2, R2 la sube a 3... hasta llegar a 16. Mitigaciones: split horizon, poison reverse, triggered updates.

Verificación: python3 _verif_redes.py → 122 comprobaciones OK (subnetting, VLSM, fragmentación, rangos, LPM, tiempos, Nyquist/Shannon, TCP). Ningún distractor coincide con la respuesta correcta.