Ripasso rapido: Supporto tecnico – CCNA

Cosa devi sapere davvero

Il supporto tecnico nel CCNA non significa solo conoscere comandi. Significa saper affrontare un problema di rete con metodo, evitando di cambiare configurazioni a caso o saltare subito alla conclusione più comoda.

In una rete reale, un problema può dipendere da cavi, porte, VLAN, indirizzi IP, DHCP, DNS, routing, ACL, firewall, servizi, configurazioni errate o modifiche recenti. Per questo il troubleshooting deve essere ordinato: identificare il problema, raccogliere informazioni, formulare ipotesi, testare, applicare una soluzione, verificare e documentare.

Il punto centrale è questo: un buon tecnico non indovina. Osserva, verifica e procede per esclusione.

Concetti chiave

• Troubleshooting: processo strutturato per identificare e risolvere un problema.
• Identificazione del problema: capire cosa non funziona e quale impatto ha.
• Raccolta informazioni: ottenere dati da utenti, dispositivi, log e strumenti.
• Ipotesi: possibile causa del problema.
• Test: verifica controllata di una ipotesi.
• Verifica: conferma che la soluzione abbia risolto il problema.
• Documentazione: registrazione di causa, soluzione e modifiche applicate.
• Layered approach: analisi per livelli OSI/TCP-IP.
• Baseline: stato normale della rete usato come riferimento.
• Change management: gestione controllata delle modifiche.
• Escalation: coinvolgimento di team o livelli superiori quando necessario.
• Comunicazione: aggiornamento chiaro verso utenti e stakeholder.

Differenze da non confondere

Concetto	Significato principale
Sintomo	Effetto visibile del problema
Causa radice	Motivo reale del problema
Ipotesi	Possibile spiegazione da verificare
Test	Verifica controllata
Workaround	Soluzione temporanea
Fix	Correzione stabile
Verifica	Conferma del ripristino
Documentazione	Registrazione del lavoro svolto
Escalation	Passaggio a supporto superiore
Baseline	Comportamento normale atteso

Metodo di troubleshooting

Un metodo semplice di troubleshooting può seguire questi passaggi:

1. identificare il problema;
2. raccogliere informazioni;
3. stabilire una teoria sulla causa probabile;
4. testare la teoria;
5. creare un piano di azione;
6. applicare la soluzione;
7. verificare il funzionamento;
8. documentare problema, causa e soluzione.

Questo metodo evita interventi casuali e riduce il rischio di peggiorare la situazione.

Nel CCNA devi ragionare in modo tecnico ma ordinato: prima capire, poi modificare.

Identificare il problema

Prima di risolvere, devi capire bene cosa non funziona.

Domande utili:

• chi è coinvolto?
• quanti utenti sono colpiti?
• il problema riguarda un solo host o molti?
• il problema è locale o remoto?
• quando è iniziato?
• è successo dopo una modifica?
• il problema è continuo o intermittente?
• quali servizi non funzionano?
• cosa funziona ancora?

Esempio: “Internet non funziona” è troppo generico. Devi capire se è un problema DNS, gateway, Wi-Fi, DHCP, routing, firewall o solo di una applicazione.

Raccolta informazioni

La raccolta informazioni include dati da:

• utenti;
• ticket;
• log;
• configurazioni;
• comandi show;
• monitoring;
• Syslog;
• SNMP;
• ping e traceroute;
• strumenti fisici;
• documentazione di rete;
• modifiche recenti.

Un errore comune è fidarsi solo della descrizione iniziale. Gli utenti descrivono il sintomo, non sempre la causa tecnica.

Approccio per livelli

Un approccio molto utile è ragionare per livelli.

Esempi:

• Layer 1: cavi, porte, alimentazione, segnale.
• Layer 2: VLAN, MAC address, trunk, STP.
• Layer 3: IP, gateway, routing.
• Layer 4: porte TCP/UDP, ACL, firewall.
• Layer 7: DNS, applicazioni, servizi.

Se un host non comunica, controllare prima Layer 1 e Layer 2 può evitare di perdere tempo su routing o DNS quando il problema è un cavo scollegato.

Top-down, bottom-up e divide-and-conquer

Esistono diversi modi per affrontare il troubleshooting.

Bottom-up: parti dal Layer 1 e sali. Utile quando sospetti problemi fisici o di connettività base.

Top-down: parti dall’applicazione e scendi. Utile quando il problema riguarda un servizio specifico.

Divide-and-conquer: parti da un punto intermedio, spesso Layer 3, e poi sali o scendi in base al risultato.

Per CCNA devi sapere che non esiste un solo metodo valido sempre. La scelta dipende dallo scenario.

Baseline

Una baseline descrive il comportamento normale della rete.

Può includere:

• utilizzo normale della banda;
• latenza media;
• configurazioni standard;
• porte normalmente attive;
• percorsi di routing attesi;
• CPU e memoria dei dispositivi;
• log normali;
• numero di utenti o dispositivi attesi.

Senza baseline è più difficile capire se un valore è normale o anomalo.

Esempio: una latenza di 80 ms può essere normale su un collegamento geografico, ma anomala in una LAN.

Change management

Molti problemi nascono dopo una modifica.

Esempi:

• nuova VLAN;
• modifica ACL;
• aggiornamento firmware;
• cambio gateway;
• nuova configurazione DHCP;
• sostituzione switch;
• modifica trunk;
• aggiornamento driver;
• cambio DNS.

Il change management serve a pianificare, approvare, documentare e verificare le modifiche.

Nel troubleshooting, una domanda fondamentale è: “Cosa è cambiato di recente?”

Comandi show

I comandi show sono fondamentali nei dispositivi Cisco.

Esempi utili:

• show running-config;
• show startup-config;
• show ip interface brief;
• show interfaces;
• show vlan brief;
• show interfaces trunk;
• show mac address-table;
• show ip route;
• show arp;
• show cdp neighbors;
• show lldp neighbors;
• show access-lists;
• show logging.

Questi comandi permettono di osservare lo stato del dispositivo senza modificare la configurazione.

Debug

I comandi debug mostrano informazioni dettagliate in tempo reale.

Sono potenti ma vanno usati con attenzione.

Rischi:

• alto consumo CPU;
• output eccessivo;
• impatto su dispositivi in produzione;
• difficoltà di lettura;
• rischio di peggiorare performance.

Per CCNA devi ricordare che debug può essere utile, ma va usato solo quando necessario e con attenzione, preferibilmente in finestre controllate o ambienti di laboratorio.

Ping

Ping usa ICMP per verificare la raggiungibilità.

Può aiutare a testare:

• loopback locale;
• IP dell’host;
• default gateway;
• destinazione nella stessa LAN;
• destinazione remota;
• perdita pacchetti;
• latenza.

Sequenza utile:

• ping 127.0.0.1;
• ping proprio IP;
• ping gateway;
• ping IP remoto;
• ping nome DNS.

Questa sequenza aiuta a capire dove si interrompe la comunicazione.

Traceroute

Traceroute, o tracert in Windows, mostra il percorso verso una destinazione.

È utile per capire:

• dove il traffico si ferma;
• quali router vengono attraversati;
• se il percorso è coerente;
• se il problema è vicino o remoto;
• se manca una route;
• se un firewall o router non risponde.

Attenzione: alcuni dispositivi non rispondono ai pacchetti usati da traceroute, quindi un asterisco non significa sempre guasto.

Syslog

Syslog permette di raccogliere messaggi di log dai dispositivi.

Può mostrare:

• interfacce up/down;
• errori;
• login riusciti o falliti;
• modifiche di configurazione;
• eventi di routing;
• violazioni ACL;
• problemi hardware;
• eventi di sicurezza.

Centralizzare Syslog è utile perché i log locali possono essere persi dopo riavvio o limitati dalla memoria del dispositivo.

SNMP

SNMP permette di monitorare dispositivi di rete.

Può raccogliere dati come:

• stato interfacce;
• utilizzo banda;
• CPU;
• memoria;
• errori;
• disponibilità;
• temperatura;
• eventi tramite trap.

SNMP è utile per monitoraggio proattivo. Non devi aspettare che l’utente segnali il problema: il sistema può avvisare quando un’interfaccia va down o una soglia viene superata.

Cable tester

Un cable tester verifica problemi fisici sui cavi.

Può aiutare a individuare:

• cavo interrotto;
• coppie invertite;
• terminazione errata;
• lunghezza eccessiva;
• corto circuito;
• problemi di continuità;
• cablaggio non conforme.

Se una porta non sale o ha molti errori, un tester fisico può essere più utile di qualunque comando software.

Problemi Layer 1

Problemi comuni Layer 1:

• cavo scollegato;
• cavo danneggiato;
• porta spenta;
• interfaccia administratively down;
• modulo SFP incompatibile;
• fibra sporca;
• TX/RX invertiti;
• PoE insufficiente;
• velocità o duplex errati;
• distanza massima superata;
• errori CRC.

Sintomi tipici:

• interfaccia down;
• link intermittente;
• molti errori;
• throughput basso;
• packet loss.

Problemi Layer 2

Problemi comuni Layer 2:

• VLAN errata;
• trunk non configurato;
• VLAN non allowed sul trunk;
• native VLAN mismatch;
• MAC address table errata o instabile;
• STP blocking;
• port security violation;
• DHCP snooping configurato male;
• DAI che blocca ARP;
• loop Layer 2.

Comandi utili:

• show vlan brief;
• show interfaces trunk;
• show mac address-table;
• show spanning-tree;
• show port-security;
• show interfaces status.

Problemi Layer 3

Problemi comuni Layer 3:

• IP errato;
• subnet mask errata;
• gateway mancante;
• route mancante;
• route di ritorno mancante;
• default route errata;
• OSPF non adiacente;
• ACL che blocca traffico;
• NAT non configurato correttamente.

Comandi utili:

• show ip interface brief;
• show ip route;
• show arp;
• ping;
• traceroute;
• show access-lists;
• show ip protocols.

DHCP troubleshooting

Problemi DHCP comuni:

• server DHCP non raggiungibile;
• pool esaurito;
• scope errato;
• gateway distribuito errato;
• DNS distribuito errato;
• ip helper-address mancante;
• VLAN sbagliata;
• trunk errato;
• DHCP snooping che blocca risposte;
• client con lease vecchio.

Sintomi:

• host senza IP;
• indirizzo APIPA;
• IP nella subnet sbagliata;
• gateway o DNS errati.

DNS troubleshooting

Problemi DNS comuni:

• DNS server errato;
• record mancante;
• record sbagliato;
• cache DNS obsoleta;
• firewall che blocca DNS;
• server DNS non raggiungibile;
• DHCP che distribuisce DNS errato.

Sintomo classico:

• raggiungi un IP;
• non raggiungi un nome.

In questo caso il routing può funzionare perfettamente: il problema è la risoluzione dei nomi.

Routing troubleshooting

Problemi routing comuni:

• route assente;
• default route mancante;
• route di ritorno assente;
• protocollo dinamico non funzionante;
• metrica o administrative distance non attesa;
• interfaccia down;
• subnet non annunciata;
• ACL o firewall che blocca traffico.

Nel troubleshooting end-to-end devi sempre considerare sia il percorso di andata sia quello di ritorno.

ACL e firewall

ACL e firewall possono bloccare traffico anche se IP e routing sono corretti.

Controlla:

• ordine delle regole;
• direzione;
• interfaccia;
• deny implicito;
• porte TCP/UDP;
• indirizzi sorgente e destinazione;
• traffico di ritorno;
• log di blocco.

Un errore tipico è permettere il traffico in una direzione ma dimenticare il ritorno o un servizio necessario come DNS.

Documentazione

La documentazione è parte del troubleshooting.

Deve includere:

• sintomo;
• impatto;
• causa radice;
• test eseguiti;
• modifiche applicate;
• soluzione finale;
• eventuale workaround;
• tempi;
• persone coinvolte;
• comandi usati;
• raccomandazioni future.

Documentare evita che lo stesso problema venga risolto da zero ogni volta.

Comunicazione con utenti

Il supporto tecnico richiede anche comunicazione.

Buone pratiche:

• fare domande chiare;
• non accusare l’utente;
• spiegare in modo semplice;
• aggiornare sullo stato;
• indicare tempi realistici;
• confermare la risoluzione;
• comunicare eventuali impatti;
• documentare nel ticket.

Un tecnico bravo non è solo quello che risolve, ma quello che mantiene chiarezza durante il problema.

Escalation

L’escalation serve quando il problema supera competenze, permessi o responsabilità del primo livello.

Esempi:

• problema su apparati core;
• guasto provider;
• incidente di sicurezza;
• configurazione non autorizzata;
• problema complesso routing;
• necessità di accesso amministrativo;
• impatto su molti utenti.

Escalare non significa fallire: significa coinvolgere il livello corretto.

Verifica finale

Dopo aver applicato una soluzione, devi verificare.

Esempi:

• ping funziona;
• DNS risolve;
• utenti confermano;
• interfaccia stabile;
• errori non aumentano;
• servizio raggiungibile;
• log puliti;
• routing corretto;
• ACL non blocca traffico legittimo.

La verifica è importante perché un problema può sembrare risolto ma ripresentarsi dopo pochi minuti.

Errori comuni nei quiz

• Cambiare configurazione senza raccogliere informazioni.
• Saltare Layer 1.
• Confondere sintomo e causa radice.
• Pensare che DNS sia sempre problema Internet.
• Dimenticare la route di ritorno.
• Ignorare modifiche recenti.
• Usare debug senza cautela.
• Dimenticare il deny implicito nelle ACL.
• Non documentare la soluzione.
• Non verificare dopo il fix.
• Non comunicare con l’utente.
• Non fare escalation quando necessaria.

Mini scenario d’esame

Un utente segnala che “Internet non funziona”. Il PC ha IP corretto e riesce a fare ping al gateway e a 8.8.8.8, ma non riesce ad aprire siti web tramite nome.

Il problema più probabile è DNS, non connettività Internet generale. Il tecnico dovrebbe verificare server DNS configurato, risoluzione con nslookup e configurazione DHCP.

Altro scenario: dopo una modifica a una ACL, molti utenti non raggiungono più un servizio. Il tecnico deve controllare ordine delle regole, direzione, interfaccia, deny implicito e log.

Mini checklist prima del quiz

Prima di iniziare il quiz dovresti saper spiegare:

• le fasi principali del troubleshooting;
• perché bisogna identificare bene il problema;
• cosa significa causa radice;
• come usare un approccio per livelli;
• quando usare ping e traceroute;
• a cosa servono show e debug;
• perché Syslog e SNMP sono utili;
• quando usare un cable tester;
• come distinguere problemi Layer 1, 2 e 3;
• come riconoscere problemi DHCP e DNS;
• perché ACL e firewall possono bloccare traffico corretto;
• perché documentazione e comunicazione sono parte del supporto tecnico.