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:

  1. Begiratu
  2. Sortu hipotesi bat
  3. Proba ezazu hipotesia
  4. Emaitzak aztertzea
  5. Ezarri konponketa bat
  6. Egiaztatu

Artikulu honek sare-arazoak konpontzeko marko egituratua dauka, arazo arruntak saihesten dituena:

Bost galdera nagusiak

Diagnostiko teknikoetan murgildu aurretik, erantzun bost galdera kritiko horiei ikerketa-esparrua estutzeko:

Galdera: Zer aldatu da orain dela gutxi?
  • Egiaztatu aldaketak kudeatzeko erregistroak
  • Berrikuspen berria konfigurazio-kudeaketako sistemetan
  • Galdetu: "Atzo funtzionatu al zuen?"
2. galdera: Nori eragiten dio?
  • 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
↓
3. galdera: Konstantea ala tartekoa da?
  • 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
↓
4. galdera: Berrida dezakezu?
  • Bai: Errazagoa da diagnostikatzea (suposizioak froga ditzake)
  • Ez: Konfiguratu monitorizazioa/saioa eta itxaron errepikatzeari
↓
5. galdera: Zer ikusten du beste aldeak?
  • 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:

1. geruza: fisikoa
↓
2. geruza: datuen esteka
↓
3. geruza: sarea
↓
4. geruza: garraioa
↓
5-7 geruza: saioa/aurkezpena/Aplikazioa

Goi-beherako hurbilketa (Layer 7 → Geruza 1)

Noiz erabili:

Adibidea:

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:

Bertako ostalariaren ping-a egin dezakezu (127.0.1)?
Ez
Arazoa: Sistema eragilea / Softwarearen gaia
Bai
Zure IP helbidea jar dezakezu?
↓ NO
Arazoa: 1/2 geruza - Sare lokaleko interfazea
↓ YES
Atebide lehenetsia ping dezakezu?
↓ NO
Arazoa: 1/2 geruza - Sare lokala
↓ YES
Urruneko ostalaria ping egin dezakezu IP helbide bidez?
↓ NO
Arazoa: 3. geruza - Bideraketa
↓ YES
DNSa konpon dezakezu (ez bilatu ostalari-izena)?
↓ NO
Arazoa: DNS konfigurazioa
↓ YES
Aplikazio-portura iritsi zaitezke (telneteko ataka)?
↓ NO
Arazoa: Firewall / Port Blocking
↓ YES
Sarea ongi dago - Aplikazio-geruzaren gaia

Isolamenduaren teknikak

Erro-kausaz hipotesi bat duzunean, erabili isolamendu-teknika hauek baieztatzeko edo baztertzeko:

1. Ordeztu osagaiak modu sistematikoan

Aholkua:

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
Dokumentazioa zertarako den:

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)

Diagnostiko-prozesua

  1. Ping proba:
  2. Bandwidth proba (iperf):
  3. Pakete-harrapaketa:
  4. 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)

Diagnostic Process

  1. Interfazearen ikuskapena:
  2. Errore-mahaiak:
  3. 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)

Diagnostic Process

  1. DNS ebazpena:
  2. Ping proba:
  3. HTTP eskaera txikia (curl):
  4. Deskarga handia:
  5. MTU proba:ping -M do -s 1472ping -M do -s 1473
  6. 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)

Diagnostic Process

  1. Bandwidth proba:
  2. QoS ikuskapena:
  3. Kontsultaren ikuskapena:
  4. 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
ethtool eth0		 Egoera: behera, garraiatzailerik gabe, kablea deskonektatu gabe
Packet-a galtzea 1/2 geruza show interfaces
show interfaces counters errors		 CRC erroreak, runtak, erraldoiak, talkak, azken talkak
Ezin da atebidea pingatu 2. geruza arp -a
show mac address-table
show spanning-tree		 ARP sarrerarik ez, MAC ez da ikasi, STP blokeatzen
Ezin da urruneko azpisarera iritsi 3. geruza traceroute
show ip route
show ip route summary		 Ibilbidea falta da, oker hurrengoa, begiztan
Konexioa ukatuta 4 telnet host port
netstat -an
tcpdump		 Zerbitzua ez da entzuten, suebaki blokea, TCP RST
Errendimendu motela 4+ geruza ping (RTT)
iperf3
tcpdump
show interfaces		 Latentzia altua, banda-zabaleraren muga, TCP berrerospenak, zero leiho
Ezin da ostalari-izena ebatzi 7. geruza nslookup
dig
cat /etc/resolv.conf		 DNS zerbitzaria atziezina, okerreko DNS konfigurazioa, NXDOMAIN
Tarteko tantak Layer 1/2 ping -f (flood)
show logging
show interfaces		 Duplex ez dator bat, huts egiten duen kablearekin, STP erreconvergence
Batzuetan funtzionatzen du, beste batzuetan ez. Hainbat Extended ping
Packet capture
Interface statistics		 Karga orekatzeko arazoa, ECMP asimetria, egoera taula gainezka

Noiz ihes egin

Jakin ezazu noiz igo TAC saltzailearengana edo ingeniari nagusiengana. Ihes egin:

Ihes egin aurretik:

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

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

✓ Arazoak konpontzeko garaian

✓ Erabakiaren ondoren

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