Problém: Databázová aplikace je "pomalá". Síťový tým obviňuje server tým. Serverový tým viní síť. Mezitím jsou uživatelé frustrovaní a hodiny jsou promarněny kruhovým laděním.
Řešení: Systematický, vědecký přístup k řešení problémů, který používá důkazy, nikoli předpoklady, k identifikaci základních příčin.
Náklady na haphazard řešení problémů: Plýtvání časem, nesprávné opravy, které zakrývají skutečné problémy, ukazující prsty mezi týmy a degradované zkušenosti uživatelů.
Řešení síťových problémů je v zásadě cvičení ve vědecké metodě:
Tento článek poskytuje strukturovaný rámec pro řešení problémů v síti, který zabraňuje společným úskalím jako:
Než se ponoříte do technické diagnostiky, odpovězte na těchto pět kritických otázek, abyste zúžili svůj rozsah vyšetřování:
Změny konfigurace? Nový hardware? Aktualizace softwaru? Topologické úpravy?
Jeden uživatel? Jedna budova? Všichni? Pouze pro specifické použití?
Stává se to pořád? Jen v určitých hodinách? Náhodné události?
Můžete spustit problém na požádání?
Zkontrolujte oba konce spoje
Model OSI poskytuje strukturovaný rámec pro řešení problémů. Práce od vrstvy 1 (Fyzikální) nahoru, nebo od vrstvy 7 (Aplikace) dolů, v závislosti na symptomech.
Při použití: Kompletní ztráta konektivity, žádné světlo, nebo fyzické příznaky vrstvy
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -an, zachycení paketunslookup, dig, curl -vPři použití: Specifické problémy týkající se použití, pokud existuje základní konektivita
Začít na Layer 7 (Je SharePoint služba běží? DNS řešení opravy IP?) a pracovat dolů pouze v případě potřeby.
Použijte tento rychlý diagnostický strom k určení, která vrstva selhává:
TCP / IP zásobník nefunguje. Zkontrolujte služby OS, znovu nainstalujte síťové ovladače.
NIC deaktivováno, špatný ovladač, kabel odpojen. Kontrola: ip link show nebo Správce zařízení
Check: Fyzický kabel, status přepínače, zadání vlakových spojů, ARP tabulka
Kontrola: Směrovací stůl, firewall pravidla, ACL. Použití traceroute zjistit, kde se pakety zastaví
Zkontrolujte: nastavení DNS serveru, dostupnost DNS serveru, blokovací port firewall 53
Kontrola: Firewall pravidla, bezpečnostní skupiny, servis poslech na portu
Problém je v samotné aplikaci, autentizaci nebo konfiguraci aplikace
Pokud máte hypotézu o kořenové příčiny, použijte tyto techniky izolace potvrdit nebo odmítnout:
Zachytit provoz ve zdrojích, mezibodech a cílech za účelem zjištění, kde jsou pakety upuštěny nebo upraveny:
# 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
Odstranit vnější proměnné testováním konektivity v rámci jednoho zařízení:
# 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
Porovnejte konfiguraci a chování s pracovním systémem:
# 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")
Správná dokumentace zabraňuje kruhovému ladění, kde zkoušíte stejnou věc vícekrát, aniž byste si to uvědomili.
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
Odezva databázové aplikace se sníží z < 100ms na 5 + sekund. Aplikační tým obvinil "síť latence".
Databázové servery OS buffery byly příliš malé pro high-šířka pásma × zpoždění produktu. Okno TCP by se naplnilo, nutilo odesílatele čekat.
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Nepředpokládejte: "Pomalý" neznamená vždy "síťová latence". Vždy shromáždit důkazy (ping pro latentnost, zachycení paketů pro chování) před skákání k závěrům.
Spojení se serverem by se snížilo náhodně, zejména při zatížení. Někdy to fungovalo dobře, někdy úplně nereagovalo.
Automatické vyjednávání selhalo. Server vyjednal fullduplex, přepínač spadl zpět do poloduplexu. Ke srážkám došlo při zatížení pouze tehdy, když se obě strany snažily vysílat současně.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Zkontrolujte oba konce: Stav rozhraní ukazuje dojednaná nastavení. Nesoulad znamená, že autovyjednávání selhalo. Vždy hard-code rychlost / duplex pro servery.
Uživatelé mohli procházet některé webové stránky (Google, Yahoo), ale ne jiné (bankovní stránky, firemní portál). Malé HTTP požadavky pracoval, velké stránky načasovány.
ping -M do -s 1472 úspěchy, ping -M do -s 1473 selháníVPN tunel snížil MTU na 1400, ale firewall blokoval ICMP zprávy "Fragmentace potřebná". Cesta MTU Discovery (PMTUD) nemohl fungovat, vytvoření černé díry MTU. Malé pakety sedí, velké pakety s bitem DF byly tiše staženy.
! 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
Na velikosti záleží: Pokud malé požadavky fungují, ale velké převody selhávají, podezření MTU / fragmentace problémy. Použijte ping s DF bitem k testování dráhy MTU.
Hlasové hovory měly pichlavý zvuk, přerušované výpadky. K tomu došlo pouze během pracovní doby (9-5 hodin).
QoS politika existovala, ale rozdělení šířky pásma bylo obráceně: best- úsilí dostalo 60%, hlas dostal 5%. Během pracovní doby, kdy se zvýšil datový provoz, byly hlasové pakety upuštěny kvůli přetečení fronty.
! 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
Časové otázky = kapacita: Pokud se problémy vyskytnou jen během pracovní doby, není to těžké selhání, ale kapacita / QoS problém. Zkontrolujte statistiky front, nejen celkovou šířku pásma.
| Příznaky | Vrstva | Příkazy ke spuštění | Co hledat |
|---|---|---|---|
| Žádné světlo spojení | Vrstva 1 | show interfaces |
Stav: dole, bez nosiče, kabel odpojen |
| Ztráta paketu | Vrstva 1 / 2 | show interfaces |
Chyby CRC, kruhy, obři, kolize, pozdní kolize |
| Can 't ping gateway | Vrstva 2 | arp -a |
Žádný ARP vstup, MAC se nenaučil, STP blokování |
| Nedosáhnu na vzdálenou subsíť. | Vrstva 3 | traceroute |
Chybějící trasa, chybný nexthop, směrovací smyčka |
| Spojení odmítnuto | Vrstva 4 | telnet host port |
Servis neposlouchá, firewall block, TCP RST |
| Pomalý výkon | Vrstva 4 + | ping (RTT) |
Vysoká latence, omezení šířky pásma, TCP přenosy, nulová okna |
| Nelze vyřešit jméno hostitele | Vrstva 7 | nslookup |
DNS server nedostupný, špatný DNS config, NXDOMAIN |
| Intermitentní kapky | Layer 1/2 | ping -f (flood) |
Duplex nesoulad, selhání kabelu, STP rekonvergence |
| Někdy funguje, ne jiné. | Vícečetné | Extended ping |
Vyvažování zatížení, asymetrie ECMP, přetok tabulky stavů |
Vědět, kdy eskalovat prodávat TAC nebo senior inženýři. Eskalovat, pokud:
Každé problémové sezení je poučná příležitost. Vytvořit osobní znalostní základnu:
# 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
Organizovat často používané příkazy podle scénáře pro rychlou referenci při řešení problémů.
Změna konfigurace bez pochopení problému často věci zhoršuje nebo maskuje skutečný problém.
Často "síťové problémy" jsou problémy s aplikací, serverem nebo klientskými stránkami. Shromážděte důkazy, než přijmete vinu.
Budete ztrácet čas opakovanými testy, které jste již provedli, nebo nebudete schopni vysvětlit kolegům, co jste zkoušeli.
Intermitentní problémy jsou často časné varovné příznaky blížícího se selhání. Prozkoumejte je, než se stanou kritickými.
Restartování zařízení může obnovit službu, ale pokud nezjistíte, proč to potřebuje restartovat, problém se obnoví.
Síťové řešení problémů je věda i umění. Věda se řídí systematickou metodikou, pomocí diagnostických nástrojů správně, a porozumění protokoly. Umění je vědět, které testy spustit jako první na základě příznaků, rozpoznat vzory ze zkušenosti, a vědět, kdy se stupňovat.
Následováním systematického přístupu uvedeného v tomto článku - pokládání správných otázek, metodicky práce prostřednictvím modelu OSI, dokumentování vašich kroků a učení se z každého problému - se stanete účinnějšími při řešení problémů a vyhnout se společným nástrahám, které vedou k plýtvání časem a nesprávným opravám.
Pamatujte: Cílem není jen obnovit službu, ale pochopit, proč selhala, abyste tomu zabránili.
Aktualizováno: 2. února 2026