Intermittent Bağlantı Sorunları: Aralıklı Kesinti Analizi ve Çözüm Yöntemleri

Ağ sorunlarının en sinir bozucu türü hangisidir diye sorsan, neredeyse her sysadmin aynı cevabı verir: aralıklı bağlantı sorunları. Sürekli olan bir kesinti en azından rahat bir şekilde reproduce edilebilir, analiz edilebilir, çözülebilir. Ama bazen olan, bazen olmayan bir sorun? İşte bu tam anlamıyla kabus. Kullanıcı gelir şikayet eder, sen bakarsın her şey normal görünür, kullanıcı masasına döner, sorun tekrarlar. Bu döngü saatler, bazen günler sürebilir. Bu yazıda intermittent bağlantı sorunlarını sistematik bir şekilde nasıl analiz edeceğini, hangi araçları kullanacağını ve gerçek dünya senaryolarından öğrenilen dersleri paylaşacağım.

Intermittent Sorunların Doğası

Aralıklı sorunlar genellikle şu kategorilerden birine girer: fiziksel katman problemleri (kablo, SFP modül, switch portu), ağ protokol sorunları (spanning tree, ARP, yönlendirme), kaynak tüketimi (CPU, memory, bant genişliği spike’ları) ve uygulama katmanı sorunları (connection timeout, keep-alive ayarları).

Sorunun aralıklı olması çoğunlukla şunu işaret eder: bir eşik değeri var ve bu eşik zaman zaman aşılıyor. Ya da bir zamanlama çakışması söz konusu. Bu perspektiften bakınca işin aslında mantıklı bir çözümü olduğunu görürsün. Ama önce doğru veriyi toplamak lazım.

Altın kural: Sorun yaşanırken değil, sorun yaşanmadan önce monitoring başlatmak gerekir. Çünkü sorun anlık yaşanır, iz bırakır ve geçer. Sen sonradan gelip “ne oldu acaba” diye bakarsın ama veri yoksa hiçbir şey bulamazsın.

Temel Tanı Araçları

ping ile Sürekli İzleme

En basit ama en değerli araçlardan biri. Sürekli çalışan bir ping ile paket kayıplarını ve RTT değişimlerini izleyebilirsin.

# Zaman damgasıyla birlikte ping - sorun anını kaydetmek için
ping -i 0.5 -W 2 192.168.1.1 | while read line; do
    echo "$(date '+%Y-%m-%d %H:%M:%S') $line"
done | tee /var/log/ping_monitor.log

# Sadece kayıpları ve yüksek RTT'leri filtrele
ping -i 1 10.0.0.1 | grep -E "(timeout|time=[0-9]{3,})" | 
    while read line; do echo "$(date) $line"; done

Bu komutu bir screen veya tmux oturumunda arka planda çalıştır. Sorun yaşandığında log dosyasına bakarak tam zamanı tespit edebilirsin.

mtr ile Hop-by-Hop Analiz

mtr, traceroute ve ping’in birleşimi gibidir. Her hop’taki paket kaybını ve gecikmeyi gerçek zamanlı gösterir.

# 100 paket gönderip rapor al, TCP mode (firewall bypass için)
mtr --report --report-cycles 100 --tcp --port 443 8.8.8.8

# JSON çıktısı al, otomatik parse etmek için
mtr --report --report-cycles 60 --json 10.0.0.1 > /tmp/mtr_report.json

# Belirli aralıklarla mtr raporu al ve logla
while true; do
    echo "=== $(date) ===" >> /var/log/mtr_analysis.log
    mtr --report --report-cycles 30 --no-dns 10.10.1.1 >> /var/log/mtr_analysis.log
    sleep 300
done

mtr çıktısında özellikle dikkat etmen gereken şey şu: Eğer bir hop’ta paket kaybı görüyorsun ama sonraki hop’larda kayıp yoksa, o hop muhtemelen ICMP rate limiting yapıyor ve gerçek bir sorun yok demektir. Ama kayıp bir hop’tan itibaren devam ediyorsa, problem orada başlıyor demektir.

tcpdump ile Paket Düzeyinde Analiz

Gerçek sorunun ne olduğunu anlamak için paket yakalamak şarttır.

# Belirli bir host ile olan trafiği yakala
tcpdump -i eth0 -w /tmp/capture.pcap host 10.0.0.1 &

# TCP RST paketlerini izle - ani kapanmaların göstergesi
tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0' -n

# Retransmission'ları yakala (TCP sorunları için)
tcpdump -i any -w /tmp/full_capture.pcap -C 100 -W 10 &
# -C 100: Her dosya 100MB olsun
# -W 10: Toplam 10 dosya tut, sonra döngüsel yaz

# ICMP unreachable mesajlarını izle
tcpdump -i eth0 'icmp and (icmp[icmptype] = icmp-unreach)'

Yakalanan pcap dosyasını Wireshark’ta açtığında, Statistics > TCP Stream Graphs > Time-Sequence Graph ile TCP sorunlarını görselleştirebilirsin. Retransmission’lar ve window size sıfırlanmaları burada çok net görünür.

Sistem Kaynaklarının Sorunla İlişkisini İnceleme

Network Interface İstatistikleri

Aralıklı sorunların önemli bir kısmı aslında NIC veya driver seviyesinde yaşanır. Kernel sayaçlarına bakmak lazım.

# Detaylı interface istatistikleri
ip -s -s link show eth0

# ethtool ile driver istatistikleri - dropped, missed, overflow sayaçları
ethtool -S eth0 | grep -E "(drop|miss|over|error|fail)"

# Sürekli izleme için watch ile kullan
watch -n 2 'ethtool -S eth0 | grep -E "(drop|miss|over|error)"'

# /proc/net/dev üzerinden de bakabilirsin
cat /proc/net/dev

# Receive buffer overflow'ları kontrol et
netstat -su | grep -E "(error|overflow|failed)"

Gerçek bir senaryodan bahsedeyim: Bir e-ticaret firmasında sabah saatlerinde 5-10 dakika süren yavaşlamalar yaşanıyordu. Herkes uygulama sunucusuna bakıyordu. Ben ethtool -S çıktısına baktım ve rx_missed_errors sayacının her gün belirli saatte artış kaydettiğini gördüm. Sorun NIC ring buffer’ının yetersizliğiydi. Şirket sabah vardiya geçişinde toplu veri senkronizasyonu yapıyordu ve bu ani trafik spike’ı buffer overflow’a yol açıyordu.

# Ring buffer boyutunu artırmak için
ethtool -G eth0 rx 4096 tx 4096

# Kalıcı hale getirmek için /etc/udev/rules.d/ altına kural ekle
echo 'ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth0", 
RUN+="/sbin/ethtool -G eth0 rx 4096 tx 4096"' 
> /etc/udev/rules.d/99-network-tuning.rules

ss ve netstat ile Soket Durumu Analizi

Bağlantı durumlarını izlemek, sorunun tam olarak nerede yaşandığını gösterir.

# TIME_WAIT ve CLOSE_WAIT yığılmalarını izle
ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn

# Belirli bir porta olan bağlantıları izle
watch -n 1 'ss -tn dst 10.0.0.1:5432 | wc -l'

# SYN_RECV durumundaki soketleri say - SYN flood veya backlog dolması
ss -tn state syn-recv | wc -l

# Retransmit olan bağlantıları göster
ss -ti | grep retrans

Eğer CLOSE_WAIT durumunda çok sayıda soket birikiyor ve sayı sürekli artıyorsa, uygulama soketleri düzgün kapatmıyor demektir. Bu da zamanla “bağlanamıyorum” şikayetlerine yol açar çünkü port tükenmesi yaşanır.

Zaman Bazlı Korelasyon Analizi

Aralıklı sorunların en önemli ipucu, sorunun ne zaman yaşandığıdır. Bir pattern yoksa bile, birkaç gün veri toplayınca mutlaka bir örüntü çıkar.

Cron Job ve Zamanlama Çakışmaları

Pratik olarak gördüğüm vakaların büyük çoğunluğunda sorun, planlı bir görevle örtüşüyordu. Backup başladığında, log rotate olduğunda, cron ile çalışan bir script ağa yük bindirdiğinde.

# Sistem genelindeki zamanlı görevleri listele
for user in $(cut -d: -f1 /etc/passwd); do
    crontab -l -u $user 2>/dev/null | grep -v '^#' | 
    grep -v '^$' | sed "s/^/$user: /"
done

# Systemd timer'ları kontrol et
systemctl list-timers --all

# Sorun anında hangi process'lerin ağ kullandığını logla
# Bu scripti crontab'a ekle, dakika başı çalıştır
#!/bin/bash
echo "=== $(date) ===" >> /var/log/net_consumers.log
ss -tnp | grep ESTABLISHED | 
    awk '{print $6}' | sort | uniq -c | sort -rn >> /var/log/net_consumers.log

sar ile Tarihsel Veri Analizi

sysstat paketinin bir parçası olan sar, geçmişe dönük sistem metriklerine bakmanı sağlar. Sorun yaşandıktan sonra “o saat ne oluyordu” sorusunu yanıtlayabilirsin.

# sysstat kurulu değilse
apt install sysstat  # Debian/Ubuntu
yum install sysstat  # RHEL/CentOS

# Ağ istatistiklerini geçmiş verilerle incele
sar -n DEV -f /var/log/sysstat/sa$(date +%d -d yesterday) | grep eth0

# Bugünün ağ verisi, 5 dakikalık aralıklarla
sar -n DEV 1 | grep eth0

# Paket drop istatistikleri
sar -n EDEV -f /var/log/sysstat/sa$(date +%d) | grep eth0

# Tam tarih aralığı ile
sar -n DEV -s 09:00:00 -e 11:00:00 -f /var/log/sysstat/sa15

Bir keresinde üretim ortamında her gece 02:15’te 3-4 dakika süren bağlantı sorunları yaşanıyordu. sar çıktısına baktım, o saatte network trafiği spike yapıyordu. Sonra crontab -l ile baktım, bir backup script’i 02:00’da başlıyordu. Backup tamamlandıktan sonra oluşan dosyalar başka bir sunucuya rsync ile gönderiliyordu. Rsync bant genişliğini limit koymadan kullanıyordu ve diğer tüm trafiği eziyor du. Çözüm basitti: --bwlimit=50000 ekledik.

Fiziksel Katman Sorunları

Switch Port ve Kablo Sorunları

Aralıklı sorunların sessiz katilleri genellikle fiziksel katmandadır. Bir kablo veya SFP modülü çoğunlukla çalışır ama zaman zaman sorun çıkarır.

# Fiziksel katman hataları için kernel log'ına bak
dmesg | grep -E "(eth0|ens|link|carrier|error)" | tail -50

# Sürekli izle
dmesg -w | grep -E "(link|carrier|NIC|error)"

# ethtool ile link durumu ve hız/duplex bilgisi
ethtool eth0

# Auto-negotiation sorunlarına dikkat et
# Mismatch genellikle aralıklı sorun yaratır
ethtool eth0 | grep -E "(Speed|Duplex|Auto)"

# Link down/up eventlerini syslog'da ara
grep -E "(link up|link down|Link is)" /var/log/syslog | tail -30
# veya RHEL/CentOS için
grep -E "(link up|link down|Link is)" /var/log/messages | tail -30

Eğer ethtool çıktısında speed 100Mb/Full görünmesi gereken bir bağlantı 10Mb/Half olarak görünüyorsa, auto-negotiation başarısız olmuş demektir. Bu klassik bir aralıklı sorun kaynağıdır: bağlantı kurulur, ama yavaş ve hatalı çalışır.

# Manuel hız ve duplex ayarla (geçici, test için)
ethtool -s eth0 speed 1000 duplex full autoneg off

# CRC hataları var mı kontrol et (kötü kablo işareti)
ethtool -S eth0 | grep -i crc
ip -s link show eth0 | grep -A1 "RX:"

ARP ve Layer 2 Sorunları

ARP Cache Sorunları

Özellikle VMware veya benzeri sanallaştırma ortamlarında, vMotion veya live migration sonrasında ARP cache sorunları yaşanır. Bir VM başka bir host’a taşınır ama eski MAC-IP eşlemesi cache’de kalır.

# ARP tablosunu incele
arp -n
ip neigh show

# Eski/stale ARP girdilerini bul
ip neigh show | grep STALE

# Belirli bir IP için ARP cache'i temizle
ip neigh del 10.0.0.1 dev eth0

# Tüm ARP cache'i temizle (dikkatli kullan!)
ip neigh flush all

# ARP trafiğini izle
tcpdump -i eth0 arp -n

# Gratuitous ARP gönder (IP sahipliğini yeniden duyur)
arping -c 3 -A -I eth0 192.168.1.100

Spanning Tree Sorunları

STP, özellikle büyük switch ortamlarında aralıklı sorunların klasik kaynağıdır. Topology change event’leri her host’un MAC adresini switch’in yeniden öğrenmesine neden olur ve bu sırada paket kaybı yaşanır.

# Kernel log'unda STP ile ilgili mesajları ara
dmesg | grep -i "topology|spanning|bridge"

# Bağlantı noktasında STP durumunu kontrol et (Linux bridge ise)
brctl showstp br0

# Switch tarafında (Cisco örneği, SSH ile bağlanıp çalıştır)
# show spanning-tree detail | include ieee|from|occur|is exec|ens|root
# show logging | include SPANTREE

# tcpdump ile STP BPDU'ları izle
tcpdump -i eth0 stp

DNS Kaynaklı Aralıklı Sorunlar

DNS sorunları çok sinsi bir şekilde intermittent bağlantı sorunu gibi görünür. Uygulama bağlanamadığını söyler ama aslında IP’yi resolve edemiyordur.

# DNS çözümleme sürelerini ölç
for i in {1..20}; do
    time host google.com 8.8.8.8 2>&1 | tail -1
    sleep 2
done

# DNS sorgu izleme - hangi server'a gidiyor, ne kadar sürüyor
dig +stats google.com

# Belirli bir DNS server'ı test et
dig @10.0.0.53 internal.domain.com +time=2 +tries=3

# Farklı DNS server'ları karşılaştır
for dns in 10.0.0.53 8.8.8.8 1.1.1.1; do
    echo -n "DNS $dns: "
    dig @$dns google.com | grep "Query time"
done

# /etc/resolv.conf içindeki timeout ayarları
# options timeout:2 attempts:3 rotate
# Bu ayarlar DNS failover davranışını belirler
cat /etc/resolv.conf

Gerçek bir vaka: Bir müşteri, sabah saatlerinde web uygulamasına erişimin zaman zaman çok yavaş olduğunu bildirdi. Her şeye baktık, web server sağlıklıydı, uygulama log’ları temizdi. Sonunda connection log’larından dikkatimi çeken bir şey fark ettim: bazı istekler tam olarak 5 saniye gecikerek geliyordu. 5 saniye çok spesifik bir değerdir, DNS timeout değeridir. /etc/resolv.conf dosyasına baktım: birincil DNS server ayarlıydı ama o server birkaç haftadır yanıt vermiyordu. Her istek önce ölü server’ı deneyip timeout’u bekliyordu, sonra ikincil server’a geçiyordu.

Otomatik İzleme Scripti

Tüm bu kontrolleri manuel yapmak yerine, sorun yaşandığında otomatik veri toplayan bir script hazırlamak mantıklıdır.

#!/bin/bash
# intermittent_monitor.sh
# Kullanım: ./intermittent_monitor.sh 10.0.0.1 5432

TARGET_IP=${1:-"8.8.8.8"}
TARGET_PORT=${2:-"80"}
LOG_DIR="/var/log/netmon"
THRESHOLD_MS=100  # RTT eşiği (ms)

mkdir -p $LOG_DIR

log() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') $1" | tee -a $LOG_DIR/monitor.log
}

capture_state() {
    local timestamp=$(date '+%Y%m%d_%H%M%S')
    local snapshot_file="$LOG_DIR/snapshot_${timestamp}.txt"

    echo "=== Network Snapshot: $(date) ===" > $snapshot_file
    echo "--- ARP Table ---" >> $snapshot_file
    ip neigh show >> $snapshot_file

    echo "--- Connection Stats ---" >> $snapshot_file
    ss -tan | awk '{print $1}' | sort | uniq -c >> $snapshot_file

    echo "--- Interface Stats ---" >> $snapshot_file
    ip -s link show >> $snapshot_file

    echo "--- Top Network Consumers ---" >> $snapshot_file
    ss -tnp | grep ESTABLISHED | awk '{print $6}' | 
        sort | uniq -c | sort -rn | head -10 >> $snapshot_file

    echo "--- Routing Table ---" >> $snapshot_file
    ip route show >> $snapshot_file

    echo "--- dmesg (last 20 lines) ---" >> $snapshot_file
    dmesg | tail -20 >> $snapshot_file

    log "Snapshot kaydedildi: $snapshot_file"
}

log "Monitoring başladı: Hedef $TARGET_IP:$TARGET_PORT"

while true; do
    # Ping testi
    rtt=$(ping -c 3 -W 2 $TARGET_IP 2>/dev/null | 
          grep 'avg' | awk -F'/' '{print $5}' | cut -d'.' -f1)

    if [ -z "$rtt" ]; then
        log "ALERT: $TARGET_IP UNREACHABLE - Snapshot alınıyor"
        capture_state
        # tcpdump ile 30 saniyelik yakalama başlat
        timeout 30 tcpdump -i any -w $LOG_DIR/capture_$(date +%Y%m%d_%H%M%S).pcap 
            host $TARGET_IP &
    elif [ "$rtt" -gt "$THRESHOLD_MS" ]; then
        log "WARNING: Yüksek RTT: ${rtt}ms (Eşik: ${THRESHOLD_MS}ms)"
        capture_state
    else
        log "OK: RTT ${rtt}ms"
    fi

    # TCP port testi
    if ! timeout 5 bash -c "echo >/dev/tcp/$TARGET_IP/$TARGET_PORT" 2>/dev/null; then
        log "ALERT: TCP $TARGET_IP:$TARGET_PORT UNREACHABLE"
    fi

    sleep 30
done

Log Korelasyonu ve Pattern Analizi

Topladığın log’lardan anlamlı bilgi çıkarmak için bazı pratik yöntemler:

# Ping log'undan paket kayıplarını say, saate göre grupla
grep "timeout" /var/log/ping_monitor.log | 
    awk '{print $1, $2}' | 
    cut -d: -f1-2 | 
    sort | uniq -c

# mtr log'unda en çok sorun yaşanan hop'ları bul
grep -A 20 "===" /var/log/mtr_analysis.log | 
    awk '/Loss/{if($3>0) print $0}' | 
    sort -k3 -rn | head -10

# Syslog'da ağ ile ilgili tüm hata mesajlarını zaman sırasına göre listele
grep -E "(error|fail|drop|reset|timeout)" /var/log/syslog | 
    grep -E "(eth|ens|eno|wlan|NetworkManager|dhcp)" | 
    tail -100

Sonuç

Intermittent bağlantı sorunlarını çözmenin sırrı sabır ve sistematik veri toplamadır. Sorun anlık yaşanıp geçiyor diye panik yapmak yerine, şunları yapmalısın:

• Önce veri topla: ping, mtr, sar, tcpdump’ı sorun tekrar etmeden önce başlat.
• Zaman damgasına dikkat et: Her log satırında zaman bilgisi olsun, korelasyon için şarttır.
• Katman katman ilerle: Fiziksel katmandan başla (CRC hataları, link flap), sonra Layer 2 (ARP, STP), sonra Layer 3 (yönlendirme), sonra uygulama katmanına geç.
• Zamanlama çakışmalarını ara: Sorunun cron job, backup veya batch işlemle örtüşüp örtüşmediğini kontrol et.
• Otomatik snapshot al: Sorun yaşandığı anda sistem durumunu otomatik kaydeden bir script çalıştır.
• Sabırlı ol: Bazı sorunlar haftalar içinde ancak netleşir. Veri biriktirmeden sonuca atlamak seni yanlış yere götürür.

Ağ sorunları nadiren gizemli nedenlere sahiptir. Çoğunlukla bir ring buffer doluyordur, bir kablo yarım iletiyordur, bir DNS server ölüdür ya da bir cron job gece yarısı ortalığı kasıp kavuruyordur. Doğru araçlarla ve yeterli veriyle neredeyse her intermittent sorunu çözebilirsin. Zaman zaman saatler, bazen günler gerekebilir ama sistematik yaklaşım seni mutlaka hedefe ulaştırır.