En Ethernet II ese campo dice qué protocolo viaja dentro para entregarlo al subir la pila: 0x0800=IPv4, 0x0806=ARP, 0x86DD=IPv6. El checksum TCP vive en TCP (a), Ethernet no tiene números de secuencia (b), y la "longitud" sería el caso de IEEE 802.3, no Ethernet II (c).

El par trenzado está limitado a 100 m por norma; a 105 m queda fuera y no se certifica, así que "casi llega" no vale (b). La multimodo OM4 cubre cientos de metros y es el medio típico de backbone vertical entre plantas. Coaxial está obsoleto en LAN (c) y Bluetooth no es un backbone fiable (a).

Son los 48 bits a 1: significa "para todos los equipos de esta LAN". La usa el ARP Request. No cruza routers (delimita el dominio de broadcast).

Como el payload máximo es 1500, una "longitud" nunca puede valer 1536 o más. Por eso se fijó el umbral: ≥1536 (0x0600) = EtherType = Ethernet II; ≤1500 = longitud = IEEE 802.3. Ejemplo: 0x0800 = 2048 ≥ 1536 → Ethernet II con IPv4.

La palabra clave es interferencia electromagnética. El UTP normal solo se defiende con el trenzado; con ruido fuerte hacen falta las versiones apantalladas (F/UTP, S/FTP, STP), que llevan lámina/malla a tierra. Llevar monomodo a cada puesto (b) es desproporcionado y carísimo para el tramo horizontal; el cable cruzado (a) no tiene nada que ver con el ruido; Cat 5 sin apantallar (d) es lo peor aquí.

El hub (capa 1) repite la señal a todos los puertos: un único dominio de colisión. El switch (capa 2) aprende las MAC origen en su tabla CAM y reenvía cada trama solo por el puerto de la MAC destino; cada puerto es su propio dominio de colisión. Las demás opciones invierten capas (c) o niegan lo que define al switch (d).

2 km = 2000 m. El cobre muere en 100 m (b). La multimodo llega a ~400–550 m: a 2 km la dispersión degrada la señal (c). La monomodo aguanta decenas de km y es el estándar para enlaces entre sedes. La opción d ni siquiera es un medio.

El cable tiene 4 pares. 10BASE-T y 100BASE-TX usan 2 pares (uno para transmitir, otro para recibir). 1000BASE-T (Gigabit) usa los 4 pares a la vez, en ambos sentidos, para repartir la velocidad. La c lo dice al revés; la d es falsa (los 4 pares existen en RJ-45).

La trama mínima son 64 bytes. Restando 14 de cabecera (6+6+2) y 4 de FCS: 64 − 18 = 46. Si los datos son menos, se rellena con padding. El 64 viene de CSMA/CD (slot time).

Esta es la que no pude leer con total nitidez, así que va a nivel conceptual: el DTE (Data Terminal Equipment) es el equipo terminal que genera o consume los datos (un PC, un router). El DCE (Data Communication Equipment) es el equipo que conecta el DTE a la red y proporciona la señal de reloj/adapta al medio (un módem, una CSU/DSU). La opción correcta será la que diga algo como "el DCE adapta/sincroniza y el DTE es el equipo terminal". Descarta cualquiera que mezcle DTE/DCE con direcciones IP, con TCP o con firewalls.

El campo Protocol dice qué hay dentro del datagrama IP. Los tres de memoria: 1 = ICMP, 6 = TCP, 17 = UDP. ARP no va dentro de IP (va directo sobre Ethernet), así que nunca aparece aquí.

El next hop tiene que ser una IP a la que el router entregue directamente, es decir, un vecino en una de sus redes conectadas (p. ej. en R1, la ruta a 192.168.20.0/24 tiene next hop 10.0.0.2, que es R2). Las MAC no aparecen en tablas de rutas (a), y el broadcast no es un destino de reenvío (d).

17 = UDP. Recuerda la terna: 1 ICMP · 6 TCP · 17 UDP. Ethernet (d) es capa 2, no aparece en el campo Protocol de IP.

Regla del prefijo más largo: el destino encaja en las tres rutas, pero gana la de máscara mayor (la más específica): /24 > /16 > /0. El orden físico en la tabla da igual (a). La default /0 solo se usaría si no hubiera nada mejor.

PC-A ve que SRV está fuera de su red (192.168.20.10 no encaja en 192.168.10.0/24) → entrega al gateway. La trama vive solo en la LAN local, así que su MAC destino es la del siguiente salto: R1. No puede ser la de SRV (otra red, ARP no la resuelve) ni broadcast (eso solo lo usa el ARP Request).

El ping usa ICMP Echo. Que no responda tiene muchas causas posibles: un firewall que filtra ICMP, pérdida de paquetes, ruta mal configurada o el host caído. No demuestra ninguna en concreto. El puerto TCP 80 (a) no tiene que ver con ICMP, y el host podría estar encendido pero filtrando (b).

MF (More Fragments) vale 1 en todos los fragmentos menos el último, y 0 en el último para indicar "ya no vienen más". Así el destino sabe cuándo tiene la pieza final. No depende del protocolo de transporte (c).

Paso a paso:

1. Payload ajustado por fragmento = ⌊(1000−20)/8⌋×8 = ⌊980/8⌋×8 = 122×8 = 976 B.
2. Datos a repartir = 4500 − 20 = 4480 B.
3. Fragmentos = ⌈4480 / 976⌉ = ⌈4,59⌉ = 5 (cuatro de 976 B y uno de 576 B).

1000 − 20 = 980, pero el offset se mide en bloques de 8 bytes, así que el payload debe ser múltiplo de 8: 980/8 = 122,5 → bajamos a 122×8 = 976.

Son 5 fragmentos; el último es el 5.º. Antes de él van 4 fragmentos de 976 B = 3904 bytes de datos. El offset se expresa en unidades de 8: 3904 / 8 = 488.

El último fragmento lleva los datos que sobran: 4480 − (4×976) = 4480 − 3904 = 576 B de datos. Como cada fragmento añade su propia cabecera IP de 20 B: Total Length = 576 + 20 = 596.

La IP destino identifica al receptor final y no cambia en ningún salto (los routers la necesitan intacta para enrutar). Lo que cambia salto a salto son las MAC. La d ni es una IP (es una MAC).

/26 → 32−26 = 6 bits de host → 2⁶ = 64 direcciones por bloque. Se restan la de red y la de broadcast: 64 − 2 = 62 hosts útiles.

ARP no cruza routers, así que cada tramo Ethernet resuelve la MAC de su siguiente salto: PC-A→R1 (1), R1→R2 (2), R2→SRV (3) = 3 ARP Request. Los switches no cuentan (son capa 2).

/26 → bloque de 64. Múltiplos: .0, .64, .128… 77 cae en el bloque que empieza en .64 (esa es la red). El broadcast es la última del bloque: 64 + 64 − 1 = .127. Hosts útiles: .65–.126.

Un socket es IP + puerto. El cliente es PC-A (192.168.10.34) y usa un puerto efímero (≥49152) que el SO eligió para esta conexión; en la captura es el 52344. El servidor sería 192.168.20.10:80.

El FIN consume 1 número de secuencia. El cliente confirma el siguiente byte esperado: 46201 + 1 = 46202.

2¹⁶ = 65 536 valores, numerados del 0 al 65535.

RTTVAR = (1−β)·RTTVAR + β·|SRTT − RTT| = ¾·20 + ¼·|100−140| = 15 + ¼·40 = 15 + 10 = 25 ms. (Se usa el SRTT viejo, antes de actualizarlo.)

⌈25000 / 1460⌉ = ⌈17,12⌉ = 18. Diecisiete segmentos llenos (17×1460 = 24 820 B) y uno final con los 180 B restantes.

Cuatro campos de 2 bytes: puerto origen, puerto destino, longitud y checksum. Frente a los 20 B mínimos de TCP.

SRTT = (1−α)·SRTT + α·RTT = ⅞·100 + ⅛·140 = 87,5 + 17,5 = 105 ms.

Cada segmento añade 20 + 20 = 40 B de cabeceras. Con 18 segmentos: 18 × 40 = 720 bytes.

BDP = ancho de banda × RTT = 100·10⁶ bits/s × 0,05 s = 5·10⁶ bits. A bytes: 5 000 000 / 8 = 625 000 bytes. (Atajo: 100 Mb/s = 12,5 MB/s; × 0,05 s = 0,625 MB.)

El checksum UDP sí existe y cubre la cabecera + los datos + una pseudocabecera IP. En IPv4 es opcional (se puede dejar a 0, porque IPv4 ya tiene su propio checksum de cabecera); en IPv6 es obligatorio, porque IPv6 eliminó el checksum de la cabecera IP y UDP debe protegerse solo. La a y la b son falsas; la d lo dice al revés.

Puertos, número de secuencia, ACK, flags, ventana, checksum y puntero urgente: 20 bytes sin opciones (puede crecer hasta 60 con opciones).

Si el emisor recibe 3 ACK duplicados (el receptor repite "espero el mismo byte" porque le llegan segmentos posteriores), retransmite ese segmento sin esperar al timeout. Son 3 y no 1 porque uno o dos duplicados pueden deberse a simple reordenación.

17 segmentos llenos = 17 × 1460 = 24 820 B. El último lleva lo que sobra: 25000 − 24820 = 180 bytes.

El cliente mandó el SYN con Seq=12000; como el SYN consume 1, su siguiente número es 12001. El tercer paso del handshake (el ACK al SYN-ACK) sale con Seq = 12001 y Ack = 45001.

El servidor empezó su secuencia en 45000 (SYN-ACK); el SYN consumió 1 → 45001. Desde entonces solo había mandado ACK puros, que no consumen secuencia, así que su Seq sigue en 45001. Esos 1200 B ocupan del 45001 al 46200; por eso su FIN posterior sale con 46201 (pregunta 27).

Split horizon evita bucles: si aprendí una ruta de un vecino, no se la vuelvo a anunciar a él. Así, cuando esa red cae, el vecino no recibe un "rumor" que le haga creer que aún existe (origen del count-to-infinity). Las demás opciones mezclan conceptos de otros temas (fragmentación, ARP).

RIP difunde su tabla completa a los vecinos cada 30 s. (Otros temporizadores asociados: invalid 180 s, flush 240 s — por si los piden.)

RIP viaja sobre UDP puerto 520. (RIPng, la versión para IPv6, usa el 521.)

RIPv1 era classful (no enviaba la máscara). RIPv2 añade soporte classless/CIDR con VLSM (envía la máscara en cada ruta), además de multicast (224.0.0.9) y autenticación. Sigue siendo vector distancia sobre UDP/520 con infinito = 16, así que a, b y c son falsas.

RIP cuenta routers atravesados (hops), nada más; es ciego a la calidad del enlace. El ancho de banda como métrica es de OSPF (a). Con infinito = 16, RIP solo sirve para redes de ≤15 saltos.