Llegamos a la capa 3 del modelo OSI, la capa de red: la que rompe la frontera de lo local. Todo lo visto hasta ahora —señales, tramas, MACs, switches, VLANs— funciona dentro de una red; la capa de red es la que permite que el paquete de Marta salga de Valencia, cruce la VPN y llegue a la impresora de Bilbao, o que cualquier equipo alcance un servidor al otro lado del mundo. En el módulo 2 (lección 02-03) ya conociste a sus protagonistas: el paquete IP, el TTL, la puerta de enlace, la tabla de rutas del router de Valencia e ICMP con el ping. Aquí no repetiremos ese material: estudiaremos la capa 3 como capa del modelo —sus servicios, su dispositivo emblemático, los tipos de encaminamiento y su papel en el diagnóstico—, apoyándonos en aquellos ejemplos como terreno ya conquistado.

1. La función de la capa de red dentro del modelo
2. Servicio 1: direccionamiento lógico
3. Servicio 2: encaminamiento (routing)
4. Servicio 3: fragmentación
5. El router como dispositivo de capa 3
6. Enrutamiento estático y dinámico
7. Calidad de servicio (QoS), una pincelada
8. Diagnóstico de capa 3: la gateway del PC de Jon

El contrato OSI de la capa 3:

• Qué recibe de arriba (capa 4): un segmento que debe llegar a un proceso en otro equipo, esté donde esté — misma mesa o mismo planeta.
• Qué servicio ofrece a la capa 4: entrega de paquetes de extremo a extremo entre redes distintas, eligiendo el camino. Ojo: en IP, esta entrega es de "mejor esfuerzo" (best effort): la capa 3 no garantiza que el paquete llegue, ni que llegue en orden; si hace falta fiabilidad, la aporta la capa 4 (como hace TCP).
• Qué usa de abajo (capa 2): la entrega local, salto a salto, dentro de cada red que atraviesa el paquete.
• Su PDU: el paquete. Sus direcciones: las IP (direccionamiento lógico).

La imagen mental correcta es la de una cadena de tramos locales cosidos por routers: el paquete (capa 3) viaja intacto de extremo a extremo, mientras que en cada tramo lo transporta una trama (capa 2) nueva. Ya lo viste con el viaje del ping a Bilbao en 02-03 — el TTL que llegaba a 62 tras descontar los dos routers era la firma visible de esos saltos.

¿Por qué hacen falta direcciones IP si ya tenemos MACs? Porque son direccionamientos de naturaleza opuesta, y compararlos es la mejor forma de entender la palabra lógico:

La estructura es la clave. Una MAC no dice nada de dónde está el equipo; una IP sí: 192.168.20.7 declara "red 192.168.20.0/24 (Bilbao), equipo 7". Gracias a esa jerarquía, el router de Valencia no necesita conocer cada equipo de Bilbao: le basta una entrada en su tabla para toda la red 192.168.20.0/24, igual que Correos encamina por código postal sin conocer a cada vecino. El detalle de la parte red/host con /24 lo trabajaste en 02-03, y las máscaras a fondo llegarán en el módulo 5; aquí basta con retener el principio: el direccionamiento lógico es jerárquico, y esa jerarquía es lo que hace escalable el encaminamiento.

El segundo servicio es decidir el camino: ante un paquete para la red X, ¿por dónde lo envío? Cada router responde consultando su tabla de rutas (recuerda la del router de Valencia en 02-03: red destino → interfaz de salida / siguiente salto). El proceso, visto desde OSI:

1. Llega una trama; el router la desencapsula (sube de capa 1-2 a capa 3) y lee la IP destino del paquete.
2. Busca en su tabla la ruta más específica que coincida con esa red destino (si no hay ninguna, usa la ruta por defecto, si existe; si tampoco, descarta el paquete y avisa con un ICMP).
3. Decrementa el TTL (y descarta el paquete si llega a 0 — el seguro antibucles que ya conoces).
4. Reencapsula el paquete en una trama nueva para el medio de salida y lo transmite hacia el siguiente salto.

Y así, salto a salto, hasta la red de destino, donde el último router entrega el paquete directamente al equipo final. Cada router decide solo el siguiente salto: nadie planifica la ruta completa de antemano. Es un sistema descentralizado, y por eso resiste fallos: si un camino cae y el router conoce otro, el tráfico se desvía.

En Meridiano el encaminamiento es minúsculo pero completo: el router de Valencia conoce su red local, la ruta hacia 192.168.20.0/24 por el túnel VPN, y la ruta por defecto hacia Internet. Tres decisiones posibles; los routers de un operador de Internet manejan cientos de miles, pero el mecanismo es idéntico.

Cada tecnología de capa 2 impone un tamaño máximo de trama (la MTU, unidad máxima de transmisión: en Ethernet, 1500 bytes de carga). ¿Qué pasa si un paquete de capa 3 no cabe en la trama del siguiente tramo? La capa de red ofrece la fragmentación: partir el paquete en fragmentos que sí quepan, cada uno viajando como paquete independiente, y que el destino final (no los routers intermedios) reensambla.

Basta la idea conceptual, con dos apuntes prácticos:

• La fragmentación es un último recurso, no una virtud: multiplica trabajo y, si se pierde un fragmento, se pierde el paquete entero. Los sistemas modernos prefieren evitarla averiguando de antemano el tamaño máximo que cabe por todo el camino y ajustando los envíos.
• Te la encontrarás en la vida real precisamente donde hay túneles: la VPN de Meridiano añade sus propias cabeceras a cada paquete, con lo que un paquete que llenaba la trama ya no cabe al entrar al túnel. Los síntomas típicos ("el ping funciona entre sedes pero las transferencias grandes se cuelgan") son un clásico del soporte; quédate con que existen y con su causa de capa 3.

El router es a la capa 3 lo que el switch a la capa 2, y compararlos fija las fronteras del modelo:

Conviene recordar también el papel de la puerta de enlace (gateway) visto en 02-03, ahora en vocabulario OSI: es la dirección del router local que cada equipo tiene configurada, y representa la decisión de capa 3 más básica que toma un host: "¿el destino está en mi red? → entrego directo por capa 2; ¿está fuera? → se lo paso a mi gateway". Todo equipo con IP toma esta decisión en cada paquete que envía. Guárdala: es la pieza central del caso de diagnóstico de esta lección.

Los routers domésticos y de pyme (como los de Meridiano) hacen además muchas otras cosas (NAT, DHCP, firewall, punto de terminación de la VPN...), pero su esencia OSI es esta: decidir el siguiente salto de cada paquete entre redes.

¿De dónde salen las rutas de la tabla? Hay dos filosofías:

• Enrutamiento estático: el administrador escribe las rutas a mano. Es simple, predecible y sin tráfico extra, pero no reacciona a cambios (si un enlace cae, la ruta sigue apuntando al vacío hasta que alguien la corrija) y no escala: mantener a mano las tablas de cientos de routers sería inviable.
• Enrutamiento dinámico: los routers se cuentan unos a otros qué redes conocen mediante protocolos de enrutamiento, y calculan las mejores rutas automáticamente, recalculándolas cuando algo cambia (un enlace cae, aparece una red nueva).

Existen protocolos de enrutamiento como OSPF (habitual dentro de las organizaciones) y BGP (el que cose entre sí las redes de todo Internet). No los desarrollaremos en este curso —pertenecen a un nivel más avanzado—; te basta con saber que existen, para qué sirven y esta regla de decisión:

En Meridiano, efectivamente, todo es estático: el router de Valencia tiene una ruta fija hacia 192.168.20.0/24 por la VPN, y el de Bilbao su simétrica hacia 192.168.10.0/24. Simple y suficiente.

Último servicio conceptual de la capa 3: no todo el tráfico sufre igual la congestión. Si el enlace de Valencia a Internet se satura, a una descarga le da igual esperar medio segundo más; a una videollamada, no — la voz entrecortada es inutilizable. La calidad de servicio (QoS) es el conjunto de mecanismos por los que la red prioriza unos tráficos sobre otros: los paquetes pueden llevar una marca de prioridad en su cabecera, y los routers, al gestionar sus colas de salida, despachan antes lo marcado como sensible (voz, vídeo) y dejan esperar lo tolerante (descargas, copias de seguridad).

Ejemplo Meridiano: las videollamadas semanales entre Valencia y Bilbao comparten el enlace VPN con las copias de seguridad nocturnas y las transferencias de ficheros. Si alguna vez coinciden, sin QoS la videollamada de Jon se entrecorta; con QoS, el router de cada sede da paso preferente a los paquetes de la videollamada y la copia simplemente tarda un poco más. Nos quedamos en el concepto: QoS = priorizar en las colas de los routers según marcas en los paquetes; su configuración es materia de cursos avanzados.

Caso práctico completo, al estilo de la lección anterior pero un piso más arriba.

Síntoma: Jon, en Bilbao, llama al soporte: "Puedo imprimir en la impresora de aquí y veo el ordenador de mi compañera, pero no me abre la intranet de Valencia ni ninguna página de Internet. A los demás de Bilbao les funciona todo."

Primer análisis por capas: imprime y ve equipos de su red → las capas 1 y 2 funcionan, y su IP local también. Falla todo lo que está fuera de 192.168.20.0/24, y solo a él. Un patrón "lo local sí, lo remoto no" apunta directamente a capa 3, y en concreto a la decisión que separa lo local de lo remoto: la puerta de enlace.

Diagnóstico, con los comandos que ya conoces de 02-03:

Interpretación: el PC de Jon, ante un destino remoto, entrega el paquete a su gateway configurada... que es 192.168.20.254, una dirección donde no hay ningún router (o hay un equipo que no enruta). Los paquetes salen del PC, la capa 2 los entrega (o ARP ni siquiera resuelve esa dirección) y ahí muere todo. Lo local funciona porque para destinos de su propia red la gateway no interviene: la entrega es directa por capa 2. El síntoma encaja al milímetro.

Causa y solución: el PC de Jon tenía la IP configurada a mano de una prueba antigua (los demás la reciben por DHCP, con la gateway correcta 192.168.20.1). Se devuelve el equipo a configuración automática, recibe gateway correcta, y todo funciona.

Moraleja OSI: el patrón de fallo delimita la capa. "Nada funciona" → empieza en capa 1. "Lo local sí, lo remoto no" → capa 3, y el primer sospechoso es la gateway. "Todo conecta pero un servicio concreto falla" → capas 4-7, como veremos en las próximas lecciones.

• Confundir el ámbito de MAC e IP. Las MAC nunca cruzan un router; las IP de origen y destino, sí (viajan intactas de extremo a extremo, salvo NAT, que veremos en el módulo 5). Si te descubres diciendo "la MAC del servidor de Valencia llega a Bilbao", relee el viaje del paquete de 02-03.
• Creer que la capa 3 garantiza la entrega. IP es mejor esfuerzo: los paquetes pueden perderse, duplicarse o llegar desordenados. La fiabilidad, quien la necesita, la contrata con la capa 4 (TCP). Muchos malentendidos de diagnóstico nacen de esperar de la capa 3 promesas que nunca hizo.
• Olvidar comprobar la gateway (y la máscara) al revisar una IP. Una IP correcta con gateway o máscara incorrectas produce el traicionero "lo local va, lo remoto no". ipconfig / ip addr + ip route deben leerse completos, no solo la línea de la IP.
• Pensar que el ping "prueba la aplicación". Un ping correcto solo certifica las capas 1-3 entre dos puntos. La intranet puede seguir fallando por DNS, por el servicio web parado o por un certificado: capas superiores. El ping delimita, no concluye.
• Consejo: memoriza la decisión del host — destino en mi red: entrega directa; destino fuera: a la gateway. La mitad de los problemas de capa 3 de una pyme son esa decisión funcionando con datos mal configurados.
• Consejo: en redes pequeñas, prefiere rutas estáticas y documenta cada una (destino, siguiente salto, por qué existe). El enrutamiento dinámico brilla donde hay escala y redundancia, no en dos sedes con un túnel.

Ejercicio 1. El paquete de una videollamada sale del PC de Jon (192.168.20.7) hacia el servidor de Valencia (192.168.10.10) atravesando: switch de Bilbao → router de Bilbao → [VPN] → router de Valencia → switch de Valencia → servidor. (a) ¿Cuántas tramas distintas se crean por el camino (sin contar el interior del túnel)? (b) ¿Cuántos paquetes IP distintos, desde la perspectiva de los extremos? (c) ¿Qué dos campos del paquete sabes que cambian por el camino y quién los cambia?

Ejercicio 2. Meridiano abre una tercera sede en Sevilla (red 192.168.30.0/24) conectada por VPN a Valencia (no directamente a Bilbao; el tráfico Bilbao↔Sevilla pasará por Valencia). (a) ¿Qué rutas estáticas nuevas necesita el router de Valencia? (b) ¿Y el de Bilbao? (c) ¿Recomendarías pasar a enrutamiento dinámico por esto? Justifica.

Ejercicio 3. Ana, en Valencia, puede navegar por Internet con normalidad, pero no llega a nada de Bilbao (ni a la impresora ni al router 192.168.20.1); al resto de Valencia le funciona todo, incluido Bilbao. Aplica el razonamiento por capas: (a) ¿qué capas puedes dar por buenas en el equipo de Ana y por qué? (b) ¿El patrón apunta a la gateway de Ana, como en el caso de Jon? (c) ¿Qué comprobarías?

Solución 1. (a) Cuatro tramas en las redes de las sedes: PC de Jon→switch→router de Bilbao (1, el switch no crea tramas nuevas, solo las conmuta), router de Bilbao→túnel (la trama se rehace al entrar en juego la VPN; contamos el tramo Bilbao como 1 ya emitido), router de Valencia→switch→servidor (1)... siendo estrictos con "cada router destruye y crea trama": trama 1 en la red de Bilbao (Jon→router de Bilbao), trama(s) del tramo entre routers a través del túnel, y trama final en la red de Valencia (router→servidor); lo esencial: una trama nueva por cada tramo de capa 2, tres tramos visibles aquí. (b) Un solo paquete IP de extremo a extremo (origen 192.168.20.7, destino 192.168.10.10), que viaja encapsulado dentro del túnel entre routers. (c) El TTL (lo decrementa cada router: dos saltos, como delataba el TTL=62 de 02-03) y, en consecuencia, el campo de verificación de la cabecera que cada router recalcula al modificar el TTL. Las IP de origen/destino no cambian.

Solución 2. (a) Valencia añade una ruta: 192.168.30.0/24 → túnel VPN con Sevilla. (b) Bilbao añade también una ruta: 192.168.30.0/24 → túnel VPN con Valencia (su único camino hacia Sevilla pasa por allí; de hecho, si Bilbao ya usara Valencia como salida por defecto para todo lo no local, incluso podría no necesitar entrada explícita). El router de Sevilla necesitará rutas hacia 192.168.10.0/24 y 192.168.20.0/24 vía Valencia. (c) No todavía: tres sedes en estrella sobre Valencia siguen siendo un puñado de rutas estables; el estático sigue siendo más simple de operar y auditar. El dinámico empezaría a compensar con más sedes, enlaces redundantes entre ellas o cambios frecuentes.

Solución 3. (a) Capas 1-2 bien (llega a su red y navega), y su capa 3 parcialmente verificada: alcanza Internet, luego su IP, máscara y gateway funcionan. (b) No: si la gateway de Ana estuviera mal, fallaría todo lo remoto, incluido Internet. Aquí falla solo un destino remoto concreto (la red de Bilbao) y solo para Ana. (c) Comprobaría qué diferencia a Ana del resto: ¿tiene alguna ruta estática antigua en su PC que capture 192.168.20.0/24 y la envíe mal (route print / ip route)? ¿Algún firewall local o software VPN de cliente en su equipo que interfiera con ese rango? El patrón "un destino concreto falla solo en un equipo" apunta a configuración local de ese equipo, no a la red común — que queda descartada porque a los demás les funciona.

La capa de red es la que convierte muchas redes locales en una sola red de redes: aporta el direccionamiento lógico y jerárquico (las IP, con su parte de red que hace escalable todo el sistema), el encaminamiento salto a salto mediante las tablas de rutas —pobladas a mano (estático) o por protocolos como OSPF y BGP (dinámico)—, la fragmentación cuando un paquete no cabe en el tramo siguiente, y mecanismos de prioridad (QoS) para que la videollamada gane a la copia de seguridad. Su dispositivo es el router, frontera de los dominios de difusión y ejecutor de la decisión clave que también toma cada host: local directo, remoto a la gateway — la decisión que el PC de Jon tenía rota. Pero fíjate en lo que la capa 3 entrega: paquetes a un equipo, sin garantías y sin saber a cuál de sus programas van dirigidos. Convertir esa entrega de mejor esfuerzo entre máquinas en conversaciones fiables entre procesos —con puertos, reensamblado y control de flujo— es el oficio de la capa 4: la capa de transporte, próxima lección.