Problemet: En databasapplikation är "slow". Nätverksteamet skyller på serverteamet. Serverteamet skyller på nätverket. Samtidigt är användarna frustrerade och timmar slösas bort i cirkulär felsökning.
Lösningen: Ett systematiskt, vetenskapligt tillvägagångssätt för felsökning som använder bevis, inte antaganden, för att identifiera grundorsaker.
Kostnaden för Haphazard Felsökning: Slösad tid, felaktiga fixar som maskerar verkliga problem, fingerpekning mellan lag och försämrad användarupplevelse.
Nätverksfelsökning är i grunden en övning i den vetenskapliga metoden:
Denna artikel ger en strukturerad ram för nätverksfelsökning som förhindrar vanliga fallgropar som:
Innan du dyker in i teknisk diagnostik, svara på dessa fem kritiska frågor för att begränsa ditt undersökningsområde:
Configuration ändras? Ny hårdvara? Programvaruuppdateringar? Topologi modifieringar?
En användare? En byggnad? Alla? Specifik applikation endast?
Händer hela tiden? Endast under vissa timmar? Slumpmässiga händelser?
Kan du utlösa problemet på efterfrågan?
Kontrollera båda ändarna av anslutningen
OSI-modellen ger en strukturerad ram för felsökning. Arbeta från Layer 1 (Fysisk) uppåt, eller från Layer 7 (Applikation) nedåt, beroende på symtom.
När man ska använda: Fullständig anslutningsförlust, ingen länk ljus eller fysiska lager symptom
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -an, packet capturenslookup, dig, curl -vNär man ska använda: Tillämpningsspecifika problem där grundläggande anslutning existerar
Börja på Layer 7 (Finns SharePoint-tjänsten? DNS lösa för att korrigera IP?) och arbeta ner endast om det behövs.
Använd detta snabba diagnostiska träd för att identifiera vilket lager som misslyckas:
TCP/IP stack fungerar inte. Kontrollera OS-tjänster, installera om nätverksdrivrutiner.
NIC inaktiverad, fel drivrutin, kabel inkopplad. Check: ip link show eller Device Manager
Kontrollera: Fysisk kabel, växla portstatus, VLAN-uppdrag, ARP-bord
Kontrollera: Ruttbord, brandväggsregler, ACLs. Användning traceroute för att hitta var paket stannar
Kontrollera: DNS-serverinställningar, DNS-servertillgänglighet, brandväggsblockering port 53
Kontrollera: Brandväggsregler, säkerhetsgrupper, servicelyssning på hamn
Problemet är med själva programmet, autentisering eller applikationskonfiguration
När du har en hypotes om grundorsaken, använd dessa isoleringstekniker för att bekräfta eller avvisa den:
Fånga trafiken vid källa, mellanpunkter och destination för att identifiera var paket tappas eller ändras:
# 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
Eliminera externa variabler genom att testa anslutning inom en enhet:
# 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
Jämför konfiguration och beteende mot ett arbetssystem:
# 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")
Korrekt dokumentation förhindrar cirkulär felsökning där du provar samma sak flera gånger utan att inse det.
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
Database applikationssvarstider degraderade från <100ms till 5 + sekunder. Applikationsteamet skyllde "network latency".
Databasserver OS-buffertar var för små för hög bandbredd × fördröjning produkt. TCP fönster skulle fylla, tvinga avsändare att vänta.
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Anta inte: "Slow" betyder inte alltid "nätverks latens". Alltid samla bevis (ping för latens, paketfångst för beteende) innan du hoppar till slutsatser.
Serveranslutning skulle sjunka slumpmässigt, särskilt under belastning. Ibland fungerade bra, ibland helt oansvarigt.
Autoförhandlingar misslyckades. Server förhandlade fullduplex, bytte föll tillbaka till halvduplex. Kollisioner inträffade endast under belastning när båda sidor försökte överföra samtidigt.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Kolla båda ändarna: Interface status visar de förhandlade inställningarna. En missmatchning innebär att auto-förhandling misslyckades. Alltid hårdkodshastighet/duplex för servrar.
Användare kan surfa på vissa webbplatser (Google, Yahoo) men inte andra (bankwebbplats, företagsportal). Små HTTP-förfrågningar fungerade, stora sidor utpekade.
ping -M do -s 1472 lyckas, ping -M do -s 1473 misslyckasVPN-tunneln minskade MTU till 1400, men brandvägg blockerade ICMP "Fragmentering behövs". Path MTU Discovery (PMTUD) kunde inte fungera, skapa ett MTU svart hål. Små paket passar, stora paket med DF bit set var tyst tappade.
! 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
Storleksfrågor: Om små förfrågningar fungerar men stora överföringar misslyckas misstänker MTU/fragmentering. Använd ping med DF bit för att testa banan MTU.
Röstsamtal hade choppy ljud, intermittent dropouts. Endast inträffade under arbetstid (9:00-5:00).
QoS-policy existerade men bandbreddstilldelningen var baklänges: bäst först fick 60%, rösten fick 5%. Under arbetstid när datatrafiken ökade sjönk röstpaket på grund av kööverflödet.
! 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
Tidsbaserade problem = kapacitet: Om problem bara uppstår under upptagna timmar är det inte ett hårt misslyckande utan en kapacitet/QoS-fråga. Kontrollera köstatistik, inte bara total bandbredd.
| Symptom | Layer | Kommandon till Run | Vad att leta efter |
|---|---|---|---|
| Inget länkljus | Layer 1 | show interfaces |
Status: ner, ingen bärare, kabel ansluten |
| Packet förlust | Layer 1/2 | show interfaces |
CRC-fel, runt, jättar, kollisioner, sena kollisioner |
| Kan inte ping gateway | Layer 2 | arp -a |
Ingen ARP-post, MAC inte lärt sig, STP blockering |
| Kan inte nå fjärrsubnet | Layer 3 | traceroute |
Saknar rutt, fel nästa hop, routing loop |
| Anslutning vägrade | Layer 4 | telnet host port |
Tjänst som inte lyssnar, brandvägg block, TCP RST |
| Långsam prestanda | Layer 4+ | ping (RTT) |
Hög latens, bandbredd gräns, TCP retransmissioner, noll fönster |
| Kan inte lösa värdnamn | Layer 7 | nslookup |
DNS-server oåtkomlig, fel DNS-konfig, NXDOMAIN |
| Intermittent droppar | Layer 1/2 | ping -f (flood) |
Duplex felmatch, misslyckande kabel, STP-rekonvergens |
| Fungerar ibland, inte andra | Multiple | Extended ping |
Load Balancing Problem, ECMP asymmetri, statlig överflöde |
Vet när du ska eskalera till leverantör TAC eller senior ingenjörer. Skala när:
Varje felsökning session är en inlärningsmöjlighet. Bygg en personlig kunskapsbas:
# 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
Organisera ofta använda kommandon genom scenario för snabb referens under felsökning.
Ändra konfigurationer utan att förstå problemet gör ofta saker värre eller maskerar den verkliga frågan.
Ofta är "nätverksproblem" applikation, server eller problem med klientsidan. Samla bevis innan du accepterar skulden.
Du kommer att slösa tid på att upprepa tester du redan har gjort eller inte kunna förklara för kollegor vad du har försökt.
Intermittent problem är ofta tidiga varningssignaler för överhängande misslyckande. Undersök dem innan de blir kritiska.
Omstart av en enhet kan återställa tjänsten, men om du inte upptäcker varför det behövs omstart, kommer problemet att återkomma.
Nätverkets felsökning är både vetenskap och konst. Vetenskapen följer en systematisk metodik, med hjälp av diagnostiska verktyg korrekt och förståelse protokoll. Konsten är att veta vilka tester som ska köras först baserat på symtom, erkänna mönster från erfarenhet och veta när man ska eskalera.
Genom att följa det systematiska tillvägagångssätt som beskrivs i denna artikel - fråga rätt frågor, arbeta metodiskt genom OSI-modellen, dokumentera dina steg och lärande från varje problem - du kommer att bli effektivare vid felsökning och undvika de gemensamma fallgropar som leder till bortkastad tid och felaktiga fixar.
Kom ihåg: Målet är inte bara att återställa service, utan att förstå varför det misslyckades så att du kan förhindra att det händer igen.
Senast uppdaterad: 2 februari 2026 | Författare: Baud9600 Technical Team