Última sessió del curs, i és diferent de totes les anteriors. Ja no hi ha apartats per tema, ni pistes de quina lliçó repassar, ni exercicis «de subnetting» o «de DNS»: hi ha incidències. Quatre casos complets — dos a Grupo Meridiano, dos a la Clínica Azahar, sobre la xarxa que tu mateix vas dissenyar a la sessió anterior — explicats tal com arriben a la vida real: un usuari que descriu un símptoma a la seva manera, unes sortides d'ordres, i ningú que et digui a quina capa és el problema. La teva feina és aplicar la metodologia del mòdul 6 (definir, reproduir, hipòtesi, provar, aplicar, verificar, documentar) recolzant-te en tot l'après als mòduls 1 a 5. És l'examen final oficiós del curs — i el format exacte del teu futur dia a dia.

1. Com treballar aquests casos
2. Cas 1: el PC nou de Torrevella que «té Internet però no historials»
3. Cas 2: «ha caigut Internet» a Meridiano València
4. Cas 3: el servidor d'historials que va i ve
5. Cas 4: el router nou d'Elx
6. Errors comuns en diagnosticar
7. Conclusió: final del curs

• Cada cas té quatre parts: context, símptomes, dades (sortides d'ordres reals) i preguntes guiades. La solució raonada ve després — i aquí, més que mai: no la miris fins a tenir el teu diagnòstic escrit, amb capa sospitosa i causa arrel incloses.
• Treballa amb el mètode de 7 passos de la lliçó 06-03. Les preguntes guiades en segueixen l'ordre; si t'encalles, torna a la pregunta d'or: a qui afecta i què va canviar?
• Tingues a mà els teus plans d'adreçament: el /24 de Meridiano València (192.168.10.0/24, router .1, servidor .10, DHCP .100–.199) i el teu pla VLSM d'Azahar de la lliçó 07-05 (Alacant 172.20.40.0/26, sala d'espera .64/27, Elx .96/28, Torrevella .112/28, túnels .128/30 i .132/30). En aquests casos, conèixer el pla és la meitat del diagnòstic: diverses pistes només són visibles per a qui sap què hi hauria d'haver.
• Apunta quins mòduls fas servir a cada cas. Al final veuràs que cap no es resol amb un sol mòdul — aquesta és la gràcia.

Azahar ja treballa amb el pla VLSM que vas dissenyar a la lliçó anterior. Dilluns s'incorpora una fisioterapeuta al consultori de Torrevella i el proveïdor del programari d'historials li instal·la el PC. Com que l'instal·lador «no es refiava del DHCP», va configurar la xarxa a mà.

Dimarts, 9:40. Truca la fisio nova: «puc navegar per Internet sense problema, però el programa d'historials diu no es pot connectar amb el servidor. A la meva companya de la taula del costat li funciona tot».

Al PC nou:

Al PC de la companya (funciona): 172.20.40.115, màscara 255.255.255.240, gateway 172.20.40.113, tot per DHCP.

1. Abans de tocar res: què et diu el patró «Internet sí, historials no, i només en aquest equip»? Què descarta?
2. Compara l'ipconfig del PC nou amb el teu pla d'adreçament de Torrevella. Quin camp està malament?
3. Per què el ping al servidor falla amb «Host de destino inaccesible» des de la mateixa IP del PC, i quin paper hi juga ARP en aquest missatge?
4. Per què, amb aquest mateix error de configuració, Internet funciona perfectament?
5. Enuncia causa arrel, capa del model, solució i com prevenir la reincidència.

Pas 1 — definir i delimitar. Afecta un sol equip (la companya treballa) → la causa viu en aquell lloc de treball. Que alguna cosa funcioni (Internet) descarta de cop la capa física, el switch i la sortida WAN del consultori: no és «la xarxa de Torrevella», és aquest PC parlant amb aquella destinació. La dada «el van configurar a mà ahir» (què va canviar) apunta directe a la configuració.

Pas 2 — reproduir. Fet a les dades: el gateway respon, el servidor no — i el missatge no és un tímid «tiempo de espera agotado», sinó «Host de destino inaccesible» emès pel mateix PC (fixa-t'hi: «Respuesta desde 172.20.40.120», la seva pròpia adreça). Això vol dir que el PC ni tan sols va intentar enviar el paquet lluny: va decidir que no sabia lliurar-lo.

Pas 3 — hipòtesi. Contrastant amb el pla: Torrevella és 172.20.40.112/28, màscara 255.255.255.240. El PC té màscara 255.255.255.0. Hipòtesi: màscara errònia — el PC creu que TOT 172.20.40.0–255 és la seva xarxa local.

Pas 4 — provar (entendre el mecanisme). Amb /24, l'AND del mòdul 5 diu al PC que 172.20.40.10 és a la seva pròpia LAN → en lloc d'enviar-ho al gateway, llança un ARP al cable de Torrevella preguntant «qui té 172.20.40.10?». Però el servidor és a Alacant, a l'altra banda del túnel: a Torrevella ningú no respon aquest ARP. Sense MAC de destinació no hi ha trama possible, i el sistema declara «Host de destino inaccesible» — per això l'arp -a no mostra cap entrada per a la .10. El gateway .113 sí que respon perquè casualment és dins de totes dues versions de la xarxa (la real /28 i la imaginària /24): l'error queda emmascarat justament a la comprovació més habitual. I Internet funciona perquè qualsevol destinació pública (p. ex. 198.51.100.60) queda fora fins i tot de la /24 imaginària → aquell trànsit sí que s'envia al gateway, que el treu per NAT amb tota normalitat. La fallada només afecta les destinacions 172.20.40.x remotes: historials, impressores d'altres seus… exactament el símptoma.

Passos 5 i 6 — aplicar i verificar. Es corregeix la màscara a 255.255.255.240 (millor encara: es passa el PC a DHCP, com la resta del consultori):

~39 ms i TTL 62 (64 − 2 routers: el de Torrevella i el d'Alacant): ara el paquet creua el túnel. El programa d'historials connecta. La fisio ho confirma.

Pas 7 — documentar. Causa arrel: màscara de subxarxa errònia (/24 en una subxarxa /28) en configuració manual — capa 3, configuració d'adreçament. Prevenció: els llocs de treball de consultori es configuren per DHCP (amb reserva si el programari exigeix IP fixa), i qualsevol proveïdor extern rep el full del pla d'adreçament abans d'instal·lar res. És, gairebé literalment, el cas del NAS de la lliçó 05-02 — vist ara des de la cadira del qui el diagnostica.

Mòduls usats: 2 (ARP), 5 (màscares i AND), 6 (mètode i lectura de ping/arp).

Dimecres, 8:55. Comencen a arribar avisos en cadena des de València: «no hi ha Internet». La Marta, l'Ana, administració — tothom. A Bilbao, en Jon confirma que allà tot funciona. Ningú no recorda cap canvi… fins que algú esmenta que el router de València «es va actualitzar sol» aquesta matinada (actualització automàtica de microprogramari programada per l'ISP).

Cap web no obre («no es pot trobar el servidor»). El correu tampoc. I — detall curiós que aporta un usuari observador — la intranet tampoc no obre pel seu nom, però un marcador vell que apunta a https://192.168.10.10 sí que funciona.

Des del PC de la Marta:

1. El segon ping és la frontissa del cas sencer: què demostra ping 1.1.1.1 responent en 9 ms?
2. Què et diuen, combinats, els dos nslookup? Sigues precís: quin component exacte està fallant i quin està sa?
3. Com hi encaixa la pista de «la intranet no va per nom però sí per IP»?
4. A quina capa situes el problema i quina és la causa arrel més probable, tenint en compte què va canviar aquesta nit?
5. Quina millora permanent proposaries en documentar? (Pista: recorda com va acabar el cas C de la lliçó 06-03.)

Pas 1 — definir i delimitar. Afecta tota València, «tot Internet», amb Bilbao sa → la causa és en alguna cosa comuna de València (router, DHCP, DNS, sortida WAN). Canvi conegut: microprogramari del router aquesta matinada.

Passos 2 i 3 — reproduir i afinar la hipòtesi. Aquí hi ha la finor del cas: «no hi ha Internet» resulta ser fals. ping 1.1.1.1 respon: hi ha cable, hi ha switch, hi ha IP, hi ha gateway, hi ha NAT i hi ha sortida WAN — les capes 1 a 3 fins a Internet estan intactes. El que no funciona és allò que converteix noms en adreces: la consulta DNS al servidor configurat (el router, 192.168.10.1) expira, però la mateixa consulta a 8.8.8.8 resol a l'instant. Traducció exacta: la xarxa està bé i el resolutor extern està bé; el que ha mort és el servei DNS del router de València. La pista de la intranet ho confirma per un altre camí: per IP funciona (xarxa sana, servidor sa), per nom no (ningú no resol intranet.grupomeridiano.example — el DNS intern és el mateix servei del router). I explica per què «no hi ha Internet» per a l'usuari: sense DNS, cap URL no obre; per a un humà, això és Internet caigut.

Pas 4 — provar. Al tauler del router, el servei DNS forwarder apareix aturat després de l'actualització de microprogramari de les 4:12 (els registres del router ho confirmen — el «què va canviar» del pas 1 era la causa, com gairebé sempre).

Passos 5 i 6 — aplicar i verificar. Es reinicia el servei DNS del router (i es desactiven les actualitzacions automàtiques en horari no controlat, que es reprogramen a finestra de manteniment amb avís). Verificació amb l'ordre que fallava: nslookup www.proveedor-cloud.example contra el .10.1 resol, les webs obren, la intranet torna per nom. Confirmat amb dos usuaris.

Pas 7 — documentar. Causa arrel: servei DNS del router aturat després d'una actualització de microprogramari — capa d'aplicació (DNS), amb la xarxa de sota intacta. Millora permanent: després del cas C del mòdul 6, Meridiano va deixar un únic DNS (el .10.1) al DHCP — avui s'ha pagat aquesta decisió: un sol servei caigut va deixar «sense Internet» la seu sencera. S'afegeix un DNS secundari sa (p. ex. el resolutor de l'ISP) a les opcions del DHCP: amb el primari caigut, els equips haurien trigat uns segons més… però haurien funcionat. I la lliçó de butxaca, per a sempre: davant d'un «no hi ha Internet», separa connectivitat de resolució — un ping a una IP i un nslookup valen més que vint reinicis.

Mòduls usats: 2 (DNS), 4 (què valida un ping per capes), 5 (el NAT continuava fent la seva feina), 6 (mètode, nslookup contrastat).

Azahar, seu d'Alacant. Dimarts a primera hora, un proveïdor d'electromedicina instal·la a la consulta 2 un ecògraf nou amb connectivitat de xarxa, per arxivar les imatges. L'instal·lador el deixa funcionant i se'n va. «Li he posat la IP que fem servir sempre a les instal·lacions», comenta en sortir.

Des de les 12:30, avisos intermitents de les tres seus: «el programa d'historials es queda penjat una estona i després torna sol». De vegades funciona minuts seguits; de vegades es talla a mitja fitxa. Reiniciar el PC «de vegades ho arregla» (i de vegades no — el clàssic dels problemes intermitents).

Des del PC de recepció d'Alacant (172.20.40.21), un ping sostingut al servidor:

La taula ARP del mateix PC, consultada dues vegades amb tres minuts de diferència:

I al mateix servidor d'historials (Linux), el registre del sistema crida:

Una captura ràpida al servidor (mòdul 6, amb autorització) remata la pel·lícula:

1. Què significa que la MAC associada a 172.20.40.10 canviï entre dues consultes d'arp -a?
2. Per què dues respostes al mateix ARP Request són la prova definitiva? Quin dispositiu és cada MAC?
3. Explica la intermitència amb precisió: per què funciona a estones, i per què «reiniciar de vegades ho arregla»?
4. A quina capa (o capes) situes el problema? Quina és la causa arrel — la tècnica i la de procés?
5. Què faries per resoldre-ho i perquè no torni a passar?

Pas 1 — definir i delimitar. Afecta totes les seus però un sol servei (historials) i de manera intermitent → el sospitós comú és el servidor o el seu tram. Què va canviar avui? La instal·lació de l'ecògraf a mig matí; els avisos comencen just després. La correlació temporal és la pista mestra.

Passos 2–4 — reproduir, hipòtesi, prova. El ping -t intermitent amb l'aplicació «que va i ve» hi encaixa. I la taula ARP ho delata: una IP no pot tenir dues MAC — si l'entrada de 172.20.40.10 canvia de aa-4c-… a 00-1f-…, hi ha dos dispositius reclamant la mateixa adreça IP. La captura és la prova irrefutable: a un sol «qui té la .10?» responen dos equips. La MAC aa-4c-52-… és el servidor d'historials; la 00-1f-5b-… resulta ser l'ecògraf acabat d'instal·lar — amb la IP estàtica 172.20.40.10, la mateixa del servidor, perquè l'instal·lador va fer servir «la de sempre» sense consultar el pla.

El mecanisme de la intermitència, amb l'après al mòdul 2: cada equip de la xarxa guarda a la seva memòria cau ARP la parella IP→MAC. Segons qui va respondre últim a l'ARP, la memòria cau de cada PC apunta al servidor (tot funciona) o a l'ecògraf (els paquets «per al servidor» arriben a un ecògraf que no entén d'historials: penjades i timeouts)… fins que l'entrada caduca, es torna a preguntar, i el guanyador pot canviar. Per això cada equip falla en moments diferents, i per això reiniciar «de vegades» ho arregla: buida la memòria cau ARP i rellança la loteria. Res no està «trencat»: hi ha dos veïns amb el mateix número de portal, i el carter lliura cada vegada a un.

Passos 5 i 6 — aplicar i verificar. Es canvia la IP de l'ecògraf a 172.20.40.12 (lliure al rang estàtic del pla) i es neteja la memòria cau on urgeix (arp -d o esperar la caducitat). Verificació: ping -t a la .10 durant 15 minuts sense ni una sola pèrdua, arp -a estable amb la MAC del servidor, i el registre del servidor sense nous avisos de duplicat. Les tres seus ho confirmen.

Pas 7 — documentar. Causa arrel tècnica: adreça IP duplicada (estàtica repetida) — un problema de capa 3 que es manifesta i es diagnostica a la capa 2 (ARP), just a la frontera que tant hem practicat. Causa arrel de procés, la de debò: un dispositiu es va endollar a la xarxa sense consultar el pla d'adreçament. Prevenció: el pla VLSM de la 07-05 passa a estar imprès a l'armari de comunicacions i a la documentació que es lliura a tot proveïdor; les IP estàtiques es demanen, no es trien. La tècnica arregla la incidència; el procés evita la següent.

Mòduls usats: 2 (ARP i la seva memòria cau), 5 (pla d'adreçament), 6 (ping sostingut, captura, mètode).

Una tempesta deixa sense línia el consultori d'Elx el diumenge. Dilluns a primera hora, un tècnic de l'ISP substitueix l'equip de fibra per un router nou «tot en u» i se'n va deixant «Internet funcionant». En recollir, comenta: «aquell aparell vell de l'armari l'he deixat desconnectat, ja no fa falta».

Dilluns, 10:15, truca Elx: «Internet va perfectament, però no podem obrir historials des de cap equip. I la impressora de xarxa ha desaparegut dels PC».

Des d'un PC d'Elx:

A l'armari de comunicacions: el router de l'ISP nou, amb el switch del consultori connectat a les seves preses LAN… i el router de la clínica (el que manté el túnel VPN amb Alacant i el DHCP del pla) apagat i desendollat a la lleixa: l'«aparell vell que ja no fa falta».

1. Mira l'ipconfig amb el teu pla d'Elx al davant (172.20.40.96/28). Què és el primer que grinyola, abans fins i tot de pensar en causes?
2. D'on ha sortit aquesta configuració 192.168.1.x? Per què els equips la van acceptar sense queixar-se?
3. Per què Internet funciona de meravella mentre historials i impressora han desaparegut? On van (i on moren) els paquets cap a 172.20.40.10?
4. Quina és la causa arrel i a quina capa va néixer el problema?
5. Proposa la reparació correcta. Quin problema addicional apareixeria si simplement s'endollés el router de la clínica darrere del router nou de l'ISP, tal qual?

Pas 1 — definir i delimitar. Tota una seu, des d'una intervenció física aquest matí. El «què va canviar» és evident; la pregunta és què va canviar exactament. Enfocament bottom-up sense dubtar-ho: hi va haver mans a l'armari.

Passos 2 i 3 — reproduir i hipòtesi. L'ipconfig és la pista mestra per a qui coneix el pla: un PC d'Elx ha de viure a 172.20.40.97–.110, i aquest té 192.168.1.34 — una adreça que no existeix al pla d'Azahar. Amb la dada de l'armari, la pel·lícula es reconstrueix sola: el tècnic de l'ISP va connectar el switch del consultori a les preses LAN del seu router nou, que porta de fàbrica el seu propi DHCP (192.168.1.0/24). Els PC, en renovar el lloguer al matí, van acceptar l'oferta de l'únic DHCP present — DORA no fa preguntes de lleialtat: respon el primer que arriba. I el router de la clínica — l'extrem del túnel VPN, el gateway 172.20.40.97, el DHCP legítim del /28 — va quedar desendollat: per a la xarxa, Elx ja no és Elx; és «una casa més» penjada d'un router domèstic.

Pas 4 — provar (confirmar el mecanisme). Internet funciona perquè el router de l'ISP fa NAT amb tota solvència: per navegar, qualsevol xarxa amb sortida serveix — «Internet va» no valida la teva xarxa; valida qualsevol xarxa. Però 172.20.40.10 ja no és «a l'altra banda del túnel», perquè no hi ha túnel: el tracert mostra el paquet entrant a 192.168.1.1, que no té cap ruta cap a 172.20.40.0/24 → l'envia per la seva ruta per defecte cap a l'ISP, on una destinació privada RFC 1918 mor sense remei (mòdul 4, la ruta que desapareix; mòdul 5, adreces no encaminables a Internet). La impressora «desapareguda» és el mateix fenomen en local: continua configurada a 172.20.40.x i ja ningú no comparteix subxarxa amb ella.

Passos 5 i 6 — aplicar i verificar. Reparació correcta: restaurar la topologia lògica — el router de l'ISP es configura en mode bridge (o es fa servir només com a accés WAN), el router de la clínica torna al seu lloc com a gateway de la LAN (172.20.40.97), amb el switch penjant d'ell i el túnel VPN renegociat amb Alacant. Els equips renoven DHCP (ipconfig /renew) i recuperen les seves adreces del pla.

Verificació completa: ipconfig (adreça del /28 ✔), tracert 172.20.40.10 creuant el túnel en tres salts (gateway d'Elx, router d'Alacant, servidor — el patró que ja vas veure al cas B del mòdul 6), historials obrint, impressora visible. Sobre la pregunta 5: endollar el router de la clínica darrere del router de l'ISP «tal qual» crearia doble NAT (192.168.1.x a fora, 172.20.40.x a dins): la LAN tornaria a funcionar, però el túnel VPN de lloc a lloc quedaria negociant des de darrere d'un NAT que no controla — amb la negociació IPsec patint o caient, i cada servei entrant necessitant regles a dos routers (mòdul 5, lliçó 05-03). Funciona-a-mitges és la pitjor classe d'arranjament: bridge i topologia neta.

Pas 7 — documentar. Causa arrel: canvi de topologia física no autoritzat (capa 1 d'origen) que va substituir gateway, DHCP i adreçament de la seu (conseqüències a les capes 2–3). Prevenció: full de topologia enganxat a l'armari («aquest equip NO es desconnecta»), i tota intervenció de l'ISP amb presència o revisió posterior de Meridiano. Nota per a la posteritat a la base de coneixement: la IP fora de pla va ser el diagnòstic sencer; la resta va ser confirmar-lo.

Mòduls usats: 1 (topologia), 2 (DHCP/DORA), 4 (rutes i ruta per defecte), 5 (RFC 1918, NAT i doble NAT), 6 (tracert, bottom-up).

Els quatre casos comparteixen patrons d'error que convé endur-se gravats:

• Creure's el símptoma literal. «No hi ha Internet» era un DNS caigut; «té Internet però no historials» era una màscara; «Internet va perfecte» amagava una seu sencera fora de la seva xarxa. El símptoma és el punt de partida de la investigació, mai la seva conclusió.
• Diagnosticar sense el pla d'adreçament al davant. Als casos 1, 3 i 4, l'anomalia només és visible comparant el que hi ha amb el que hi hauria d'haver. Una xarxa sense pla documentat no es pot diagnosticar: només es pot endevinar.
• Ignorar la pregunta «què va canviar?». Un instal·lador, un microprogramari nocturn, un ecògraf, un tècnic de l'ISP: els quatre casos neixen d'un canvi recent. La correlació no és causalitat, però és la millor hipòtesi inicial que existeix.
• Subestimar els intermitents. El cas 3 no es caça amb un ping solt: es caça amb ping -t, dues lectures d'arp -a i una captura. Instrumentar i esperar és diagnòstic, no passivitat.
• Verificar només la meitat. «Ja hi ha Internet» no tanca el cas 4; tancar-lo és historials + impressora + túnel + DHCP correcte. Verifica contra el símptoma original i contra el pla.
• Arreglar la tècnica i oblidar el procés. Canviar la IP de l'ecògraf triga un minut; aconseguir que el pròxim proveïdor demani la IP en lloc d'inventar-se-la és el que evita el cas 5. La documentació (pas 7) és on una incidència es converteix en millora.

S'ha acabat el gimnàs — i amb ell, el curs. Val la pena mirar enrere per veure el camí complet: al mòdul 1 vas aprendre què és una xarxa, els seus tipus i topologies; al mòdul 2, els protocols que la fan parlar — Ethernet i ARP, IP, TCP i UDP, DNS, HTTP i companyia; al mòdul 3, el mapa OSI de set capes que ordena tot això; al mòdul 4, el model TCP/IP que corre de debò a cada màquina, amb les seves rutes i els seus sockets; al mòdul 5, l'adreçament de punta a punta — binari, màscares, subnetting, VLSM, NAT i IPv6; al mòdul 6, les eines de diagnòstic i el mètode que les governa; i en aquest mòdul 7 vas convertir tot allò en soltesa, primer per temes i avui contra incidències completes, sense etiquetes ni xarxa de seguretat.

Fixa't en el que ja saps fer, perquè no és poc: llegir la configuració de qualsevol equip i detectar al vol el que no quadra; dissenyar l'adreçament d'una organització petita des de zero, pla VLSM inclòs; seguir un paquet mentalment des de l'ARP inicial fins al 200 OK final; interpretar ping, traceroute, arp, nslookup, ss i una captura de trànsit; i — el que de debò et distingeix — diagnosticar amb mètode, aïllant la capa, trobant la causa arrel i documentant-la. A la primera lliçó d'aquest mòdul vam dir que si només saps raonar sobre la xarxa que et saps de memòria, encara no saps raonar sobre xarxes; després de resoldre els problemes d'una clínica que no existia quan vas començar el curs, aquest llistó està superat.

I ara què? Tres camins, compatibles entre si. Practica en laboratori: simuladors com Packet Tracer o GNS3, o un parell de routers vells i una tarda lliure, et deixen trencar i arreglar xarxes sense que ningú truqui enfadat; obre Wireshark sovint — cada captura ensenya alguna cosa. Certifica l'après si la teva carrera ho demana: aquest curs et deixa una base sòlida per preparar certificacions de xarxes de nivell inicial i intermedi. I aprofundeix cap a on et cridi: la seguretat de xarxa (tallafocs, VPN a fons, anàlisi de trànsit), l'administració de sistemes, o el món IPv6 i cloud on tot l'après es recombina. Les xarxes tenen aquesta qualitat rara: són invisibles quan funcionen i apassionants quan no.

La Marta i en Jon continuaran obrint la intranet cada matí sense sospitar la coreografia de capes que ho fa possible, i a la sala d'espera d'Azahar ningú no sabrà mai que el Wi-Fi de pacients viu a la seva pròpia subxarxa per una bona raó. Però tu sí que ho saps — i saps exactament per què. Això és haver acabat un curs de xarxes. Enhorabona, i que les teves taules ARP siguin sempre estables.