A probléma: Egy adatbázis alkalmazás "lassú". A hálózati csapat a szerver csapatot hibáztatja. A szerver csapat a hálózatot hibáztatja. Eközben a felhasználók frusztráltak, és a körkörös hibakeresések óráit vesztegetik.
A megoldás: A problémamegoldás szisztematikus, tudományos megközelítése, amely bizonyítékot használ fel, nem feltételezéseket, a kiváltó okok azonosítására.
A Haphazard problémamegoldás költsége: Elpazarolt idő, helytelen javítások, amik elfedik a valódi problémákat, a csapatok közötti ujjal mutogatás és a korlátozott felhasználói élmények.
A hálózati problémamegoldás alapvetően a tudományos módszer egyik gyakorlata:
Ez a cikk strukturált keretet biztosít a hálózati hibaelhárításhoz, amely megakadályozza a közös csapdázásokat, mint például:
Mielőtt belemerülne a műszaki diagnosztikába, válaszoljon erre az öt kritikus kérdésre, hogy szűkítse a nyomozási körét:
Konfigurációs változások? Új hardver? Szoftver frissítések? Topológiai módosítások?
Egy felhasználó? Egy épület? Mindenki? Csak konkrét alkalmazás?
Mindig ez van? Csak bizonyos órákban? Véletlenszerű események?
Meg tudod oldani a problémát igény esetén?
A kapcsolat mindkét végének ellenőrzése
Az OSI modell strukturált keretet biztosít a problémamegoldáshoz. A tünetek függvényében az 1. rétegből (fizikai) felfelé, vagy a 7. rétegből (alkalmazás) lefelé kell dolgozni.
Mikor kell használni: Teljes kapcsolat elvesztése, nincs kapcsolat fény, vagy fizikai réteg tünetek
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -an, csomag rögzítésenslookup, dig, curl -vMikor kell használni: Alkalmazás-specifikus problémák, ahol alapvető kapcsolat van
Kezdje a Layer 7 (SharePoint szolgáltatás fut? DNS megoldása, hogy helyesbítse IP?) és a munka csak szükség esetén.
Használja ezt a gyors diagnosztikai fa azonosítani, hogy melyik réteg nem működik:
A TCP / IP stack nem működik. Ellenőrizzék az OS szolgáltatásokat, telepítsék újra a hálózati meghajtókat.
NIC kikapcsolva, rossz sofőr, kábel kihúzva. Ellenőrzés: ip link show vagy eszközkezelő
Ellenőrzés: Fizikai kábel, port állapot váltás, VLAN megbízás, ARP asztal
Jelölje be: AsztalátName Felhasználás traceroute ahol a csomagok megállnak
Ellenőrzés: DNS kiszolgáló beállítások, DNS kiszolgáló rendelkezésre állás, tűzfal blokkoló port 53
Ellenőrzés: Tűzfal szabályok, biztonsági csoportok, szolgáltatás figyelés a kikötőben
A probléma maga az alkalmazás, a hitelesítés vagy az alkalmazás konfigurációja.
Ha van egy hipotézis a kiváltó ok, használja ezeket az izolációs technikákat, hogy erősítse vagy utasítsa el:
A csomagokat a forrásnál, a közbenső pontoknál és a célállomásnál kell rögzíteni, ahol a csomagokat ledobják vagy módosítják:
# 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
Külső változók eltávolítása egyetlen eszközön belüli kapcsolat tesztelésével:
# 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
Hasonlítsa össze a konfigurációt és a viselkedést egy működő rendszerrel:
# 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")
A megfelelő dokumentáció megakadályozza a körkörös hibakeresést, ahol ugyanazt a dolgot többször is megpróbálod anélkül, hogy észrevennéd.
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
Adatbázis az alkalmazás válaszideje < 100 ms-ról 5 + másodpercre lebontva. Az application team a "network latency" -t hibáztatta.
Az adatbázis szerver OS pufferei túl kicsik voltak a nagy sávszélesség × késleltetett termékhez. A TCP ablak megtelne, a feladó várna.
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Ne feltételezd: A "lassú" nem mindig azt jelenti, hogy "hálózati késleltetés". Mindig gyűjtsön bizonyítékot (ping a láthatóság, csomag elfogása a viselkedés), mielőtt a következtetéseket.
A kiszolgáló kapcsolat véletlenszerűen csökkenne, különösen terhelés alatt. Néha jól működött, néha egyáltalán nem reagált.
Az automatikus tárgyalás sikertelen. A szerver a teljes duplexről tárgyalt, a váltás visszaesett a félduplexre. Az ütközések csak akkor keletkeztek terhelés alatt, amikor mindkét oldal egyszerre próbált továbbítani.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Ellenőrizze mindkét végét: Az interfész állapota mutatja a megbeszélt beállításokat. A téves egyezés azt jelenti, hogy az automatikus tárgyalás megbukott. Mindig kemény kód sebesség / duplex szerverek.
A felhasználók böngészhetnek néhány weboldalon (Google, Yahoo), de nem mások (banki honlap, vállalati portál). A kis HTTP kérések működtek, nagy oldalak időzítve.
ping -M do -s 1472 Sikeres, ping -M do -s 1473 hibaVPN alagút csökkentette MTU 1400, de tűzfal blokkolta ICMP "Törékenység Needed" üzenetek. Menetvonal MTU Discovery (PMTUD) nem tudott működni, létrehozása MTU fekete lyuk. Kis csomagok illeszkednek, nagy csomagok DF bit készlet csendben esett.
! 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
Méret: Ha a kis kérelmek működnek, de a nagy átutalások nem, gyanús MTU / szétaprózódás. Használjon ping DF bit tesztelésére útvonal MTU.
A hanghívások hanghullámos, időszakos kimaradások voltak. Csak munkaidőben (este 9 óra 5 perc) történt.
A QoS politika létezett, de a sávszélesség-elosztás visszafelé volt: a legjobb erőfeszítés 60% -ot, a hang 5% -ot kapott. Az üzleti órákban, amikor az adatforgalom nőtt, a hangcsomagok leestek a sorban álló túlcsordulások miatt.
! 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
Időalapú kérdések = kapacitás: Ha a problémák csak a zsúfolt órákban jelentkeznek, az nem egy kemény kudarc, hanem egy kapacitás / QoS probléma. A sorban álló statisztikák ellenőrzése, nem csak a teljes sávszélesség.
| Szimuláció | Réteg | Parancsok a futásra | Mit keressünk? |
|---|---|---|---|
| Nincs kapcsolat fény | 1. réteg | show interfaces |
Állapot: le, nincs szállító, kábel kihúzva |
| Csomagveszteség | 1 / 2 réteg | show interfaces |
CRC hibák, futások, óriások, ütközések, késői ütközések |
| Nem lehet pingelni | 2. réteg | arp -a |
Nincs ARP bejegyzés, MAC nem tanult, STP blokkolás |
| Nem érem el a távoli alhálót | 3. réteg | traceroute |
Hiányzó útvonal, rossz next- hop, útvonal hurok |
| A kapcsolat elutasítása | 4. réteg | telnet host port |
Szolgáltatás nem figyel, tűzfal blokk, TCP RST |
| Lassú teljesítmény | 4 + réteg | ping (RTT) |
Nagy latencia, sávszélesség-határ, TCP átadás, nulla ablak |
| Nem tudom megoldani a hostname | 7. réteg | nslookup |
DNS szerver elérhetetlen, hibás DNS config, NXDOMAIN |
| Időszakos cseppek | Layer 1/2 | ping -f (flood) |
Duplex-eltérés, hibás kábel, STP-konvergencia |
| Néha működik, nem máskor. | Többszörös | Extended ping |
Terhelési kiegyensúlyozási probléma, ECMP aszimmetria, állami asztal túlcsordulása |
Tudd, mikor lépjünk át a TAC-ra vagy a rangidős mérnökökre. Escalate, ha:
Minden problémamegoldás tanulási lehetőség. Személyi tudásbázis építése:
# 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
Rendszerezze a gyakran használt parancsokat forgatókönyv szerint gyors referencia közben hibaelhárítás.
A konfigurációk megváltoztatása a probléma megértése nélkül gyakran rontja a helyzetet, vagy elfedi az igazi problémát.
Gyakran "hálózati problémák" alkalmazás, szerver, vagy ügyféloldali problémák. Gyűjtsön bizonyítékot, mielőtt elfogadja a felelősséget.
Időpocsékolás lesz megismételni a teszteket, amiket már elvégeztek, vagy képtelen lesz elmagyarázni a kollégáknak, hogy mit próbáltak.
Az időszakos problémák gyakran a küszöbön álló sikertelenség korai figyelmeztető jelei. Vizsgáljátok meg őket, mielőtt kritikussá válnak.
Egy eszköz újraindítása visszaállíthatja a szolgáltatást, de ha nem derítjük ki, miért volt szükség az újraindításra, a probléma megismétlődik.
A hálózati hibaelhárítás egyszerre tudomány és művészet. A tudomány szisztematikus módszertant követ, helyes diagnosztikai eszközöket és megértő protokollokat használ. A művészet az, hogy tudjuk, mely teszteket kell először lefuttatni a tünetek alapján, felismerve a mintákat a tapasztalatokból, és tudjuk, mikor kell fokozni.
Az ebben a cikkben körvonalazott módszeres megközelítés követésével - a megfelelő kérdéseket feltéve, módszeresen dolgozva az OSI-modellen, dokumentálva a lépéseidet, és tanulva minden egyes kérdésből - hatékonyabbá válik a problémamegoldásban, és elkerüli azokat a közös csapdákat, amelyek időpocsékoláshoz és helytelen javításokhoz vezetnek.
Emlékezz: A cél nem csak a szolgáltatás helyreállítása, hanem annak megértése, hogy miért nem sikerült, hogy megakadályozd, hogy újra megtörténjen.
Utolsó frissítés: 2026. február 2.