Network Troubleshooting Methodology - The Systematic Approach
Sareko arazoak konpontzeko metodoa: ikuspegi sistematikoa
Zergatik da garrantzitsua metodologia?
Arazoa:
Irtenbidea:
Haphazard-en arazoak konpontzeko kostua:
Sarrera: Sareari aplikatutako metodo zientifikoa
Sareko arazoak konpontzea oinarrizko ariketa bat da metodo zientifikoan:
- Begiratu
- Sortu hipotesi bat
- Proba ezazu hipotesia
- Emaitzak aztertzea
- Ezarri konponketa bat
- Egiaztatu
Artikulu honek sare-arazoak konpontzeko marko egituratua dauka, arazo arruntak saihesten dituena:
- Berrespenaren alborapena (hasierako susmoa onartzen duen ebidentziaren bila soilik)
- Ausazko aldaketak diagnostikorik gabe (irauli eta otoitz hurbilketa)
- Sintomak konpontzen ditu erroko kausen ordez
- Arazketa zirkularra, probatutakoa dokumentatu gabe
Bost galdera nagusiak
Diagnostiko teknikoetan murgildu aurretik, erantzun bost galdera kritiko horiei ikerketa-esparrua estutzeko:
- Egiaztatu aldaketak kudeatzeko erregistroak
- Berrikuspen berria konfigurazio-kudeaketako sistemetan
- Galdetu: "Atzo funtzionatu al zuen?"
- Gailu bat: Baliteke arazo lokala izatea (NIC, kablea, konfigurazioa)
- Azpisare bat: Gateway, DHCP edo kommutadorearen gaia
- Denak: Oinarrizko azpiegitura, ISP edo arazo orokorra
- Aplikazio espezifikoa: Aplikazio-zerbitzaria, suebaki-araua edo DNSa
- Konstantea: Hutsegite gogorra (kable ebakia, misconfiguration, down service)
- Denboran oinarrituta: Bilerak negozio-orduetan, programatutako prozesuetan
- Intermittent/Random: Duplex ez dator bat, hardware huts bat, behin-behineko esteka
- Bai: Errazagoa da diagnostikatzea (suposizioak froga ditzake)
- Ez: Konfiguratu monitorizazioa/saioa eta itxaron errepikatzeari
- Bezeroaren ikuspegia vs. zerbitzariaren perspektiba
- Packet-en harrapaketa iturburuan vs. helmugan
- Bideratze asimetrikoa? Bidaltzeko bide desberdinak, jaso?
OSI ereduan oinarritutako diagnostiko-ikuspegia
OSI ereduak arazoak konpontzeko marko egituratua eskaintzen du. 1. geruzatik (fisikoa) gorantz edo 7. geruzatik beherantz, sintomen arabera.
Behetik gora (Layer 1 → Geruza 7)
Noiz erabili:
Goi-beherako hurbilketa (Layer 7 → Geruza 1)
Noiz erabili:
Hasi 7. geruzan ( SharePoint zerbitzua martxan dago? DNSa IPa zuzentzeko?) eta behar izanez gero bakarrik lan egiten du.
Erabaki-zuhaitza: 1., 2. edo 3. geruza da?
Erabili diagnostiko azkarreko zuhaitz hau zein geruzak huts egiten duen identifikatzeko:
Isolamenduaren teknikak
Erro-kausaz hipotesi bat duzunean, erabili isolamendu-teknika hauek baieztatzeko edo baztertzeko:
1. Ordeztu osagaiak modu sistematikoan
- Trukatu adabaki kablea kable ezagunarekin
- Probatu konmutadorearen ataka desberdinetan
- Saiatu NIC desberdinekin (edo USB sareko moldagailua)
- Bezeroaren gailu ezberdinen proba
- Mugitu beste VLAN/subnet batera
2. Enbalaje-kapturak hainbat puntutan
Hartu trafikoa iturburuan, bitarteko puntuetan eta helburuan paketeak non erortzen edo aldatzen diren identifikatzeko:
# 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. Begizta-probak
Kanpoko aldagaiak ezabatu gailu bakarrean konektibitatea probatzean:
# 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
Oinarri-lerro ezaguneko konparazioak
Konparatu konfigurazioa eta portaera lan-sistema baten aurka:
# 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")
Dokumentazioa arazoen konponketan
Dokumentazio egokiak arazketa zirkularra saihesten du, non gauza bera behin eta berriz egiten duzun konturatu gabe.
Txantiloiak konpontzen
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
Mundu errealeko azterketak
1. kasua: "sarea motela da" (Egia esan, TCP leihoen hedapena)
Symptom
Datu-basearen aplikazioen erantzun-denborak <100m-tik 5+ segundora degradatu dira. Aplikazio-taldeak "sareko latentzia" egotzi zuen.
Hasierako Jasokundeak (Wrong)
- Sareko pilaketa
- WAN esteka saturatua
- Firewall botilak
Diagnostiko-prozesua
- Ping proba:
- Bandwidth proba (iperf):
- Pakete-harrapaketa:
- Zerbitzariaren ikuskapena:
Kausa nagusia
Datu-base zerbitzariko bufferrak txikiegiak ziren banda zabaleko x atzerapeneko produkturako. TCP leihoak bete egiten zuen, bidaltzailea itxarotera behartuz.
Bereizmena
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Ikasitakoa
Ez pentsatu:
2. kasua: behin-behineko konektibitatea (Actualki: Duplex Mismatch)
Symptom
Zerbitzariaren konexioa ausaz eroriko litzateke, batez ere kargapean. Batzuetan ondo funtzionatzen zuen, batzuetan erabat erantzun gabe.
Initial Assumptions (Wrong)
- NIC huts egitea
- Kable txarra
- Aldatu hardwarearen arazoa
Diagnostic Process
- Interfazearen ikuskapena:
- Errore-mahaiak:
- Talkak:
Root Cause
Auto-egotziak huts egin du. Zerbitzariak full-duplex negoziatu zuen, eta etengailua erdi-duplexera itzuli zen. Kolisioak kargapean bakarrik gertatu ziren bi aldeak aldi berean transmititzen saiatu zirenean.
Resolution
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Lesson Learned
Egiaztatu bi muturrak:
3. kasua: "Ezin da zenbait webgunetara iritsi" (Egia esan: MTU/PMTUD Zulo beltza)
Symptom
Erabiltzaileek webgune batzuk arakatu ditzakete (Google, Yahoo) baina ez beste batzuk (bankuaren webgunea, enpresaren ataria). HTTP eskaera txikiek funtzionatu zuten, orrialde handiak denbora galdu zuten.
Initial Assumptions (Wrong)
- DNS arazoa
- Suebaki guneak blokeatzen
- ISP bideratze-arazoa
Diagnostic Process
- DNS ebazpena:
- Ping proba:
- HTTP eskaera txikia (curl):
- Deskarga handia:
-
MTU proba:
ping -M do -s 1472ping -M do -s 1473 - ICMP monitorizazioa:
Root Cause
VPN tunelak MTU 1400era murriztu zuen, baina suebakiak ICMP "Fragmentazioa behar zen" mezuak blokeatzen zituen. Path MTU Discovery-k (PMTUD) ezin zuen funtzionatu, MTU zulo beltz bat sortuz. Pakete txikiak ondo egokitzen dira, DF bit-multzoko pakete handiak isilean erortzen ziren.
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
Tamainak garrantzia du:
4. kasua: VoIP-ren kalitatearen gaiak (benetan: QoS deskonfigurazioa)
Symptom
Ahots-deiek audio atsegina zuten, noizbehinkako tantak. Negozio-orduetan bakarrik gertatu zen (9am-5pm).
Initial Assumptions (Wrong)
- Ez dago nahikoa banda-zabalera
- VoIP zerbitzaria gainkargatuta
- ISP konexioaren kalitatea
Diagnostic Process
- Bandwidth proba:
- QoS ikuskapena:
- Kontsultaren ikuskapena:
- Pakete-harrapaketa:
Root Cause
QoS politika bazegoen, baina banda-zabalerak atzera egin zuen: defentsarik onenak %60 lortu zuen, ahotsak %5 lortu zuen. Negozio-orduetan, datuen trafikoa handitu zenean, ahots-paketeak jaitsi egin ziren ilara gainezka zegoelako.
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
Denboran oinarritutako gaiak = ahalmena:
Komandoaren erreferentzia Symptom-en
| Symptom | Geruza | Exekutatu beharreko aginduak | Zer bilatu |
|---|---|---|---|
| Ez dago esteka argirik | 1. geruza | show interfaces |
Egoera: behera, garraiatzailerik gabe, kablea deskonektatu gabe |
| Packet-a galtzea | 1/2 geruza | show interfaces |
CRC erroreak, runtak, erraldoiak, talkak, azken talkak |
| Ezin da atebidea pingatu | 2. geruza | arp -a |
ARP sarrerarik ez, MAC ez da ikasi, STP blokeatzen |
| Ezin da urruneko azpisarera iritsi | 3. geruza | traceroute |
Ibilbidea falta da, oker hurrengoa, begiztan |
| Konexioa ukatuta | 4 | telnet host port |
Zerbitzua ez da entzuten, suebaki blokea, TCP RST |
| Errendimendu motela | 4+ geruza | ping (RTT) |
Latentzia altua, banda-zabaleraren muga, TCP berrerospenak, zero leiho |
| Ezin da ostalari-izena ebatzi | 7. geruza | nslookup |
DNS zerbitzaria atziezina, okerreko DNS konfigurazioa, NXDOMAIN |
| Tarteko tantak | Layer 1/2 | ping -f (flood) |
Duplex ez dator bat, huts egiten duen kablearekin, STP erreconvergence |
| Batzuetan funtzionatzen du, beste batzuetan ez. | Hainbat | Extended ping |
Karga orekatzeko arazoa, ECMP asimetria, egoera taula gainezka |
Noiz ihes egin
Jakin ezazu noiz igo TAC saltzailearengana edo ingeniari nagusiengana. Ihes egin:
- Zure ezagutza-oinarrian zailtasun-maila guztiak agortu dituzu.
- Kontuak sarbidea eta baimenak behar ditu.
- Arazoa saltzailearen software-akatsa edo hardware-akatsa da
- Negozioaren eragina larria da eta denbora-sentsiboa
- Hainbat taldek kolaboratu behar dute (aplikazioa + sarea + zerbitzaria)
- Sintomaren deskribapen osoa
- Arazoa noiz hasi zen
- Komando diagnostikoak exekutatzen dira eta irteera
- Konfigurazio-kopiak
- Packet-en kapturak (hala badagokio)
- Dagoeneko probatu duzuna
Zure ezagutza pertsonalaren oinarria eraikitzea
Arazoak konpontzeko saio bakoitza ikasteko aukera bat da. Eraiki ezagutza-oinarri pertsonal bat:
1. Arazoak konpontzeko egunkaria sortu
# 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.Eraiki Cheat Sheet komandoa
Antolatu maiz erabiltzen diren komandoak agertokiaren arabera erreferentzia azkarra lortzeko arazoak konpontzeko garaian.
Dokumentuak zure sarea
- Topologia-diagramak (2. eta 3. geruza)
- IP helbide-eskemaren dokumentazioa
- VLANen zereginak
- Konfigurazio estandarrak (templates)
- Oinarri-lerro ezagunak (interface estatistikak arazoen aurretik)
Anti-Pattern arruntak saihesteko
Ez egin ausazko aldaketak diagnostikorik gabe
Arazoak ulertu gabe konfigurazioak aldatzeak gauzak okertzen edo benetako arazoa ezkutatzen du.
the Don't: Demagun sarea beti erruduna dela.
Sarritan "sareko arazoak" aplikazio, zerbitzari edo bezeroaren arazoak dira. Bildu frogak errua onartu aurretik.
Don't: Saihestu zure urratsak dokumentatzea
Denbora galduko duzu egin dituzun probak errepikatuz, edo ezin diezu lankideei azaldu zer egin duzun.
Don't: ezikusi egin aldizkako arazoei
Behin-behineko arazoak, askotan, hutsegite larriaren abisu goiztiarrak dira. Ikertu kritiko bihurtu aurretik.
Don't: sintomak konpondu erro-kausa ordez
Gailu bat birbootatzeak zerbitzua berreskura dezake, baina ez baduzu ulertzen zergatik behar duen berriro berrabiarazi, arazoa berriro gertatuko da.
Laburpena: Arazo sistematikoak konpontzeko zerrenda
✓ Hasi aurretik
- Erantzun funtsezko bost galderei (Zer aldatu da? Nori eragin dio? Konstantea ala aldizkakoa? Erantzungarria? Zer ikusten du beste aldeak?)
- Bildu hasierako sintomak eta erabiltzailearen txostenak
- Begiratu azken aldaketak edo mantentze-lanak
✓ Arazoak konpontzeko garaian
- Metodoz lan egin OSI geruzen bidez (behean edo goitik behera)
- Aldatu aldagai bat aldi berean probak egitean
- Proba bakoitza eta emaitza
- Erabili paketeen harrapaketak trafiko-portaera erreala ikusteko
- Konparatu oinarri-lerro ezagunekin
✓ Erabakiaren ondoren
- Egiaztatu konponketak arazoa konpondu duela
- Dokumentuaren erroko kausa eta bereizmena
- Eguneratu zure ezagutza-oinarria
- Konfigurazioa aldatu bada, eguneratu dokumentazioa
- Kontuan izan: monitorizazioak lehenago harrapatu ote zuen?
Ondorioa
Sareko arazoak zientzia eta artea dira. Zientziak metodologia sistematikoa jarraitzen du, diagnostiko-tresnak eta ulermen-protokoloak erabiliz. Arteak badaki zein proba egin behar diren lehenik sintometan oinarrituta, esperientziaren ereduak ezagutuz eta noiz eskalatu jakinez.
Artikulu honetan azaldutako ikuspegi sistematikoari jarraituz, galdera egokiak eginez, OSI ereduaren bidez metodikoki lan eginez, zure urratsak dokumentatuz eta gai bakoitzetik ikasiz, eraginkorragoa bihurtuko zara arazoak konpontzeko eta denbora alferrik galtzen duten eta konponketa okerrak saihesten dituzten ohiko zuloak saihesteko.
Gogoratu:
Azken eguneraketa: otsailak 2, 2026 | Egilea: Baud9600 Talde teknikoa