Problemet: Et databaseprogram er "slow." Nettverket bebreider serverteamet. Serverteamet klandrer nettverket. I mellomtiden er brukerne frustrert, og timer er bortkastet i sirkulær feilsøking.
Løsningen: En systematisk, vitenskapelig tilnærming til feilsøking som bruker bevis, ikke antakelser, for å identifisere rotårsaker.
Kostnaden for feilsøking: Forkastet tid, feil rettinger som maskerer virkelige problemer, fingerpunkt mellom lag og degradert brukeropplevelse.
Nettverksfeilsøking er i utgangspunktet en øvelse i den vitenskapelige metoden:
Denne artikkelen gir en strukturert ramme for nettverksfeilsøking som hindrer vanlige fallgruber som:
Før du dykker i teknisk diagnostikk, svare på disse fem kritiske spørsmålene for å begrense etterforskningsområdet ditt:
Konfigurasjonsendringer? Ny maskinvare? Programvareoppdateringer? Topologimodifikasjoner?
En bruker? En bygning? Alle sammen? Spesifikk søknad?
skjer det hele tiden? Bare i visse timer? Tilfeldige hendelser?
Kan du utløse problemet på etterspørsel?
Sjekk begge endene av tilkoblingen
OSI-modellen gir et strukturert rammeverk for feilsøking. Arbeid fra lag 1 (fysisk) oppover, eller fra lag 7 (Applicasjon) nedover, avhengig av symptomer.
Når du skal bruke: Komplett tilkoblingstap, ingen lenkelys eller fysiske lagsymptomer
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -an, pakkefangstnslookup, dig, curl -vNår du skal bruke: Søknadsspesifikke problemer der grunnleggende tilkobling eksisterer
Start på Layer 7 (Er SharePoint-tjenesten i drift? DNS løsning for å rette IP?) og jobbe ned kun om nødvendig.
Bruk dette raske diagnostiske treet til å identifisere hvilket lag som mangler:
TCP/IP-stabel fungerer ikke. Sjekk OS-tjenester, installer nettverksdrivere på nytt.
NIC deaktivert, feil driver, kabel avkoblet. Sjekk: ip link show eller enhetshåndtering
Sjekk: Fysisk kabel, bryterportstatus, VLAN-tildeling, ARP-tabell
Sjekk: Rutetabell, brannmurregler, ACLs. Bruk traceroute For å finne hvor pakker stopper
Sjekk: DNS serverinnstillinger, DNS server tilgjengelighet, brannmur blokkerer port 53
Sjekk: Firewall-regler, sikkerhetsgrupper, service som lytter til havn
Problem er med selve programmet, autentisering eller programkonfigurasjon
Når du har en hypotese om roten årsak, bruk disse isolasjonsteknikkene til å bekrefte eller avvise det:
Fang trafikken ved kilden, mellompunktene og bestemmelsesstedet for å identifisere hvor pakkene slippes eller endres:
# 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
Eliminer eksterne variabler ved å teste tilkobling i en enkelt 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
Sammenlign konfigurasjon og oppførsel mot et arbeidssystem:
# 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 dokumentasjon hindrer sirkulær feilsøking der du prøver det samme flere ganger uten å innse 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
Databaseprogramresponstider degradert fra <100ms til 5+ sekunder. Applikasjon team skyldt "network latency."
Databaseserver OS-buffere var for små for høybåndsbredde × forsinkelsesprodukt. TCP vindu vil fylle, tvinge avsender til å vente.
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Ikke anta: Slow" betyr ikke alltid " network latens." Alltid samle bevis (ping for latens, pakkefangst for oppførsel) før du hopper til konklusjoner.
Serverforbindelsen vil slippe tilfeldig, spesielt under belastning. Noen ganger fungerte bra, noen ganger helt uresponsivt.
Autoforhandling mislyktes. Server forhandlet full duplex, bryter falt tilbake til halvduplex. Kollisjoner skjedde kun under belastning når begge sider prøvde å overføre samtidig.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Sjekk begge endene: Grensesnittstatus viser de forhandlede innstillingene. En feil betyr at autoforhandling mislykkes. Alltid hard-kode hastighet/duplex for servere.
Brukere kan bla gjennom noen nettsteder (Google, Yahoo) men ikke andre (banknettsted, selskapsportal). Små HTTP-forespørsler fungerte, store sider avslappet.
ping -M do -s 1472 lykkes, ping -M do -s 1473 feilVPN-tunnelen reduserte MTU til 1400, men brannmuren blokkerte ICMP-Fragmentation Needed" meldinger. Path MTU Discovery (PMTUD) kan ikke fungere, og skaper et MTU svart hull. Små pakker passform, store pakker med DF bit sett ble stille droppet.
! 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
Størrelsesspørsmål: Hvis små forespørsler fungerer, men store overføringer mislykkes, mistenkes MTU/fragmenteringsproblemer. Bruk ping med DF-bit til å teste banen MTU.
Stemmesamtaler hadde kuttet lyd, periodiske dropouts. Bare skjedde i løpet av virketiden (9am-5pm).
QoS-politikken eksisterte, men båndbreddetildelingen var bakover: best-effort fikk 60%, stemme fikk 5%. I løpet av virketiden da datatrafikken økte, ble stemmepakker falt på grunn av køoverflod.
! 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
Tidsbaserte problemer = kapasitet: Hvis det bare oppstår problemer i travle timer, er det ikke en hard feil, men en kapasitet / QoS problem. Sjekk køstatistikk, ikke bare total båndbredde.
| Symptom | Lag | Kommandoer å kjøre | Hva å se etter |
|---|---|---|---|
| Ingen link lys | Lag 1 | show interfaces |
Status: ned, ingen bærer, kabel avkoblet |
| Pakketap | Lag 1/2 | show interfaces |
CRC feil, runts, kjemper, kollisjoner, sen kollisjoner |
| Kan ikke ping gateway | Lag 2 | arp -a |
Ingen ARP-oppføring, MAC ikke lært, STP blokkering |
| Kan ikke nå fjernt undernett | Lag 3 | traceroute |
Manglende rute, feil neste-hop, ruteløyfe |
| Tilkobling nektet | Lag 4 | telnet host port |
Tjeneste ikke lytte, brannmur blokk, TCP RST |
| Langsom ytelse | Lag 4+ | ping (RTT) |
Høy latens, båndbreddegrense, TCP-overføringer, nullvinduer |
| Kan ikke løse vertsnavn | Lag 7 | nslookup |
DNS-server som ikke kan nås, feil DNS-oppsett, NXDOMAIN |
| Intermitterende dråper | Layer 1/2 | ping -f (flood) |
Duplex feil, sviktende kabel, STP rekonvergens |
| Fungerer noen ganger, ikke andre | Flere | Extended ping |
Lastebalanseringsproblem, ECMP asymmetri, tilstandstabelloverflyt |
Vet når du skal eskalere til leverandøren TAC eller senior ingeniører. Escalate når:
Hver feilsøkingsøkt er en læringsmulighet. Bygg en personlig kunnskapsbase:
# 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
Organiser ofte brukte kommandoer av scenario for rask referanse under feilsøking.
Å endre konfigurasjoner uten å forstå problemet gjør ofte ting verre eller maskerer det virkelige problemet.
Ofte " nettverksproblemer" er applikasjon, server eller klientside problemer. Samle bevis før du tar imot skylden.
Du vil kaste bort tiden med å gjenta tester du allerede har gjort, eller være ute av stand til å forklare for kolleger hva du har prøvd.
Intermittente problemer er ofte tidlige advarsel tegn på forestående svikt. Undersøk dem før de blir kritiske.
Omstarting av en enhet kan gjenopprette tjenesten, men hvis du ikke finner ut hvorfor den trengte omstart, vil problemet gjenta.
Nettverksfeilsøking er både vitenskap og kunst. Vitenskapen følger en systematisk metodikk, bruker diagnostiske verktøy riktig og forstår protokoller. Kunsten er å vite hvilke tester å kjøre først basert på symptomer, gjenkjenne mønstre fra erfaring, og vite når å eskalere.
Ved å følge den systematiske tilnærmingen som er skissert i denne artikkelen - spør riktige spørsmål, jobbe metodisk gjennom OSI-modellen, dokumentere dine skritt og lære fra hvert problem - vil du bli mer effektiv på feilsøking og unngå de vanlige fallgruber som fører til bortkastet tid og feil rettelser.
Husk: Målet er ikke bare å gjenopprette tjenesten, men å forstå hvorfor det mislyktes slik at du kan hindre det i å skje igjen.
Sist oppdatert: 2. februar 2026 中 Forfatter: Baud9600 Tekniske team