Problema: Duomenų bazės programa "lėtai". Tinklo komanda kaltina serverio komandą. Serverio komanda kaltina tinklą. O vartotojai yra nusivylę, o valandos yra švaistomi žiedinio derinimo.
Tirpalas: Sistemingas, mokslinis požiūris į problemų šalinimą, kuriame naudojami įrodymai, ne prielaidos, siekiant nustatyti pagrindines priežastis.
Haplarity trikdžių šalinimo išlaidos: Keptas laikas, neteisingi pataisymai, kad maskuoti realias problemas, pirštų rodymas tarp komandų, ir pablogėjusi vartotojo patirtis.
Trūkumų šalinimas tinkle iš esmės yra mokslinio metodo įgyvendinimas:
NAME OF TRANSLATORS
Prieš nardymo į techninę diagnostikos, atsakyti į šiuos penkis svarbius klausimus susiaurinti savo tyrimo apimtį:
Konfigūracijos pakeitimai? Nauja techninė įranga? Programinės įrangos atnaujinimas? Topologijos modifikacijos?
Vieną naudotoją? Vieną pastatą? Visiems? III PRIEDAS
Visą laiką? Vos per kelias valandas? Atsitiktiniai įvykiai?
Jūs galite sukelti problemą pagal pareikalavimą?
Patikrinkite abu ryšio galus
OSI modelis suteikia struktūrizuotą problemų šalinimo sistemą. Darbas nuo Layer 1 (Fizinis) aukštyn, arba nuo Layer 7 (taikymas) žemyn, priklausomai nuo simptomų.
Kada naudoti: Visiškas junglumo praradimas, jokios nuorodos, arba fizinio sluoksnio simptomai
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -an, paketų surinkimasnslookup, dig, curl -vKada naudoti: Specifinės taikymo problemos, kai egzistuoja pagrindinis ryšys
@ info: whatsthis DNS sprendimas ištaisyti IP?) ir dirbti žemyn tik jei reikia.
Naudokite šį greitą diagnostikos medis nustatyti, kuris sluoksnis neveikia:
TCP / IP stekas neveikia. Patikrinkite OS paslaugas, iš naujo įdiegti tinklo tvarkykles.
NIC išjungtas, neteisingas vairuotojas, atjungtas kabelis. Patikrinkite: ip link show arba įrenginių tvarkyklė
Patikrinkite: Fizinis kabelis, jungiklis, VLAN priskyrimas, ARP lentelė
Patikrinkite: Maršrutizatorius, ugniasienės taisyklės, ACLs. Naudojimas traceroute rasti, kur sustabdyti paketus
Patikrinkite: DNS serverio nustatymai, DNS serverio prieinamumas, ugniasienės blokavimo prievadas 53
Patikrinkite: Ugniasienės taisyklės, apsaugos grupės, paslaugų klausymas uoste
Problema yra su pačia programa, autentifikavimo, arba programos konfigūracija
Jūs turite hipotezę apie pagrindinę priežastį, naudoti šiuos izoliavimo metodus, patvirtinti arba atmesti:
Sugavimo judėjimas šaltinyje, tarpinėse vietose ir paskirties vietoje, siekiant nustatyti, iš kur pakuojami arba keičiami pakeliai:
# 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
Šalinti išorės kintamuosius, bandant ryšį su vienu prietaisu:
# 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
Konfigūracija ir elgesys su darbo sistema:
# 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")
Tinkama dokumentacija apsaugo nuo apskrito derinimo, kai jūs bandote tą patį dalyką kelis kartus, nesuvokdami jo.
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
@ info: whatsthis Programos komanda kaltina "tinklo latenciją".
Duomenų bazės serveris OS buferiai buvo per mažas High-pralaidumo × delsimo produktas. TCP langas būtų užpildyti, verčia siuntėją laukti.
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Nesitikėk: Lėtas ne visada reiškia tinklo latenciją. Visada rinkti įrodymus (ping latentinis, paketo užfiksavimas elgesio) prieš šokinėja į išvadas.
Serverio ryšys kristų atsitiktinai, ypač esant apkrovai. Kartais dirbo gerai, kartais visiškai nereaguoja.
Savaitės derybos nepavyko. Serveris susitarė dėl dvipusio duomenų perdavimo, perjungiklis nukrito atgal į dvipusio duomenų perdavimo. Lūžiai įvyko tik esant apkrovai, kai abi pusės bandė vienu metu perduoti signalus.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Patikrinkite abu galus: sąsajos būsena rodo sutartus nustatymus. Susiklostymas reiškia, kad nepavyko derėtis dėl sutarties. Visada - kodas greitis / dvipusis serverių.
Vartotojai gali naršyti kai kurias svetaines ("Google", "Yahoo"), bet ne kitas (banko svetainė, bendrovės portalas). @ info: whatsthis
ping -M do -s 1472 sėkmingai, ping -M do -s 1473 nepavykstaVPN tunelis sumažino MTU iki 1400, bet ugniasienė blokavo ICMP "Fragmentation Navy" pranešimus. Kelio MTU Discovery (PMTUD) nepavyko, sukurti MTU juodoji skylė. Maži paketai tinka, dideli paketai su DF bitų nustatyti buvo tyliai numestas.
! 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
Dydžio klausimai: Tenka įtarti MTU ir (arba) susiskaidymo problemas, jei maži prašymai veikia, bet dideli pervedimai nepavyksta. Naudokite ping su DF bitų išbandyti kelią MTU.
Balso skambučiai turėjo hoppy garso, su pertrūkiais išskleidžiamus. (9-15 val.).
QoS politika egzistavo, bet pralaidumo paskirstymas buvo atvirkščiai: pastangos buvo 60%, balsas - 5%. Darbo valandomis, kai duomenų srautas padidėjo, balso paketų sumažėjo dėl eilės perpildymo.
! 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
Laiku pagrįsti klausimai = pajėgumas: Kyla problemų tik per užimtas valandas, tai ne sunkus gedimas, bet pajėgumo / QoS problema. Patikrinkite eilių statistiką, ne tik visą pralaidumą.
| simptomas | Sluoksnis | @ info: whatsthis | Ką ieškoti |
|---|---|---|---|
| Žibinto nėra | 1 sluoksnis | show interfaces |
Statusas: išjungtas, nėra transporterio, atjungtas kabelis |
| Paketo praradimas | 1 / 2 sluoksnis | show interfaces |
VTP klaidos, bėgimai, milžinai, susidūrimai, vėlyvi susidūrimai |
| Negaliu užeiti. | 2 sluoksnis | arp -a |
ARP įrašo nėra, MAC neišmoktas, STP blokavimas |
| Nepavyko pasiekti nutolusio subtinklo | 3 sluoksnis | traceroute |
Trūksta maršrutą, ne-hop, maršrutizavimo kilpa |
| Prisijungimas atmestas | 4 sluoksnis | telnet host port |
Tarnybos nesiklausymas, ugniasienė, TCP RST |
| Lėtas našumas | 4 + sluoksnis | ping (RTT) |
Didelis vėlavimas, pralaidumo riba, TCP retransliacijos, nuliniai langai |
| Nepavyko išspręsti mazgo pavadinimo | 7 sluoksnis | nslookup |
DNS serveris nepasiekiamas, klaidinga DNS konfigūracija, NXDOMAIN |
| Lašai su pertraukomis | Layer 1/2 | ping -f (flood) |
Dvipusio duomenų perdavimo neatitiktis, žlungantis kabelis, STP rekonvergencija |
| Darbai kartais, ne kiti | Keli | Extended ping |
Krovinio balansavimo problema, ECMP asimetrija, valstybės lentelės perteklius |
Žinoti, kada pereiti prie pardavėjo TAC arba vyresniųjų inžinierių. Eskaluoti, kai:
Kiekviena trikčių šalinimo sesija - tai mokymosi galimybė. Sukurti asmeninę žinių bazę:
# 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
Organizuoti dažnai naudojamas komandas pagal scenarijų, kad būtų galima greitai nustatyti problemas.
Kintant konfigūracijas, nesuvokiant problemos, dažnai reikalai blogėja, arba slepiasi tikroji problema.
Dažnai "tinklo klausimai" yra taikymo, serveris, arba klientų pusėje problemos. Surinkti įrodymus, prieš priimant kaltę.
Jūs švaistysite laiką pakartodami bandymus, kuriuos jau atlikote, arba negalėsite paaiškinti kolegoms, ką bandėte.
Tarpinės problemos dažnai yra ankstyvi įspėjamieji artėjančio nesėkmės požymiai. Ištirti juos, kol jie tampa kritiškas.
@ info: whatsthis
Tinklų trikčių šalinimas - tai mokslas ir menas. Mokslas yra pagal sisteminę metodiką, naudojant diagnostikos priemones teisingai, ir supratimo protokolus. Menas yra žinoti, kurie bandymai paleisti pirmą remiantis simptomų, atpažinti modelius iš patirties, ir žinoti, kada eskaluoti.
Sekant šiame straipsnyje aprašytą sisteminį požiūrį - užduodant teisingus klausimus, metodiškai dirbant per OSI modelį, dokumentuojant savo veiksmus, ir mokantis iš kiekvieno klausimo - Jūs tapsite efektyvesni problemų sprendimo metu ir išvengsite bendrų spąstų, dėl kurių švaistomas laikas ir taisomi netikslumai.
Prisimink: Tikslas yra ne tik atkurti paslaugas, bet ir suprasti, kaip ji nepavyko, todėl jūs galite užkirsti kelią tai vėl vyksta.
Paskutinį kartą atnaujinta: Vasario 2, 2026; Autorius: Baud9600 Techninė komanda