Network Troubleshooting Methodology: Sistematik Yaklaşım

Metodoloji Nedenleri

Sorun:

Çözüm:

Haphazard'ın Maliyeti:

Giriş: Networking Networking için Uygulanan Bilimsel Yöntem

Ağ sorunları temel olarak bilimsel yöntemde bir egzersizdir:

Observe
Form a hipotez
hipotez test edin
Analyze sonuçları
Bir düzeltme
Verify

Bu makale, ortak tuzakları önlemek için yapılandırılmış bir çerçeve sağlar:

Onay önyargı (yalnızca ilk tahmininizi destekleyen kanıtlar için)
Tanı olmadan rastgele değişiklikler (aspray ve dua)
Kök yerine semptomları düzeltin nedenleri
Geometrik debugging, neyin denendiğini belgelemeden

Beş Anahtar Soru

Teknik tanıya girmeden önce, bu beş kritik soruyu soruşturma kapsamınızı daraltmak için cevaplayın:

Soru 1: Son zamanlarda ne değişti?

Check change management logs
Son zamanlarda yapılandırma yönetim sistemlerinde taahhütler
Soru: " dün çalışıyor mu?"

Soru 2: Kim Etkiliyor?

Bir cihaz: Yerel bir sorun gibi (NIC, kablo, konfigürasyon)
One subnet: Gateway, DHCP veya sorun
Herkes: Core altyapı, ISS veya yaygın konu
Özel uygulama: Uygulama sunucusu, güvenlik kuralı veya DNS

↓

Soru 3: Sürekli mi yoksa Intermittent mi?

Constant: Constant: Sert başarısızlık (muhtemelen kesti, yanlış yapılandırma, aşağı hizmet)
Zaman tabanlı: İş saatlerinde kesinti, planlanan süreçler
Intermittent/Random: Duplex yanlış ki, başarısız donanım, aralıklı bağlantı

↓

Soru 4: Bunu yeniden ortaya çıkarabilir misiniz?

Evet: Tanık için çok daha kolay ( hipotezleri test edebilir)
Hayır: İzleme/logging kurmak ve recurrence için beklemek

↓

Soru 5: Diğer Side Ne Görüyor?

Müşteri perspektifi vs. sunucu perspektifi
Packet kaynağında yakalama vs. destinasyon
Asymmetric routing? vs. göndermek için farklı yollar?

OSI Model tabanlı Teşhis Yaklaşımı

OSI modeli sorun giderme için yapılandırılmış bir çerçeve sağlar. Katman 1 (Physical) yukarı veya Katman 7 (Uygulama) aşağı, semptomlara bağlı olarak.

Sub-Up Yaklaşımı (Layer 1 → Katman 7)

Ne zaman kullanılır:

Katman 1: Fiziksel

↓

Katman 2: Data Link

↓

Katman 3: Network

↓

Katman 4: Transport

↓

Katman 5-7: Oturum/Örnek/Uygulama /

Top-Down Approach (Layer 7 → Katman 1)

Ne zaman kullanılır:

Örnek: Örnek:

Katman 7'de başlayın ( SharePoint servisi çalışıyor mu? DNS IP'yi düzeltmeye karar verir mi?) ve sadece gerekirse çalışır.

Karar Ağacı: 1., 2 veya 3 mı?

Hangi katmanın başarısız olduğunu tanımlamak için bu hızlı tanı ağacı kullanın:

Yerelhost (127.0.0.1) yapabilir misiniz?

Problem: İşletim Sistemi / Yazılım Problemi

YES EVET

Kendi IP adresinizi geçebilir misiniz?

↓ NO

Problem: Katman 1/2 - Local Network Interface

↓ YES

Varsayılan ağ geçidi kurabilir misiniz?

↓ NO

Problem: Katman 1/2 - Yerel Ağ

↓ YES

IP adresi tarafından uzaktan evlenebilir misiniz?

↓ NO

Problem: Katman 3 - Routing

↓ YES

DNS'i çözebilir misiniz (görüp hostname)?

↓ NO

Sorun: DNS Yapılandırma

↓ YES

Uygulama portuna ulaşabilir misiniz (telnet host port)?

↓ NO

Problem: Güvenlik / Port Bloking

↓ YES

Ağ Tamam - Uygulama Katmanı Sorun

Isolation Techniques

Kök nedeni hakkında bir hipotez olduğunda, bu izolasyon tekniklerini doğrulamak veya reddetmek için kullanın:

1. Bileşenler Sistemini Değiştirin

İpucu:

Swap patch kablo bilinen iyi kablo
Farklı geçiş limanında Test
Farklı NIC (veya USB ağ adaptörü) deneyin
Farklı müşteri cihazından test
Farklı VLAN /subnet

2. Packet Birden Çok Noktada Yakalanıyor

Kaynakta trafik yakalama, orta noktalar ve paketlerin nereye düştüğünü veya değiştirildiğini tespit etmek için varış noktası:

# 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. döngü testi

Tek bir cihaz içinde bağlantı kurarak dış değişkenleri ortadan kaldırın:

# 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. Bilinen İyi Basel Karşılaştırmaları

Bir çalışma sistemine karşı yapılandırma ve davranışlarla karşılaştırın:

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

Tartışma sırasında

Proper belgeleri, farkında olmadan aynı şeyi birden çok kez denemenizi engeller.

Troubleshooting Template

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

Neden Dokümantasyon Maddeleri:

Gerçek Dünya Vaka Çalışmaları

Vaka Çalışması 1: "The Network is Slow" (Aslında: TCP Pencere Emisyon)

Symptom

Veritabanı başvuru yanıt süreleri <100ms'tan 5+ saniyeye kadar yükseltilir. Uygulama ekibi "network latency" suçladı.

İlk Varsayımlar (Wrong)

Network congestion
WAN bağlantısı
Güvenlik Duvarı

Tanı Süreci

Ping testi:
Band genişlik testi (iperf):
Packet yakalama:
Server denetimi:

Kök Sebep

Veritabanı sunucusu OS tamponları yüksek bant genişliği × gecikme ürünü için çok küçüktü. TCP penceresi dolduracak, beklemeye zorlayacak.

Karar

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

Lesson Learned

İnanmayın:

Vaka Çalışması 2: Intermittent Connectivity (Aslında: Duplex Mismatch)

Symptom

Server bağlantısı rastgele düşebilir, özellikle yük altında. Bazen iyi çalıştı, bazen tamamen sorumlu.

Initial Assumptions (Wrong)

Başarısızlık
Bad kablo
Donanım sorunu

Diagnostic Process

Interface inceleme:
Hata sayacı:
Geç çarpışmalar:

Root Cause

Auto-negotiation başarısız oldu. Server tam çözünürlükle pazarlık etti, geçiş yarı karışıklığa geri döndü. Collisions sadece her iki tarafın da aynı anda iletmeye çalıştığı zaman yük altında gerçekleşti.

Resolution

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

Lesson Learned

Her ikisini de kontrol edin:

Vaka Çalışması 3: "Bazı Web Sitelerine Uyamazsın" (Aslında: MTU/PMTUD Black Hole)

Symptom

Kullanıcılar bazı web siteleri (Google, Yahoo) arayabilir, ancak diğerleri değil (bank web sitesi, şirket portal). Küçük HTTP istekleri işe yaradı, büyük sayfalar zamanlandı.

Initial Assumptions (Wrong)

DNS konusu
Güvenlik belirli siteleri engelleme
ISS routing problem

Diagnostic Process

DNS kararı:
Ping testi:
Küçük HTTP isteği (curl):
Büyük indirme:
MTU testi:ping -M do -s 1472ping -M do -s 1473
ICMP izleme:

Root Cause

VPN tüneli MTU'yu 1400'e düşürdü, ancak güvenlik duvarı ICMP "Fragmentation Needed" mesajlarını engelliyordu. Yol MTU Discovery (PMTUD) çalışamadı, bir MTU kara delik yaratarak. Küçük paketler uygun, DF bit seti ile büyük paketler sessizce düştü.

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

Boyut önemlidir:

Vaka Çalışması 4: VoIP Kalite Sorunları (Aslında: QoS Yanlış Yapılama)

Symptom

Ses aramaları doygun ses, aralıklı damlalar vardı. Sadece iş saatlerinde (9am-5pm).

Initial Assumptions (Wrong)

Yetersiz bant genişliği
VoIP server aşırı yükleme
ISS bağlantı kalitesi

Diagnostic Process

Band genişliği testi:
QoS denetim:
Queue inceleme:
Packet yakalama:

Root Cause

QoS politikası vardı ama bant genişliği geri döndü: en iyi şans% 60 oldu, ses% 5 aldı. Veri trafiği arttıkça, ses paketleri kuyruk aşırı akışı nedeniyle düştü.

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

Zaman temelli konular = kapasite:

Symptom

Symptom	Katman	Komutanlar	What to Look For
Hiçbir bağlantı ışığı yok	Katman 1	`show interfaces ethtool eth0`	Durum: aşağı, taşıyıcı, kablo açmadı
Packet kaybı	Katman 1/2	`show interfaces show interfaces counters errors`	CRC hataları, runts, devs, çarpışmalar, geç çarpışmalar
Ağ geçidi kaldıramaz	Katman 2	`arp -a show mac address-table show spanning-tree`	No ARP girişi, MAC öğrenilmedi, STP engelleme
Uzak subnet'e ulaşamaz	Katman 3	`traceroute show ip route show ip route summary`	Eksik rota, bir sonraki-hop, routing döngü
Bağlantı reddedildi	Katman 4	`telnet host port netstat -an tcpdump`	Dinlenme, Güvenlik Bloku, TCP RST
Yavaş performans	Katman 4+	`ping (RTT) iperf3 tcpdump show interfaces`	Yüksek gecikme, bant genişliği limiti, TCP retransmissions, zero windows
hostnameyi çözemez	7.	`nslookup dig cat /etc/resolv.conf`	DNS sunucusu ulaşılamaz, yanlış DNS yapılandırılır, NXDOMAIN
Intermittent drop	Layer 1/2	`ping -f (flood) show logging show interfaces`	Duplex yanlış ki, başarısız kablo, STP reconvergence
Bazen, başkaları değil	Birden çok	`Extended ping Packet capture Interface statistics`	Yük dengeleme sorunu, ECMP asymmetry, state table overflow

When to Escalate

TAC veya üst düzey mühendislere ne zaman yükseleceğini bilin. Ne zaman Açıklama:

Bilgi tabanınızda tüm sorun giderme adımlarını tükenmişsiniz
Sorun, sahip olmadığınız erişim/permissions gerektirir
Problem, satıcı yazılımı bug veya donanım kusurunu içerir
İş etkisi kritik ve zamana duyarlı
Birden çok takım işbirliğine ihtiyaç duyar (örneğin + ağ + sunucu)

Dinalating önce:

Tamamlanan semptom Açıklama
Sorun başladığında zaman zaman çizelgesi başladı
Tanı komutları çalışır ve çıktıları
Kurulum yedeklemeleri
Packet yakalamalar (eğer ilgiliyse)
Zaten denediniz şey

Kişisel bilgilerinizi Yapın

Her sorun oturumu bir öğrenme fırsatıdır. Kişisel bir bilgi tabanı oluşturun:

1. Problemshooting Journal oluşturun

# 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. Bir Komut Hile Belgesi oluşturun

Sık sık kullanılan komutlar, sorun sırasında hızlı referans için senaryo tarafından gerçekleştirilir.

3. Network Your Network

Topoloji diyagramları (Layer 2 ve Katman 3)
IP adresi plan belgeleri
VLAN atamaları
Standart konfigürasyonlar (geçerler)
Bilinen iyi temel hatları ( sorunlardan önce yüz istatistikler)

Common Anti-Patterns to avoid

❌ DON'T: Tanınmadan rastgele değişiklikler yapın

Problemi anlamadan değişen konfigürasyonlar genellikle şeylerin gerçek sorunu daha kötü veya maskeler yapar.

the DON'T: Ağ her zaman hatada olduğu gibi

Genellikle "network issues" uygulama, sunucu veya müşteri odaklı sorunlardır. Suç kabul etmeden önce yapılan kanıtlar.

ON DON'T: Problemleme adımlarınızı belgeleyin

Zaten yaptığınız testleri tekrarlayarak zaman harcayacaksınız ya da denemediğiniz meslektaşları açıklayamaz.

I DON'T: Ignore Intermittent issues

Intermittent problemleri genellikle erken uyarı başarısızlık belirtileridir. Onlara eleştirel hale gelmeden önce yatırım yaparlar.

❌ DON'T: Kök yerine belirtileri düzeltin

Bir cihazın yeniden yüklenmesi hizmeti geri alabilir, ancak NEDEN'yi yeniden başlatmanız için bulamazsanız, sorun tekrarlanır.

Özet: Sistematik Sorun Giderme Checklist

Başlamadan önce

Beş anahtar soruyu cevaplayın (What changed? Kim etkilendi? Sürekli veya aralıklı? Reproducible? Diğer taraf ne görüyor?)
İlk semptomlar ve kullanıcı raporları
Son değişiklikler veya bakım için kontrol

Tartışma sırasında

OSI katmanları aracılığıyla iş yöntemiyle (altın veya üst düzey)
Test yaparken bir seferde ONE değişkeni değiştirin
Her test ve sonucu
Gerçek trafik davranışını görmek için paket yakalamaları kullanın
Bilinen iyi üs hatlarına karşı Karşılaştırma

✓ After Decision

Çözüm aslında sorunu çözdü
Doküman kök nedeni ve çözümü
Bilgi tabanınızı Güncelleme
Eğer yapılandırma değiştiyse, güncelleştirme belgeleri
Dikkat: Bunu daha önce yakalayabilecek mi?

Sonuç Sonuç Sonuç Sonuç

Network sorun giderme hem bilim hem de sanattır. Bilim sistematik bir metodoloji takip ediyor, teşhis araçları doğru şekilde kullanıyor ve protokolleri anlamak. Sanat, ilk önce semptomlara dayanan hangi testleri bilmek, deneyimlerden desenleri tanımak ve ne zaman yükseleceğini bilmektir.

Bu makalede belirtilen sistematik yaklaşımı takip ederek - doğru soruları, çalışma yöntemiyle OSI modeline dayanarak, adımlarınızı belgeleyerek ve her konuda bilgi sahibi olursunuz - zaman ve yanlış düzeltmelere yol açan ortak tuzaklardan daha verimli hale gelirsiniz.

Unutmayın:

Son Güncelleme: 2 Şubat 2026 | Yazar: Baud9600 Teknik Ekip