Network Troubleshooting Methodology: La Sistema Aliro

Kial metodologio gravas

Problemo:

La solvo:

La kosto de Haphazard Troubleshooting:

Enkonduko: La Scienca Metodo Aplikata al Reto

Reta perturbado estas principe praktikado en la scienca metodo:

  1. Observi
  2. Formo hipotezo
  3. La hipotezo
  4. Analizi rezultojn
  5. Efektivigu fiksan
  6. Traduki

Tiu artikolo disponigas strukturitan kadron por sendostaciaj perturboj kiuj malhelpas oftajn faltruojn kiel:

Kvin gravaj demandoj

Antaŭ plonĝado en teknikajn testojn, respondas tiujn kvin kritikajn demandojn por malvastigi vian enketoskopon:

Demando: Kio ŝanĝiĝis lastatempe?
  • Kontrolu ŝanĝi administradajn tagalojn
  • Revizio lastatempa faras en konfiguracio-administradsistemoj
  • Demandu: “Ĉu vi laboras hieraŭ?”
↓
Demando: Kiu estas fiksita?
  • Unu aparato: Kiel loka temo (NIC, kablo, konfiguracio)
  • Unu subreto: Gateway, DHCP, aŭ ŝanĝtemo
  • Ĉiuj: Kerna infrastrukturo, ISP, aŭ ĝeneraligita temo
  • Specifa app: Apliki servilon, fajromuron, aŭ DNS
↓
Demando: Ĉu ĝi estas konstanta aŭ intermita?
  • Konstanta: Malfacila fiasko (kapabla tranĉo, miskonfiguracio, malsupren servo)
  • Tempo-bazita: Congestion dum komerchoroj, planitaj procezoj
  • Intermittent/Random: Dupleksa misagordo, malsukcesante hardvaron, intermitan ligon
↓
Demando: Ĉu vi povas reprodukti ĝin?
  • Jes, jes: Multe pli facile diagnozi (povaj testhipotezoj)
  • Neniu: Dividi monitoradon/vesti kaj atendi ripetiĝon
↓
Demando: Kion vidas la alia flanko?
  • Kliento perspektivo vs. servila perspektivo
  • Pakaĵo kaptas ĉe fonto vs. celloko
  • Malsimetria rouing? Malsamaj vojoj por sendi vs. ricevi?

OSI Model-bazita Diagnostic Approach

La OSI-modelo disponigas strukturitan kadron por maltrankviliĝoj. Laboro de Layer 1 (Physical) supren, aŭ de Layer 7 (Application) malsupren, depende de simptomoj.

Bottom-Up Aliro (Layer 1 → Layer 7)

Kiam oni uzas:

Layer 1: Fizika
↓
Layer 2: Datenligo
↓
Layer 3: Reto
↓
Layer 4: Transport
↓
Layer 5-7: Session/Presentation/Application

Top-Down Approach (Layer 7 → Layer 1)

Kiam oni uzas:

Ekzemplo:

Komencu ĉe Layer 7 (Estas SharePoint-servo kuranta? DNS-solvo por korekti IP?) kaj labori malsupren nur se bezonite.

La decida arbo: Ĉu ĝi estas 1, 2, aŭ 3?

Uzu tiun rapidan diagnozan arbon por identigi kiu tavolo malsukcesas:

Ĉu vi povas fari lokon (127.0.0.1)?
Neniu
Problemo: Funkciiga Sistemo / Softvartemo
YES
Ĉu vi povas pagi vian IP-adreson?
↓ NO
Problemo: Layer 1/2 - loka Network Interface
↓ YES
Ĉu vi povas pagi defaŭltan enirejon?
↓ NO
Problemo: Layer 1/2 - loka reto
↓ YES
Ĉu vi povas pagi malproksiman gastiganton per IP-adreso?
↓ NO
Problemo: Layer 3 - Routing
↓ YES
Ĉu vi povas solvi DNS (nslookup mastro-nomo)?
↓ NO
Problemo: DNS-konfiguracio
↓ YES
Ĉu vi povas atingi aplikaĵon (telret-fera haveno)?
↓ NO
Problemo: Firewall / Port Blocking
↓ YES
Reto estas OK - Application Layer Issue

Isolvaj teknikoj

Kiam vi havas hipotezon pri la radika kaŭzo, uzu tiujn izolajn teknikojn por konfirmi aŭ malakcepti ĝin:

Replace Components Systematally

Tip:

2. Packet Captures ĉe Multoblaj punktoj

Kapti trafikon ĉe fonto, mezaj punktoj, kaj celloko identigi kie pakaĵetoj estas faligitaj aŭ modifitaj:

# 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

3. Loopback Testing

Elimini eksterajn variablojn testante konekteblecon ene de ununura aparato:

# 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

4. Known-Good Baseline Comparisons

Komparita konfiguracio kaj konduto kontraŭ laborsistemo:

# 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")

Dokumentado dum Problemoj

Properdokumentaro malhelpas cirklan malkonstruadon kie vi provas la saman aĵon multoblaj tempoj sen realigado de ĝi.

Problemoj:

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
Kial dokumentaj aferoj:

Real-World Case Studies

Case Study 1: "La Reto estas malrapida" (Atulio: TCP Window Exhaustion)

Simbolo

Datumbazo-aplikaĵo tempoj degradis de <100ms ĝis 5+ sekundoj. Aplikiĝteamo kulpigis "netlaborlatentecon."

Komencaj Ĉieliroj (Wrong)

Diagnoza proceso

  1. Ping-testo:
  2. Bandwidth-testo (iperf):
  3. Pakta kapto:
  4. Servila inspektado:

Radia Kaŭzo

Datumaĵservilo Os bufroj estis tro malgrandaj por alt-bandwidth × prokrastprodukto. TCP-fenestro plenigus, devigante senditon atendi.

Rezolucio de rezolucio

# Increased TCP receive buffers on Linux database server sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216" sysctl -w net.core.rmem_max=16777216

Leciono lernis

Ne supozu:

Kazesploro 2: Intermittent Connectivity (Actually: Dupleksa Misaglo)

Symptom

Servilligo falus hazarde, precipe sub ŝarĝo. Foje li laboris bone, foje tute ne respondema.

Initial Assumptions (Wrong)

Diagnostic Process

  1. Interfa inspektado:
  2. Eraro kontraŭs:
  3. Malfruaj kolizioj:

Root Cause

Aŭto-traktado malsukcesis. Servilo negocis plen-dupleksan, ŝanĝon falis reen al duon-dupleksa. Kolizioj nur okazis sub ŝarĝo kiam ambaŭ flankoj provis elsendi samtempe.

Resolution

! Cisco switch - force full duplex interface GigabitEthernet1/0/10 speed 1000 duplex full

Lesson Learned

Kontrolu ambaŭ finoj:

Case Study 3: " Can't Reach Certain Websites" (Actually: MTU/PMTUD Black Hole)

Symptom

Uzantoj povis foliumi kelkajn retejojn (Google, Yahoo) sed ne aliajn (bankretejo, firmaoportalo). Malgrandaj HTTP-petoj laboris, grandaj paĝoj tempigis.

Initial Assumptions (Wrong)

Diagnostic Process

  1. DNS-rezolucio:
  2. Ping-testo:
  3. Malgranda HTTP-peto (curl):
  4. Granda elŝuto:
  5. MTU testo:ping -M do -s 1472ping -M do -s 1473
  6. ICMP monitorado:

Root Cause

VPN-tunelo reduktis MTU al 1400, sed fajromuro blokis ICMP "Fragmentation Needed" mesaĝojn. Path MTU Discovery (PMTUD) ne povis labori, kreante MTU nigran truon. Malgrandaj pakaĵetoj konvenas, grandaj pakaĵetoj kun DF peceto metita estis silente faligitaj.

Resolution

! 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

Lesson Learned

Konsideri aferojn:

Kazesploro 4: VoIP Quality Issues (Actually: QoS Misconfiguration)

Symptom

Voĉvokoj havis koluzian aŭdion, intermitajn gutojn. Nur okazis dum komercaj horoj (9am-5pm).

Initial Assumptions (Wrong)

Diagnostic Process

  1. Bandwidth-testo:
  2. QoS-inspektado:
  3. Queue inspektado:
  4. Pakta kapto:

Root Cause

QoS-politiko ekzistis sed bendolarĝsigno estis malantaŭen: plej bona-fort ricevis 60%, voĉo ricevis 5%. Dum komerchoroj kiam datentrafiko pliiĝis, voĉpakaĵetoj estis faligitaj pro atendofluo.

Resolution

! 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

Lesson Learned

Tempo-bazitaj temoj = kapacito:

Command Reference de Symptom

Simbolo Layer Komandoj al Run Kion serĉi
Neniu ligilo 1 Layer show interfaces
ethtool eth0		 Statuso: malsupren, neniu aviad-kompanio, kablo neligita
Plenkreda perdo Layer 1/2 show interfaces
show interfaces counters errors		 CRC-eraroj, runoj, gigantoj, kolizioj, malfruaj kolizioj
ne povas trovi enirejon 2 Layer arp -a
show mac address-table
show spanning-tree		 Neniu ARP-eniro, MAC ne lernis, STP blokanta
ne povas atingi malproksiman subreton 3 Layer traceroute
show ip route
show ip route summary		 Mankanta itinero, malĝusta venont-hopo, routing buklo
Ligo rifuzis 4 Layer telnet host port
netstat -an
tcpdump		 Servo ne aŭskultante, fajromuro bloko, TCP RST
Malrapida efikeco 4 + ping (RTT)
iperf3
tcpdump
show interfaces		 Alta latenteco, bendolarĝlimo, TCP redissendoj, nul fenestroj
Ne povas solvi mastron 7 Layer nslookup
dig
cat /etc/resolv.conf		 DNS-servilo neatingebla, malĝusta DNS konfig, NXDOMAIN
Intermetaj gutoj Layer 1/2 ping -f (flood)
show logging
show interfaces		 Dupleksa misagordo, malsukcesante kablon, STP-rekonverĝon
Kelkfoje, ne aliaj Multoblaj Extended ping
Packet capture
Interface statistics		 Load balancanta temon, ECMP-simetrion, ŝtattablon superfluaĵo

Kiam ĝi estas

Konata kiam al escalate al vendisto TAC aŭ altrangaj inĝenieroj. Ekrano kiam:

Antaŭ Eskalado:

Konstrui Vian Personaj Scio-Bazo

Ĉiu malfeliĉa sesio estas lerna ŝanco. Konstrui personan sciobazon:

1. Kreu Troubleshooting Journal

# 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

2 Konstruu Komandon Cheat Sheet

Organizi ofte-uzitajn komandojn per scenaro por rapida referenco dum krevigado.

3 Dokumentas Vian Reton

Oftaj kontraŭ- Padronoj Eviti

DON'T: Fari hazardajn ŝanĝojn sen diagnozo

Ŝanĝante konfiguraciojn sen komprenado de la problemo ofte faras aĵojn pli malbonaj aŭ maskas la realan temon.

DON'T: Assume la reto ĉiam estas ĉe kulpo

Ofte "ret temoj" estas apliko, servilo, aŭ kliento-flankaj problemoj. Gatero indico antaŭ akceptado de kulpigo.

DON'T: Haŭto dokumentanta viajn ĝenajn paŝojn

Vi perdos tempon ripetantan testojn kiujn vi jam faris, aŭ estos nekapabla klarigi al kolegoj kion vi provis.

DON'T: Ignoru intermitajn temojn

Intermittaj problemoj ofte estas fruaj avertantaj signoj de urĝa fiasko. Enketis ilin antaŭ ol ili iĝas kritikaj.

DON'T: Fix-simptomoj anstataŭe de radikkialoj

Rebatante aparaton eble restarigos servon, sed se vi ne trovas WHY ĝi bezonis restartigadon, la problemo ripetiĝos.

Resumo: La Systematic Troubleshooting Checklist

Antaŭ ol komenci

Dum Problemoj

Post rezolucio

Konludo

Reta perturbado estas kaj scienco kaj arto. La scienco sekvas sisteman metodaron, uzante diagnozajn ilojn ĝuste, kaj komprenante protokolojn. La arto scias kiu testas kuri unue surbaze de simptomoj, rekonante padronojn de sperto, kaj sciante kiam al escalate.

Per sekvado de la sistema aliro skizita en tiu artikolo - rigardante la ĝustajn demandojn, laborante medie tra la OSI-modelo, dokumentante viajn ŝtupojn, kaj lernadon de ĉiu temo - vi iĝos pli efika ĉe perturboj kaj eviti la komunajn faltruojn kiuj kondukas al malŝparita tempo kaj malĝustaj fiksaj fiksaĵoj.

Memoru:

Last Updated: februaro 2, 2026 | Verkinto: Baud9600 Technical Team