In un homelab che mescola Raspberry Pi, mini PC con Linux, un Mac, qualche IoT scemo e uno switch managed, prima o poi capita: “un host non risponde più, non capisco perché”. E sotto la frustrazione c’è quasi sempre la stessa cosa: una catena di ipotesi non verificate. Il modo per uscirne in tempi ragionevoli è una checklist mentale che parte dal basso e sale.
Racconto una sessione di troubleshooting recente e i comandi che uso, ne approfitto per fissare il metodo per la prossima volta.
L’incidente
Un sabato pomeriggio, verso le 16:00, mi accorgo che un Raspberry Pi del homelab (lo chiamo rpi-monitoring) non risponde più al ping dal portatile. Dalle metriche Grafana risulta off dalla rete da circa un’ora. Niente alert sul telefono perché avevo silenziato Telegram nel pomeriggio. Ma il fatto è lì: l’host non c’è più.
Step 1: dove sta il problema?
La prima domanda non è “perché non risponde”, è “da quale layer in giù la cosa funziona”. Vado dal portatile in giù:
ping -c 4 rpi-monitoring
Risposta: Name or service not known. Quindi il DNS non risolve. Il primo strato già rotto. Provo a interrogare direttamente il resolver interno:
dig +short rpi-monitoring @203.0.113.1
Risposta vuota. Il DNS interno non ha più il record. Sospetto un DHCP-DNS che non ha rinnovato la lease. Provo per IP statico, perché ricordo che ha un fallback:
ping -c 4 203.0.113.42
Anche qui timeout. Il problema non è DNS, è che proprio non raggiungo l’host in IP.
Step 2: layer 2 o layer 3?
Ipotesi: il device non è connesso alla LAN. Lo verifico dallo switch managed (accesso via Tailscale dato che è raggiungibile sulla management interface):
ssh admin@switch-managed
show interfaces ethernet port5 status
Port5 down. Cavo non collegato, NIC del device giù, o cavo rotto. Vado fisicamente al rack: cavo collegato sia sullo switch che sul Pi, ma spia LAN sul Pi spenta. Tolgo l’alimentatore e lo riattacco. La spia POWER resta spenta. Provo un altro alimentatore: idem. Sospetto SBC morto.
Step 3: c’è alimentazione?
Tiro fuori un multimetro economico, misuro la tensione del cavo USB-C dell’alimentatore: 5,15 V, dentro spec. Il problema non è l’alimentatore. Provo a infilare la microSD del Pi morto in un altro Raspberry Pi 5 di backup: avvio in 30 secondi, dmesg pulito. Il problema è hardware sul Pi originale. Probabilmente il regolatore di tensione lato SBC è andato.
A questo punto la troubleshooting di rete è finita: non c’era niente da fare via comandi. Il device è hardware-dead, non network-dead. Ma se avessi saltato i primi step e fossi corso a sostituire l’host senza verificare DNS, switch e fisico, avrei potuto perdere un’ora a configurare un Pi nuovo per scoprire poi che lo switch aveva la porta down per un altro motivo.
Comandi che uso spesso
Senza ordine preciso, la cassetta degli attrezzi:
ip link show
ip addr show
ip route show
ss -tunlp
arp -an
ping -c 4 -W 2 host
traceroute -n host
mtr -n -c 10 host
dig +short host @resolver
nslookup host resolver
nmap -sn 203.0.113.0/24
tcpdump -i eth0 -nn host 203.0.113.42
ethtool eth0
sudo nft list ruleset
Su Mac molti hanno equivalenti con flag diversi (ping con -W in millisecondi, traceroute senza -n per default).
Un caso reale collaterale
Stessa settimana, un altro incidente: latenza folle (centinaia di ms) e pacchetti duplicati ogni ping verso un host in LAN. Sintomo classico di ARP duplicato su VLAN. arp -an dal portatile mostrava due MAC diversi per lo stesso IP. Un Pi vecchio, smesso da mesi e tirato fuori per un test, era stato ricollegato con IP statico identico a uno già attivo. L’avevo dimenticato. Spegnimento del Pi vecchio, arp -d 203.0.113.42 per pulire la cache, latenza tornata a valori normali in dieci secondi. Anche quel caso si è risolto in cinque minuti perché ho seguito la checklist invece di indovinare.
Cosa funziona bene
Avere strumenti standard (ping, dig, mtr, tcpdump, ip) installati ovunque, su ogni Pi e mini PC. Niente tool esotici, niente script personalizzati. Funzionano dappertutto, e quando arriva il problema in mezzo alla notte non devi ricordarti come si lancia un binario custom.
Limiti
Il troubleshooting di rete su Wi-Fi è sempre più frustrante: client che migrano fra AP, mesh che fanno scelte opache, banda 2.4/5/6 GHz che cambia comportamento. Per quello tengo separati i client Wi-Fi dai server, e i server stanno tutti su ethernet. Niente Wi-Fi nei percorsi critici.
In pratica
Il metodo è più importante degli strumenti. Partire dal layer 1 (cavo, alimentazione, link) e salire (layer 2 MAC/switch, layer 3 IP, layer 4 porte, layer 7 applicazione) evita di girare a vuoto. Quasi tutti i problemi si risolvono nei primi tre layer, e il tempo speso a verificare l’ovvio si recupera ampiamente non andando dietro alle ipotesi sbagliate.
Immagine generata con ComfyUI Mac M1 / RealVisXL V5 Lightning.