Tens la farmaciola (06-01) i el microscopi (06-02). Però les eines, soles, no resolen incidències: sense mètode es cau en el «diagnòstic per intuïció» — reiniciar coses a l'atzar, canviar tres paràmetres alhora, arreglar el símptoma sense entendre'n la causa (que tornarà). Aquesta lliçó converteix tot el que saps en un mètode sistemàtic: els tres enfocaments per capes i quan fer servir cadascun, un procediment de 7 passos que funciona igual per a un ping perdut que per a una caiguda general, un arbre de decisió amb l'ordre exacta de cada comprovació, i — el més valuós — tres incidències reals de Grupo Meridiano resoltes de cap a cap, amb les sortides de cada ordre, perquè vegis el mètode respirar. És la lliçó que tanca el mòdul 6 i, amb ell, la part teòrica del curs.

1. Per què cal un mètode
2. Els tres enfocaments per capes: bottom-up, top-down, divideix i venceràs
3. El mètode sistemàtic en 7 passos
4. L'arbre de decisió: «no funciona la xarxa»
5. Cas A: «l'Ana no té xarxa»
6. Cas B: «Bilbao no arriba a la intranet, però navega»
7. Cas C: «la intranet va lenta... només de vegades»
8. Documentar: el pas que ningú no fa i tothom agraeix

Una incidència de xarxa és un espai de cerca enorme: desenes de components (cable, switch, VLAN, IP, DHCP, rutes, VPN, DNS, tallafoc, servei, aplicació) i la fallada pot ser a qualsevol. Provar a l'atzar té un cost exponencial; un mètode per capes el redueix a un recorregut ordenat on cada comprovació descarta un bloc sencer de causes. A més, el mètode aporta dues coses que la intuïció no dona:

• Reproduïbilitat: dos tècnics amb el mateix mètode arriben a la mateixa conclusió i es poden rellevar a mitja incidència.
• Evidència: cada pas deixa una sortida d'ordre que prova allò descartat — imprescindible per escalar (a l'ISP, al proveïdor de la VPN) sense que et retornin el problema.

La bona notícia: el mètode ja gairebé el tens. Els models OSI i TCP/IP que vas estudiar no eren teoria decorativa, eren el mapa del diagnòstic; l'«embut» del mòdul 4 i el «capa 1 primer» del mòdul 3 n'eren els primers esbossos.

Sobre el mapa de capes hi ha tres maneres de recórrer-lo:

El tercer és el favorit dels professionals perquè un sol ping amb èxit valida de cop les capes 1, 2 i 3 fins a aquella destinació: la meitat del mapa descartada amb una sola ordre. D'aquí que l'arbre de decisió de més avall pivoti sobre ell. I el «capa 1 primer» (mòdul 3) continua vigent com a excepció d'or: si hi ha qualsevol indici físic (LED apagat, «Medios desconectados», obres, trasllats), comença bottom-up encara que el símptoma sembli d'aplicació — comprovar un cable costa 10 segons.

Els enfocaments diuen per on buscar; els 7 passos diuen com treballar la incidència completa:

1. Definir el problema i el seu abast. «No va la xarxa» no és un problema definit. Pregunta fins a obtenir: què falla exactament, des de quan, què va canviar i — la pregunta més rendible del diagnòstic — a qui afecta?: un usuari o tots? una seu o totes dues? un servei o tots? Cada resposta retalla el mapa: si només falla a l'Ana, la causa és al seu lloc o al seu tram; si falla tota València però Bilbao navega, mira l'electrònica o la sortida de València; si totes dues seus fallen contra la intranet però naveguen, mira el servidor .10.10.
2. Reproduir la fallada. Veure-la amb els teus propis ulls (o amb una ordre) evita perseguir descripcions inexactes. Si és intermitent, deixa monitoratge (ping -t, captura) fins a caçar-la.
3. Formular una hipòtesi. Amb l'abast i allò reproduït, tria la causa més probable i l'enfocament (bottom-up/top-down/divideix). Una hipòtesi s'enuncia falsable: «el DHCP no està servint adreces», no «alguna cosa del DHCP».
4. Provar la hipòtesi amb l'eina que la confirmi o la refuti — i canviant una sola cosa cada vegada. Si la refutes, torna al pas 3 amb el que has après (allò descartat també és informació).
5. Aplicar la solució. Si pot ser, amb pla de marxa enrere (anota el valor anterior abans de canviar-lo).
6. Verificar que el problema original ha desaparegut i que no has trencat cap altra cosa. Verifica amb l'usuari i amb l'ordre que abans fallava.
7. Documentar. Símptoma, causa arrel, solució, evidències. Ho desenvolupem al final — és el pas que converteix una incidència patida en coneixement reutilitzable.

Per a l'avís genèric des d'un lloc de treball, aquesta és la llista de comprovació ordenada — de la capa 1 cap amunt — amb l'ordre exacta de cada node. Memoritza'l: és el mòdul 6 sencer en un diagrama.

Dos matisos d'ús: si l'abast (pas 1 del mètode) ja et diu que afecta tothom, no comencis pel lloc d'un usuari — ves a allò comú (router, DHCP, DNS, servidor). I si la destinació és a l'altra seu, insereix després de la porta d'enllaç el node «ruta/VPN?»: tracert cap a la IP remota, com al cas B.

Pas 1 — definir i delimitar. Dilluns, 9:05. L'Ana (València) truca: «no tinc res, ni intranet ni Internet». Preguntes d'abast: la Marta, a dues taules, treballa amb normalitat → afecta un sol usuari de València. Canvis? Divendres a la tarda es van recol·locar taules a la seva zona. L'abast + el canvi físic decideixen l'enfocament: bottom-up.

Pas 2 — reproduir. Al PC de l'Ana:

Reproduït i amb mig diagnòstic inclòs: hi ha link (si no, posaria «Medios desconectados» — la capa 1 queda descartada malgrat el trasllat), però la IP és APIPA (mòdul 5): el PC va demanar DHCP i ningú no va respondre. Sense IP vàlida ni porta d'enllaç, és coherent que «no hi hagi res».

Pas 3 — hipòtesi. DHCP caigut al router .10.1? Contrast ràpid d'abast: ipconfig /all al PC de la Marta mostra el lloguer renovat a les 8:47 → el DHCP funciona per a la resta. Hipòtesi afinada: el problema és entre l'Ana i el DHCP; i com que el DHCP corre al router de la VLAN 10, sospita concreta: en recablejar les taules, el PC de l'Ana va quedar connectat a una presa del switch assignada a la VLAN 20 (convidats) — en aquella VLAN la seva petició DORA (mòdul 2) no arriba mai al DHCP corporatiu.

Pas 4 — provar. Al switch, la presa de la roseta nova de l'Ana (port 14):

El port 14 és a la VLAN 20. Hipòtesi confirmada: divendres, el cable de connexió de l'Ana es va endollar a una presa de convidats.

Passos 5 i 6 — aplicar i verificar. Es reassigna el port 14 a la VLAN 10 (o es mou el cable a una presa corporativa; es tria la primera opció i s'anota el valor anterior). Al PC de l'Ana:

IP del rang dinàmic (.100–.199), porta d'enllaç correcta, intranet accessible. L'Ana ho confirma. Pas 7, al final de la lliçó.

Pas 1 — definir i delimitar. En Jon (Bilbao): «no puc obrir la intranet des d'aquest matí; Internet va perfecte». Es comprova amb un altre company de Bilbao: tampoc → tota la seu de Bilbao, només cap a recursos de València, Internet intacte. A València tot funciona, intranet inclosa. Aquest abast és eloqüent: LAN de Bilbao sana (naveguen), servidor sa (València el fa servir) → la sospita neix ja a l'enllaç entre seus: la VPN. Enfocament: divideix i venceràs sobre la ruta.

Pas 2 — reproduir. Des del PC d'en Jon (.20.7):

Lectura (06-01): el salt 1 respon — fins a la seva porta d'enllaç tot bé — i la ruta mor just després de 192.168.20.1, al tram del túnel. Asteriscos fins al final: tall real, no un router tímid.

Pas 3 — hipòtesi. O el túnel VPN està caigut, o el router de Bilbao ha perdut la ruta cap a 192.168.10.0/24 (mòdul 4: sense ruta, aquells paquets se'n van per la default cap a Internet, on una adreça privada RFC 1918 no arriba enlloc — i per això «Internet va perfecte» mentre València és inabastable).

Pas 4 — provar. Al router de Bilbao:

Confirmat per partida doble: el túnel està DOWN des de les 6:12 i, amb ell caigut, ha desaparegut la ruta 192.168.10.0/24 via Tunnel1 de la taula. El registre del router mostra que a les 6:10 l'ISP de Bilbao va renovar la IP pública de la seu, i l'extrem de València continuava esperant la IP antiga (recorda del mòdul 5 tot el que NAT i les IP dinàmiques compliquen).

Passos 5 i 6 — aplicar i verificar. Es reinicia la negociació del túnel amb la IP nova (i s'anota per al pas 7 una millora permanent: passar la identificació del túnel a un nom DNS dinàmic en lloc d'una IP fixa). Verificació des del PC d'en Jon:

La traça torna a creuar el túnel en 3 salts i l'API respon: verificat en capa 3 i en capa d'aplicació.

Pas 1 — definir i delimitar. Diversos usuaris de València, durant dues setmanes: «la intranet de vegades triga moltíssim a carregar; després va normal». Afecta diversos usuaris, una sola aplicació, de manera intermitent. Els problemes intermitents són els que més castiguen el diagnòstic per intuïció — i on més brilla el mètode.

Pas 2 — reproduir (o monitorar fins a caçar-lo). No es reprodueix a voluntat, així que s'instrumenta: al PC de la Marta es deixa un bucle que mesura l'API cada minut amb curl (opció -w, que imprimeix temps per fase — la versió cronòmetre del -v de 06-01), registrant a fitxer. L'endemà, les dades:

La reproducció instrumentada val or: la lentitud no és a TCP, ni a TLS, ni al servidor (les seves fases són constants): són ~4 segons exactes de DNS, a ràfegues. La xifra rodona fa olor de timeout + reintent: el resolutor espera un servidor que no contesta i, un cop esgotat el termini, pregunta al següent.

Pas 3 — hipòtesi. El DHCP de Meridiano reparteix dos DNS. Hipòtesi: el primer falla intermitentment; quan falla, cada resolució paga el timeout abans de caure al secundari. Pas 4 — provar, primer mirant la configuració i després amb el microscopi (06-02) — captura autoritzada al PC de la Marta, filtre dns:

Aquí hi ha la pel·lícula completa: tres intents al primari .10.2 (una màquina de proves que algú va configurar com a DNS primari al DHCP fa dues setmanes... i que s'apaga a estones) sense resposta, i als 4 segons el sistema pregunta al .10.1, que respon en 2 ms. Coincideix al mil·lisegon amb les ràfegues del curl -w. Hipòtesi confirmada amb evidència de paquet.

Passos 5 i 6 — aplicar i verificar. Es corregeix l'opció DNS del DHCP (primari .10.1, es retira el .10.2), es força la renovació (ipconfig /renew + /flushdns als equips afectats, o s'espera el cicle de lloguer). El monitor de curl -w corre 48 h més: cap mesura per sobre de 0,06 s. Verificat — amb dades, no amb un «sembla que ja va».

El pas 7 és el més barat (10 minuts) i el de més retorn. Què anotar de cada incidència, amb el cas C com a exemple:

Per què val la pena, en fred:

• La pròxima vegada seran 5 minuts: el símptoma «lentitud a ràfegues de ~4 s» quedarà associat a «timeout de DNS primari» a la base de coneixement de l'equip.
• Revela patrons: tres incidències de VLAN mal assignada en dos mesos (cas A) no són tres accidents: són un procediment de recablejat que falta.
• La causa arrel evita la reincidència: sense ella, el cas B s'hauria «resolt» reiniciant el router — fins a la següent renovació d'IP de l'ISP. Documentar obliga a distingir he arreglat el símptoma de he entès la causa.
• Protegeix l'equip: davant d'un «porteu dues setmanes amb la intranet lenta», el registre demostra què es va fer, quan i amb quina evidència.

• Saltar-se el pas 1 i anar directe a les ordres. Dues preguntes d'abast (qui? des de quan/què va canviar?) estalvien més temps que qualsevol eina.
• Canviar diverses coses alhora. Si toques la VLAN, el cable i el DHCP i alguna cosa millora, no saps què era — i potser has introduït una fallada nova. Un canvi, una verificació.
• Confondre correlació amb causa. «Vaig reiniciar el switch i va tornar» no prova que fos el switch (potser el lloguer DHCP es va renovar alhora). La causa arrel exigeix evidència, no coincidència.
• Tancar sense verificar amb l'ordre que fallava (i amb l'usuari). «Ja hauria de funcionar» no és un tancament.
• No anotar l'estat previ abans de canviar res. Sense pla de marxa enrere, un intent fallit es converteix en dues incidències.
• Perseguir problemes intermitents amb proves puntuals. Un ping solt a les 12:00 no caça una fallada de les 9:43. Instrumenta i espera: ping -t, bucles de curl -w, captures programades.
• Tractar el model per capes com un dogma. Els enfocaments són heurístics: si hi ha un indici fort (una obra, un canvi d'ahir), salta-hi directament. El mètode hi és per ordenar la cerca, no per frenar-la.

1. Avís a les 9:00: «no funciona la intranet». Abans de tocar ni una sola ordre, escriu les tres preguntes d'abast que faries i, per a cada combinació de respostes següent, digues on començaries a buscar: (a) només li falla a la Marta, a la resta no; (b) falla a tota València i a tot Bilbao, però tothom navega per Internet; (c) falla a tot Bilbao i només a Bilbao.
2. Al cas A, després de veure l'APIPA al PC de l'Ana, un tècnic proposa com a solució «posar-li una IP fixa: 192.168.10.50, màscara /24, porta d'enllaç .10.1». Comprova que aquesta «solució» probablement semblaria funcionar a mitges o gens — raona què passaria exactament amb el port encara a la VLAN 20 — i explica per què, encara que hagués funcionat, continuaria sent una mala resolució de la incidència segons el mètode.
3. Dissenya el pla de diagnòstic (passos 1–4 del mètode, sense resoldre'l) per a aquest símptoma: «des del portàtil de la sala de reunions de València, connectat al Wi-Fi de convidats, no es pot obrir la intranet; des del Wi-Fi corporatiu, sí». Inclou-hi la hipòtesi més probable tenint en compte el disseny de xarxa de Meridiano i quina ordre la confirmaria.

1. Preguntes: A qui afecta? (un usuari, una seu, tothom?), què falla exactament i què funciona? (només la intranet o també Internet/altres serveis?), des de quan i què va canviar?. Respostes: (a) un sol usuari → la causa és al lloc de la Marta o al seu tram: començar pel seu equip (ipconfig /all, ping a la porta d'enllaç i a la intranet). (b) Totes dues seus fallen només contra la intranet i tota la resta funciona → l'únic element comú a aquest símptoma és el servidor .10.10 (o el seu servei web): anar-hi directament (ping 192.168.10.10 des de València, i ss -tlnp al servidor — host caigut o port tancat?). (c) Només Bilbao, i només cap a València → tram entre seus: VPN/rutes, com al cas B (tracert -d 192.168.10.10 des de Bilbao per veure on mor).
2. Amb el port a la VLAN 20, la IP fixa 192.168.10.50 no serveix: les VLAN separen dominis de capa 2 (mòdul 3), així que els ARP de l'Ana preguntant per .10.1 o .10.10 no arribarien a la VLAN 10 — arp -a mostraria entrades incompletes i els pings fallarien igualment (potser amb la confusió afegida de conflictes si la VLAN 20 fa servir un altre pla). És a dir: la proposta ni tan sols ataca la causa (port a la VLAN equivocada), només el símptoma visible (falta d'IP). I encara que hagués funcionat, violaria el mètode: no hi ha hipòtesi confirmada ni causa arrel (per què va deixar de servir el DHCP a l'Ana?), introdueix una excepció no documentada (una IP fixa fora del pla d'adreçament i de les reserves, futura font de conflictes amb el rang DHCP) i garanteix la reincidència al següent equip que s'endolli a aquella roseta.
3. Pas 1 (definir/delimitar): afecta qualsevol equip del Wi-Fi de convidats (comprovar-ho amb un segon dispositiu), només cap a la intranet (verificar que Internet sí que funciona des de convidats), des de sempre o des d'una data concreta (havia funcionat mai?). Pas 2 (reproduir): des del portàtil a convidats, ipconfig /all (esperable: IP de la xarxa de convidats, no 192.168.10.x) i curl -v https://intranet.grupomeridiano.example anotant en quina fase falla. Pas 3 (hipòtesi): el Wi-Fi de convidats va a la VLAN 20, aïllada deliberadament de la VLAN 10 corporativa — que els convidats no arribin a la intranet no és una avaria sinó el disseny de seguretat de Meridiano funcionant (probablement amb regles al router que permeten convidats→Internet però bloquegen convidats→VLAN 10). Pas 4 (provar): ping 192.168.10.10 i tracert des de convidats (esperable: bloquejat o tallat al router) i contrast immediat del mateix curl des del Wi-Fi corporatiu (funciona). Confirmada la hipòtesi, la «solució» no és tècnica sinó de procediment: qui necessiti la intranet ha de fer servir la xarxa corporativa; si de debò calgués accés des de convidats, seria un canvi de política a decidir i documentar, no un pedaç.

Ja tens complet el mòdul 6: les utilitats esmolades una a una (06-01), el microscopi dels paquets amb el seu marc legal (06-02) i, en aquesta lliçó, el mètode que les governa — els tres enfocaments per capes i quan fer servir cadascun, els 7 passos de definir a documentar, l'arbre de decisió amb la seva ordre per node, i tres incidències de Meridiano (l'APIPA de l'Ana que va acabar en una VLAN, el túnel VPN que va tombar Bilbao, el DNS intermitent caçat amb instrumentació i captura) resoltes de cap a cap. Fixa't en el que ha passat al llarg del mòdul: ARP, TTL, DORA, APIPA, VLAN, rutes, sockets, el handshake... tot allò après als mòduls 1 a 5 ha deixat de ser temari per convertir-se en peces de diagnòstic. Ja tens coneixements i mètode. El que queda és soltesa, i aquesta només es guanya entrenant: el mòdul 7 és exactament això — el gimnàs del curs, amb exercicis de cada bloc i casos pràctics integrats on consolidar tot el que ara saps fer.