El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

En tancar el mòdul 5 sabies dissenyar l'adreçament d'una xarxa com la de Grupo Meridiano de punta a punta. Però una xarxa ben dissenyada també falla: la Marta no arriba a la intranet, un ping es perd a mig camí, el DNS resol estrany. En aquest mòdul convertirem el que saps en un mètode de diagnòstic, i el primer pas és sistematitzar la farmaciola. Les eines d'aquesta lliçó ja han anat apareixent puntualment al llarg del curs (ping al mòdul 2, arp -a amb Ethernet, nslookup amb DNS, ss amb els sockets, ip route amb TCP/IP); ara les esmolem: quines opcions importen, com llegir-ne les sortides com un professional i — sobretot — quan fer servir cadascuna. Treballarem sempre en paral·lel Windows/Linux, perquè a Meridiano (i a gairebé qualsevol empresa) conviuen tots dos: els PC de la Marta i l'Ana són Windows, el servidor de la intranet (192.168.10.10) és Linux.

Contingut

Veure la configuració pròpia: ipconfig /all davant ip addr + ip route
ping a fons: opcions, TTL, pèrdua i jitter
traceroute/tracert: veure el camí salt a salt
arp -a: confirmar la capa 2
nslookup i dig: interrogar el DNS amb precisió
netstat/ss: repàs operatiu
curl: el comprovador de la capa d'aplicació
Taula final: símptoma → primera eina

Veure la configuració pròpia: `ipconfig /all` davant `ip addr` + `ip route`

Abans de culpar la xarxa, mira la teva pròpia configuració. És l'equivalent a comprovar que el cotxe té benzina abans de trucar a la grua. A Windows, l'ordre és ipconfig /all (el /all és important: sense ell no veuràs la MAC, el servidor DHCP ni els DNS).

Al PC de la Marta, a València:

C:\> ipconfig /all

Adaptador de Ethernet Ethernet0:

   Sufijo DNS específico para la conexión. . : grupomeridiano.example
   Dirección física. . . . . . . . . . . . . : 5C-26-0A-4B-91-D3
   DHCP habilitado . . . . . . . . . . . . . : sí
   Dirección IPv4. . . . . . . . . . . . . . : 192.168.10.21(Preferido)
   Máscara de subred . . . . . . . . . . . . : 255.255.255.0
   Concesión obtenida. . . . . . . . . . . . : lunes, 13 de julio de 2026 8:02:11
   La concesión expira . . . . . . . . . . . : martes, 14 de julio de 2026 8:02:11
   Puerta de enlace predeterminada . . . . . : 192.168.10.1
   Servidor DHCP . . . . . . . . . . . . . . : 192.168.10.1
   Servidores DNS. . . . . . . . . . . . . . : 192.168.10.1

Lectura línia a línia, en l'ordre en què la mira un professional:

Dirección IPv4: és l'esperada? 192.168.10.21 és la reserva DHCP de la Marta (associada a la seva MAC 5c:26:0a:4b:91:d3, com vam veure al mòdul 2). Si aquí aparegués 169.254.x.x (APIPA, mòdul 5), el diagnòstic gairebé estaria fet: el DHCP no va respondre.
Máscara de subred: /24 correcte. Recorda el cas de la màscara /25 mal posada del mòdul 5: una màscara errònia produeix fallades asimètriques molt confuses.
Puerta de enlace predeterminada: sense ella no hi ha sortida de la xarxa local. Buida o incorrecta = el cas d'en Jon al mòdul 3.
Servidores DNS: si la IP i la porta d'enllaç estan bé però «no funciona Internet», el sospitós habitual és aquest camp.
DHCP habilitado / concesión: et diu si la IP és dinàmica i quan caduca el lloguer. Útil per saber si un ipconfig /release + /renew té sentit.

A Linux, la mateixa informació es reparteix en dues ordres que ja vam presentar al mòdul 4. Al servidor de la intranet:

joan@intranet:~$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
    link/ether 00:1a:4d:7e:22:0f brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.10/24 brd 192.168.10.255 scope global eth0
       valid_lft forever preferred_lft forever

joan@intranet:~$ ip route
default via 192.168.10.1 dev eth0
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.10

state UP i LOWER_UP: la interfície està administrativament activa i té link físic (cable/portadora). Si falta LOWER_UP, ets davant d'un problema de capa 1 — el cable de l'Ana del mòdul 3.
inet 192.168.10.10/24: IP i màscara en notació CIDR, en una sola línia.
default via 192.168.10.1: la ruta per defecte, és a dir, la porta d'enllaç.
Els DNS a Linux es consulten a part: cat /etc/resolv.conf (o resolvectl status en sistemes amb systemd-resolved).

Què mirar (en ordre)	Windows	Linux
Hi ha link físic?	«Medios desconectados» a `ipconfig`	`LOWER_UP` a `ip link` / `ip addr`
IP correcta? (APIPA?)	`ipconfig /all` → Dirección IPv4	`ip addr` → `inet`
Màscara correcta?	Máscara de subred	el `/NN` després de la IP
Porta d'enllaç configurada?	Puerta de enlace predeterminada	`ip route` → `default via`
DNS configurat?	Servidores DNS	`/etc/resolv.conf`

Aquest ordre no és casual: és el «capa 1 primer» (mòdul 3) aplicat a la teva pròpia màquina.

`ping` a fons: opcions, TTL, pèrdua i jitter

ping (mòdul 2) envia ICMP Echo Request i espera Echo Reply. És l'eina de connectivitat per excel·lència, però la seva sortida diu molt més que «respon / no respon».

Diferència clau entre sistemes: Windows envia 4 paquets i para; Linux envia indefinidament fins que prems Ctrl+C.

Necessito...	Windows	Linux
Ping continu	`ping -t 192.168.10.10`	`ping 192.168.10.10` (ja ho és)
Un nombre concret de paquets	`ping -n 10 ...`	`ping -c 10 ...`
Mida de paquet	`ping -l 1400 ...`	`ping -s 1400 ...`
No fragmentar (provar l'MTU)	`ping -f -l 1472 ...`	`ping -M do -s 1472 ...`

El ping continu (-t) és or per a problemes intermitents: el deixes corrent mentre reprodueixes la fallada. I les opcions de mida + no fragmentar són exactament el que vam fer servir al mòdul 4 per diagnosticar el problema d'MTU a la VPN amb Bilbao.

La Marta fa ping a la intranet i al PC d'en Jon a Bilbao:

C:\> ping -n 4 192.168.10.10

Haciendo ping a 192.168.10.10 con 32 bytes de datos:
Respuesta desde 192.168.10.10: bytes=32 tiempo<1ms TTL=64
Respuesta desde 192.168.10.10: bytes=32 tiempo<1ms TTL=64
Respuesta desde 192.168.10.10: bytes=32 tiempo=1ms TTL=64
Respuesta desde 192.168.10.10: bytes=32 tiempo<1ms TTL=64

Estadísticas de ping para 192.168.10.10:
    Paquetes: enviados = 4, recibidos = 4, perdidos = 0 (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 0ms, Máximo = 1ms, Media = 0ms

C:\> ping -n 4 192.168.20.7

Respuesta desde 192.168.20.7: bytes=32 tiempo=38ms TTL=126
Respuesta desde 192.168.20.7: bytes=32 tiempo=41ms TTL=126
Respuesta desde 192.168.20.7: bytes=32 tiempo=39ms TTL=126
Respuesta desde 192.168.20.7: bytes=32 tiempo=112ms TTL=126

Lectura experta:

TTL=64 des de la intranet: recorda del mòdul 2 que cada router resta 1 al TTL. Els valors inicials típics són 64 (Linux), 128 (Windows) i 255 (equips de xarxa). TTL=64 sense restar-hi res et diu dues coses: el servidor és a la teva mateixa xarxa (0 salts) i probablement és Linux.
TTL=126 des de Bilbao: 128 − 126 = 2 salts → el PC d'en Jon és Windows (va partir de 128) i hi ha 2 routers pel mig (el de València i el de Bilbao, a través del túnel VPN). El TTL et permet inferir salts i sistema operatiu sense tocar la destinació.
Temps: <1 ms en LAN és normal; ~40 ms a Bilbao per la VPN, raonable. Fixa't en el quart paquet: 112 ms. Aquesta variació entre temps s'anomena jitter, i és la que arruïna videotrucades i VoIP encara que la mitjana sigui bona.
Pèrdua de paquets: 0 % és l'esperable en LAN. Un 2–5 % sostingut ja degrada notablement TCP (retransmissions) i destrossa el temps real. La veurem «en persona» a la lliçó 06-02.

I l'advertiment més important: «Tiempo de espera agotado» NO demostra que el host estigui caigut. Molts tallafocs (inclòs el de Windows per defecte davant de xarxes «públiques») filtren ICMP: el host és viu i està servint, però no contesta pings. Ho vam veure al mòdul 3 amb el cas «port tancat vs host caigut». Regla pràctica: un ping que respon confirma connectivitat; un ping que no respon només és un indici que cal contrastar (per exemple, amb curl al servei real, més avall).

`traceroute`/`tracert`: veure el camí salt a salt

Eina nova. Quan el ping falla «a mig camí», vols saber on es talla la ruta. tracert (Windows) i traceroute (Linux) et mostren cada router intermedi.

El seu funcionament és una idea brillant construïda sobre el TTL del mòdul 2:

Envia un paquet amb TTL=1. El primer router el rep, resta 1, arriba a 0, el descarta… i retorna un ICMP "Time Exceeded" amb la seva pròpia IP com a remitent. Primer salt identificat.
N'envia un altre amb TTL=2: mor al segon router, que es delata igual.
Repeteix amb TTL=3, 4, 5… fins que el paquet arriba a la destinació, que respon normalment.

sequenceDiagram
    participant M as Marta (.10.21)
    participant R1 as Router VLC (.10.1)
    participant R2 as Router BIO (.20.1)
    participant J as Jon (.20.7)
    M->>R1: paquet TTL=1
    R1-->>M: ICMP Time Exceeded (soc .10.1)
    M->>R2: paquet TTL=2 (passa per R1)
    R2-->>M: ICMP Time Exceeded (soc .20.1)
    M->>J: paquet TTL=3
    J-->>M: resposta normal (destinació assolida)

Traça de la Marta cap a Bilbao (per la VPN) i cap a Internet:

C:\> tracert -d 192.168.20.7

Traza a 192.168.20.7 sobre caminos de 30 saltos como máximo:

  1    <1 ms    <1 ms    <1 ms  192.168.10.1
  2    37 ms    39 ms    38 ms  192.168.20.1
  3    39 ms    40 ms    41 ms  192.168.20.7

Traza completa.

C:\> tracert -d 8.8.8.8

  1    <1 ms    <1 ms    <1 ms  192.168.10.1
  2     9 ms     8 ms    10 ms  10.140.2.1
  3    11 ms    12 ms    11 ms  81.46.15.77
  4     *        *        *     Tiempo de espera agotado para esta solicitud.
  5    17 ms    16 ms    17 ms  8.8.8.8

Com llegir-la:

-d (Windows) / -n (Linux) desactiva la resolució DNS inversa de cada salt: la traça va molt més ràpida i en diagnòstic gairebé sempre la vols així.
Cap a Bilbao només hi ha 3 salts: el túnel VPN encapsula el trànsit, així que tots els routers d'Internet que hi ha físicament entre València i Bilbao són invisibles — el túnel es comporta com un cable virtual entre .10.1 i .20.1. Coincideix amb el que vam deduir del TTL=126 del ping (2 routers).
Cap a Internet apareixen la porta d'enllaç, l'ISP (10.140.2.1, una adreça privada de la xarxa de l'operador — CG-NAT, mòdul 5) i salts públics.
Els asteriscos * al salt 4 no signifiquen avaria: aquell router simplement no respon a les sondes (per política, o per prioritat baixa del pla de control), però reenvia el trànsit — la prova és que el salt 5 respon. Preocupa't quan els asteriscos apareixen en un salt i en tots els següents fins al final: aquí sí que es talla la ruta, i l'últim salt que va respondre és la teva millor pista d'on és el problema.
Detall tècnic que de vegades importa: Windows sondeja amb ICMP Echo; Linux, per defecte, amb UDP a ports alts (fes servir traceroute -I per forçar ICMP). Alguns tallafocs tracten diferent cada tipus, així que la mateixa traça pot diferir entre sistemes.

Quan fer servir traceroute? Quan la connectivitat extrem a extrem falla o és lenta i necessites localitzar el tram: si de València a Bilbao la traça mor després de 192.168.10.1, el problema és a la VPN o més enllà; si ni tan sols apareix el salt 1, el problema és local.

`arp -a`: confirmar la capa 2

Ja coneixes ARP del mòdul 2: tradueix IP a MAC dins de la xarxa local. Com a eina de diagnòstic, arp -a respon una pregunta molt concreta: «el meu equip ha aconseguit parlar en capa 2 amb aquell veí?»

C:\> arp -a

Interfaz: 192.168.10.21 --- 0xb
  Dirección de Internet      Dirección física      Tipo
  192.168.10.1               a4-91-b1-0c-77-2e     dinámico
  192.168.10.10              00-1a-4d-7e-22-0f     dinámico
  192.168.10.255             ff-ff-ff-ff-ff-ff     estático

Hi ha entrada amb MAC per a la porta d'enllaç (.10.1) i la intranet (.10.10): la resolució ARP va funcionar, per tant la capa 1 i la capa 2 fins a aquests equips queden confirmades. Si un ping a .10.10 fallés però la seva entrada ARP existís i fos recent, el problema seria per sobre de la capa 2 (un tallafoc, per exemple).
A Linux, ip neigh mostra a més l'estat: REACHABLE (confirmat), STALE (antic, es revalidarà) o FAILED/INCOMPLETE.
Una entrada incompleta (Linux: INCOMPLETE; Windows: l'entrada directament no apareix després d'intentar el ping) significa que es va preguntar «qui té 192.168.10.10?» i ningú no va contestar: el host està apagat, desconnectat o en una altra VLAN (recorda: la VLAN 20 de convidats de Meridiano no veu ARP de la VLAN 10 corporativa).
Matís important: ARP només serveix per a la pròpia subxarxa. De 192.168.20.7 no en veuràs mai la MAC a València; veuràs trànsit cap a la MAC de la porta d'enllaç.

Truc de camp: arp -a immediatament després d'un ping fallit a un veí és la manera més ràpida de separar «problema de capa 2» de «host que filtra ICMP».

`nslookup` i `dig`: interrogar el DNS amb precisió

nslookup va aparèixer al mòdul 2 amb els tipus A/AAAA/CNAME/MX. Com a eina de diagnòstic, el seu valor rau en dues capacitats: demanar tipus concrets de registre i preguntar a un servidor concret, saltant-te la configuració local.

C:\> nslookup intranet.grupomeridiano.example
Servidor:  router.grupomeridiano.example
Address:  192.168.10.1

Nombre:  intranet.grupomeridiano.example
Address:  192.168.10.10

C:\> nslookup intranet.grupomeridiano.example 8.8.8.8
Servidor:  dns.google
Address:  8.8.8.8

*** dns.google no puede encontrar intranet.grupomeridiano.example:
    Non-existent domain

Interpretació — i és un patró que veuràs mil vegades:

Les dues primeres línies de cada consulta et diuen a qui estàs preguntant. La primera consulta fa servir el DNS configurat (el router de Meridiano, que resol la zona interna).
Afegir una IP al final (... 8.8.8.8) força la consulta a aquell servidor. Que Google no conegui intranet.grupomeridiano.example aquí és normal: és un nom intern que només existeix al DNS de l'empresa. Però aquesta tècnica és la clau per respondre «el problema és el meu DNS o el nom en general?»: si el teu DNS falla i 8.8.8.8 resol, el problema és el teu servidor DNS, no el domini.
Per a un tipus concret: nslookup -type=MX grupomeridiano.example.

A Linux, l'eina preferida dels professionals és dig, més detallada:

joan@intranet:~$ dig intranet.grupomeridiano.example A +noall +answer

intranet.grupomeridiano.example. 3600 IN A 192.168.10.10

El 3600 és el TTL del registre (un altre TTL, diferent del d'IP!): els segons que la resposta pot viure en memòries cau. Explica el clàssic «he canviat el DNS però uns usuaris van al servidor vell i altres al nou»: les memòries cau amb el registre antic el serviran fins a esgotar-ne el TTL.
Sintaxi per a un servidor concret a dig: dig @8.8.8.8 grupomeridiano.example MX.
A Windows, ipconfig /displaydns mostra la memòria cau DNS local i ipconfig /flushdns la buida — el primer remei quan sospites d'una resposta en cau obsoleta.

`netstat`/`ss`: repàs operatiu

Aquestes dues les vam treballar a fons a la lliçó 04-04 (sockets, LISTEN/ESTABLISHED/TIME_WAIT, EADDRINUSE); aquí només en fixem el paper a la farmaciola: responen a «el servei escolta i qui hi està connectat?». Les invocacions que has de tenir a la memòria muscular:

# Linux — la intranet escolta al 443?
joan@intranet:~$ ss -tlnp | grep 443
LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=812,fd=6))

# Windows — quines connexions tinc obertes i qui les va obrir?
C:\> netstat -ano | findstr ESTABLISHED

Mnemotècnia de ss -tlnp: tcp, listening, numèric, processos. Si un curl a un servidor falla, la comprovació al servidor és sempre aquesta: sense un socket en LISTEN, no hi ha res que connecti. El detall fi (estats, cues, TIME_WAIT) és a 04-04.

`curl`: el comprovador de la capa d'aplicació

Tot l'anterior comprova les capes 1–4. Però «la intranet no va» pot ser una fallada de capa 7 amb totes les capes inferiors perfectes. curl fa peticions HTTP/HTTPS reals des del terminal (ve de sèrie a Linux i a Windows 10+), i amb -v (verbose) t'ensenya cada fase per separat — exactament el flux DNS→TCP→TLS→HTTP que vam disseccionar al mòdul 4:

joan@intranet:~$ curl -v https://intranet.grupomeridiano.example/api/proyectos
* Host intranet.grupomeridiano.example:443 was resolved.
* IPv4: 192.168.10.10                          ← fase DNS: resolt
*   Trying 192.168.10.10:443...
* Connected to intranet.grupomeridiano.example (192.168.10.10) port 443
                                               ← fase TCP: handshake OK
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
*  subject: CN=intranet.grupomeridiano.example
*  expire date: Mar  2 11:00:00 2027 GMT       ← fase TLS: certificat vàlid
> GET /api/proyectos HTTP/1.1
> Host: intranet.grupomeridiano.example
< HTTP/1.1 200 OK                              ← fase HTTP: el servidor respon
< Content-Type: application/json
[{"id":1,"nombre":"Migració ERP Ondarreta"},{"id":2,"nombre":"Web Ajt. Mislata"}]

El poder diagnòstic és a on s'atura la sortida:

`curl -v` s'atura a...	Capa culpable	Eina següent
`Could not resolve host`	DNS	`nslookup`/`dig`
`Trying ...` i timeout	Xarxa/ruta (o tallafoc que descarta)	`ping`, `tracert`
`Connection refused`	Servei aturat (port tancat)	`ss -tlnp` al servidor
Error de certificat TLS	TLS (caducat, el nom no coincideix)	revisar el certificat
Connecta però HTTP 4xx/5xx	La mateixa aplicació	logs de l'aplicació

Fixa't que Connection refused (RST immediat: hi ha host, no hi ha servei) davant de timeout (ningú no contesta) és la mateixa distinció «port tancat vs host caigut» del mòdul 3 — curl te la serveix etiquetada.

Taula final: símptoma → primera eina

Símptoma	Primera eina	Què et dirà
«No tinc xarxa» (res no funciona)	`ipconfig /all` / `ip addr`	Link? APIPA? porta d'enllaç? — capa 1 primer
«No arribo a un equip concret»	`ping` i després `arp -a` (si és veí)	Connectivitat; confirmació de capa 2
«Arribo a uns llocs i a altres no»	`tracert`/`traceroute`	En quin salt es talla o es degrada la ruta
«Els noms no resolen» o resolen estrany	`nslookup`/`dig` (provant un altre servidor)	El meu DNS, la memòria cau o el domini?
«La web/API falla» amb la xarxa aparentment bé	`curl -v`	En quina fase (DNS/TCP/TLS/HTTP) es trenca
«El servei no accepta connexions» (al servidor)	`ss -tlnp` / `netstat -ano`	És en LISTEN? Quin procés?
«Va lent / es talla a estones»	`ping -t` (jitter, pèrdua) + `tracert`	On apareix la pèrdua/latència

Errors Comuns i Consells

Concloure «host caigut» perquè no respon al ping. Els tallafocs filtren ICMP constantment. Contrasta sempre amb el servei real: curl al port de l'aplicació.
Oblidar el /all a ipconfig. Sense ell no veus DHCP, DNS ni MAC, que és just el que sol importar.
Espantar-se per asteriscos solts en un traceroute. Un salt mut amb salts posteriors que responen és cosmètic. Només importa el punt a partir del qual tot són asteriscos fins al final.
Ignorar el TTL de les respostes de ping. És informació gratis: salts fins a la destinació i pista del sistema operatiu remot.
Provar el DNS només amb el servidor configurat. La consulta a un segon servidor (nslookup nom 8.8.8.8) separa en segons «el meu DNS falla» de «el domini falla».
Buscar amb arp -a la MAC d'un equip d'una altra subxarxa. ARP no creua routers; per a Bilbao només veuràs la MAC de la teva porta d'enllaç.
Fer un sol ping i decidir. Els problemes intermitents exigeixen ping -t (o -c 100) mirant pèrdua i jitter, no un ping solt.

Exercicis

Des del PC de la Marta, ping 192.168.10.10 retorna respostes amb TTL=64, i ping 192.168.20.1 retorna respostes amb TTL=254. Raona, per a cada cas: quants routers hi ha pel mig i quina pista tens del tipus de sistema que respon?
L'Ana no pot obrir https://intranet.grupomeridiano.example. Executa curl -v i la sortida s'atura després de * Trying 192.168.10.10:443... amb Connection refused immediat. El seu company afirma: «el servidor està caigut, ni tan sols està encès». Té raó? Què indica exactament aquest missatge i quina ordre executaries al servidor per confirmar-ho?
Un tracert -d 192.168.20.7 des de València mostra: salt 1 192.168.10.1 OK; salts 2 a 30, tot asteriscos. Un altre dia, la mateixa traça mostrava al salt 2 192.168.20.1 i al salt 3 la destinació. Quin tram assenyalaries com a avariat i per què el salt 1 correcte és una pista valuosa?

Solucions

Intranet, TTL=64: els TTL inicials típics són 64, 128 o 255. Rebre exactament 64 significa 0 routers pel mig (és a la mateixa subxarxa, coherent: .10.21 i .10.10 comparteixen la /24) i suggereix un sistema Linux/Unix (inicial 64). Router de Bilbao, TTL=254: va partir de 255 (habitual en equips de xarxa) i s'hi va restar 1 una vegada → 1 router pel mig (el de València, .10.1; la mateixa destinació no descompta el seu salt). Fixa't que el mateix valor de TTL rebut s'interpreta relatiu a l'inicial més probable.
No té raó. Connection refused significa que el host va respondre — amb un RST: hi ha una màquina viva a 192.168.10.10, però cap procés no escolta al port 443 (servei aturat o escoltant en un altre port). Si el servidor estigués apagat, el símptoma seria un timeout (ningú no contesta), no un rebuig immediat. Confirmació al servidor: ss -tlnp | grep 443 — si no hi ha línia LISTEN, cal arrencar/revisar l'nginx de la intranet. És la distinció «port tancat vs host caigut» del mòdul 3.
El tall és després de la porta d'enllaç de València i abans del router de Bilbao: és a dir, al túnel VPN (o a la connexió a Internet que el transporta). El salt 1 correcte és valuós perquè descarta tot el tram local: el PC de la Marta, el cablatge, el switch i la porta d'enllaç funcionen; no té sentit revisar res a la LAN de València. A diferència d'un asterisc solt, aquí els asteriscos van del salt 2 fins al final: la ruta es talla de veritat. Pas següent: revisar l'estat del túnel VPN al router .10.1.

Conclusió

Ja tens la farmaciola endreçada: ipconfig/ip addr + ip route per a la teva pròpia configuració (capa 1 primer), ping llegit amb ull expert (TTL, pèrdua, jitter, i la seva gran limitació: l'ICMP filtrat), traceroute per localitzar el tram que falla reutilitzant el truc del TTL, arp -a com a confirmació de capa 2, nslookup/dig per interrogar el DNS amb precisió de cirurgià, ss/netstat per als sockets i curl -v com a sonda de la capa d'aplicació que separa DNS, TCP, TLS i HTTP en fases visibles. Amb la taula símptoma → eina tens el reflex inicial per a gairebé qualsevol avís. Però totes aquestes utilitats comparteixen un límit: et diuen que alguna cosa falla i on, però no sempre per què — treballen sobre resums i inferències. Quan necessites la veritat completa, cal baixar al nivell on no es pot mentir: veure els paquets un a un. Això — Wireshark, tcpdump i l'anàlisi de trànsit, amb el seu marc legal i ètic — és la lliçó següent.

Utilitats Bàsiques de Xarxa

Contingut

Veure la configuració pròpia: `ipconfig /all` davant `ip addr` + `ip route`

`ping` a fons: opcions, TTL, pèrdua i jitter

`traceroute`/`tracert`: veure el camí salt a salt

`arp -a`: confirmar la capa 2

`nslookup` i `dig`: interrogar el DNS amb precisió

`netstat`/`ss`: repàs operatiu

`curl`: el comprovador de la capa d'aplicació

Taula final: símptoma → primera eina

Errors Comuns i Consells

Exercicis

Solucions

Conclusió

Curs de Xarxes

Mòdul 1: Introducció a les Xarxes

Mòdul 2: Protocols de Comunicació

Mòdul 3: El Model OSI

Mòdul 4: El Model TCP/IP

Mòdul 5: Adreçament IP i Subxarxes

Mòdul 6: Eines de Diagnòstic de Xarxa

Mòdul 7: Exercicis i Casos Pràctics

Utilitats Bàsiques de Xarxa

Contingut

Veure la configuració pròpia: ipconfig /all davant ip addr + ip route

ping a fons: opcions, TTL, pèrdua i jitter

traceroute/tracert: veure el camí salt a salt

arp -a: confirmar la capa 2

nslookup i dig: interrogar el DNS amb precisió

netstat/ss: repàs operatiu

curl: el comprovador de la capa d'aplicació

Taula final: símptoma → primera eina

Errors Comuns i Consells

Exercicis

Solucions

Conclusió

Curs de Xarxes

Mòdul 1: Introducció a les Xarxes

Mòdul 2: Protocols de Comunicació

Mòdul 3: El Model OSI

Mòdul 4: El Model TCP/IP

Mòdul 5: Adreçament IP i Subxarxes

Mòdul 6: Eines de Diagnòstic de Xarxa

Mòdul 7: Exercicis i Casos Pràctics

Veure la configuració pròpia: `ipconfig /all` davant `ip addr` + `ip route`

`ping` a fons: opcions, TTL, pèrdua i jitter

`traceroute`/`tracert`: veure el camí salt a salt

`arp -a`: confirmar la capa 2

`nslookup` i `dig`: interrogar el DNS amb precisió

`netstat`/`ss`: repàs operatiu

`curl`: el comprovador de la capa d'aplicació