Troubleshooting di rete: 10 controlli che ogni network engineer dovrebbe saper eseguire

Quando una rete smette di comportarsi come previsto, la tentazione è quella di provare soluzioni a caso: riavviare il router, cambiare un cavo, alzare la voce in sala server. Ma il troubleshooting efficace non è improvvisazione: è un metodo. Un network engineer esperto non "spera" che il problema sparisca, esegue controlli ordinati e usa i dati per restringere il campo delle cause possibili.

In questo articolo raccogliamo dieci controlli pratici, dal livello più basso (fisico e data link) fino alle applicazioni, che ogni professionista di rete dovrebbe saper eseguire con sicurezza. L'ordine non è casuale: riflette il modo in cui i problemi si manifestano e si risolvono, partendo dagli strati più fondamentali del modello di riferimento e risalendo verso quelli applicativi.

1. Verificare lo stato fisico delle interfacce

Il primo controllo è anche il più banale e il più spesso trascurato: la porta è davvero su? Su un dispositivo Cisco, comandi come show interfaces status e show interfaces <nome> mostrano lo stato operativo e amministrativo di ogni interfaccia. Uno stato "down/down" indica tipicamente un problema fisico (cavo scollegato, porta spenta amministrativamente, dispositivo spento all'altro capo), mentre "up/down" suggerisce un problema a livello di protocollo, ad esempio un mismatch di duplex o di velocità.

Prima di analizzare pacchetti e routing, conviene sempre escludere l'ovvio: led spenti, cavi danneggiati, moduli SFP non rilevati. La maggior parte dei guasti di rete che sembrano "impossibili" inizia da un cavo o da un connettore.

2. Controllare la tabella ARP

L'Address Resolution Protocol (ARP) è il meccanismo con cui un host IPv4 scopre l'indirizzo MAC associato a un indirizzo IP sulla stessa rete fisica, come definito nella RFC 826. Se il livello 2 non funziona, nulla di ciò che sta sopra può funzionare, anche se la configurazione IP è corretta.

show arp su un dispositivo Cisco (o arp -a su Windows/Linux) mostra le associazioni IP-MAC apprese. Un host che risponde al ping ma non è in ARP, oppure un indirizzo MAC inatteso (una macchina diversa da quella attesa, un indirizzo che cambia spesso), è un segnale d'allarme: può indicare un conflitto di indirizzi o, in ambienti critici, un tentativo di ARP spoofing. Le voci ARP "incomplete" rivelano che la richiesta di risoluzione non ha ottenuto risposta.

3. Verificare l'indirizzamento e la maschera di sottorete

Un errore di configurazione IP è tra le cause più comuni di "non si vede niente ma tutto sembra a posto". Due dispositivi con indirizzi della stessa rete ma maschere diverse possono non riuscire a comunicare: un host che considera un indirizzo "remoto" inoltra il traffico al gateway invece di consegnarlo direttamente sul segmento.

Il controllo è rapido: ipconfig su Windows, ip addr o ifconfig su Linux, show ip interface brief su un router Cisco. Vanno verificati tre valori: indirizzo, maschera e gateway predefinito. Un errore sul gateway è particolarmente insidioso perché la rete locale funziona, ma tutto il traffico verso l'esterno fallisce.

4. Testare la raggiungibilità con ping

Ping è lo strumento di base per la verifica della raggiungibilità. Usa messaggi ICMP Echo Request e attende le corrispondenti Echo Reply (RFC 792): un flusso di risposte conferma che il percorso di rete, in entrambe le direzioni, funziona.

Il valore del ping non sta solo nel "risponde o non risponde", ma nei dettagli: percentuale di pacchetti persi, tempi di risposta medi e massimi, varianza tra le misure. Una perdita sporadica di pacchetti può indicare congestione, errori di trasmissione o buffer pieni; un aumento progressivo dei tempi di risposta suggerisce un percorso sempre più lento. Su dispositivi di rete si usa ping con estensioni, ad esempio ping ip o ping vrf <nome> per testare specifiche tabelle di routing.

5. Tracciare il percorso con traceroute

Quando la destinazione è raggiungibile ma "male", traceroute mostra il percorso che i pacchetti attraversano. Lo strumento sfrutta il campo Time-to-Live dell'IP e i messaggi ICMP Time Exceeded (RFC 792): a ogni salto, il router che scarta il pacchetto per TTL esaurito invia una notifica che permette di identificare l'hop corrente.

Il risultato è una mappa del percorso: dove i tempi di risposta schizzano verso l'alto, dove compaiono asterischi (hop che non rispondono, spesso per scelte di filtraggio), e dove il percorso si interrompe del tutto. Questo permette di capire se il problema è "dalla nostra parte", nel transit di un provider, o verso la destinazione. Su un router Cisco si usa traceroute, e per il traffico IPv6 traceroute ipv6.

6. Verificare le tabelle di routing

Anche se il percorso fisico è corretto, i pacchetti devono essere instradati. show ip route su un dispositivo Cisco mostra le rotte apprese e le rotte statiche: la destinazione è raggiungibile secondo la tabella? La rotta punta all'hop giusto? Una rotta mancante o una rotta "via" un gateway irraggiungibile spiega perfettamente un traffico che si ferma a metà strada.

Il controllo va eseguito sia sul dispositivo di origine sia sui dispositivi intermedi, perché il problema può essere in un solo punto del percorso. Con show ip route <destinazione> è possibile verificare la rotta specifica verso un singolo indirizzo, senza interpretare l'intera tabella.

7. Esaminare le statistiche degli errori

Le interfacce di rete accumulano contatori che raccontano la salute del collegamento: show interfaces mostra errori di input/output, collisioni, pacchetti scartati, CRC errori e runts. Valori che crescono nel tempo indicano un problema fisico o di configurazione, come un cavo danneggiato, un connettore ossidato, un duplex mismatch o un interferenza elettromagnetica.

La differenza tra due letture successive (ad esempio show interfaces | include error a distanza di qualche minuto) è più utile del valore assoluto: se i contatori avanzano mentre la rete "sembra" funzionare, il problema è in corso e va cercato prima che peggiori.

8. Controllare i log e le syslog

I dispositivi di rete registrano gli eventi: collegamenti che si alzano e si abbassano, cambi di stato del protocollo di routing, tentativi di accesso falliti, modifiche di configurazione. show logging o l'invio dei log a un server syslog centrale permette di ricostruire la sequenza degli eventi che hanno preceduto il guasto.

Il valore dei log sta nel contesto: un link che si è abbassato alle 14:32 e un utente che segnala un problema alle 14:35 sono quasi certamente collegati. Un server syslog centralizzato è un investimento che ripaga nel momento in cui serve ricostruire la cronologia di un incidente.

9. Usare la segmentazione per isolare il problema

Il principio fondamentale del troubleshooting è dividere per conquistare: restringere il problema a un segmento, a un dispositivo o a un protocollo, invece di analizzare l'intera rete. Se un utente non raggiunge un server, si testa il percorso un pezzo alla volta: host verso gateway, gateway verso router successivo, e così via fino alla destinazione.

L'isolamento può anche essere logico: se solo un'applicazione non funziona mentre la rete è sana, il problema non è la rete ma l'applicazione o la sua configurazione. Questa distinzione, apparentemente ovvia, evita di "riparare" la rete quando il problema è altrove.

10. Documentare, verificare e ripetere

L'ultimo controllo è metodologico: ogni operazione di troubleshooting andrebbe documentata, con sintomi osservati, controlli eseguiti, risultati e soluzione applicata. La documentazione non è burocrazia: è il materiale con cui si costruiscono playbook e conoscenza condivisa del team.

Dopo un intervento, inoltre, va verificato che il problema sia effettivamente risolto e che non siano state introdotte regressioni. Un cambiamento di configurazione fatto "per risolvere" senza una verifica successiva è la causa di molti incidenti futuri.

Un metodo, non una lista

Questi dieci controlli non sono un elenco da eseguire meccanicamente, ma gli ingredienti di un metodo: partire dal livello fisico, raccogliere dati, restringere il campo e verificare ogni ipotesi. La competenza di un network engineer non si misura dalla quantità di comandi memorizzati, ma dalla capacità di usarli nell'ordine giusto e di interpretarne i risultati.

I professionisti che padroneggiano queste tecniche sono quelli che trasformano i guasti da eventi stressanti in esercizi risolvibili con metodo. E come ogni competenza tecnica, si costruisce con la pratica: su laboratori, su ambienti di test e con una formazione strutturata che va ben oltre la memorizzazione dei comandi.

Se vuoi costruire o consolidare queste competenze, esplora i nostri corsi di networking e Cisco: percorsi pratici che ti accompagnano dal primo approccio alla diagnostica di rete fino alla gestione operativa di infrastrutture complesse.