Il problema: Un'applicazione del database è "slow". Il team di rete incolpa il team del server. Il team del server incolpa la rete. Nel frattempo, gli utenti sono frustrati, e le ore sono sprecate in debug circolare.
La soluzione: Un approccio sistematico e scientifico alla risoluzione dei problemi che utilizza prove, non ipotesi, per identificare le cause della radice.
Il costo della risoluzione dei problemi Haphazard: Tempo sprecato, correzioni errate che mascherano problemi reali, puntare le dita tra le squadre, e l'esperienza dell'utente degradato.
La risoluzione dei problemi di rete è fondamentalmente un esercizio nel metodo scientifico:
Questo articolo fornisce un quadro strutturato per la risoluzione dei problemi di rete che impedisce le trappole comuni come:
Prima di immergersi nella diagnostica tecnica, rispondere a queste cinque domande critiche per restringere il campo di indagine:
Cambiamenti di configurazione? Nuovo hardware? Aggiornamenti software? Modifiche di Topologia?
Un utente? Un edificio? Tutti? Applicazione specifica?
Succede sempre? Solo durante alcune ore? Accadimenti casuali?
Puoi attivare il problema a richiesta?
Controllare entrambe le estremità della connessione
Il modello OSI fornisce un quadro strutturato per la risoluzione dei problemi. Lavorare da Livello 1 (Physical) verso l'alto, o da Livello 7 (Applicazione) verso il basso, a seconda dei sintomi.
Quando usare: Perdita completa della connettività, nessun collegamento luce, o sintomi dello strato fisico
show interfaces♪ ethtool eth0show mac address-table♪ show spanning-treeping♪ traceroute♪ show ip routetelnet host port♪ netstat -an, cattura dei pacchettinslookup♪ dig♪ curl -vQuando usare: Problemi specifici dell'applicazione in cui esiste la connettività di base
Iniziare a Layer 7 (Il servizio SharePoint è in esecuzione? Risolvere DNS per correggere IP?) e lavorare giù solo se necessario.
Utilizzare questo albero diagnostico rapido per identificare quale strato sta fallendo:
Lo stack TCP/IP non funziona. Controlla i servizi OS, reinstalla i driver di rete.
NIC disabilitato, driver sbagliato, cavo non montato. Check: ip link show o Gestione dispositivi
Verifica: Cavo fisico, stato della porta di commutazione, assegnazione VLAN, tavolo ARP
Controllo: tavolo di routine, regole firewall, ACL. Uso traceroute per trovare dove si fermano i pacchetti
Verifica: Impostazioni server DNS, disponibilità server DNS, porta di blocco firewall 53
Controllo: regole Firewall, gruppi di sicurezza, servizio di ascolto sul porto
Il problema è con l'applicazione stessa, l'autenticazione o la configurazione dell'applicazione
Quando si ha un'ipotesi sulla causa principale, utilizzare queste tecniche di isolamento per confermare o rifiutare:
Cattura il traffico in punti sorgente, intermedi e la destinazione per identificare dove i pacchetti sono caduti o modificati:
# Capture on client
tcpdump -i eth0 -w client.pcap host server.example.com
# Capture on server
tcpdump -i eth0 -w server.pcap host client.example.com
# Compare:
# - Do packets leave client? (check client.pcap)
# - Do packets arrive at server? (check server.pcap)
# - If yes/no: problem is in the path between
# - If yes/yes but server doesn't respond: server-side issue
Eliminare le variabili esterne testando la connettività all'interno di un singolo dispositivo:
# Test TCP stack without network
ping 127.0.0.1
# Test application listening locally
telnet localhost 80
# Test loopback on network interface (if supported)
# Some NICs support physical loopback for Layer 1 testing
Confronta configurazione e comportamento contro un sistema di lavoro:
# Compare interface settings
diff <(ssh working-switch "show run int gi1/0/1") \
<(ssh broken-switch "show run int gi1/0/1")
# Compare routing tables
diff <(ssh router1 "show ip route") \
<(ssh router2 "show ip route")
La documentazione corretta impedisce il debug circolare dove si prova la stessa cosa più volte senza rendersene conto.
Issue ID: TICKET-12345
Date/Time: 2026-02-02 14:30 UTC
Reported By: Jane Smith (jane.smith@company.com)
Affected Users: ~50 users in Building A, 3rd floor
Symptom: Cannot access file server \\fileserver01
Initial Observations:
- Issue started around 14:00 UTC
- Only affects Building A, 3rd floor
- Other buildings can access fileserver01
- Ping to fileserver01 (10.1.50.10) times out from affected users
- Ping to default gateway (10.1.30.1) succeeds
Tests Performed:
1. [14:35] Checked switch port status: gi1/0/15 is UP/UP
2. [14:38] Checked VLAN assignment: Port is in VLAN 30 (correct)
3. [14:42] Checked interface errors: 1,234 CRC errors on gi1/0/15
4. [14:45] Replaced patch cable - still seeing CRC errors
5. [14:50] Moved uplink to different port (gi1/0/16) - errors persist
6. [14:55] Checked fiber cleanliness - dirty connector found
Root Cause:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss
Resolution:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.
Verification:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.
Time to Resolution: 25 minutes
I tempi di risposta dell'applicazione del database sono diminuiti da <100ms a 5+ secondi. Il team di applicazioni ha incolpato "latenza rete".
I buffer OS del server di database erano troppo piccoli per il prodotto di ritardo × ad alta larghezza di banda. La finestra TCP riempirebbe, costringendo il mittente ad aspettare.
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Non assumere: "Slow" non significa sempre "latenza rete". Raccogli sempre le prove (ping per la latenza, cattura dei pacchetti per il comportamento) prima di saltare a conclusioni.
La connessione del server scenderebbe casualmente, soprattutto sotto carico. A volte ha funzionato bene, a volte completamente non rispondente.
L'autonegoziazione è fallita. Il server ha negoziato full-duplex, l'interruttore è sceso a metà-duplex. Le collisioni si sono verificate solo sotto carico quando entrambi i lati hanno cercato di trasmettere simultaneamente.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Controllare entrambe le estremità: Lo stato dell'interfaccia mostra le impostazioni negoziate. Un errore significa che l'auto-negoziazione è fallita. Velocità/duplex di codice sempre duro per i server.
Gli utenti potrebbero navigare alcuni siti web (Google, Yahoo) ma non altri (il sito web della banca, il portale aziendale). Piccole richieste HTTP funzionate, grandi pagine timed out.
ping -M do -s 1472 succede, ping -M do -s 1473 fallisceIl tunnel VPN ha ridotto MTU a 1400, ma il firewall stava bloccando i messaggi ICMP "Fragmentation Needed". Path MTU Discovery (PMTUD) non poteva funzionare, creando un buco nero MTU. Piccoli pacchetti adatti, grandi pacchetti con set bit DF sono stati silenziosamente calati.
! Implemented TCP MSS clamping on router
interface Tunnel0
ip tcp adjust-mss 1360
! Alternative: Allow ICMP Type 3 Code 4 through firewall
access-list 101 permit icmp any any packet-too-big
Questioni di dimensione: Se piccole richieste di lavoro ma grandi trasferimenti falliscono, sospetti problemi MTU/fragmentazione. Utilizzare ping con bit DF per testare il percorso MTU.
Le chiamate vocali avevano l'audio tagliente, i dropout intermittenti. Si è verificato solo durante le ore di lavoro (9am-5pm).
La politica QoS esisteva, ma l'allocazione della larghezza di banda era all'indietro: il miglior sforzo ha ottenuto il 60%, la voce ha ottenuto il 5%. Durante le ore di lavoro quando il traffico di dati è aumentato, i pacchetti vocali sono stati eliminati a causa di overflow di coda.
! Corrected QoS policy
policy-map WAN-QOS
class VOICE
priority percent 33
class VIDEO
bandwidth percent 25
class CRITICAL-DATA
bandwidth percent 20
class class-default
bandwidth percent 22
Problemi basati sul tempo = capacità: Se i problemi si verificano solo durante ore occupate, non è un fallimento difficile, ma un problema di capacità / QoS. Controlla le statistiche della coda, non solo la larghezza di banda totale.
| Sintomo | Livello | Comandi da eseguire | Cosa cercare |
|---|---|---|---|
| Nessuna luce di collegamento | Livello 1 | show interfaces |
Stato: verso il basso, nessun vettore, cavo non montato |
| Perdita del pacchetto | Livello 1/2 | show interfaces |
Errori CRC, runt, giganti, collisioni, collisioni tardi |
| Non riesco a ping gateway | Livello 2 | arp -a |
Nessun ingresso ARP, MAC non imparato, blocco STP |
| Non può raggiungere la subnet remota | Livello 3 | traceroute |
Percorso mancante, sbagliato passo successivo, anello di routing |
| Connessione rifiutata | Livello 4 | telnet host port |
Servizio non ascolto, blocco firewall, TCP RST |
| Performance lenta | Livello 4+ | ping (RTT) |
Alta latenza, limite di larghezza di banda, ritrasmissioni TCP, finestre zero |
| Non riesco a risolvere il nome host | Livello 7 | nslookup |
Server DNS irraggiungibile, configurazione DNS sbagliata, NXDOMAIN |
| Gocce intermittenti | Layer 1/2 | ping -f (flood) |
Mismatch duplex, cavo mancante, STP reconvergenza |
| Funziona a volte, non altri | Più | Extended ping |
Emissione di bilanciamento del carico, asimmetria ECMP, overflow della tabella di stato |
Sapere quando escalare al fornitore TAC o ingegneri senior. Escalate quando:
Ogni sessione di risoluzione dei problemi è un'opportunità di apprendimento. Costruisci una base di conoscenza personale:
# Example structure
~/troubleshooting-journal/
├── 2026-01-15-duplex-mismatch.md
├── 2026-01-22-mtu-black-hole.md
├── 2026-02-02-tcp-window-exhaustion.md
└── README.md # Index of all issues
# Each file contains:
# - Symptom
# - Diagnostic steps
# - Root cause
# - Resolution
# - Lessons learned
# - Related tickets/documentation
Organizzare comandi frequentemente utilizzati per scenario per un rapido riferimento durante la risoluzione dei problemi.
Cambiare le configurazioni senza capire il problema spesso rende le cose peggiori o maschera il problema reale.
Spesso "problemi di rete" sono problemi di applicazione, server o lato client. Raccogli le prove prima di accettare la colpa.
Perderai tempo a ripetere i test che hai già fatto, o non sarai in grado di spiegare ai colleghi quello che hai provato.
I problemi intermittenti sono spesso segnali di allarme precoce di insufficienza imminente. Investirli prima che diventino critici.
Riavviare un dispositivo potrebbe ripristinare il servizio, ma se non si scopre Perché ha bisogno di riavvio, il problema si ripeterà.
La risoluzione dei problemi di rete è sia scienza che arte. La scienza sta seguendo una metodologia sistematica, utilizzando strumenti diagnostici correttamente e protocolli di comprensione. L'arte è sapere quali test eseguire prima sulla base dei sintomi, riconoscendo modelli dall'esperienza, e sapendo quando escalare.
Seguendo l'approccio sistematico delineato in questo articolo – prendendo le giuste domande, lavorando metodicamente attraverso il modello OSI, documentando i vostri passi e imparando da ogni problema – diventerete più efficienti a risolvere i problemi ed evitare le insidie comuni che portano a tempo sprecato e correzioni errate.
Ricorda: L'obiettivo non è solo quello di ripristinare il servizio, ma di capire perché ha fallito in modo da poter evitare che accada di nuovo.
Ultimo aggiornamento: 2 febbraio 2026 | Autore: Baud9600 Technical Team