Por qué: el dato decisivo es 105 m > 100 m. El estándar de cableado estructurado limita el canal de par trenzado a 100 m (90 m de enlace permanente + 10 m de latiguillos); a 105 m el cobre queda fuera de norma, aunque "casi" llegue. No se certifica y no es válido. La OM4 cubre cientos de metros y además es el medio típico de backbone vertical entre plantas. Coaxial no se usa en LAN modernas y un enlace inalámbrico no es un backbone fiable.

Por qué: la palabra clave es interferencia electromagnética (EMI). El par trenzado normal (UTP, Unshielded) se defiende del ruido solo con el trenzado de los pares; con EMI fuerte eso no basta y aparecen errores de FCS. Las variantes apantalladas añaden una lámina o malla metálica conectada a tierra que bloquea el ruido: F/UTP (pantalla global), S/FTP o STP (pantalla por par y/o global). Sigue siendo cobre y sigue limitado a 100 m, pero protegido.

Por qué: 2 km = 2000 m. El Cat 6A muere en 100 m (a). La OM4 llega a ~400–550 m según la velocidad: a 2 km la dispersión modal (los rayos de luz rebotan por caminos distintos y el pulso se "ensancha") degrada la señal (b). La monomodo tiene un núcleo tan fino (~9 µm) que la luz viaja por un único camino: aguanta decenas de km, es el medio estándar para enlaces urbanos/entre sedes. La (d) es absurda: un hub no es un medio y los repetidores pasivos no regeneran señal a esas distancias.

Por qué: en Ethernet II ese campo identifica qué protocolo viaja dentro del payload, para que la tarjeta de red sepa a quién entregar los datos al subir la pila: 0x0800 → IPv4, 0x0806 → ARP, 0x86DD → IPv6. Es el mecanismo de demultiplexación de capa 2 (igual que el campo "Protocolo" de IP apunta a TCP/UDP, y el puerto apunta a la aplicación). La (a) sería cierto en IEEE 802.3, no en Ethernet II. (c) y (d) no existen en la cabecera Ethernet: el checksum TCP va en TCP y Ethernet no tiene números de secuencia.

Por qué: existe una convención para que ambos formatos convivan en la misma red: el payload máximo es 1500 bytes, así que un campo de longitud jamás puede valer más de 1500. Se reservó el umbral 1536 (0x0600): cualquier valor ≥ 1536 no puede ser longitud, luego es un EtherType y la trama es Ethernet II. Valores ≤ 1500 son longitud → IEEE 802.3 con LLC/SNAP. Comprobación rápida: IPv4 = 0x0800 = 2048 ≥ 1536 ✔.

Por qué: el hub es un repetidor multipuerto de capa 1: no entiende tramas, solo regenera la señal eléctrica y la copia a TODOS los puertos. Consecuencia: todos los equipos comparten un único dominio de colisión. El switch es de capa 2: lee la MAC origen de cada trama que recibe y la apunta en su tabla CAM (puerto ↔ MAC); cuando llega una trama, busca la MAC destino en la tabla y la reenvía solo por el puerto correcto (si no la conoce, la inunda a todos; el broadcast siempre se inunda). Cada puerto del switch es su propio dominio de colisión. Las otras opciones invierten capas (a), niegan el aprendizaje que define al switch (c) o atribuyen al hub la virtud del switch (d).

Por qué: CSMA/CD (Carrier Sense Multiple Access / Collision Detection) funciona así: escucha antes de transmitir (carrier sense); si el medio está libre transmite mientras sigue escuchando; si detecta colisión, aborta, envía señal de jam y reintenta tras un tiempo aleatorio (backoff exponencial). Solo tiene sentido cuando varios equipos comparten el medio (hub, coaxial antiguo, half-duplex). En un switch full-duplex cada enlace es punto a punto con carriles separados de transmisión y recepción: las colisiones son físicamente imposibles y CSMA/CD queda desactivado. Por eso (a). La (d) describe mal el orden: escucha antes Y durante, y no evita colisiones, las detecta.

Por qué: la trama Ethernet mínima es de 64 bytes (sin contar preámbulo). Restando cabecera y cola: 64 − 14 de cabecera (6 MAC dst + 6 MAC src + 2 EtherType) − 4 de FCS = 46 bytes de payload mínimo. Si los datos reales ocupan menos (p. ej. un ARP de 28 B), la tarjeta añade padding de ceros hasta llegar a 46.

De dónde sale el 64: herencia de CSMA/CD. Una trama debía durar lo suficiente para que, en el peor caso (colisión en el extremo opuesto de la red), la señal de colisión volviera al emisor antes de terminar de transmitir (slot time). Con tramas más cortas, el emisor podría acabar sin enterarse de la colisión.

Por qué: es la dirección con los 48 bits a 1 (FF hex = 11111111). Significa "para todos los equipos de esta LAN": los switches la inundan por todos los puertos y todas las tarjetas la procesan. La usa, por ejemplo, el ARP Request ("¿quién tiene esta IP?") porque aún no se conoce la MAC del destinatario. Importante: el broadcast no cruza routers; delimita el dominio de broadcast.

Por qué: el emisor calcula un CRC-32 sobre toda la trama y lo pone en el FCS (Frame Check Sequence, 4 bytes finales). El receptor repite el cálculo: si no coincide, la trama llegó corrupta (ruido, interferencia) y se descarta en silencio. Matiz que el profesor remarca: Ethernet detecta pero NO retransmite (por eso la (c) es falsa). Recuperar lo perdido es trabajo de capas superiores: TCP retransmitirá; si era UDP, se pierde sin más. (b) y (d) mezclan capas: puertos son de transporte y TTL es de IP.

Por qué: rige la regla del prefijo más largo (longest prefix match). Se comprueba qué rutas "contienen" al destino: 192.168.20.10 encaja en las tres (en /24, en /16 y en la default /0). De entre las que encajan, gana la de máscara más larga porque es la más específica: /24 > /16 > /0. La lógica: una ruta más específica representa información más precisa sobre dónde está esa red. El orden físico en la tabla es irrelevante (d).

Por qué: PC-A aplica su máscara /24 y ve que 192.168.20.10 está fuera de 192.168.10.0/24 → debe entregárselo a su gateway (192.168.10.1 = R1). La trama Ethernet solo vive dentro de la LAN local, así que su MAC destino es la del siguiente salto físico: R1. No puede ser la MAC de SRV (a): SRV está en otra LAN y ARP no puede resolverla (ARP no cruza routers). Broadcast (d) solo se usa para el propio ARP Request, no para el tráfico normal.

Por qué: es el espejo de la P12 y juntas forman LA pareja estrella del examen. La IP destino identifica al receptor final y no cambia en ningún salto (sin NAT): los routers la necesitan intacta precisamente para decidir el camino consultando su tabla de rutas. Lo que cambia en cada salto son las MAC. La (d) ni siquiera es una IP, es una MAC: típico distractor de mezcla de capas.

Por qué: ARP (Address Resolution Protocol) responde a una sola pregunta: "tengo la IP de mi siguiente salto, ¿cuál es su MAC?". Funciona con un ARP Request en broadcast ("¿quién tiene 192.168.10.1?") y un ARP Reply unicast ("yo, soy CC:CC:..."). Como el broadcast no sale de la LAN, ARP no cruza routers (a falsa). Va montado directamente sobre Ethernet con EtherType 0x0806, ni siquiera usa IP, mucho menos TCP (c falsa). Y complementa a la tabla de rutas, no la sustituye: la tabla decide el siguiente salto (capa 3) y ARP averigua su MAC (capa 2) (d falsa). El resultado se guarda en la caché ARP unos minutos.

Por qué: el TTL (Time To Live) existe para impedir que un paquete dé vueltas infinitas si hay un bucle de enrutamiento. Cada router resta 1 al reenviar; si tras restar queda 0, el router descarta el datagrama y envía al origen un mensaje ICMP tipo 11, Time Exceeded. Nadie "recarga" el TTL en ruta (b). Dato extra que suele caer: traceroute explota esto a propósito, enviando paquetes con TTL=1,2,3… para que cada router del camino se delate con su Time Exceeded.

Por qué: el bit DF (Don't Fragment) es una orden del emisor: "prohibido trocearme". Si el datagrama no cabe en la MTU de salida y DF=1, el router tiene prohibido fragmentar (a falsa), así que descarta y avisa con ICMP tipo 3 código 4 ("Fragmentation needed and DF set"), que además incluye la MTU que no se pudo cumplir. Esto no es un fallo: es el mecanismo en que se basa Path MTU Discovery: el emisor envía con DF=1, recibe estos ICMP y va reduciendo el tamaño hasta dar con el MTU mínimo del camino, evitando fragmentar (que es caro y frágil). Los routers nunca reensamblan (c) ni tocan capa 4 (d).

Por qué: IP fragmenta su payload a ciegas, sin entender qué hay dentro. La cabecera TCP/UDP es simplemente los primeros 20/8 bytes de ese payload, así que cae entera en el primer trozo. Lo que SÍ se copia a cada fragmento es la cabecera IP (cada fragmento debe poder enrutar por sí solo). Consecuencia práctica importante: los fragmentos 2.º en adelante no llevan puertos → un firewall que filtra por puerto no puede clasificarlos, y por eso la fragmentación se evita siempre que se puede (PMTUD).

Por qué: dos razones de diseño. (1) Eficiencia: reensamblar exige guardar fragmentos en memoria y esperar a que lleguen todos; un router debe reenviar millones de paquetes por segundo, no puede permitírselo. (2) Posibilidad: en una red con múltiples caminos, no hay garantía de que todos los fragmentos pasen por el mismo router; el único punto por el que seguro pasan todos es el destino final. El destino agrupa por el campo Identification, ordena por offset y sabe que terminó cuando tiene el fragmento con MF=0 y no hay huecos. Un switch (c) ni mira IP; ARP (d) no tiene nada que ver.

Por qué: el next hop debe ser una IP a la que el router pueda entregar directamente la trama, es decir, un vecino que esté en una de sus redes conectadas. Ejemplo del escenario: en R1, la ruta hacia la LAN de servidores es 192.168.20.0/24 → next hop 10.0.0.2 (la IP de R2 en el enlace común 10.0.0.0/30). Sería absurdo poner como next hop algo que no es alcanzable de un salto. Las MAC no aparecen en tablas de rutas (c, mezcla de capas) y el broadcast no es un destino de reenvío (d).

Por qué: la máscara /0 significa "0 bits tienen que coincidir" → cualquier dirección encaja. Es el comodín "todo lo que no sepa a dónde va, mándalo por aquí" (típicamente hacia Internet). Por longest prefix match (P11) solo se usa cuando ninguna ruta más específica encaja. Las otras son direcciones especiales que conviene reconocer: 255.255.255.255 = broadcast limitado, 127.0.0.0/8 = loopback (localhost), 224.0.0.0/4 = multicast clase D.

Paso a paso:

1. El MTU limita el datagrama IP completo: cabecera + datos ≤ 1000.
2. Espacio bruto para datos: 1000 − 20 = 980 bytes.
3. Restricción extra: el Fragment Offset se mide en bloques de 8 bytes, así que los datos de cada fragmento (salvo el último) deben ser múltiplo de 8.
4. ¿980 es múltiplo de 8? 980 / 8 = 122,5 → no. Bajamos al múltiplo de 8 anterior: 8 × 122 = 976.

Paso a paso:

1. Datos totales a trocear: 4500 − 20 = 4480 bytes (el offset cuenta bytes de DATOS, no de cabecera).
2. Cada fragmento lleva 976 bytes de datos. Posición inicial (en bytes) del fragmento n: (n−1) × 976.
3. Cuarto fragmento: 3 × 976 = 2928 bytes.
4. El campo Offset se expresa en unidades de 8 bytes: 2928 / 8 = 366.

El mapa completo (para cualquier variante de la pregunta): 4480 = 976×4 + 576 → 5 fragmentos:

Por qué: ARP no cruza routers, así que cada tramo Ethernet del camino necesita su propia resolución. Cuenta los tramos:

1. PC-A → R1: PC-A pregunta "¿quién tiene 192.168.10.1?" → 1.er ARP Request.
2. R1 → R2: R1 pregunta por 10.0.0.2 en el enlace 10.0.0.0/30 → 2.º ARP Request.
3. R2 → SRV: R2 pregunta por 192.168.20.10 en la LAN de servidores → 3.er ARP Request.

Es exactamente la "pregunta recurrente" que avisa el profesor: cada salto de la ruta genera su propio ARP Request. Los switches (SW-A, SW-S) no cuentan: son de capa 2, no originan ni terminan tramos IP.

Paso a paso (método del tamaño de bloque):

1. /26 → 26 bits de red, 32 − 26 = 6 bits de host → bloques de 2⁶ = 64 direcciones en el último octeto.
2. Las subredes empiezan en múltiplos de 64: .0, .64, .128, .192.
3. ¿En qué bloque cae 77? Entre 64 y 127 → la red es 192.168.10.64.

Comprobación en binario (por si la piden): 77 = 01001101. La máscara /26 deja los 2 primeros bits del octeto como red: 01······ → 01000000 = 64 ✔.

Paso a paso: el broadcast es la última dirección del bloque (todos los bits de host a 1).

1. De la P24: la red es 192.168.10.64 y el bloque mide 64 direcciones.
2. Siguiente red: 64 + 64 = .128. Broadcast = siguiente red − 1 = .127.

El bloque completo queda: red .64 · hosts utilizables .65 – .126 (62 hosts = 2⁶−2) · broadcast .127. Con esto respondes también las variantes "¿primer/último host utilizable?" y "¿cuántos hosts caben?".

Por qué: los 16 bits de puerto (0–65535) se dividen en tres zonas según IANA: 0–1023 bien conocidos (servicios estándar: 80 HTTP, 443 HTTPS, 53 DNS, 22 SSH, 25 SMTP), 1024–49151 registrados (aplicaciones concretas: 3306 MySQL, 8080…), y 49152–65535 dinámicos/efímeros: los que el sistema operativo asigna al azar al cliente para cada conexión saliente. En la captura se ve perfecto: el cliente usa 52344 (efímero ✔) contra el 80 del servidor (bien conocido ✔).

Por qué: la quíntupla (5-tuple) identifica unívocamente una conexión: IP origen, puerto origen, IP destino, puerto destino, protocolo. La conexión web es la del SYN de la línea 5: cliente 192.168.10.34 desde su puerto efímero 52344, hacia el servidor 192.168.20.10 al puerto 80, protocolo TCP. La (b) describe la consulta DNS (puerto 53), no la web — y además DNS iba en UDP. La (c) dice UDP para una conexión TCP. La (d) mezcla protocolos sueltos sin sentido.

Por qué: cuando al receptor le llega un segmento fuera de orden (le falta uno anterior), responde repitiendo el ACK del último byte en orden que tiene ("sigo esperando el byte X"). Si al emisor le llegan 3 ACKs duplicados (4 ACKs iguales en total), interpreta que ese segmento se perdió —pero que los siguientes sí llegaron— y lo retransmite inmediatamente sin esperar al timeout (RTO). De ahí el nombre fast: el RTO puede tardar cientos de ms; esto reacciona en cuanto llegan los duplicados. ¿Por qué 3 y no 1? Porque 1–2 duplicados pueden deberse a simple reordenación de paquetes en la red; 3 ya es señal fuerte de pérdida.

Por qué: UDP es mínimo a propósito: 4 campos de 2 bytes = puerto origen, puerto destino, longitud y checksum. Nada más: sin números de secuencia, sin acks, sin control de flujo ni congestión, sin conexión. Compárala con TCP: 20 bytes mínimo (puertos, seq, ack, flags, ventana, checksum, urgent + opciones). Esa ligereza es la razón de que DNS (líneas 3–4 de la captura), streaming o juegos usen UDP: menos overhead y sin esperar handshake.

Por qué: regla 1: el flag SYN consume exactamente 1 número de secuencia aunque no lleve datos. Regla 3: Ack = siguiente byte que espero = 12000 + 1 = 12001. El servidor dice literalmente: "recibí tu SYN (que ocupaba el seq 12000); lo próximo tuyo que espero empieza en 12001".

Por qué: el segmento cubre los bytes 12001…12350 (350 bytes: del 12001 al 12001+350−1). El servidor confirma con el siguiente byte que espera: 12001 + 350 = 12351. Fíjate en que el ack NO es "el último byte recibido" (12350) sino "el primero que falta" — error típico de examen.

Por qué: seguimos la secuencia del servidor: su SYN-ACK llevaba Seq=45000 y el SYN consumió 1 → su siguiente seq es 45001. Desde entonces el servidor no ha enviado ningún dato, solo acks, y (regla 4) los ACK puros no consumen secuencia → su Seq sigue siendo 45001. Por eso la línea 10 (su primer envío de datos) también sale con Seq=45001: el ack puro de la línea 9 no lo gastó.

Por qué: misma regla que la P31 pero en sentido contrario: el servidor ocupó los bytes 45001…46200 (1200 bytes), y el cliente pide el siguiente: 45001 + 1200 = 46201. Coincide con la línea 11 de la captura ✔.

Por qué: cuenta de seq del cliente: ISN 12000 → +1 por el SYN → 12001 → +350 por la petición → 12351. Después solo ha enviado ACKs puros (líneas 7 y 11), que no consumen. Así que su FIN sale con Seq = 12351. (Y el servidor lo confirmará con Ack = 12351+1 = 12352, porque el FIN consume 1: línea 13 ✔.)

Por qué: el MSS (Maximum Segment Size) es la cantidad máxima de datos de aplicación que caben en un segmento TCP sin provocar fragmentación IP: MSS = MTU − cab. IP − cab. TCP = 1500 − 20 − 20 = 1460. Cada extremo anuncia su MSS como opción en su SYN (se ve en las líneas 5 y 6 de la captura: "MSS=1460") y se usa el menor de los dos. Ojo al matiz: el MTU se mide en capa 2 (payload de la trama), el MSS en capa 4 (payload del segmento).

Paso a paso: 25000 / 1460 = 17,12… → 17 segmentos llenos no bastan (17 × 1460 = 24820 bytes), quedan 25000 − 24820 = 180 bytes → hace falta un 18.º segmento con esos 180. Total: 18. Siempre se redondea hacia arriba (función techo): cualquier resto, por pequeño que sea, necesita su propio segmento.

Paso a paso: "en vuelo" (in flight) = bytes enviados pero aún no confirmados por ACK = 5 × 1024 = 5120. El dato de rwnd = 8192 es el límite que impone el receptor (control de flujo): el emisor podría llegar a tener 8192 en vuelo, pero ahora mismo lleva 5120. Aún podría enviar 8192 − 5120 = 3072 bytes más (3 segmentos) antes de tener que parar a esperar ACKs.

Paso a paso:

1. BDP (Bandwidth-Delay Product) = ancho de banda × RTT.
2. 100 Mb/s = 100 000 000 bits/s. RTT = 50 ms = 0,05 s.
3. BDP = 10⁸ × 0,05 = 5 000 000 bits.
4. A bytes: 5 000 000 / 8 = 625 000 bytes.

Qué significa: es la cantidad de datos que "caben en la tubería": lo que el emisor puede haber enviado antes de que le llegue el primer ACK. Para aprovechar el enlace al 100%, la ventana TCP debe ser ≥ BDP; si la ventana es menor, el emisor pasa parte del RTT parado y el enlace queda infrautilizado.

Paso a paso (fórmula estándar de RFC 6298):

1. RTTVAR_nuevo = (1 − β) × RTTVAR_viejo + β × |SRTT − RTT_muestra|
2. Desviación de la muestra: |100 − 140| = 40 ms.
3. RTTVAR = (3/4) × 20 + (1/4) × 40 = 15 + 10 = 25 ms.

Qué es cada cosa: SRTT es la media suavizada del RTT (memoria de cómo viene tardando la red) y RTTVAR su variabilidad suavizada. Son medias móviles exponenciales: pesan mucho el pasado (3/4) y poco la muestra nueva (1/4), para que un pico aislado no desestabilice el temporizador. El enunciado dice "RTTVAR antes que SRTT" porque el orden importa: RTTVAR se calcula con el SRTT antiguo.

Paso a paso: RTO = 105 + 4 × 25 = 105 + 100 = 205 ms.

Qué significa: el RTO (Retransmission TimeOut) es cuánto espera el emisor un ACK antes de retransmitir por timeout. La fórmula tiene lógica: espera el tiempo típico (SRTT) más un margen de seguridad proporcional a lo variable que es la red (4 × RTTVAR). Red estable → RTTVAR pequeño → RTO ajustado; red errática → RTO holgado para no retransmitir en falso. Fíjate en que las preguntas 39 y 40 son una cadena: muestra RTT → RTTVAR → SRTT → RTO.

Por qué: en RIP cada router anuncia a sus vecinos un "vector" de pares (red, distancia). El que escucha aplica Bellman-Ford: si mi vecino llega a X con coste n, yo llego con n+1 por él; me quedo la mejor opción. Nadie ve la topología completa: es enrutamiento "por rumores", y de ahí vienen sus problemas (P43). Las otras familias: estado de enlace = OSPF/IS-IS (mapa completo + Dijkstra); vector camino = BGP (anuncia la ruta AS por AS); conmutación de circuitos ni siquiera es enrutamiento dinámico.

Por qué: RIP cuenta routers atravesados (hops) y nada más: cada router que reenvía el anuncio suma 1. Es simple pero ciego a la calidad de los enlaces: para RIP, dos saltos por enlaces de 10 Gb/s "cuestan más" que un salto por un enlace de 1 Mb/s saturado — elegiría el malo. OSPF corrige esto usando un coste basado en ancho de banda (b es su terreno). Y como infinito = 16, RIP solo sirve para redes de diámetro ≤ 15 saltos.

Por qué, con el caso del enunciado: R1 pierde la Red X. Pero R2 aún tiene en su tabla "Red X a 2 por R1", y se lo anuncia a todos — incluido R1. R1, que ya no tiene ruta, se lo cree: "R2 llega a 2 → yo llego a 3 por R2". En el siguiente ciclo R2 recalcula por el anuncio de R1: "a 4 por R1"… y así suben de 2 en 2, realimentándose con información obsoleta, formando además un bucle de reenvío entre ambos. Solo paran al llegar a 16 = infinito, cuando por fin declaran la red inalcanzable. Por eso el infinito de RIP es tan bajo: limita cuánto dura esta cuenta.

Por qué: split horizon ("horizonte dividido") ataca la raíz del count-to-infinity: la realimentación. Si R2 aprendió la ruta a Red X de R1, no tiene sentido que se la anuncie de vuelta a R1 — R1 ya la conoce mejor, y devolvérsela solo sirve para engañarlo cuando la pierda. En el caso de la P43: con split horizon, R2 nunca anuncia "Red X por R1" hacia R1, así que cuando R1 pierde la red, no recibe el rumor falso y el bucle R1↔R2 no se forma. Variante reforzada: poison reverse — sí se la anuncia, pero con métrica 16 ("para ti, esa ruta está envenenada"), que es un rechazo explícito. Limitación honesta: evita bucles de 2 routers, pero no todos los bucles con 3 o más.

Por qué: RIP define que una métrica de 16 saltos = inalcanzable; el camino útil más largo es de 15 saltos. Es un compromiso de diseño: un infinito bajo hace que el count-to-infinity termine rápido (de 2 se sube a 16 en pocos ciclos de 30 s), a cambio de limitar el tamaño de red que RIP puede manejar. También se usa como veneno: poison reverse anuncia rutas con 16 precisamente para decir "no vayas por mí".