{"id":542,"date":"2026-01-27T19:39:04","date_gmt":"2026-01-27T19:39:04","guid":{"rendered":"https:\/\/www.nextred.it\/web\/?p=542"},"modified":"2026-01-27T20:04:22","modified_gmt":"2026-01-27T20:04:22","slug":"542-szmjas","status":"publish","type":"post","link":"https:\/\/www.nextred.it\/web\/2026\/01\/27\/542-szmjas\/","title":{"rendered":"Troubleshooting Le strategie bottom\u2011up e top\u2011down a confronto"},"content":{"rendered":"\n

Ogni volta che si \u00e8 chiamati a occuparsi di risolvere un problema connesso al networking, di elettronica o informatico \u00e8 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. <\/p>\n\n\n\n

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 \u201clivello di astrazione\u201d del sistema.<\/p>\n\n\n\n

\n\n\n\n

1. Top\u2011down (dal livello pi\u00f9 alto al pi\u00f9 basso)<\/h2>\n\n\n\n

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

Schematizzando in tabella:<\/p>\n\n\n\n

Caratteristica<\/th>Descrizione<\/th><\/tr><\/thead>
Punto di partenza<\/strong><\/td>Si parte dal symptom<\/strong> percepito dall\u2019utente o dall\u2019applicazione (es. \u201cla web\u2011app \u00e8 lenta\u201d).<\/td><\/tr>
Livelli attraversati<\/strong><\/td>Applicazione \u2192 Sessione \u2192 Trasporto \u2192 Rete \u2192 Data\u2011link \u2192 Fisico.<\/td><\/tr>
Obiettivo<\/strong><\/td>Verificare se il problema \u00e8 logico o di configurazione<\/strong> prima di scendere nell\u2019hardware.<\/td><\/tr>
Tipico flusso<\/strong><\/td>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).<\/td><\/tr>
Quando usarlo<\/strong><\/td>\u2022 Problemi percepiti a livello utente (browser, email, VoIP). <br>\u2022 Quando si sospetta un errore di configurazione o di policy. <br>\u2022 In ambienti con molteplici dipendenze software (cloud, micro\u2011servizi).<\/td><\/tr>
Vantaggi<\/strong><\/td>\u2022 Spesso risolve il problema pi\u00f9 rapidamente perch\u00e9 si parte dal punto pi\u00f9 \u201cvisibile\u201d. <br>\u2022 Riduce il rischio di \u201ccercare il guasto nel posto sbagliato\u201d (es. cambiare cavo quando il problema \u00e8 DNS).<\/td><\/tr>
Svantaggi<\/strong><\/td>\u2022 Pu\u00f2 richiedere pi\u00f9 passaggi se il guasto \u00e8 realmente hardware; si \u201cperde tempo\u201d nei livelli superiori.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Esempio top\u2011down<\/h3>\n\n\n\n

Facciamo un esempio di come avviene il processo di troubleshooting Top-down quando un utente ci segnala una problematica. <\/p>\n\n\n\n

Esempio: Un utente segnala \u201cnon riesco a connettermi a\u00a0https:\/\/mail.example.com<\/code><\/em><\/strong>\u201d.<\/p>\n\n\n\n

    \n
  1. Browser<\/strong> \u2192 errore ERR_CONNECTION_TIMED_OUT<\/em>.<\/li>\n\n\n\n
  2. DNS<\/strong>\u00a0\u2192\u00a0nslookup mail.example.com<\/code>\u00a0restituisce l\u2019indirizzo corretto. (da usare in terminale)<\/li>\n\n\n\n
  3. TCP<\/strong>\u00a0\u2192\u00a0telnet mail.example.com 443<\/code>\u00a0non risponde \u2192 possibile blocco firewall. (da usare in terminale)<\/li>\n\n\n\n
  4. Firewall\/router<\/strong> \u2192 verifica regole ACL, NAT, stato della connessione.<\/li>\n\n\n\n
  5. Switch<\/strong> \u2192 verifica porte, VLAN, link status.<\/li>\n\n\n\n
  6. Cavo<\/strong> \u2192 test con cable diagnostics<\/code> \u2192 cavo difettoso \u2192 sostituito \u2192 problema risolto.<\/li>\n<\/ol>\n\n\n\n
    \n\n\n\n

    2. Bottom\u2011up (dal livello pi\u00f9 basso al pi\u00f9 alto)<\/h2>\n\n\n\n

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

    Caratteristica<\/th>Descrizione<\/th><\/tr><\/thead>
    Punto di partenza<\/strong><\/td>Si parte dal livello fisico\/hardware<\/strong> (cavi, interfacce, LED).<\/td><\/tr>
    Livelli attraversati<\/strong><\/td>Fisico \u2192 Data\u2011link \u2192 Rete \u2192 Trasporto \u2192 Sessione \u2192 Applicazione.<\/td><\/tr>
    Obiettivo<\/strong><\/td>Escludere prima tutti i guasti hardware<\/strong> o di collegamento, perch\u00e9 sono spesso pi\u00f9 facili da verificare con strumenti automatici.<\/td><\/tr>
    Tipico flusso<\/strong><\/td>1. Controllo LED, test cavo, show interfaces status<\/code>. <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).<\/td><\/tr>
    Quando usarlo<\/strong><\/td>\u2022 Segnalazioni di \u201cnessuna connettivit\u00e0\u201d (link down). <br>\u2022 Dopo un intervento hardware (cambio cavo, upgrade firmware). <br>\u2022 In ambienti dove i problemi pi\u00f9 frequenti sono legati a cablaggio, POE, switch malfunzionanti.<\/td><\/tr>
    Vantaggi<\/strong><\/td>\u2022 Elimina rapidamente i guasti pi\u00f9 comuni (cavo rotto, porta down). <br>\u2022 Riduce il numero di \u201cfalse positive\u201d dovute a configurazioni errate a livelli superiori.<\/td><\/tr>
    Svantaggi<\/strong><\/td>\u2022 Pu\u00f2 far perdere tempo se il problema \u00e8 puramente di configurazione applicativa (es. credenziali errate). <br>\u2022 Richiede accesso a dispositivi di rete (switch, router) che a volte non \u00e8 immediato.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Esempio bottom\u2011up<\/h3>\n\n\n\n

    Proviamo ad esemplificare un possibile processo di risoluzione di un problema, utilizzando il metodo bottom-up<\/p>\n\n\n\n

    Esempio: Un cliente ci segnala che un server non risponde a ping da un client.<\/em><\/strong><\/p>\n\n\n\n

      \n
    1. Fisico<\/strong> \u2192 LED della porta dello switch sul server spenti \u2192 porta disabilitata.<\/li>\n\n\n\n
    2. Data\u2011link<\/strong>\u00a0\u2192\u00a0show interface status<\/code>\u00a0mostra \u201cadmin down\u201d; abilito la porta (no shutdown<\/code>). (Da usare in Terminale)<\/li>\n\n\n\n
    3. Rete<\/strong>\u00a0\u2192\u00a0show ip route<\/code>\u00a0conferma che il router ha la rotta verso la subnet del server. (Da usare in Terminale)<\/li>\n\n\n\n
    4. Trasporto<\/strong> \u2192 tcpdump<\/code> sul server mostra SYN in arrivo, SYN\u2011ACK inviato, ACK perso \u2192 verifica MTU, fragmentazione.<\/li>\n\n\n\n
    5. Applicazione<\/strong> \u2192 servizio web sul server risponde correttamente.
      Problema risolto riattivando la porta dello switch.<\/li>\n<\/ol>\n\n\n\n
      \n\n\n\n

      3. Come scegliere la strategia<\/h2>\n\n\n\n

      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 \u00e8 la strategia che porter\u00e0 alla risoluzione del problema con meno passaggi. Schematizzando alcuni esempi: <\/p>\n\n\n\n

      Situazione<\/th>Strategia consigliata<\/th><\/tr><\/thead>
      Utente segnala \u201cpagina web non carica\u201d<\/strong><\/td>Top\u2011down<\/strong> (partire dall\u2019applicazione, poi DNS, TCP, ecc.).<\/td><\/tr>
      Link LED spento \/ porta \u201cdown\u201d<\/strong><\/td>Bottom\u2011up<\/strong> (controlli fisici e di data\u2011link).<\/td><\/tr>
      Dopo un upgrade firmware il traffico \u00e8 pi\u00f9 lento<\/strong><\/td>Bottom\u2011up<\/strong> (verifica interfacce, MTU, QoS).<\/td><\/tr>
      Problema intermittente solo in certe ore<\/strong><\/td>Top\u2011down<\/strong> (analisi di policy, QoS, schedulazione).<\/td><\/tr>
      Nuova VLAN aggiunta, host non comunica<\/strong><\/td>Top\u2011down<\/strong> (controllo VLAN, trunk, routing).<\/td><\/tr>
      Miglioramento di performance richiesto<\/strong><\/td>Iterativo<\/strong>: inizia top\u2011down per capire i colli di bottiglia, poi bottom\u2011up per verificare che l\u2019infrastruttura fisica possa supportare il carico.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      \n\n\n\n

      4. Checklist rapida<\/h2>\n\n\n\n
      Fase<\/th>Domande chiave<\/th><\/tr><\/thead>
      Top\u2011down<\/strong><\/td>L\u2019applicazione 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?<\/td><\/tr>
      Bottom\u2011up<\/strong><\/td>Le luci delle porte sono accese?
      Le interfacce sono \u201cup\u201d e senza errori?
      Ci sono errori di duplex o speed mismatch?
      Il link \u00e8 stabile (ping continuo, nessuna perdita)?
      I protocolli di livello 2 (STP, LLDP) sono convergenti?<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      \n\n\n\n

      In sintesi<\/h3>\n\n\n\n

      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. <\/p>\n\n\n\n

        \n
      • Top\u2011down<\/strong>\u00a0= parte dal\u00a0symptom<\/strong>\u00a0(utente\/applicazione) e scende verso l\u2019hardware. Ideale per problemi percepiti a livello di servizio.<\/li>\n\n\n\n
      • Bottom\u2011up<\/strong> = parte dal cavo\/porta<\/strong> e sale verso l\u2019applicazione. Ideale per guasti di collegamento o quando si sospetta un problema fisico.<\/li>\n<\/ul>\n\n\n\n

        <\/p>\n\n\n\n

        <\/p>\n","protected":false},"excerpt":{"rendered":"

        Ogni volta che si \u00e8 chiamati a occuparsi di risolvere un problema connesso al networking, di elettronica o informatico \u00e8 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 […]<\/p>\n","protected":false},"author":1,"featured_media":565,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":4,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"","footnotes":""},"categories":[59,1,6],"tags":[71,149,150,148],"class_list":["post-542","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cybersecurity","category-news","category-tech","tag-cybersecurity","tag-informatica","tag-networking","tag-troubleshooting"],"_links":{"self":[{"href":"https:\/\/www.nextred.it\/web\/wp-json\/wp\/v2\/posts\/542","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.nextred.it\/web\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.nextred.it\/web\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.nextred.it\/web\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.nextred.it\/web\/wp-json\/wp\/v2\/comments?post=542"}],"version-history":[{"count":0,"href":"https:\/\/www.nextred.it\/web\/wp-json\/wp\/v2\/posts\/542\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.nextred.it\/web\/wp-json\/wp\/v2\/media\/565"}],"wp:attachment":[{"href":"https:\/\/www.nextred.it\/web\/wp-json\/wp\/v2\/media?parent=542"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.nextred.it\/web\/wp-json\/wp\/v2\/categories?post=542"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.nextred.it\/web\/wp-json\/wp\/v2\/tags?post=542"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}