Segona sessió de gimnàs, i pugem pes: els protocols del mòdul 2. Aquí ja no n'hi ha prou amb la lògica de cada dia — cal llegir trames, seguir números de seqüència, interpretar sortides de ping i arp, i reconstruir converses DNS i DHCP. Són els músculs que més faràs servir a la teva vida professional: pràcticament qualsevol incidència de xarxa es diagnostica amb el que es practica en aquesta lliçó. Continuem amb Grupo Meridiano (la Marta a 192.168.10.21, el servidor a .10.10, el router a .10.1, en Jon a Bilbao a 192.168.20.7) i algun cameo de la Clínica Azahar.

• Resol per escrit abans de mirar la solució — és just a sota de cada enunciat, així que disciplina.
• Amb les sortides de consola, llegeix-les de debò: camp a camp, com si fossin a la teva pantalla a les 9 del matí amb un usuari esperant. La velocitat vindrà sola; primer, precisió.
• Si falles, repassa la lliçó indicada amb 📌 abans de continuar: els exercicis posteriors donen per assimilats els anteriors.

La Marta prem Enter a https://intranet.grupomeridiano.example. Ordena les etapes següents de l'encapsulació de la seva petició, de la primera a l'última, i anomena la unitat de dades resultant a cada pas:

• (a) S'hi afegeixen les adreces IP d'origen i destinació.
• (b) La petició HTTP es genera amb el seu mètode i les seves capçaleres.
• (c) Els senyals es transmeten pel cable.
• (d) S'hi afegeixen els ports d'origen i destinació i els números de seqüència.
• (e) S'hi afegeixen les adreces MAC d'origen i destinació i l'FCS.

📌 Repassa si falles: lliçó 02-01.

Ordre: b → d → a → e → c. L'aplicació genera la dada i cada protocol la va embolicant, com nines russes:

1. (b) HTTP crea la petició → dades.
2. (d) TCP la trosseja i hi afegeix ports i seqüència → segment.
3. (a) IP hi afegeix adreces de xarxa → paquet.
4. (e) Ethernet hi afegeix MAC i l'FCS de comprovació → trama.
5. (c) La trama es converteix en senyals → bits al mitjà.

A destinació passa exactament a l'inrevés (desencapsulació): cada capa retira el «seu» sobre i lliura el contingut a la següent.

Errors freqüents: col·locar IP abans que TCP. Regla mnemotècnica: el sobre que es posa primer és el que s'obre últim; HTTP és el contingut, TCP el primer sobre, IP el segon, Ethernet l'últim i més extern.

Un analitzador captura aquesta trama a la xarxa de València (camps simplificats):

Se sap que 3C:52:82:AA:21:07 és la targeta de xarxa del PC de la Marta i 00:0C:29:5A:11:10 la del servidor.

1. Qui envia i qui rep aquesta trama?
2. Què indica el camp Tipus amb valor 0x0800?
3. Per a què serveix l'FCS i què fa el receptor si no quadra?
4. Veuran aquesta trama els altres PC de l'oficina, si l'equip central és un switch?

📌 Repassa si falles: lliçó 02-02.

1. L'envia el PC de la Marta (MAC origen) cap al servidor (MAC destinació). Compte amb l'ordre dels camps: a la trama, la destinació va abans que l'origen.
2. Que el contingut transportat és un paquet IPv4: el camp Tipus declara quin protocol viatja a dins, perquè el receptor sàpiga a qui lliurar-lo.
3. L'FCS (Frame Check Sequence) és una suma de comprovació (CRC) calculada sobre la trama. El receptor la recalcula en arribar: si no coincideix, la trama s'ha fet malbé pel camí i es descarta en silenci — l'enllaç no reenvia; si aquelles dades importaven, ja les recuperarà TCP més amunt.
4. No. El switch consulta la seva taula MAC i reenvia la trama només pel port on hi ha 00:0C:29:5A:11:10. Això el diferencia d'un hub, que la repetiria per tots els ports.

La Marta acaba d'engegar el seu PC (memòria cau ARP buida) i executa ping 192.168.10.10. Abans del primer ICMP, el seu equip fa una altra cosa. Al seu PC, arp -a mostra abans i després:

1. Descriu, missatge a missatge, què ha passat entre el ping i el primer paquet ICMP.
2. Qui rep la pregunta ARP i qui la contesta?
3. Per què el router .10.1 ja era a la memòria cau abans del ping?

📌 Repassa si falles: lliçó 02-02.

1. El PC necessita la MAC de 192.168.10.10 per construir la trama, i no la té. Seqüència:
   • ARP Request: «Qui té 192.168.10.10? Que li ho digui a 192.168.10.21» — enviat en difusió (MAC destinació ff:ff:ff:ff:ff:ff), perquè no sap a qui preguntar.
   • ARP Reply: el servidor respon en unicast directament a la Marta: «192.168.10.10 és a 00:0c:29:5a:11:10».
   • El PC guarda la parella a la memòria cau (per això apareix al segon arp -a) i ja pot enviar l'ICMP echo request dins d'una trama ben adreçada.
2. La pregunta la reben tots els equips de la xarxa local (és broadcast); la contesta només el propietari de la IP preguntada.
3. Perquè el PC ja havia parlat amb el router abans (en arrencar: DHCP, primeres connexions a Internet, DNS...). Les entrades dinàmiques s'aprenen amb l'ús i caduquen soles al cap d'un temps.

Errors freqüents: pensar que ARP «surt a Internet a preguntar». ARP no creua routers mai: és un protocol de la xarxa local. Per a destinacions remotes no es pregunta per la IP remota, sinó per la del gateway — que és justament l'exercici següent.

El PC de la Marta (192.168.10.21, màscara 255.255.255.0, gateway 192.168.10.1) envia un paquet a cadascuna d'aquestes destinacions. Per a cada cas indica: és una destinació local o remota?, per quina IP pregunta ARP?, i quina IP i quina MAC de destinació portarà la trama que surt de la seva targeta?

1. El servidor 192.168.10.10.
2. El PC d'en Jon, 192.168.20.7.
3. Un servidor d'Internet, 93.184.216.34.

📌 Repassa si falles: lliçó 02-03.

L'equip aplica la màscara: tot el que comenci per 192.168.10 és la seva xarxa; la resta, remot.

La idea clau és a la fila 2: la IP de destinació no canvia en tot el viatge (és la destinació final), però la MAC de destinació és sempre la del salt següent — canvia a cada tram. La trama és el sobre del repartiment local; el paquet, la carta que viatja sencera.

Errors freqüents: respondre que la trama cap a en Jon porta «la MAC d'en Jon». El PC de la Marta no la pot conèixer ni li serviria: les MAC només tenen sentit dins de la xarxa local. Si en un examen (o a Wireshark) veus IP remota + MAC del router, és que ho has entès.

Des del PC de la Marta s'executen dos pings amb aquest resultat:

1. Al primer ping: quants routers ha travessat la resposta i com ho saps? Quin sistema operatiu corre probablement al router de Bilbao?
2. Què et diuen els temps (29–33 ms)?
3. Al segon ping: què significa «tiempo de espera agotado» i quines causes hi són compatibles? En què es diferenciaria un «Host de destino inaccesible»?

📌 Repassa si falles: lliçons 02-03 i 06-01.

1. El TTL arriba a 62. Els valors inicials típics són 64 (Linux) i 128 (Windows); 62 és a 2 salts de 64, així que la resposta ha travessat 2 routers (el de Bilbao en sortir i el de València en entrar, a través del túnel VPN) i l'emissor és amb tota probabilitat un Linux — l'esperable en un router.
2. Que hi ha uns 30 ms d'anada i tornada fins a Bilbao, estables (poca variació entre mostres = poc jitter). És una línia sana per a trànsit interactiu.
3. «Tiempo de espera agotado» = he enviat l'echo request i ningú no ha respost res: compatible amb el fet que l'equip .20.99 no existeixi, estigui apagat, o que un tallafoc descarti els ICMP en silenci — el ping sol no distingeix entre aquestes causes. «Host de destino inaccesible» és diferent: algú ha respost activament (un router, o el teu propi equip) dient que no sap arribar-hi o que no troba el host a la xarxa local; hi ha diagnòstic explícit, no silenci.

Errors freqüents: concloure «l'equip no existeix» davant de timeouts. El silenci té tres explicacions, i una d'elles (tallafoc) és un equip perfectament viu. Abans de sentenciar, contrasta-ho per una altra via (respon a un altre port? apareix a la taula del router?).

Aquests tres segments TCP entre el PC d'en Jon i el servidor de la intranet han arribat desordenats a l'analitzador:

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

1. Ordena'ls i justifica l'ordre amb els números de seqüència i ACK.
2. Qui és el client i qui el servidor? Quin tipus de port fa servir cadascun?
3. Després del handshake, en Jon envia el seu primer segment amb 200 bytes de dades. Quin seq portarà i quin ack retornarà el servidor?

📌 Repassa si falles: lliçó 02-04.

1. Ordre: Z → X → Y (SYN → SYN-ACK → ACK). L'aritmètica ho demostra: Z proposa seq=3500; X respon ack=3501 («rebut el teu 3500, espero el 3501») i proposa el seu propi seq=8800; Y confirma amb ack=8801. Cada ACK és «el següent byte que espero», per això sempre és el seq de l'altre + 1 al handshake.
2. Client: el PC d'en Jon — envia el primer SYN i fa servir un port efímer (52144, triat a l'atzar per a aquesta connexió). Servidor: la intranet al seu port well-known/de servei (443, HTTPS), fix i conegut per endavant.
3. El seu primer byte de dades és el 3501, així que enviarà seq=3501 amb 200 bytes (bytes 3501–3700). El servidor confirmarà amb ack=3701: el següent byte que espera.

Errors freqüents: creure que l'ACK confirma «el segment núm. X». Confirma bytes, no segments: ack=3701 significa «ho tinc tot fins al byte 3700». Aquest matís és el que permet a TCP detectar i retransmetre exactament allò perdut.

Per a cada aplicació de Meridiano i Azahar, tria TCP o UDP i justifica-ho en una frase:

1. Descarregar un contracte en PDF del servidor de fitxers.
2. La videotrucada setmanal València–Bilbao.
3. La consulta DNS que precedeix gairebé tot.
4. La crida GET /api/proyectos a l'API de la intranet.
5. Sondes de monitoratge que cada 10 segons envien un «soc viu» des de cada equip de la clínica a un tauler central.

📌 Repassa si falles: lliçó 02-04.

1. TCP. Un PDF amb un byte corrupte és un PDF trencat: aquí la integritat és innegociable i la latència tant se val.
2. UDP. Retransmetre un tros de veu de fa 2 segons no té sentit (arribaria tard); millor perdre un frame i continuar. La fluïdesa mana sobre la integritat.
3. UDP. Pregunta petita, resposta petita: muntar i desmuntar una connexió TCP costaria més que la consulta sencera. Si es perd, l'aplicació simplement torna a preguntar.
4. TCP. Una resposta JSON truncada o corrupta és un error d'aplicació; a més, HTTP (i el TLS que el protegeix) es recolzen en el flux fiable i ordenat de TCP.
5. UDP. Missatges minúsculs, freqüents i prescindibles un a un: si es perd un «soc viu», en 10 segons n'arriba un altre. Mantenir centenars de connexions TCP per a això seria un malbaratament.

Errors freqüents: raonar «UDP = dolent/poc fiable, TCP = bo». Són eines: UDP no és pitjor, és més barat, i hi ha trànsit (veu, sondes, DNS) on pagar la fiabilitat de TCP és pagar per una cosa que fa nosa.

Aparella cada situació amb el seu codi d'estat (200, 301, 403, 404, 500) i indica en cada cas si el problema —si n'hi ha— és a la banda del client o del servidor:

1. L'Ana escriu /api/proyectoss (amb doble s) i la intranet no té aquesta ruta.
2. La petició GET /api/proyectos de la Marta retorna el JSON esperat.
3. La intranet ha mogut els manuals a una altra URL i redirigeix automàticament a la nova.
4. En Jon, sense permisos d'administració, intenta entrar a /admin.
5. Una fallada al codi de la intranet fa explotar la petició en consultar la base de dades.

📌 Repassa si falles: lliçó 02-05.

1. 404 Not Found — família 4xx: l'error és a la petició del client (aquesta ruta no existeix).
2. 200 OK — família 2xx: èxit.
3. 301 Moved Permanently — família 3xx: redirecció; no és un error, és un «és a una altra banda, ves-hi» que el navegador segueix tot sol.
4. 403 Forbidden — 4xx: el servidor t'entén perfectament, però no tens permís. Compara'l amb el 404: aquí la ruta existeix; el que falta és autorització.
5. 500 Internal Server Error — família 5xx: la petició era correcta; el que ha fallat és el servidor. El client no ho pot arreglar per més que ho reintenti.

La regla que cal portar tatuada: 4xx → revisa la teva petició; 5xx → el problema és de l'altra banda. Dirigeix el diagnòstic en segons.

L'Ana visita per primera vegada www.clinicaazahar.example (el web públic de la clínica, que Meridiano els manté). Ni el seu PC ni el servidor DNS que fa servir el seu equip tenen res a la memòria cau. Després, nslookup mostra:

1. Descriu en ordre tots els passos de la resolució, des del navegador fins a obtenir la IP.
2. Quin tipus de registre DNS s'ha consultat?
3. Què significa «respuesta no autoritativa»?
4. Si l'Ana hi torna a entrar dos minuts després, es repeteix tot el procés?

📌 Repassa si falles: lliçó 02-05.

1. Pas a pas:
   1. El navegador consulta la memòria cau local de l'equip: buida.
   2. El PC pregunta al seu servidor DNS configurat (el router, 192.168.10.1, que fa de DNS per a l'oficina).
   3. Aquest tampoc no ho té, així que recorre la jerarquia: pregunta a un servidor arrel (que el remet als servidors del TLD .example), després al TLD (que el remet al servidor autoritatiu del domini clinicaazahar.example), i finalment a l'autoritatiu, que respon: www.clinicaazahar.example → 203.0.113.80.
   4. El router guarda la resposta a la seva memòria cau i la retorna al PC de l'Ana, que també la desa. El navegador ja pot obrir la connexió cap a 203.0.113.80.
2. Un registre A: nom → adreça IPv4. (Si fos IPv6 seria AAAA; un àlies seria CNAME; el correu, MX.)
3. Que qui respon (el router) no és el servidor autoritatiu del domini: està servint una còpia de memòria cau o recursiva. És el normal en el dia a dia; només l'autoritatiu dona resposta «oficial».
4. No. La resposta és a la memòria cau (al PC i al router) i se serveix des d'allà fins que expiri el seu temps de vida. Per això la primera visita a un lloc sempre és un pèl més lenta que les següents — i per això els canvis de DNS «triguen a veure's».

Un portàtil nou s'endolla a la xarxa de València i al cap de pocs segons té l'adreça 192.168.10.101. Aquell mateix dia, el PC de la Marta es reinicia i torna a tenir, com sempre, 192.168.10.21.

1. Ordena i descriu els 4 missatges que ha intercanviat el portàtil nou amb el servidor DHCP (el router .10.1), indicant quins viatgen en difusió.
2. A més de la IP, quins altres tres paràmetres com a mínim li ha lliurat el DHCP, i per a què serveix cadascun? (Pensa en els exercicis 4 i 9.)
3. Per què el portàtil ha rebut la .10.101 i la Marta rep sempre la .10.21, si tots dos fan servir DHCP?

📌 Repassa si falles: lliçó 02-05.

1. La seqüència DORA:
   1. Discover — el portàtil, que encara no té IP, crida en difusió: «hi ha cap servidor DHCP per aquí?».
   2. Offer — el router li ofereix una adreça lliure del seu rang (.10.100–.199): «t'ofereixo la 192.168.10.101».
   3. Request — el client, encara en difusió, demana formalment aquesta oferta (així, si hi hagués diversos servidors, tots s'assabenten de quina ha acceptat).
   4. Acknowledge — el servidor confirma i engega el contracte de lloguer (lease). Els missatges del client van en difusió perquè encara no té identitat de xarxa des d'on parlar en unicast.
2. Com a mínim: la màscara (255.255.255.0 — sense ella no sabria decidir local/remot, exercici 4), el gateway (192.168.10.1 — sense ell no sortiria de la xarxa), i el servidor DNS (sense ell no resoldria noms, exercici 9). Una IP sense aquests tres acompanyants és un cotxe sense volant.
3. Perquè la Marta té una reserva per MAC: el DHCP té anotat «a la MAC del PC de la Marta, lliura-li sempre la 192.168.10.21». Mateixa mecànica DORA, resultat fix. És la manera de donar adreces estables (al seu PC, a la impressora) sense renunciar a la gestió centralitzada del DHCP.

Errors freqüents: confondre reserva DHCP amb IP estàtica configurada a mà. El resultat s'assembla (IP fixa), però la reserva s'administra al servidor —un sol lloc, sense tocar l'equip— i per això sol ser l'opció preferida a les xarxes gestionades.

Si has arribat fins aquí resolent (i no només llegint), acabes d'exercitar la columna vertebral de les xarxes: encapsular en ordre, llegir una trama i saber qui parla amb qui, entendre ARP com el «pregó» de la xarxa local, separar la IP de destinació (final del viatge) de la MAC de destinació (salt següent), extreure salts i sistema operatiu d'un simple TTL, reconstruir un handshake amb la seva aritmètica de seq/ACK, triar transport amb criteri, traduir codis HTTP a culpables, narrar una resolució DNS completa i recitar DORA amb els seus regals inclosos. La pròxima sessió canvia el tipus de múscul: exercicis del model OSI, on practicaràs l'idioma de capes amb què s'entenen els professionals — i el clàssic examen de taula que tard o d'hora et trobaràs.