Segunda sesión de gimnasio, y subimos peso: los protocolos del módulo 2. Aquí ya no basta la lógica de andar por casa — hay que leer tramas, seguir números de secuencia, interpretar salidas de ping y arp, y reconstruir conversaciones DNS y DHCP. Son los músculos que más vas a usar en tu vida profesional: prácticamente cualquier incidencia de red se diagnostica con lo que se practica en esta lección. Seguimos con Grupo Meridiano (Marta en 192.168.10.21, el servidor en .10.10, el router en .10.1, Jon en Bilbao en 192.168.20.7) y algún cameo de la Clínica Azahar.

• Resuelve por escrito antes de mirar la solución — está justo debajo de cada enunciado, así que disciplina.
• Con las salidas de consola, léelas de verdad: campo a campo, como si estuvieran en tu pantalla a las 9 de la mañana con un usuario esperando. La velocidad vendrá sola; primero, precisión.
• Si fallas, repasa la lección indicada con 📌 antes de continuar: los ejercicios posteriores dan por asimilados los anteriores.

Marta pulsa Enter en https://intranet.grupomeridiano.example. Ordena las siguientes etapas de la encapsulación de su petición, de la primera a la última, y nombra la unidad de datos resultante en cada paso:

• (a) Se añaden las direcciones IP de origen y destino.
• (b) La petición HTTP se genera con su método y sus cabeceras.
• (c) Las señales se transmiten por el cable.
• (d) Se añaden los puertos de origen y destino y los números de secuencia.
• (e) Se añaden las direcciones MAC de origen y destino y el FCS.

📌 Repasa si fallas: lección 02-01.

Orden: b → d → a → e → c. La aplicación genera el dato y cada protocolo va envolviéndolo, como muñecas rusas:

1. (b) HTTP crea la petición → datos.
2. (d) TCP la trocea y añade puertos y secuencia → segmento.
3. (a) IP añade direcciones de red → paquete.
4. (e) Ethernet añade MACs y el FCS de comprobación → trama.
5. (c) La trama se convierte en señales → bits en el medio.

En destino ocurre exactamente lo inverso (desencapsulación): cada capa retira "su" sobre y entrega el contenido a la siguiente.

Errores frecuentes: colocar IP antes que TCP. Regla mnemotécnica: el sobre que se pone primero es el que se abre último; HTTP es el contenido, TCP el primer sobre, IP el segundo, Ethernet el último y más externo.

Un analizador captura esta trama en la red de Valencia (campos simplificados):

Se sabe que 3C:52:82:AA:21:07 es la tarjeta de red del PC de Marta y 00:0C:29:5A:11:10 la del servidor.

1. ¿Quién envía y quién recibe esta trama?
2. ¿Qué indica el campo Tipo con valor 0x0800?
3. ¿Para qué sirve el FCS y qué hace el receptor si no cuadra?
4. ¿Verán esta trama los demás PCs de la oficina, si el equipo central es un switch?

📌 Repasa si fallas: lección 02-02.

1. La envía el PC de Marta (MAC origen) hacia el servidor (MAC destino). Ojo al orden de los campos: en la trama, el destino va antes que el origen.
2. Que el contenido transportado es un paquete IPv4: el campo Tipo declara qué protocolo viaja dentro, para que el receptor sepa a quién entregárselo.
3. El FCS (Frame Check Sequence) es una suma de comprobación (CRC) calculada sobre la trama. El receptor la recalcula al llegar: si no coincide, la trama se dañó por el camino y se descarta en silencio — el enlace no reenvía; si esos datos importaban, ya los recuperará TCP más arriba.
4. No. El switch consulta su tabla MAC y reenvía la trama solo por el puerto donde está 00:0C:29:5A:11:10. Eso lo diferencia de un hub, que la repetiría por todos los puertos.

Marta acaba de encender su PC (caché ARP vacía) y ejecuta ping 192.168.10.10. Antes del primer ICMP, su equipo hace otra cosa. En su PC, arp -a muestra antes y después:

1. Describe, mensaje a mensaje, qué ha ocurrido entre el ping y el primer paquete ICMP.
2. ¿Quién recibe la pregunta ARP y quién la contesta?
3. ¿Por qué el router .10.1 ya estaba en la caché antes del ping?

📌 Repasa si fallas: lección 02-02.

1. El PC necesita la MAC de 192.168.10.10 para construir la trama, y no la tiene. Secuencia:
   • ARP Request: "¿Quién tiene 192.168.10.10? Que se lo diga a 192.168.10.21" — enviado en difusión (MAC destino ff:ff:ff:ff:ff:ff), porque no sabe a quién preguntar.
   • ARP Reply: el servidor responde en unicast directamente a Marta: "192.168.10.10 está en 00:0c:29:5a:11:10".
   • El PC guarda la pareja en la caché (por eso aparece en el segundo arp -a) y ya puede enviar el ICMP echo request dentro de una trama bien dirigida.
2. La pregunta la reciben todos los equipos de la red local (es broadcast); la contesta solo el dueño de la IP preguntada.
3. Porque el PC ya había hablado con el router antes (al arrancar: DHCP, primeras conexiones a Internet, DNS...). Las entradas dinámicas se aprenden con el uso y caducan solas al cabo de un tiempo.

Errores frecuentes: pensar que ARP "sale a Internet a preguntar". ARP no cruza routers jamás: es un protocolo de la red local. Para destinos remotos no se pregunta por la IP remota, sino por la del gateway — que es justo el siguiente ejercicio.

El PC de Marta (192.168.10.21, máscara 255.255.255.0, gateway 192.168.10.1) envía un paquete a cada uno de estos destinos. Para cada caso indica: ¿es un destino local o remoto?, ¿por qué IP pregunta ARP?, y ¿qué IP y qué MAC de destino llevará la trama que sale de su tarjeta?

1. El servidor 192.168.10.10.
2. El PC de Jon, 192.168.20.7.
3. Un servidor de Internet, 93.184.216.34.

📌 Repasa si fallas: lección 02-03.

El equipo aplica la máscara: todo lo que empiece por 192.168.10 es su red; lo demás, remoto.

La idea clave está en la fila 2: la IP de destino no cambia en todo el viaje (es el destino final), pero la MAC de destino es siempre la del siguiente salto — cambia en cada tramo. La trama es el sobre del reparto local; el paquete, la carta que viaja entera.

Errores frecuentes: responder que la trama hacia Jon lleva "la MAC de Jon". El PC de Marta no puede conocerla ni le serviría: las MACs solo tienen sentido dentro de la red local. Si en un examen (o en Wireshark) ves IP remota + MAC del router, es que lo has entendido.

Desde el PC de Marta se ejecutan dos pings con este resultado:

1. En el primer ping: ¿cuántos routers ha atravesado la respuesta y cómo lo sabes? ¿Qué sistema operativo corre probablemente el router de Bilbao?
2. ¿Qué te dicen los tiempos (29–33 ms)?
3. En el segundo ping: ¿qué significa "tiempo de espera agotado" y qué causas son compatibles con él? ¿En qué se diferenciaría un "Host de destino inaccesible"?

📌 Repasa si fallas: lecciones 02-03 y 06-01.

1. El TTL llega a 62. Los valores iniciales típicos son 64 (Linux) y 128 (Windows); 62 está a 2 saltos de 64, así que la respuesta ha atravesado 2 routers (el de Bilbao al salir y el de Valencia al entrar, a través del túnel VPN) y el emisor es con toda probabilidad un Linux — lo esperable en un router.
2. Que hay unos 30 ms de ida y vuelta hasta Bilbao, estables (poca variación entre muestras = poco jitter). Es una línea sana para tráfico interactivo.
3. "Tiempo de espera agotado" = envié el echo request y nadie respondió nada: compatible con que el equipo .20.99 no exista, esté apagado, o un firewall descarte los ICMP en silencio — el ping solo no distingue entre esas causas. "Host de destino inaccesible" es distinto: alguien respondió activamente (un router, o tu propio equipo) diciendo que no sabe llegar o que no encuentra al host en la red local; hay diagnóstico explícito, no silencio.

Errores frecuentes: concluir "el equipo no existe" ante timeouts. El silencio tiene tres explicaciones, y una de ellas (firewall) es un equipo perfectamente vivo. Antes de sentenciar, contrasta con otra vía (¿responde a otro puerto? ¿aparece en la tabla del router?).

Estos tres segmentos TCP entre el PC de Jon y el servidor de la intranet han llegado desordenados al analizador:

• Segmento X: origen 192.168.10.10:443 → destino 192.168.20.7:52144, flags SYN, ACK, seq=8800, ack=3501
• Segmento Y: origen 192.168.20.7:52144 → destino 192.168.10.10:443, flags ACK, seq=3501, ack=8801
• Segmento Z: origen 192.168.20.7:52144 → destino 192.168.10.10:443, flags SYN, seq=3500

1. Ordénalos y justifica el orden con los números de secuencia y ACK.
2. ¿Quién es el cliente y quién el servidor? ¿Qué tipo de puerto usa cada uno?
3. Tras el handshake, Jon envía su primer segmento con 200 bytes de datos. ¿Qué seq llevará y qué ack devolverá el servidor?

📌 Repasa si fallas: lección 02-04.

1. Orden: Z → X → Y (SYN → SYN-ACK → ACK). La aritmética lo demuestra: Z propone seq=3500; X responde ack=3501 ("recibido tu 3500, espero el 3501") y propone su propio seq=8800; Y confirma con ack=8801. Cada ACK es "el siguiente byte que espero", por eso siempre es el seq del otro + 1 en el handshake.
2. Cliente: el PC de Jon — envía el primer SYN y usa un puerto efímero (52144, elegido al azar para esta conexión). Servidor: la intranet en su puerto well-known/de servicio (443, HTTPS), fijo y conocido de antemano.
3. Su primer byte de datos es el 3501, así que enviará seq=3501 con 200 bytes (bytes 3501–3700). El servidor confirmará con ack=3701: el siguiente byte que espera.

Errores frecuentes: creer que el ACK confirma "el segmento nº X". Confirma bytes, no segmentos: ack=3701 significa "tengo todo hasta el byte 3700". Ese matiz es el que permite a TCP detectar y retransmitir exactamente lo perdido.

Para cada aplicación de Meridiano y Azahar, elige TCP o UDP y justifica en una frase:

1. Descargar un contrato en PDF del servidor de ficheros.
2. La videollamada semanal Valencia–Bilbao.
3. La consulta DNS que precede a casi todo.
4. La llamada GET /api/proyectos a la API de la intranet.
5. Sondas de monitorización que cada 10 segundos envían "estoy vivo" desde cada equipo de la clínica a un panel central.

📌 Repasa si fallas: lección 02-04.

1. TCP. Un PDF con un byte corrupto es un PDF roto: aquí la integridad es innegociable y la latencia da igual.
2. UDP. Retransmitir un trozo de voz de hace 2 segundos no tiene sentido (llegaría tarde); mejor perder un frame y seguir. La fluidez manda sobre la integridad.
3. UDP. Pregunta pequeña, respuesta pequeña: montar y desmontar una conexión TCP costaría más que la consulta entera. Si se pierde, la aplicación simplemente repregunta.
4. TCP. Una respuesta JSON truncada o corrupta es un error de aplicación; además HTTP (y el TLS que lo protege) se apoyan en el flujo fiable y ordenado de TCP.
5. UDP. Mensajes minúsculos, frecuentes y prescindibles uno a uno: si se pierde un "estoy vivo", en 10 segundos llega otro. Mantener cientos de conexiones TCP para esto sería un despilfarro.

Errores frecuentes: razonar "UDP = malo/poco fiable, TCP = bueno". Son herramientas: UDP no es peor, es más barato, y hay tráfico (voz, sondas, DNS) donde pagar la fiabilidad de TCP es pagar por algo que estorba.

Empareja cada situación con su código de estado (200, 301, 403, 404, 500) e indica en cada caso si el problema —si lo hay— está en el lado cliente o en el servidor:

1. Ana escribe /api/proyectoss (con doble s) y la intranet no tiene esa ruta.
2. La petición GET /api/proyectos de Marta devuelve el JSON esperado.
3. La intranet ha movido los manuales a otra URL y redirige automáticamente a la nueva.
4. Jon, sin permisos de administración, intenta entrar en /admin.
5. Un fallo en el código de la intranet hace explotar la petición al consultar la base de datos.

📌 Repasa si fallas: lección 02-05.

1. 404 Not Found — familia 4xx: el error está en la petición del cliente (esa ruta no existe).
2. 200 OK — familia 2xx: éxito.
3. 301 Moved Permanently — familia 3xx: redirección; no es un error, es un "está en otra parte, ve allí" que el navegador sigue solo.
4. 403 Forbidden — 4xx: el servidor te entiende perfectamente, pero no tienes permiso. Compáralo con 404: aquí la ruta existe; lo que falta es autorización.
5. 500 Internal Server Error — familia 5xx: la petición era correcta; el que ha fallado es el servidor. El cliente no puede arreglarlo por mucho que reintente.

La regla que hay que llevar tatuada: 4xx → revisa tu petición; 5xx → el problema es del otro lado. Dirige el diagnóstico en segundos.

Ana visita por primera vez www.clinicaazahar.example (la web pública de la clínica, que Meridiano les mantiene). Ni su PC ni el servidor DNS que usa su equipo tienen nada en caché. Después, nslookup muestra:

1. Describe en orden todos los pasos de la resolución, desde el navegador hasta obtener la IP.
2. ¿Qué tipo de registro DNS se ha consultado?
3. ¿Qué significa "respuesta no autoritativa"?
4. Si Ana vuelve a entrar dos minutos después, ¿se repite todo el proceso?

📌 Repasa si fallas: lección 02-05.

1. Paso a paso:
   1. El navegador consulta la caché local del equipo: vacía.
   2. El PC pregunta a su servidor DNS configurado (el router, 192.168.10.1, que hace de DNS para la oficina).
   3. Este tampoco lo tiene, así que recorre la jerarquía: pregunta a un servidor raíz (que le remite a los servidores del TLD .example), luego al TLD (que le remite al servidor autoritativo del dominio clinicaazahar.example), y por último al autoritativo, que responde: www.clinicaazahar.example → 203.0.113.80.
   4. El router guarda la respuesta en su caché y se la devuelve al PC de Ana, que también la cachea. El navegador ya puede abrir la conexión hacia 203.0.113.80.
2. Un registro A: nombre → dirección IPv4. (Si fuera IPv6 sería AAAA; un alias sería CNAME; el correo, MX.)
3. Que quien responde (el router) no es el servidor autoritativo del dominio: está sirviendo una copia cacheada o recursiva. Es lo normal en el día a día; solo el autoritativo da respuesta "oficial".
4. No. La respuesta está en caché (en el PC y en el router) y se sirve de ahí hasta que expire su tiempo de vida. Por eso la primera visita a un sitio siempre es un pelín más lenta que las siguientes — y por eso los cambios de DNS "tardan en verse".

Un portátil nuevo se enchufa a la red de Valencia y a los pocos segundos tiene la dirección 192.168.10.101. Ese mismo día, el PC de Marta se reinicia y vuelve a tener, como siempre, 192.168.10.21.

1. Ordena y describe los 4 mensajes que ha intercambiado el portátil nuevo con el servidor DHCP (el router .10.1), indicando cuáles viajan en difusión.
2. Además de la IP, ¿qué otros tres parámetros como mínimo le ha entregado el DHCP, y para qué sirve cada uno? (Piensa en los ejercicios 4 y 9.)
3. ¿Por qué el portátil ha recibido .10.101 y Marta recibe siempre .10.21, si ambos usan DHCP?

📌 Repasa si fallas: lección 02-05.

1. La secuencia DORA:
   1. Discover — el portátil, que aún no tiene IP, grita en difusión: "¿hay algún servidor DHCP ahí?".
   2. Offer — el router le ofrece una dirección libre de su rango (.10.100–.199): "te ofrezco la 192.168.10.101".
   3. Request — el cliente, aún en difusión, pide formalmente esa oferta (así, si hubiera varios servidores, todos se enteran de cuál aceptó).
   4. Acknowledge — el servidor confirma y arranca el contrato de alquiler (lease). Los mensajes del cliente van en difusión porque todavía no tiene identidad de red desde la que hablar en unicast.
2. Como mínimo: la máscara (255.255.255.0 — sin ella no sabría decidir local/remoto, ejercicio 4), el gateway (192.168.10.1 — sin él no saldría de la red), y el servidor DNS (sin él no resolvería nombres, ejercicio 9). Una IP sin esos tres acompañantes es un coche sin volante.
3. Porque Marta tiene una reserva por MAC: el DHCP tiene anotado "a la MAC del PC de Marta, entrégale siempre 192.168.10.21". Misma mecánica DORA, resultado fijo. Es la forma de dar direcciones estables (a su PC, a la impresora) sin renunciar a la gestión centralizada del DHCP.

Errores frecuentes: confundir reserva DHCP con IP estática configurada a mano. El resultado se parece (IP fija), pero la reserva se administra en el servidor —un solo sitio, sin tocar el equipo— y por eso suele ser la opción preferida en redes gestionadas.

Si has llegado hasta aquí resolviendo (y no solo leyendo), acabas de ejercitar la columna vertebral de las redes: encapsular en orden, leer una trama y saber quién habla con quién, entender ARP como el "pregón" de la red local, separar la IP de destino (fin del viaje) de la MAC de destino (siguiente salto), extraer saltos y sistema operativo de un simple TTL, reconstruir un handshake con su aritmética de seq/ACK, elegir transporte con criterio, traducir códigos HTTP a culpables, narrar una resolución DNS completa y recitar DORA con sus regalos incluidos. La próxima sesión cambia el tipo de músculo: ejercicios del modelo OSI, donde practicarás el idioma de capas con el que los profesionales se entienden — y el clásico examen de tabla que tarde o temprano te encontrarás.