El enunciado da una distancia ("backbone de 105 m", "sedes a 2 km") o una condición ambiental ("alta interferencia", "zona industrial", "junto a motores"). A veces ambas.

1. Localiza la distancia y compárala con los umbrales: ≤100 m → cobre · cientos de m → multimodo · km → monomodo.
2. Si supera 100 m aunque sea por poco (105 m), el cobre queda descartado: fuera de norma, no se certifica.
3. ¿Menciona interferencia/ruido y la distancia permite cobre? → versión apantallada (siglas con S o F: STP, FTP, F/UTP, S/FTP). Con interferencia extrema, fibra (inmune total).
4. Descarta automáticamente: coaxial (obsoleto en LAN), hubs/repetidores pasivos (no son medios), inalámbrico para backbone.

«Hay que cablear un tramo de 350 m entre dos edificios del campus y otro de 80 m dentro de una nave con maquinaria pesada.» → 350 m > 100 m → fibra multimodo OM4 para el primero. 80 m ≤ 100 m pero "maquinaria pesada" = EMI → Cat 6A apantallado (S/FTP) para el segundo.

«Cat 6A llega porque 105 está cerca de 100» ✗ (la norma es estricta). «Monomodo para 200 m» — funcionaría, pero la respuesta "que mejor encaja" suele ser multimodo: más barata y pensada para esa escala. Elige el medio proporcionado a la distancia.

| Preámbulo 7+1 | MAC dst 6 | MAC src 6 | EtherType 2 | Payload 46–1500 | FCS 4 |

• Preámbulo+SFD: sincronización; Wireshark no los muestra (los quita la NIC).
• EtherType: qué protocolo va dentro. 0x0800=IPv4, 0x0806=ARP, 0x86DD=IPv6.
• FCS: CRC-32. Solo detecta errores → trama corrupta se descarta, sin retransmitir (eso es cosa de TCP).
• Trama mínima 64 B = 14 cabecera + 46 payload mínimo (se rellena con padding) + 4 FCS. Herencia de CSMA/CD: la trama debe durar más que el viaje de ida y vuelta de una colisión (slot time).

Preguntas directas: "¿qué representa el campo de 2 bytes?", "¿payload mínimo?", "¿para qué sirve el FCS?", "escribe la MAC broadcast" (FF:FF:FF:FF:FF:FF, 48 bits a 1, no cruza routers).

Regla del 1536: el campo de 2 bytes tras las MACs se interpreta así: ≥ 1536 (0x0600) → EtherType → Ethernet II; ≤ 1500 → longitud → IEEE 802.3 (con LLC/SNAP). No es ambiguo porque el payload nunca supera 1500. Si te dan el valor en hex, pásalo a decimal y compara.

«El campo vale 0x0806.» → 0x0806 = 2054 ≥ 1536 → es EtherType → trama Ethernet II llevando ARP. · «El campo vale 0x004E.» → 78 ≤ 1500 → longitud → IEEE 802.3, payload de 78 bytes.

"FCS retransmite/corrige" ✗ solo detecta y descarta. "Número de secuencia Ethernet" ✗ no existe. "Checksum TCP en la trama" ✗ mezcla de capas. El payload mínimo es 46, no 64 (64 es la trama entera).

"Diferencia hub/switch", "¿quién separa dominios de colisión/broadcast?", o preguntas de CSMA/CD (siguiente ficha, van de la mano).

Memoriza el doble eslogan: «hub repite, switch decide» y «switch separa colisiones, router separa broadcasts». Para saber por dónde reenvía un switch: ¿la MAC destino está en su tabla? sí → solo ese puerto; no o broadcast → todos menos el de entrada.

«Un switch recibe en el puerto 3 una trama con MAC destino desconocida, ¿qué hace?» → la inunda por todos los puertos menos el 3, y de paso apunta la MAC origen en su tabla asociada al puerto 3.

El protocolo de acceso al medio del Ethernet compartido: (1) escucha antes de transmitir; (2) transmite mientras sigue escuchando; (3) si detecta colisión: aborta, señal de jam, espera aleatoria (backoff exponencial) y reintenta.

"¿Cuál es la afirmación correcta sobre CSMA/CD?" o "¿hay colisiones en X escenario?".

Tradúcelo a la pregunta real: ¿medio compartido o conmutado? Hub / coaxial / half-duplex → CSMA/CD activo, colisiones posibles. Switch full-duplex (lo normal hoy) → carriles separados TX/RX, colisiones imposibles, CSMA/CD desactivado/irrelevante.

«Dos PCs conectados a un switch full-duplex transmiten a la vez, ¿colisionan?» → No: cada enlace es punto a punto full-duplex; el switch almacena y reenvía. CSMA/CD ni interviene.

"CSMA/CD evita colisiones" ✗ las detecta (quien evita es CSMA/CA, el de WiFi). "Escucha después de transmitir, no antes" ✗ escucha antes Y durante. "Obligatorio en fibra moderna" ✗ la fibra moderna es full-duplex conmutado.

Una IP con máscara /n divide sus 32 bits en n bits de red + (32−n) bits de host. La dirección de red tiene los bits de host a 0; el broadcast, a 1; entre medias están los hosts utilizables.

"Dada la IP X/n, indica la dirección de red / broadcast / primer y último host / cuántos hosts caben". También encubierto: "¿están A y B en la misma red?" o "¿qué máscara necesito para 50 hosts?".

1. Bits de host = 32 − n. Tamaño de bloque = 2^(bits de host) (atajo: 256 − octeto de la máscara).
2. Red = múltiplo del bloque inmediatamente ≤ al octeto interesante de la IP.
3. Broadcast = red + bloque − 1. Hosts = del red+1 al broadcast−1 → 2^(32−n) − 2 utilizables.

Bloques que conviene saber de memoria: /24→256 · /25→128 · /26→64 · /27→32 · /28→16 · /29→8 · /30→4 (2 hosts: enlaces router-router).

«172.16.5.200/27» → bits host = 5 → bloque = 32 → múltiplos: 0,32,…,160,192,224. 200 cae entre 192 y 223 → red 172.16.5.192, broadcast 172.16.5.223, hosts .193–.222 (30 = 2⁵−2).
«¿Misma red 192.168.10.34/24 y 192.168.20.10/24?» → aplica /24 a ambas: 192.168.10.0 vs 192.168.20.0 → no → hará falta gateway (esto conecta con el Tema 4).

Contar la red y el broadcast como hosts ✗ (siempre −2). Confundir "primer host" (.193 en el ejemplo) con la red (.192). Con /26 y octeto 77: la red es 64, no 77 redondeado a 70 ni nada raro: múltiplo del bloque.

Cuando varias rutas de la tabla "contienen" al destino, el router usa la de prefijo más largo (máscara mayor): es la información más específica. La default 0.0.0.0/0 encaja con todo y por eso solo gana en último recurso. El next hop de cada ruta debe ser un vecino directamente alcanzable (en una red conectada del router).

"Una tabla tiene rutas a X/16, Y/24 y 0.0.0.0/0; para el destino Z, ¿cuál se usa?" · "¿Qué representa 0.0.0.0/0?" · "¿Qué debe ser el next hop de una ruta estática?"

1. Filtra: para cada ruta, ¿el destino encaja en su prefijo? (aplica la máscara de la ruta al destino y compara).
2. Elige: de las que encajan, la de /n más alto. El orden en la tabla da igual.

Tabla: 10.0.0.0/8 · 10.20.0.0/16 · 10.20.30.0/24 · 0.0.0.0/0. Destino 10.20.30.40: encaja en las cuatro → gana 10.20.30.0/24. Destino 10.99.1.1: encaja en /8 y /0 → gana 10.0.0.0/8. Destino 8.8.8.8: solo encaja la default → 0.0.0.0/0.

"La primera de la tabla" ✗. "La default siempre que exista" ✗ (es la última opción, no la primera). Direcciones especiales que debes reconocer para descartar: 255.255.255.255 broadcast limitado · 127.0.0.0/8 loopback · 224.0.0.0/4 multicast.

El datagrama IP lleva IP origen y destino de los extremos y no cambian en todo el viaje (sin NAT). La trama Ethernet se destruye y reconstruye en cada salto: sus MACs son las de los extremos del tramo actual. El emisor decide si el destino es local aplicando su máscara: si no lo es, entrega al gateway.

"¿Qué MAC destino lleva la primera trama que sale de PC-A?" · "¿Qué IP destino lleva el datagrama en el tramo R1→R2?" · Cualquier pregunta con un dibujo PC→R1→R2→SRV y la palabra "trama" o "datagrama".

1. Dibuja el camino y marca el tramo por el que preguntan.
2. IPs = extremos de la comunicación (siempre las mismas).
3. MACs = extremos del tramo marcado (cambian en cada salto).
4. La MAC del destino final solo aparece en el último tramo.

PC-B (172.16.1.5) envía a un servidor (203.0.113.7) por la ruta PC-B → R1 → R2 → SRV. Tramo R1→R2: IP origen 172.16.1.5, IP destino 203.0.113.7 (intactas); MAC origen = interfaz de salida de R1, MAC destino = interfaz de entrada de R2. En ningún tramo viaja la MAC del servidor salvo en el último.

"La primera trama lleva la MAC de SRV" ✗ (ARP no puede resolverla: está en otra red). "La IP destino es la del gateway" ✗ (el gateway se usa en capa 2, no se escribe en el datagrama). "MAC broadcast siempre" ✗ (solo el ARP Request va en broadcast).

Traduce «IP de mi siguiente salto → su MAC», solo dentro de la LAN. Funciona con Request en broadcast («¿quién tiene 192.168.10.1?») y Reply en unicast («yo: CC:CC:…»). Va directo sobre Ethernet (EtherType 0x0806), no usa IP ni TCP. El resultado se guarda en la caché ARP. Como el broadcast no cruza routers, ARP no cruza routers.

"Afirmación correcta sobre ARP" · y el cálculo clásico: "con cachés vacías, ¿cuántos ARP Request se generan en la ida?"

Receta del conteo: nº de ARP Request = nº de tramos Ethernet del camino = routers + 1 (con todas las cachés vacías). Ajustes: si una caché ya conoce a su siguiente salto, resta ese tramo. La vuelta no genera ARP nuevos: cada equipo apuntó la MAC del que le habló en la ida.

Secuencia completa al enviar (sirve para ordenar cualquier pregunta): (1) ¿destino local? (máscara) → (2) tabla de rutas: siguiente salto → (3) ¿MAC en caché? si no, ARP → (4) construir trama.

Camino PC → R1 → R2 → R3 → SRV, cachés vacías: tramos = PC-R1, R1-R2, R2-R3, R3-SRV → 4 ARP Request. Mismo camino pero PC ya tiene al gateway en caché → 3.

"ARP cruza routers si el destino está lejos" ✗. "ARP viaja en TCP" ✗. "ARP sustituye a la tabla de rutas" ✗ (la complementa: la tabla decide el salto, ARP averigua su MAC). Los switches NO cuentan como tramos: son de capa 2.

El TTL evita paquetes dando vueltas eternas en bucles: cada router resta 1; al llegar a 0, descarta + ICMP Time Exceeded (tipo 11) al origen. ICMP es el mensajero de errores/diagnóstico de IP. Los tres que caen: 11 Time Exceeded (TTL) · 3/4 Destination Unreachable "Fragmentation needed" (no cabe y DF=1) · 8/0 Echo Request/Reply (ping).

"Si el TTL llega a cero…" · "Un datagrama con DF=1 no cabe en la MTU…" · "¿Con qué TTL llega al destino?" · menciones a traceroute.

TTL al llegar = TTL inicial − nº de routers atravesados. Decisión del router que no puede reenviar por tamaño: DF=0 → fragmenta · DF=1 → descarta + ICMP 3/4 (este aviso lleva la MTU del enlace y es la base de Path MTU Discovery). Traceroute = enviar con TTL 1, 2, 3… para que cada router se delate con su Time Exceeded.

«Un paquete sale con TTL=64 y atraviesa 3 routers, ¿con qué TTL llega?» → 64−3 = 61. «¿Y si sale con TTL=2?» → R1 lo deja en 1, R2 lo deja en 0 → R2 lo descarta y envía Time Exceeded; nunca llega.

"El router reinicia el TTL" ✗ nadie lo recarga. "Con DF=1 fragmenta igualmente" ✗ DF es una prohibición. "El host destino genera el Time Exceeded" ✗ lo genera el router donde expiró.

Si un datagrama no cabe en el MTU del enlace de salida (y DF=0), el router lo trocea. Campos: Identification (mismo en todos los fragmentos, para agruparlos) · MF = More Fragments (1 en todos menos el último) · Fragment Offset = posición de los datos en unidades de 8 bytes. Cada fragmento lleva copia de la cabecera IP; la cabecera TCP/UDP solo va en el primero (offset 0), porque IP trocea su payload a ciegas. Reensambla únicamente el host destino (los routers ni pueden ni deben: tendrían que retener fragmentos que quizá viajan por otros caminos).

"Cada router reensambla" ✗ · "todos los fragmentos llevan cabecera TCP" ✗ · offset en bytes en vez de unidades de 8 ✗ · olvidar que el offset cuenta solo DATOS (sin los 20 de cabecera) ✗.

El enunciado da Total Length (o tamaño del datagrama), cabecera (20 B) y un MTU, y pide: payload máximo ajustado, nº de fragmentos, offset/MF de un fragmento concreto, o tamaño del último.

1. Payload por fragmento = MTU − 20, redondeado HACIA ABAJO a múltiplo de 8: ⌊(MTU−20)/8⌋×8.
2. Datos totales = Total Length − 20.
3. Nº fragmentos = ⌈datos / payload⌉. El último lleva el resto.
4. Offset del fragmento n = (n−1) × payload / 8. (Cada fragmento suma payload/8.)
5. MF = 1 en todos menos el último (MF=0).

«Datagrama de Total Length = 3000 B, cabecera 20 B, MTU = 620 B. ¿Fragmentos, y offset del 3.º?»

1. Payload = 620−20 = 600; ¿múltiplo de 8? 600/8 = 75 ✔ → 600.
2. Datos = 3000−20 = 2980.
3. Fragmentos = ⌈2980/600⌉ = ⌈4,97⌉ = 5 (4 de 600 y el último de 580).
4. Offset del 3.º = 2×600/8 = 150. (Serie completa: 0, 75, 150, 225, 300.)
5. MF: 1,1,1,1,0.

Comprobación rápida: el último fragmento empieza en byte 4×600 = 2400 y lleva 580 → 2400+580 = 2980 ✔ todos los datos cubiertos.

Los puertos (16 bits, 0–65535) identifican la aplicación. Rangos: 0–1023 bien conocidos (80 HTTP, 443 HTTPS, 53 DNS, 22 SSH, 25 SMTP) · 1024–49151 registrados · 49152–65535 dinámicos/efímeros (los elige el SO del cliente al azar). Una conexión se identifica por su quíntupla: IP origen, puerto origen, IP destino, puerto destino, protocolo. Cabeceras: TCP 20 B · UDP 8 B (solo puertos, longitud y checksum: sin conexión, sin fiabilidad, sin orden — por eso lo usan DNS, streaming, juegos).

"Rango de puertos efímeros" · "quíntupla de la conexión X de la captura" · "bytes de la cabecera UDP".

Para la quíntupla: busca el SYN en la captura (su emisor es el cliente) y copia IP.src, port.src, IP.dst, port.dst + TCP. El puerto bajo te dice el servicio; el alto y raro es el efímero del cliente. Descarta opciones con el protocolo equivocado (UDP en una conexión web TCP) o con puertos de otro flujo (53 = DNS, no web).

Captura: 10.1.1.5:61234 → 93.184.216.34:443 [SYN] → quíntupla: 10.1.1.5, 61234, 93.184.216.34, 443, TCP. 61234 ≥ 49152 → efímero ✔; 443 → HTTPS.

TCP numera cada byte. Seq = primer byte que transporta este segmento; Ack = siguiente byte que espero recibir (acumulativo). Las 4 reglas:

1. SYN y FIN consumen 1 número de secuencia (byte fantasma).
2. Los datos consumen Len (tantos como bytes lleven).
3. Ack = Seq recibido + Len (o +1 si era SYN/FIN) = "primer byte que me falta", no "último recibido".
4. Los ACK puros (Len=0) no consumen: enviar acks no avanza tu Seq.

Estructura de una conexión: handshake SYN → SYN-ACK → ACK (cliente inicia) · intercambio de datos · cierre FIN → ACK(+FIN) → ACK; quien cierra primero acaba en TIME_WAIT. UDP no tiene nada de esto.

Cadenas de 4–6 preguntas sobre una captura: "¿qué Ack devuelve el SYN-ACK?", "¿qué Ack confirma estos N bytes?", "¿qué Seq lleva el ACK puro / el FIN?".

Método de los dos contadores. En el borrador escribe dos líneas, una por lado, y ve sumando:

• Contador del cliente: ISN → +1 (su SYN) → +Len de cada envío suyo → +1 (su FIN).
• Contador del servidor: igual con sus números.
• Seq de cualquier segmento = valor actual del contador de quien envía. Ack = contador del otro lado (lo que llevas recibido de él + las consumiciones de sus flags).

Cliente ISN=5000, servidor ISN=9000. Petición de 200 B, respuesta de 800 B, cierra el cliente:

Responder "último byte recibido" en vez de "siguiente esperado" (off-by-one clásico). Mezclar los contadores de los dos lados. Olvidar que el ACK puro no consume (por eso el Seq se "repite" en la siguiente línea). Olvidar el +1 del SYN al calcular el Seq del primer dato.

TCP detecta pérdidas de dos formas: timeout (RTO) — lento, último recurso — y fast retransmit: si llegan 3 ACK duplicados (el receptor repite "sigo esperando el byte X" porque le llegan segmentos posteriores), el emisor retransmite ese segmento sin esperar al RTO. Son 3 y no 1 porque uno o dos duplicados pueden ser simple reordenación de la red.

"¿Qué evento dispara fast retransmit?" o un enunciado que describa "ACKs repetidos pidiendo el mismo byte".

El emisor manda segmentos con Seq 1000, 2000, 3000, 4000 (1000 B cada uno) y se pierde el de 2000. El receptor responde Ack=2000, Ack=2000, Ack=2000, Ack=2000 → al 3.er duplicado el emisor retransmite el segmento de Seq 2000 inmediatamente.

MSS (Maximum Segment Size) = datos de aplicación máximos por segmento TCP sin provocar fragmentación IP. Se anuncia como opción en el SYN de cada extremo y se usa el menor. La cadena de tamaños: datos ≤ MSS → +20 TCP → +20 IP ≤ MTU → +18 Ethernet.

"Con MTU X, ¿cuál es el MSS?" · "¿Cuántos segmentos genera enviar N bytes con MSS M?"

MSS = MTU − 20 (IP) − 20 (TCP) · segmentos = ⌈datos / MSS⌉ (redondeo SIEMPRE hacia arriba; el último va parcial). Mismo patrón "total/unidad" que los fragmentos IP, sin la regla del múltiplo de 8.

«MTU 1400» → MSS = 1400−40 = 1360. «Enviar 10 000 B con MSS 1360» → 10000/1360 = 7,35 → 8 segmentos (7 llenos = 9520 B y el 8.º con 480 B).

rwnd (receive window): cuántos bytes acepta el receptor sin confirmar — control de flujo. Bytes en vuelo: enviados pero aún sin ACK. El emisor debe cumplir: en vuelo ≤ ventana.

"Ha enviado N segmentos completos sin recibir ACK, ¿cuántos bytes están en vuelo?" — a menudo con un rwnd de cebo.

en_vuelo = segmentos sin ACK × MSS. margen = rwnd − en_vuelo. Lee qué piden: lo que HAY en vuelo (multiplicación) o lo que PODRÍA enviar aún (resta).

«rwnd = 16 384, MSS = 1460, 6 segmentos sin ACK» → en vuelo = 6×1460 = 8760 B. Podría enviar aún: 16384−8760 = 7624 B (5 segmentos más).

Los datos que "caben en la tubería": lo que puedes haber enviado antes de que vuelva el primer ACK. Para saturar el enlace, la ventana debe ser ≥ BDP; si es menor, el emisor pasa parte del RTT parado.

"Enlace de X Mb/s con RTT = Y ms, ¿BDP en bytes?"

BDP(bytes) = BW(bits/s) × RTT(s) / 8. Checklist de unidades: Mb/s → ×10⁶ · ms → ÷1000 · bits → ÷8. Atajo: pasa primero el BW a bytes/s (÷8) y multiplica por el RTT en s.

«50 Mb/s, RTT 80 ms» → 50×10⁶ × 0,08 = 4×10⁶ bits → /8 = 500 000 bytes. (Atajo: 50 Mb/s = 6,25 MB/s; ×0,08 s = 0,5 MB ✔.)

Olvidar ÷8 (dar bits como bytes) y olvidar ms→s son LOS dos errores. Si tu resultado parece enorme o ridículo, revisa unidades.

TCP estima cuánto esperar un ACK antes de retransmitir (RTO) a partir de medias móviles suavizadas del RTT: SRTT (media, α=1/8) y RTTVAR (variabilidad, β=1/4). Pesan mucho el pasado para que un pico aislado no desestabilice el temporizador. Red estable → RTO ajustado; red errática → RTO holgado.

"Llega una muestra RTT = X, calcula el nuevo RTTVAR / SRTT / RTO". Suelen ser 2 preguntas encadenadas, te dan los pesos (β=1/4) en el enunciado.

Orden estricto (RTTVAR usa el SRTT viejo):

1. RTTVAR ← ¾·RTTVAR + ¼·|SRTT − RTT|
2. SRTT ← ⅞·SRTT + ⅛·RTT
3. RTO = SRTT + 4·RTTVAR

«SRTT = 200 ms, RTTVAR = 50 ms, llega muestra RTT = 120 ms»:

1. |200−120| = 80 → RTTVAR = ¾·50 + ¼·80 = 37,5 + 20 = 57,5 ms
2. SRTT = ⅞·200 + ⅛·120 = 175 + 15 = 190 ms
3. RTO = 190 + 4·57,5 = 190 + 230 = 420 ms

Calcular SRTT antes que RTTVAR (cambia el resultado). Olvidar el valor absoluto en |SRTT−RTT|. Usar α donde va β. El enunciado del profesor avisa del orden ("calculando RTTVAR antes que SRTT"): hazle caso.

Protocolo de vector distancia: cada router solo sabe lo que le anuncian sus vecinos («llego a X con coste n») y aplica Bellman-Ford: «entonces yo llego con n+1; me quedo lo mejor». Nadie ve el mapa completo (enrutamiento "por rumores"). Datos fijos: métrica = saltos · anuncios cada 30 s · UDP/520 · infinito = 16 (máximo útil 15 saltos). Familias para clasificar protocolos: vector distancia = RIP · estado de enlace = OSPF (mapa completo + Dijkstra, coste por ancho de banda) · vector camino = BGP.

"¿A qué familia pertenece RIP?" · "¿qué métrica usa?" · "¿qué valor es infinito?" · cálculo de métricas en un diagrama en cadena.

Para métricas en un diagrama R1—R2—R3 con Red X colgando de R1: R1 anuncia Red X con 1 (directamente conectada), R2 la aprende con 2, R3 con 3. Cada router que reenvía el anuncio suma 1. Ceguera de RIP: solo cuenta saltos, no calidad: preferiría 1 salto lento a 2 rápidos.

«Cadena R1—R2—R3—R4, Red Y conectada a R4. ¿Métrica de R1 hacia Red Y?» → R4 anuncia 1 → R3: 2 → R2: 3 → R1: 4.

Count-to-infinity: al caer una red, dos routers pueden realimentarse rutas obsoletas el uno al otro («yo llego por ti» ↔ «pues yo por ti»), subiendo la métrica paso a paso hasta llegar a 16 — con bucle de reenvío incluido mientras tanto. Por eso el infinito es tan bajo: corta antes la agonía.

Las 4 mitigaciones, cada una en una frase:

• Split horizon: no anuncio a un vecino las rutas que aprendí DE ese vecino (no devolver rumores).
• Poison reverse: sí se las anuncio, pero con métrica 16 (rechazo explícito).
• Hold-down timers: tras una caída, ignoro un tiempo las "resurrecciones" sospechosas de esa ruta.
• Triggered updates: anuncio los cambios al instante, sin esperar el ciclo de 30 s.

"¿Qué describe count-to-infinity?" · "¿Qué regla aplica split horizon?" · enunciados tipo "si R1 pierde la Red X, ¿qué puede pasar entre R2 y R3?".

Reconoce el patrón: red caída + vecinos anunciándola todavía + métrica subiendo poco a poco = count-to-infinity. Para las mitigaciones, identifica la conducta descrita y ponle nombre con la lista de 4. Split horizon corta los bucles de 2 routers; con 3 o más pueden hacer falta las demás.

«R1 pierde la Red X. R2 tenía "X a 2 por R1" y se lo anuncia a R1; R1 instala "X a 3 por R2"; R2 recalcula "X a 4 por R1"…» → count-to-infinity de libro; para cuando ambos llegan a 16 declaran X inalcanzable. Con split horizon, R2 jamás habría anunciado X hacia R1 (la aprendió de él) y el bucle no se forma.