Arribem a la capa 3 del model OSI, la capa de xarxa: la que trenca la frontera del que és local. Tot el que hem vist fins ara —senyals, trames, MAC, switches, VLAN— funciona dins d'una xarxa; la capa de xarxa és la que permet que el paquet de la Marta surti de València, creui la VPN i arribi a la impressora de Bilbao, o que qualsevol equip assoleixi un servidor a l'altra punta del món. Al mòdul 2 (lliçó 02-03) ja vas conèixer els seus protagonistes: el paquet IP, el TTL, la porta d'enllaç, la taula de rutes del router de València i ICMP amb el ping. Aquí no repetirem aquell material: estudiarem la capa 3 com a capa del model —els seus serveis, el seu dispositiu emblemàtic, els tipus d'encaminament i el seu paper en el diagnòstic—, recolzant-nos en aquells exemples com a terreny ja conquerit.

1. La funció de la capa de xarxa dins del model
2. Servei 1: adreçament lògic
3. Servei 2: encaminament (routing)
4. Servei 3: fragmentació
5. El router com a dispositiu de capa 3
6. Encaminament estàtic i dinàmic
7. Qualitat de servei (QoS), una pinzellada
8. Diagnòstic de capa 3: el gateway del PC d'en Jon

El contracte OSI de la capa 3:

• Què rep de dalt (capa 4): un segment que ha d'arribar a un procés en un altre equip, sigui on sigui — la mateixa taula o el mateix planeta.
• Quin servei ofereix a la capa 4: lliurament de paquets d'extrem a extrem entre xarxes diferents, triant el camí. Compte: en IP, aquest lliurament és de "millor esforç" (best effort): la capa 3 no garanteix que el paquet arribi, ni que arribi en ordre; si cal fiabilitat, l'aporta la capa 4 (com fa TCP).
• Què fa servir de baix (capa 2): el lliurament local, salt a salt, dins de cada xarxa que travessa el paquet.
• La seva PDU: el paquet. Les seves adreces: les IP (adreçament lògic).

La imatge mental correcta és la d'una cadena de trams locals cosits per routers: el paquet (capa 3) viatja intacte d'extrem a extrem, mentre que a cada tram el transporta una trama (capa 2) nova. Ja ho vas veure amb el viatge del ping a Bilbao a 02-03 — el TTL que arribava a 62 després de descomptar els dos routers era la signatura visible d'aquests salts.

Per què calen adreces IP si ja tenim MAC? Perquè són adreçaments de naturalesa oposada, i comparar-los és la millor manera d'entendre la paraula lògic:

L'estructura és la clau. Una MAC no diu res d'on és l'equip; una IP sí: 192.168.20.7 declara "xarxa 192.168.20.0/24 (Bilbao), equip 7". Gràcies a aquesta jerarquia, el router de València no necessita conèixer cada equip de Bilbao: en té prou amb una entrada a la seva taula per a tota la xarxa 192.168.20.0/24, igual que Correus encamina per codi postal sense conèixer cada veí. El detall de la part xarxa/host amb /24 el vas treballar a 02-03, i les màscares a fons arribaran al mòdul 5; aquí n'hi ha prou de retenir el principi: l'adreçament lògic és jeràrquic, i aquesta jerarquia és el que fa escalable l'encaminament.

El segon servei és decidir el camí: davant d'un paquet per a la xarxa X, per on l'envio? Cada router respon consultant la seva taula de rutes (recorda la del router de València a 02-03: xarxa destinació → interfície de sortida / salt següent). El procés, vist des d'OSI:

1. Arriba una trama; el router la desencapsula (puja de capa 1-2 a capa 3) i llegeix la IP destinació del paquet.
2. Busca a la seva taula la ruta més específica que coincideixi amb aquella xarxa destinació (si no n'hi ha cap, fa servir la ruta per defecte, si existeix; si tampoc, descarta el paquet i avisa amb un ICMP).
3. Decrementa el TTL (i descarta el paquet si arriba a 0 — l'assegurança antibucles que ja coneixes).
4. Reencapsula el paquet en una trama nova per al medi de sortida i el transmet cap al salt següent.

I així, salt a salt, fins a la xarxa de destinació, on l'últim router lliura el paquet directament a l'equip final. Cada router decideix només el salt següent: ningú no planifica la ruta completa per endavant. És un sistema descentralitzat, i per això resisteix fallades: si un camí cau i el router en coneix un altre, el trànsit es desvia.

A Meridiano l'encaminament és minúscul però complet: el router de València coneix la seva xarxa local, la ruta cap a 192.168.20.0/24 pel túnel VPN, i la ruta per defecte cap a Internet. Tres decisions possibles; els routers d'un operador d'Internet en manegen centenars de milers, però el mecanisme és idèntic.

Cada tecnologia de capa 2 imposa una mida màxima de trama (la MTU, unitat màxima de transmissió: en Ethernet, 1500 bytes de càrrega). Què passa si un paquet de capa 3 no cap a la trama del tram següent? La capa de xarxa ofereix la fragmentació: partir el paquet en fragments que sí que hi càpiguen, cadascun viatjant com a paquet independent, i que la destinació final (no els routers intermedis) reassembla.

N'hi ha prou amb la idea conceptual, amb dos apunts pràctics:

• La fragmentació és un últim recurs, no una virtut: multiplica feina i, si es perd un fragment, es perd el paquet sencer. Els sistemes moderns prefereixen evitar-la esbrinant per endavant la mida màxima que cap per tot el camí i ajustant els enviaments.
• Te la trobaràs a la vida real precisament on hi ha túnels: la VPN de Meridiano afegeix les seves pròpies capçaleres a cada paquet, de manera que un paquet que omplia la trama ja no cap en entrar al túnel. Els símptomes típics ("el ping funciona entre seus però les transferències grans es pengen") són un clàssic del suport; queda't que existeixen i amb la seva causa de capa 3.

El router és a la capa 3 el que el switch a la capa 2, i comparar-los fixa les fronteres del model:

Convé recordar també el paper de la porta d'enllaç (gateway) vist a 02-03, ara en vocabulari OSI: és l'adreça del router local que cada equip té configurada, i representa la decisió de capa 3 més bàsica que pren un host: "la destinació és a la meva xarxa? → lliuro directament per capa 2; és a fora? → la passo al meu gateway". Tot equip amb IP pren aquesta decisió a cada paquet que envia. Guarda-la: és la peça central del cas de diagnòstic d'aquesta lliçó.

Els routers domèstics i de pime (com els de Meridiano) fan a més moltes altres coses (NAT, DHCP, firewall, punt de terminació de la VPN...), però la seva essència OSI és aquesta: decidir el salt següent de cada paquet entre xarxes.

D'on surten les rutes de la taula? Hi ha dues filosofies:

• Encaminament estàtic: l'administrador escriu les rutes a mà. És simple, predictible i sense trànsit extra, però no reacciona als canvis (si un enllaç cau, la ruta continua apuntant al buit fins que algú la corregeixi) i no escala: mantenir a mà les taules de centenars de routers seria inviable.
• Encaminament dinàmic: els routers s'expliquen els uns als altres quines xarxes coneixen mitjançant protocols d'encaminament, i calculen les millors rutes automàticament, recalculant-les quan alguna cosa canvia (un enllaç cau, apareix una xarxa nova).

Existeixen protocols d'encaminament com OSPF (habitual dins de les organitzacions) i BGP (el que cus entre si les xarxes de tot Internet). No els desenvoluparem en aquest curs —pertanyen a un nivell més avançat—; en tens prou de saber que existeixen, per a què serveixen i aquesta regla de decisió:

A Meridiano, efectivament, tot és estàtic: el router de València té una ruta fixa cap a 192.168.20.0/24 per la VPN, i el de Bilbao la seva simètrica cap a 192.168.10.0/24. Simple i suficient.

Últim servei conceptual de la capa 3: no tot el trànsit pateix igual la congestió. Si l'enllaç de València a Internet se satura, a una baixada tant li fa esperar mig segon més; a una videotrucada, no — la veu entretallada és inutilitzable. La qualitat de servei (QoS) és el conjunt de mecanismes pels quals la xarxa prioritza uns trànsits sobre uns altres: els paquets poden portar una marca de prioritat a la capçalera, i els routers, en gestionar les seves cues de sortida, despatxen abans el que està marcat com a sensible (veu, vídeo) i deixen esperar el que és tolerant (baixades, còpies de seguretat).

Exemple Meridiano: les videotrucades setmanals entre València i Bilbao comparteixen l'enllaç VPN amb les còpies de seguretat nocturnes i les transferències de fitxers. Si mai coincideixen, sense QoS la videotrucada d'en Jon s'entretalla; amb QoS, el router de cada seu dona pas preferent als paquets de la videotrucada i la còpia simplement triga una mica més. Ens quedem en el concepte: QoS = prioritzar a les cues dels routers segons marques als paquets; la seva configuració és matèria de cursos avançats.

Cas pràctic complet, a l'estil de la lliçó anterior però un pis més amunt.

Símptoma: en Jon, a Bilbao, truca al suport: "Puc imprimir a la impressora d'aquí i veig l'ordinador de la meva companya, però no se m'obre la intranet de València ni cap pàgina d'Internet. Als altres de Bilbao els funciona tot."

Primera anàlisi per capes: imprimeix i veu equips de la seva xarxa → les capes 1 i 2 funcionen, i la seva IP local també. Falla tot el que és fora de 192.168.20.0/24, i només a ell. Un patró "el local sí, el remot no" apunta directament a capa 3, i en concret a la decisió que separa el local del remot: la porta d'enllaç.

Diagnòstic, amb les ordres que ja coneixes de 02-03:

Interpretació: el PC d'en Jon, davant d'una destinació remota, lliura el paquet al seu gateway configurat... que és 192.168.20.254, una adreça on no hi ha cap router (o hi ha un equip que no encamina). Els paquets surten del PC, la capa 2 els lliura (o ARP ni tan sols resol aquella adreça) i allà mor tot. El local funciona perquè per a destinacions de la seva pròpia xarxa el gateway no intervé: el lliurament és directe per capa 2. El símptoma encaixa al mil·límetre.

Causa i solució: el PC d'en Jon tenia la IP configurada a mà d'una prova antiga (els altres la reben per DHCP, amb el gateway correcte 192.168.20.1). Es retorna l'equip a configuració automàtica, rep el gateway correcte, i tot funciona.

Moralitat OSI: el patró de fallada delimita la capa. "No funciona res" → comença per capa 1. "El local sí, el remot no" → capa 3, i el primer sospitós és el gateway. "Tot connecta però un servei concret falla" → capes 4-7, com veurem a les properes lliçons.

• Confondre l'àmbit de MAC i IP. Les MAC no creuen mai un router; les IP d'origen i destinació, sí (viatgen intactes d'extrem a extrem, llevat de NAT, que veurem al mòdul 5). Si t'atrapes dient "la MAC del servidor de València arriba a Bilbao", rellegeix el viatge del paquet de 02-03.
• Creure que la capa 3 garanteix el lliurament. IP és millor esforç: els paquets es poden perdre, duplicar o arribar desordenats. La fiabilitat, qui la necessita, la contracta amb la capa 4 (TCP). Molts malentesos de diagnòstic neixen d'esperar de la capa 3 promeses que no va fer mai.
• Oblidar comprovar el gateway (i la màscara) en revisar una IP. Una IP correcta amb gateway o màscara incorrectes produeix el traïdor "el local va, el remot no". ipconfig / ip addr + ip route s'han de llegir complets, no només la línia de la IP.
• Pensar que el ping "prova l'aplicació". Un ping correcte només certifica les capes 1-3 entre dos punts. La intranet pot continuar fallant per DNS, pel servei web aturat o per un certificat: capes superiors. El ping delimita, no conclou.
• Consell: memoritza la decisió del host — destinació a la meva xarxa: lliurament directe; destinació a fora: al gateway. La meitat dels problemes de capa 3 d'una pime són aquesta decisió funcionant amb dades mal configurades.
• Consell: en xarxes petites, prefereix rutes estàtiques i documenta cadascuna (destinació, salt següent, per què existeix). L'encaminament dinàmic brilla on hi ha escala i redundància, no en dues seus amb un túnel.

Exercici 1. El paquet d'una videotrucada surt del PC d'en Jon (192.168.20.7) cap al servidor de València (192.168.10.10) travessant: switch de Bilbao → router de Bilbao → [VPN] → router de València → switch de València → servidor. (a) Quantes trames diferents es creen pel camí (sense comptar l'interior del túnel)? (b) Quants paquets IP diferents, des de la perspectiva dels extrems? (c) Quins dos camps del paquet saps que canvien pel camí i qui els canvia?

Exercici 2. Meridiano obre una tercera seu a Sevilla (xarxa 192.168.30.0/24) connectada per VPN a València (no directament a Bilbao; el trànsit Bilbao↔Sevilla passarà per València). (a) Quines rutes estàtiques noves necessita el router de València? (b) I el de Bilbao? (c) Recomanaries passar a encaminament dinàmic per això? Justifica-ho.

Exercici 3. L'Ana, a València, pot navegar per Internet amb normalitat, però no arriba a res de Bilbao (ni a la impressora ni al router 192.168.20.1); a la resta de València li funciona tot, inclòs Bilbao. Aplica el raonament per capes: (a) quines capes pots donar per bones a l'equip de l'Ana i per què? (b) El patró apunta al gateway de l'Ana, com en el cas d'en Jon? (c) Què comprovaries?

Solució 1. (a) Quatre trames a les xarxes de les seus: PC d'en Jon→switch→router de Bilbao (1, el switch no crea trames noves, només les commuta), router de Bilbao→túnel (la trama es refà en entrar en joc la VPN; comptem el tram Bilbao com a 1 ja emès), router de València→switch→servidor (1)... sent estrictes amb "cada router destrueix i crea trama": trama 1 a la xarxa de Bilbao (Jon→router de Bilbao), trama/es del tram entre routers a través del túnel, i trama final a la xarxa de València (router→servidor); l'essencial: una trama nova per cada tram de capa 2, tres trams visibles aquí. (b) Un sol paquet IP d'extrem a extrem (origen 192.168.20.7, destinació 192.168.10.10), que viatja encapsulat dins del túnel entre routers. (c) El TTL (el decrementa cada router: dos salts, com delatava el TTL=62 de 02-03) i, en conseqüència, el camp de verificació de la capçalera que cada router recalcula en modificar el TTL. Les IP d'origen/destinació no canvien.

Solució 2. (a) València afegeix una ruta: 192.168.30.0/24 → túnel VPN amb Sevilla. (b) Bilbao afegeix també una ruta: 192.168.30.0/24 → túnel VPN amb València (el seu únic camí cap a Sevilla passa per allà; de fet, si Bilbao ja fes servir València com a sortida per defecte per a tot el que no és local, fins i tot podria no necessitar cap entrada explícita). El router de Sevilla necessitarà rutes cap a 192.168.10.0/24 i 192.168.20.0/24 via València. (c) Encara no: tres seus en estrella sobre València continuen sent un grapat de rutes estables; l'estàtic continua sent més simple d'operar i auditar. El dinàmic començaria a compensar amb més seus, enllaços redundants entre elles o canvis freqüents.

Solució 3. (a) Capes 1-2 bé (arriba a la seva xarxa i navega), i la seva capa 3 parcialment verificada: assoleix Internet, per tant la seva IP, màscara i gateway funcionen. (b) No: si el gateway de l'Ana estigués malament, fallaria tot el remot, inclòs Internet. Aquí falla només una destinació remota concreta (la xarxa de Bilbao) i només per a l'Ana. (c) Comprovaria què diferencia l'Ana de la resta: té alguna ruta estàtica antiga al seu PC que capturi 192.168.20.0/24 i l'enviï malament (route print / ip route)? Algun firewall local o programari VPN de client al seu equip que interfereixi amb aquell rang? El patró "una destinació concreta falla només en un equip" apunta a configuració local d'aquell equip, no a la xarxa comuna — que queda descartada perquè als altres els funciona.

La capa de xarxa és la que converteix moltes xarxes locals en una sola xarxa de xarxes: aporta l'adreçament lògic i jeràrquic (les IP, amb la seva part de xarxa que fa escalable tot el sistema), l'encaminament salt a salt mitjançant les taules de rutes —poblades a mà (estàtic) o per protocols com OSPF i BGP (dinàmic)—, la fragmentació quan un paquet no cap al tram següent, i mecanismes de prioritat (QoS) perquè la videotrucada guanyi a la còpia de seguretat. El seu dispositiu és el router, frontera dels dominis de difusió i executor de la decisió clau que també pren cada host: local directe, remot al gateway — la decisió que el PC d'en Jon tenia trencada. Però fixa't en el que la capa 3 lliura: paquets a un equip, sense garanties i sense saber a quin dels seus programes van adreçats. Convertir aquest lliurament de millor esforç entre màquines en converses fiables entre processos —amb ports, reassemblatge i control de flux— és l'ofici de la capa 4: la capa de transport, propera lliçó.