Troubleshooting Le strategie bottom‑up e top‑down a confronto

Ogni volta che si è chiamati a occuparsi di risolvere un problema connesso al networking, di elettronica o informatico è necessario seguire precise strategie al fine di lavorare in modo schematico. Il processo di risoluzione dei problemi, anche chiamato troubleshooting, ha delle strategie al fine di essere efficace e coerente.

Nel caso del Troubleshooting esistono due maggiori metodologie di risoluzione dei problemi.
Le due metodologie rappresentano due modi opposti di affrontare un problema di rete (o di qualsiasi sistema complesso).
Entrambe cercano di arrivare alla radice del guasto, ma partono da punti diversi del “livello di astrazione” del sistema.

1. Top‑down (dal livello più alto al più basso)

Nel caso della metodica Top-down, come suggerisce la parola stessa, si parte dal livello più alto fino ad arrivare a quello più basso. Questo significa che prima di tutto si parte dal livello più vicino all’interfaccia con cui interagiamo, per poi arrivare ai livelli più bassi ovvero quelli elettronici e fisici.

Schematizzando in tabella:

Caratteristica	Descrizione
Punto di partenza	Si parte dal symptom percepito dall’utente o dall’applicazione (es. “la web‑app è lenta”).
Livelli attraversati	Applicazione → Sessione → Trasporto → Rete → Data‑link → Fisico.
Obiettivo	Verificare se il problema è logico o di configurazione prima di scendere nell’hardware.
Tipico flusso	1. Controllo dei log/applicazione (errori HTTP, timeout). <br>2. Verifica dei servizi di rete (DNS, DHCP, proxy). <br>3. Analisi delle connessioni TCP/UDP (handshake, RTT). <br>4. Controllo dei router/switch (tabelle di routing, ACL, QoS). <br>5. Test fisici (cavi, LED, interfacce).
Quando usarlo	• Problemi percepiti a livello utente (browser, email, VoIP). <br>• Quando si sospetta un errore di configurazione o di policy. <br>• In ambienti con molteplici dipendenze software (cloud, micro‑servizi).
Vantaggi	• Spesso risolve il problema più rapidamente perché si parte dal punto più “visibile”. <br>• Riduce il rischio di “cercare il guasto nel posto sbagliato” (es. cambiare cavo quando il problema è DNS).
Svantaggi	• Può richiedere più passaggi se il guasto è realmente hardware; si “perde tempo” nei livelli superiori.

Esempio top‑down

Facciamo un esempio di come avviene il processo di troubleshooting Top-down quando un utente ci segnala una problematica.

Esempio: Un utente segnala “non riesco a connettermi a https://mail.example.com”.

Browser → errore ERR_CONNECTION_TIMED_OUT.
DNS → nslookup mail.example.com restituisce l’indirizzo corretto. (da usare in terminale)
TCP → telnet mail.example.com 443 non risponde → possibile blocco firewall. (da usare in terminale)
Firewall/router → verifica regole ACL, NAT, stato della connessione.
Switch → verifica porte, VLAN, link status.
Cavo → test con cable diagnostics → cavo difettoso → sostituito → problema risolto.

2. Bottom‑up (dal livello più basso al più alto)

Dopo aver visto il Top-down, parlando della metodica Bottom-up, si inizierà il nostro processo di risoluzione del problema dalla base (ovvero quella hardware/fisica) fino ad arrivare all’interfaccia con cui ci stiamo relazionando.

Caratteristica	Descrizione
Punto di partenza	Si parte dal livello fisico/hardware (cavi, interfacce, LED).
Livelli attraversati	Fisico → Data‑link → Rete → Trasporto → Sessione → Applicazione.
Obiettivo	Escludere prima tutti i guasti hardware o di collegamento, perché sono spesso più facili da verificare con strumenti automatici.
Tipico flusso	1. Controllo LED, test cavo, `show interfaces status`. <br>2. Verifica dei protocolli di livello 2 (STP, LLDP, CDP). <br>3. Controllo delle tabelle di routing e dei protocolli di livello 3 (OSPF, BGP). <br>4. Analisi dei flussi TCP/UDP (handshake, retransmission). <br>5. Verifica dei servizi/applicazioni (DNS, HTTP, SIP).
Quando usarlo	• Segnalazioni di “nessuna connettività” (link down). <br>• Dopo un intervento hardware (cambio cavo, upgrade firmware). <br>• In ambienti dove i problemi più frequenti sono legati a cablaggio, POE, switch malfunzionanti.
Vantaggi	• Elimina rapidamente i guasti più comuni (cavo rotto, porta down). <br>• Riduce il numero di “false positive” dovute a configurazioni errate a livelli superiori.
Svantaggi	• Può far perdere tempo se il problema è puramente di configurazione applicativa (es. credenziali errate). <br>• Richiede accesso a dispositivi di rete (switch, router) che a volte non è immediato.

Esempio bottom‑up

Proviamo ad esemplificare un possibile processo di risoluzione di un problema, utilizzando il metodo bottom-up

Esempio: Un cliente ci segnala che un server non risponde a ping da un client.

Fisico → LED della porta dello switch sul server spenti → porta disabilitata.
Data‑link → show interface status mostra “admin down”; abilito la porta (no shutdown). (Da usare in Terminale)
Rete → show ip route conferma che il router ha la rotta verso la subnet del server. (Da usare in Terminale)
Trasporto → tcpdump sul server mostra SYN in arrivo, SYN‑ACK inviato, ACK perso → verifica MTU, fragmentazione.
Applicazione → servizio web sul server risponde correttamente.
Problema risolto riattivando la porta dello switch.

3. Come scegliere la strategia

Ovviamente, i due metodi non rispondono ad un rigido schema. Questo significa che non esistono informatici che prediligono l’uno o l’altro. Un bravo informatico/networker tende a decidere la propria strategia di troubleshooting in base a quella probabilisticamente è la strategia che porterà alla risoluzione del problema con meno passaggi. Schematizzando alcuni esempi:

Situazione	Strategia consigliata
Utente segnala “pagina web non carica”	Top‑down (partire dall’applicazione, poi DNS, TCP, ecc.).
Link LED spento / porta “down”	Bottom‑up (controlli fisici e di data‑link).
Dopo un upgrade firmware il traffico è più lento	Bottom‑up (verifica interfacce, MTU, QoS).
Problema intermittente solo in certe ore	Top‑down (analisi di policy, QoS, schedulazione).
Nuova VLAN aggiunta, host non comunica	Top‑down (controllo VLAN, trunk, routing).
Miglioramento di performance richiesto	Iterativo: inizia top‑down per capire i colli di bottiglia, poi bottom‑up per verificare che l’infrastruttura fisica possa supportare il carico.

4. Checklist rapida

Fase	Domande chiave
Top‑down	L’applicazione restituisce errori? Il DNS risolve correttamente? La connessione TCP/UDP si completa? Il router ha la rotta giusta? Gli switch mostrano errori di errore di CRC o collisioni?
Bottom‑up	Le luci delle porte sono accese? Le interfacce sono “up” e senza errori? Ci sono errori di duplex o speed mismatch? Il link è stabile (ping continuo, nessuna perdita)? I protocolli di livello 2 (STP, LLDP) sono convergenti?

In sintesi

Riassumendo e schematizzando per l’ultima volta, bisogna considerare la corretta strategia per risolvere in modo efficace il problema che stiamo cercando. Se si sospettasse un problema fisico o di hardware, bisogna seguire una strategia Bottom-up. Se invece una applicazione viene lanciata, ma sembra essere offline, oppure rispondere male o con lentezza, bisogna procedere ad una strategia Top-down.

Top‑down = parte dal symptom (utente/applicazione) e scende verso l’hardware. Ideale per problemi percepiti a livello di servizio.
Bottom‑up = parte dal cavo/porta e sale verso l’applicazione. Ideale per guasti di collegamento o quando si sospetta un problema fisico.