Network Troubleshooting Methodology - The Systematic Approach
Reta Troubleshooting Methodology: La Sistema Aliro
Kial Metodologio Gravas
La Problemo:Apliko de datumbazo estas "malrapida." La reto-teamo kulpigas la servilan teamon. La servila teamo kulpigas la reton. Dume, uzantoj estas frustritaj, kaj horoj estas malŝparitaj en cirkla senararigado.
La Solvo:Sistema, scienca aliro al problemoj, kiu uzas indicon, ne supozojn, por identigi radikajn kaŭzojn.
La Kosto de Hazarda Problemosolvado:Malŝparita tempo, malĝustaj korektoj, kiuj maskas realajn problemojn, fingromontradon inter teamoj, kaj degradita uzantsperto.
Enkonduko: La Scienca Metodo Aplikata al Retoj
Retaj problemoj estas esence ekzerco en la scienca metodo:
- Observula simptomoj kaj kolekti datumojn
- Formu hipotezonpri la radika kaŭzo
- Testu la hipotezonkun diagnozaj iloj
- Analizu rezultojnkaj konfirmi aŭ malakcepti la hipotezon
- Efektivigu riparigonsurbaze de konfirmita radika kaŭzo
- Kontrolula problemo estas solvita
Ĉi tiu artikolo disponigas strukturitan kadron por retproblemoj, kiu malhelpas oftajn problemojn kiel:
- Konfirma biaso (serĉante nur pruvojn, kiuj subtenas vian komencan supozon)
- Hazardaj ŝanĝoj sen diagnozo (la aliro "ŝprucigi kaj preĝi")
- Ripari simptomojn anstataŭ radikaj kaŭzoj
- Cirkla elpurigado sen dokumentado de kio estis provita
La Kvin Ŝlosilaj Demandoj
Antaŭ ol plonĝi en teknikan diagnozon, respondu ĉi tiujn kvin kritikajn demandojn por malgrandigi vian esploran amplekson:
Ŝanĝoj de agordo? Nova aparataro? ?isdatigoj de programaro? Topologiaj modifoj?
- Kontrolu ŝanĝadministrajn protokolojn
- Revizu lastatempajn komitojn en agordaj administradsistemoj
- Demandu: "Ĉu ĝi funkciis hieraŭ?"
Unu uzanto? Unu konstruaĵo? Ĉu ĉiuj? Nur specifa apliko?
- Unu aparato:Verŝajne loka problemo (NIC, kablo, agordo)
- Unu subreto:Enirejo, DHCP aŭ ŝanĝa problemo
- Ĉiuj:Kerna infrastrukturo, ISP aŭ ĝeneraligita problemo
- Specifa aplikaĵo:Aplikservilo, firewall regulo, aŭ DNS
Okazas la tutan tempon? Nur dum certaj horoj? Hazardaj okazoj?
- Konstanto:Malfacila fiasko (kablotranĉo, misagordado, malfunkcia servo)
- Tempbazita:Kongesto dum komercaj horoj, planitaj procezoj
- Intermita/Hazarda:Dupleksa miskongruo, malsukcesa aparataro, intermita ligo
Ĉu vi povas ekigi la problemon laŭ postulo?
- Jes:Multe pli facile diagnozi (povas testi hipotezojn)
- Ne:Agordu monitoradon/registradon kaj atendu ripetiĝon
Kontrolu ambaŭ finojn de la konekto
- Klienta perspektivo kontraŭ servila perspektivo
- Pakaĵeto ĉe fonto kontraŭ celo
- Nesimetria vojigo? Malsamaj vojoj por sendi kontraŭ ricevi?
La OSI-Model-Bazita Diagnoza Aliro
La OSI-modelo disponigas strukturitan kadron por solvi problemojn. Laboru de Tavolo 1 (Fizika) supren, aŭ de Tavolo 7 (Apliko) malsupren, depende de simptomoj.
Malsupra Aliro (Tavolo 1 → Tavolo 7)
Kiam uzi:Kompleta konekteblecperdo, neniu liglumo, aŭ fizikaj tavolsimptomoj
- Kontrolu: Kablo konektita? Ligo lumoj? Fibro pura?
- Komandoj:
show interfaces,ethtool eth0 - Serĉu: CRC-erarojn, koliziojn, malfruajn koliziojn, runtojn, gigantojn
- Kontrolu: Ĉu korekta VLAN? Haveno ebligita? STP-blokado?
- Komandoj:
show mac address-table,show spanning-tree - Serĉu: MAC-flapado, STP-topologioŝanĝoj, VLAN-malkongruoj
- Kontrolu: Ĉu ping povas defaŭltan enirejon? Voja tabelo ĉu ĝusta?
- Komandoj:
ping,traceroute,show ip route - Serĉu: Mankantaj itineroj, malĝusta sekva salto, vojaj bukloj
- Kontrolu: Ĉu povas establi TCP-konekton? Fajromuro blokanta havenon?
- Komandoj:
telnet host port,netstat -an, paka kapto - Serĉu: TCP-redissendojn, nul fenestrojn, RST-pakaĵojn
- Kontrolu: DNS solvas? Apliko respondas? Aŭtentikigo funkcias?
- Komandoj:
nslookup,dig,curl -v - Serĉu: DNS-malsukcesoj, aplikaj eraroj, tempofinproblemoj
Desupra Aliro (Tavolo 7 → Tavolo 1)
Kiam uzi:Aplik-specifaj problemoj kie baza konektebleco ekzistas
Komencu ĉe Tavolo 7 (Ĉu SharePoint-servo funkcias? DNS solvas por korekti IP?) kaj malfunkciu nur se necese.
La Decida Arbo: Ĉu Ĝi estas Tavolo 1, 2 aŭ 3?
Uzu ĉi tiun rapidan diagnozan arbon por identigi kiu tavolo malsukcesas:
TCP/IP-stako ne funkcias. Kontrolu OS-servojn, reinstalu retajn ŝoforojn.
NIC malŝaltita, malĝusta ŝoforo, kablo malkonektita. Kontrolu:ip link showaŭ Aparato-Administranto
Kontrolu: Fizika kablo, ŝaltila havenostatuso, VLAN-tasko, ARP-tabelo
Kontrolu: Vojetabelo, firewall reguloj, ACLs. Uzutraceroutepor trovi kie pakoj haltas
Kontrolu: DNS-servilo-agordojn, DNS-servila havebleco, fajroŝirmilo blokanta havenon 53
Kontrolu: Reguloj pri fajroŝirmilo, sekurecaj grupoj, servo aŭskultado en haveno
Problemo estas kun la aplikaĵo mem, aŭtentigo aŭ aplikaĵo-agordo
Izolaj Teknikoj
Kiam vi havas hipotezon pri la radika kaŭzo, uzu ĉi tiujn izoligajn teknikojn por konfirmi aŭ malakcepti ĝin:
1. Anstataŭigi Komponentojn Sisteme
- Interŝanĝu flikkablon kun konata bona kablo
- Testu sur malsama ŝaltila haveno
- Provu malsaman NIC (aŭ USB-retan adaptilon)
- Testu de malsama klienta aparato
- Movu al malsama VLAN/subreto
2. Pakaj Kaptoj ĉe Multoblaj Punktoj
Kaptu trafikon ĉe fonto, mezaj punktoj kaj celloko por 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 Testado
Forigu eksterajn variablojn provante 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. Konataj-Bonaj Bazliniaj Komparoj
Komparu agordon kaj konduton kontraŭ funkcianta sistemo:
# 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 Troubleshooting
Taŭga dokumentado malhelpas cirklan senararigon kie vi provas la saman aferon plurfoje sen rimarki ĝin.
Ŝablono pri solvo de problemoj
Problema ID: TICKET-12345
Dato/Horo: 2026-02-02 14:30 UTC
Raportita de: Jane Smith (jane.smith@company.com)
Afektitaj Uzantoj: ~50 users in Building A, 3rd floor
Simptomo: Cannot access file server \\fileserver01
Komencaj Observoj:
- 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
Testoj faritaj:
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
Radika Kaŭzo:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss
Rezolucio:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.
Konfirmo:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.
Tempo al Rezolucio: 25 minutes
Real-Mondaj Kazaj Studoj
Kaza studo 1: "La Reto estas Malrapida" (Fakte: TCP Fenestra Elĉerpiĝo)
Simptomo
La respondaj tempoj de datumbazaj aplikaĵoj malpliiĝis de <100ms al 5+ sekundoj. Aplika teamo kulpigis "retan latentecon."
Komencaj Supozoj (Malĝuste)
- Reta kongesto
- WAN-ligo saturita
- Fajromuro proplemkolo
Diagnoza Procezo
- Ping-testo:RTT = 2ms (bonega, ekskludas latencian de Tavolo 3)
- Testo de bendolarĝo (iperf):950 Mbps sur 1 Gbps ligo (neniu ŝtopiĝo)
- Pakaĵeto:Malkaŝitaj TCP Zero Window-pakoj de datumbaza servilo
- Servilo-inspektado:Datumbaza servilo ricevas bufrojn = 64KB (eta!)
Radika Kaŭzo
Datumservila OS-bufroj estis tro malgrandaj por alt-bendolarĝo × prokrasta produkto. TCP-fenestro pleniĝus, devigante la sendinton atendi.
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 Lernita
Ne supozu:"Malrapida" ne ĉiam signifas "retlatenteco". Ĉiam kolektu pruvojn (pingo por latenteco, pakaĵeto por konduto) antaŭ ol salti al konkludoj.
Kaza studo 2: Intermita Konektebleco (Fakte: Dupleksa Miskongruo)
Simptomo
Servila konekto falus hazarde, precipe sub ŝarĝo. Foje funkciis bone, foje tute neresponde.
Komencaj Supozoj (Malĝuste)
- Malsukcesa NIC
- Malbona kablo
- Ŝanĝi aparatan problemon
Diagnoza Procezo
- Interfaco-inspektado:Servilo NIC = 1000/Plena, Ŝaltila haveno = 1000/Duono (miskongruo!)
- Eraraj nombriloj:Amasa koliziokalkulo sur ŝaltila haveno
- Malfruaj kolizioj:Indikilo de dupleksa miskongruo
Radika Kaŭzo
Aŭtomata intertraktado malsukcesis. Servilo negocis plendupleksa, ŝaltilo falis reen al duonduplex. Kolizioj nur okazis sub ŝarĝo kiam ambaŭ flankoj provis elsendi samtempe.
Rezolucio
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Leciono Lernita
Kontrolu ambaŭ finojn:Interfaco-stato montras la intertraktatajn agordojn. Miskongruo signifas, ke aŭtomata intertraktado malsukcesis. Ĉiam malmola kodo rapido/dupleksa por serviloj.
Kaza studo 3: "Ne Povas Atingi Certajn Retejojn" (Fakte: MTU/PMTUD Nigra Truo)
Simptomo
Uzantoj povus foliumi iujn retejojn (Google, Yahoo) sed ne aliajn (banka retejo, kompania portalo). Malgrandaj HTTP-petoj funkciis, grandaj paĝoj elĉerpiĝis.
Komencaj Supozoj (Malĝuste)
- DNS-afero
- Fajroŝirmilo blokante specifajn retejojn
- Problemo pri vojigo de ISP
Diagnoza Procezo
- DNS-rezolucio:Funkcias bone por ĉiuj retejoj
- Ping-testo:Povas pingi la "neatingeblajn" retejojn
- Malgranda HTTP-peto (buklo):Verkoj por malgrandaj paĝoj
- Granda elŝuto:Haltoj post TCP-manpremo
-
MTU-testo:
ping -M do -s 1472sukcesas,ping -M do -s 1473malsukcesas - Monitorado de ICMP:Neniuj "Fragmentado Bezonata" (Tipo 3 Kodo 4) mesaĝoj ricevitaj
Radika Kaŭzo
VPN-tunelo reduktis MTU al 1400, sed fajroŝirmilo blokis ICMP "Fragmentation Needed" mesaĝojn. Path MTU Discovery (PMTUD) ne povis funkcii, kreante MTU nigran truon. Malgrandaj pakaĵoj taŭgas, grandaj pakaĵoj kun DF-bitaro estis silente faligitaj.
Rezolucio
! 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
Leciono Lernita
Grandeco gravas:Se malgrandaj petoj funkcias sed grandaj translokigoj malsukcesas, suspektu problemojn pri MTU/fragmentado. Uzu ping kun DF-bito por testi vojon MTU.
Kaza studo 4: Problemoj pri Kvalito de VoIP (Fakte: Misagordo de QoS)
Simptomo
Voĉaj vokoj havis ŝercan aŭdion, intermitaj ĉesoj. Okazis nur dum komercaj horoj (9am-5pm).
Komencaj Supozoj (Malĝuste)
- Nesufiĉa bendolarĝo
- VoIP-servilo troŝarĝita
- ISP-kvalito de konekto
Diagnoza Procezo
- Testo de bendolarĝo:Ligo nur 40% uzata dum okupata horo
- Inspektado de QoS:Voĉa trafiko markita per DSCP EF (46) ĝuste
- Inspektado de vostovico:Voĉa vico havis nur 5% bendolarĝan asignon (devus esti 33%)
- Pakaĵeto:Voĉaj pakoj estas faligitaj dum ŝtopiĝo
Radika Kaŭzo
QoS-politiko ekzistis sed bendolarĝa asigno estis malantaŭen: plej bona klopodo ricevis 60%, voĉo ricevis 5%. Dum laborhoroj kiam datumtrafiko pliiĝis, voĉpakoj estis faligitaj pro atendovicsuperfluo.
Rezolucio
! 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
Leciono Lernita
Tempobazitaj aferoj = kapacito:Se problemoj okazas nur dum okupataj horoj, ĝi ne estas malfacila fiasko sed problemo pri kapablo/QoS. Kontrolu vostostatistikojn, ne nur totalan bendolarĝon.
Komando Referenco per Simptomo
| Simptomo | Tavolo | Komandoj por Kuri | Kion Serĉi |
|---|---|---|---|
| Neniu liglumo | Tavolo 1 | show interfaces |
Statuso: malsupre, neniu portanto, kablo malkonektita |
| Paka perdo | Tavolo 1/2 | show interfaces |
CRC-eraroj, runtoj, gigantoj, kolizioj, malfruaj kolizioj |
| Ne povas ping-enirejon | Tavolo 2 | arp -a |
Neniu ARP-eniro, MAC ne lernita, STP-blokado |
| Ne povas atingi foran subreton | Tavolo 3 | traceroute |
Mankas itinero, malĝusta sekva salto, vojbuklo |
| Konekto rifuzita | Tavolo 4 | telnet host port |
Servo ne aŭskultanta, fajroŝirmilo bloko, TCP RST |
| Malrapida agado | Tavolo 4+ | ping (RTT) |
Alta latencia, bendolarĝa limo, TCP-retransmisioj, nulaj fenestroj |
| Ne povas solvi gastigan nomon | Tavolo 7 | nslookup |
DNS-servilo neatingebla, malĝusta DNS-agordo, NXDOMAIN |
| Intermitaj gutoj | Tavolo 1/2 | ping -f (flood) |
Dupleksa miskongruo, malsukcesa kablo, STP-rekonverĝo |
| Funkcias foje, ne aliaj | Multoblaj | Extended ping |
Ŝarĝekvilibra afero, ECMP-malsimetrio, ŝtattabelo superfluo |
Kiam Escalar
Sciu kiam eskaladi al vendisto TAC aŭ altrangaj inĝenieroj. Pligrandigu kiam:
- Vi elĉerpis ĉiujn solvojn de problemoj en via sciobazo
- Problemo postulas aliron/permesojn, kiujn vi ne havas
- Problemo implikas vendistan programaron cimon aŭ aparataron difekton
- Komerca efiko estas kritika kaj temp-sentema
- Multoblaj teamoj devas kunlabori (aplikaĵo + reto + servilo)
- Kompleta simptoma priskribo
- Templinio de kiam temo komenciĝis
- Diagnozaj komandoj funkcias kaj ilia eligo
- Sekurkopioj de agordo
- Pakaj kaptoj (se grave)
- Kion vi jam provis
Konstruante Vian Personan Scio-Bazon
Ĉiu sesio pri solvo de problemoj estas lerna ŝanco. Konstruu 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 Komandan Trompanton
Organizu ofte uzatajn komandojn laŭ scenaro por rapida referenco dum problemoj.
3. Dokumentu Vian Reton
- Topologiaj diagramoj (Tavolo 2 kaj Tavolo 3)
- Dokumentado pri IP-adresskemo
- VLAN-taskoj
- Normaj agordoj (ŝablonoj)
- Konataj bonaj bazlinioj (interfacaj statistikoj antaŭ problemoj)
Oftaj kontraŭ-ŝablonoj por eviti
❌ NE: Faru hazardajn ŝanĝojn sen diagnozo
Ŝanĝi agordojn sen kompreni la problemon ofte plimalbonigas aferojn aŭ maskas la veran problemon.
❌ NE: Supozu, ke la reto ĉiam kulpas
Ofte "retaj problemoj" estas problemoj pri aplikaĵo, servilo aŭ klientflankaj. Kolektu pruvojn antaŭ ol akcepti kulpigon.
❌ NE: Pretu dokumenti viajn problemojn pri solvo
Vi perdos tempon ripetante provojn, kiujn vi jam faris, aŭ ne povos klarigi al kolegoj, kion vi provis.
❌ NE: Ignoru intermitajn aferojn
Intermitaj problemoj ofte estas fruaj avertaj signoj de urĝa fiasko. Esploru ilin antaŭ ol ili fariĝos kritikaj.
❌ NE: Ripari simptomojn anstataŭ radikaj kaŭzoj
Rekomenci aparaton povus restarigi servon, sed se vi ne ekscias KIAL ĝi bezonis rekomenci, la problemo rekomenciĝos.
Resumo: La Sistema Kontrola Listo de Problemoj
✓ Antaŭ ol Vi Komencu
- Respondu la kvin ĉefajn demandojn (Kio ŝanĝiĝis? Kiu estas tuŝita? Konstanta aŭ intermita? Reproduktebla? Kion vidas la alia flanko?)
- Kolektu komencajn simptomojn kaj uzantajn raportojn
- Kontrolu pri lastatempaj ŝanĝoj aŭ prizorgado
✓ Dum Problemosolvado
- Laboru metode per OSI-tavoloj (malsupre aŭ desupre)
- Ŝanĝu UNU variablon samtempe dum testado
- Dokumentu ĉiun teston kaj ĝian rezulton
- Uzu pakajn kaptojn por vidi realan trafikan konduton
- Komparu kontraŭ konataj bonaj bazlinioj
✓ Post Rezolucio
- Kontrolu, ke la riparo efektive solvis la problemon
- Dokumentu la radikan kaŭzon kaj rezolucion
- Ĝisdatigu vian scion
- Se agordo ŝanĝiĝis, ĝisdatigu dokumentaron
- Konsideru: Ĉu monitorado povus kapti ĉi tion pli frue?
Konkludo
Retaj problemoj estas kaj scienco kaj arto. La scienco sekvas sisteman metodaron, uzanta diagnozajn ilojn ĝuste, kaj komprenante protokolojn. La arto estas scii, kiuj testoj fari unue surbaze de simptomoj, rekoni ŝablonojn de sperto, kaj scii kiam eskaladi.
Sekvante la sisteman aliron skizitan en ĉi tiu artikolo—demandante la ĝustajn demandojn, laborante metode per la OSI-modelo, dokumentante viajn paŝojn, kaj lernante de ĉiu afero—vi fariĝos pli efika ĉe solvi problemojn kaj evitos la komunajn malfacilaĵojn, kiuj kondukas al malŝparo de tempo kaj malĝustaj korektoj.
Memoru:La celo ne estas nur restarigi servon, sed kompreni KIAL ĝi malsukcesis, por ke vi povu malhelpi ĝin denove okazi.
Laste Ĝisdatigita: Februaro 2, 2026 | Aŭtoro: Baud9600 Teknika Teamo