Ağ Arayüzü Sorunları: Linux’ta ip ve ethtool ile Bağlantı Hata Ayıklama

Yazar:komut.io ekibi Linux Sistem Hata Ayıklama
0 Yorum

Gece yarısı üretim sunucunuzdan alarm geliyor: “Network unreachable.” Kullanıcılar bağlanamıyor, uygulamalar zaman aşımına uğruyor ve siz SSH üzerinden bağlı olduğunuz için şu an paniğe kapılmadan önce birkaç saniyeniz var. İşte tam bu noktada ip ve ethtool komutlarını elinizin tersi gibi bilmek sizi kurtarır. Bu yazıda gerçek dünya senaryoları üzerinden Linux ağ arayüzü sorunlarını nasıl teşhis edip çözeceğimizi adım adım inceleyeceğiz.

Neden ip ve ethtool?

Eski alışkanlıkla hâlâ ifconfig ve netstat kullananlar var. Anlıyorum, eski köye yeni adet getirmek zor. Ama net-tools paketi artık aktif olarak geliştirilmiyor ve modern dağıtımların büyük çoğunluğunda varsayılan olarak kurulu gelmiyor. iproute2 paketindeki ip komutu çok daha güçlü, tutarlı bir söz dizimi sunuyor ve çekirdekle daha doğrudan iletişim kuruyor.

ethtool ise fiziksel katmana iniyor: NIC hızı, duplex modu, sürücü bilgisi, istatistikler ve hatta bazı NIC’lerde offload ayarları. Bu ikili birlikte kullanıldığında ağ sorunlarının büyük çoğunluğunu çözebilirsiniz.

Temel Durum Kontrolü: Nerede Duruyoruz?

Herhangi bir ağ sorununda ilk yapmanız gereken mevcut durumu fotoğraflamak. Panik yapmadan, sistematik ilerliyoruz.

# Tüm arayüzlerin özet durumu
ip link show

# Daha ayrıntılı, IP adresleriyle birlikte
ip address show

# Sadece aktif (UP durumunda) arayüzler
ip link show up

# Belirli bir arayüzü incelemek
ip link show dev eth0

Bu çıktıda dikkat etmeniz gereken birkaç şey var. Köşeli parantez içindeki bayraklar size çok şey anlatır:

  • UP: Arayüz yönetici tarafından aktif edilmiş
  • LOWER_UP: Fiziksel katmanda bağlantı var (kablo takılı ve karşı taraf cevap veriyor)
  • NO-CARRIER: Fiziksel bağlantı yok, kablo sorunu olabilir
  • DORMANT: Arayüz beklemede, genellikle 802.1X authentication bekleniyor
  • PROMISC: Promiscuous mode açık, birisi paket yakalıyor olabilir

Bir arayüzde UP görüp LOWER_UP görmüyorsanız bu fiziksel katman sorununa işaret eder. Kablo, switch portu veya NIC’in kendisi sorunlu olabilir.

ip Komutu ile Derinlemesine İnceleme

Yönlendirme Tablosunu Kontrol Etmek

Bağlantı sorununun en yaygın nedenlerinden biri yanlış veya eksik route’lar. Şöyle bir senaryo düşünün: Sunucu IP alıyor ama dış dünyaya çıkamıyor.

# Ana yönlendirme tablosu
ip route show

# Belirli bir hedefe nasıl ulaşıldığını göster
ip route get 8.8.8.8

# Tüm routing tablolarını listele
ip route show table all

# Özellikle default gateway'i kontrol et
ip route show default

ip route get 8.8.8.8 komutu çok değerlidir. Size tam olarak “bu paketi göndermek için hangi arayüzü, hangi gateway’i kullanacağım” bilgisini verir. Eğer çıktıda RTNETLINK answers: Network is unreachable görüyorsanız default route yok demektir.

Default route eklemek için:

# Gateway üzerinden default route ekle
ip route add default via 192.168.1.1 dev eth0

# Mevcut default route'u sil ve yeniden ekle
ip route del default
ip route add default via 192.168.1.1

Komşu Tablosu (ARP Cache) Kontrolü

Aynı ağ segmentindeki cihazlara ulaşamıyorsanız ARP tablosuna bakın:

# ARP/NDP tablosunu göster
ip neighbour show

# Belirli bir arayüzdeki komşular
ip neighbour show dev eth0

# Sadece REACHABLE durumundaki komşular
ip neighbour show nud reachable

# ARP cache'i temizle (dikkatli kullanın!)
ip neighbour flush dev eth0

Çıktıdaki durumlar şunları ifade eder:

  • REACHABLE: Yakın zamanda iletişim kuruldu, geçerli
  • STALE: Süre dolmuş ama henüz silinmemiş
  • FAILED: ARP isteği gönderildi ama yanıt gelmedi
  • INCOMPLETE: ARP isteği gönderildi, yanıt bekleniyor

Eğer bir IP için FAILED görüyorsanız ya o IP’de cihaz yok, ya da aynı IP’yi kullanan başka bir cihaz var (IP çakışması).

Gerçek Dünya Senaryosu: IP Çakışması Tespiti

Üretimde sık karşılaşılan bir durum: Yeni bir sunucu kuruldu ve ağa eklendiğinde mevcut bir sunucunun bağlantısı kesilmeye başladı.

# Şüphelenilen IP için ARP tablosuna bak
ip neighbour show | grep 192.168.1.50

# Eğer birden fazla MAC adresi görüyorsanız çakışma var
# arping ile daha ayrıntılı araştır
arping -I eth0 192.168.1.50 -c 5

arping çıktısında farklı MAC adreslerinden yanıt geliyorsa kesinlikle IP çakışması vardır. O ağdaki switch’in MAC tablosunu kontrol edip hangi porttan geldiğini bulabilirsiniz.

ethtool ile Fiziksel Katman Analizi

ip komutu size yazılım tarafını gösterirken ethtool fiziksel ve sürücü düzeyine iniyor.

Temel ethtool Kullanımı

# NIC'in temel bilgileri: hız, duplex, link durumu
ethtool eth0

# Sürücü ve firmware bilgisi
ethtool -i eth0

# İstatistikler (hata sayaçları dahil)
ethtool -S eth0

# Arayüzün desteklediği hızlar ve modlar
ethtool eth0 | grep -A 10 "Supported link modes"

ethtool eth0 çıktısında şunlara bakın:

  • Speed: Bağlantı hızı (100Mb/s, 1000Mb/s, 10000Mb/s vs.)
  • Duplex: Full olması gerekir, Half görüyorsanız sorun var
  • Link detected: yes görmelisiniz, no görüyorsanız fiziksel bağlantı yok
  • Auto-negotiation: Genellikle on olmalı

Duplex ve Hız Sorunları

Klasik bir sorun: Switch portu Full Duplex’te sabit ayarlı ama NIC Auto-Negotiate yapıyor. Bu durumda teorik olarak bağlantı çalışır ama yük altında dramatik performans düşüşü yaşarsınız. Paket kayıpları artar, latency patlar.

# Mevcut hız ve duplex ayarlarını gör
ethtool eth0 | grep -E "Speed|Duplex|Auto"

# Hızı ve duplex'i manuel ayarla (switch ile eşleşmeli)
ethtool -s eth0 speed 1000 duplex full autoneg off

# Auto-negotiate'i tekrar açmak için
ethtool -s eth0 autoneg on

Önemli uyarı: Bu ayarlar reboot’ta kaybolur. Kalıcı yapmak için dağıtımınıza göre network konfigürasyon dosyalarına eklemeniz gerekir. RHEL/CentOS için /etc/sysconfig/network-scripts/ifcfg-eth0 dosyasına ETHTOOL_OPTS="speed 1000 duplex full autoneg off" ekleyebilirsiniz.

ethtool İstatistikleri ile Hata Analizi

Bu kısım altın değerinde. NIC sürücüsünden gelen ham istatistikler size pek çok şeyi anlatır:

# Tüm istatistikleri listele
ethtool -S eth0

# Sadece hata içeren satırları filtrele
ethtool -S eth0 | grep -i error

# Sadece drop olan paketleri göster
ethtool -S eth0 | grep -i drop

# rx ve tx istatistiklerini ayrı gör
ethtool -S eth0 | grep -E "rx_|tx_"

Dikkat etmeniz gereken sayaçlar şunlar:

  • rx_errors / tx_errors: Genel hata sayısı, sıfır olmalı
  • rx_dropped / tx_dropped: Düşürülen paketler, kernel buffer doluysa artar
  • rx_missed_errors: Ring buffer yetersizliği, NIC interrupts işlenemiyor
  • tx_aborted_errors: Gönderme iptal edildi, genellikle collision veya timeout
  • rx_crc_errors: CRC hataları, kötü kablo veya elektriksel gürültü işareti
  • rx_frame_errors: Frame hataları, duplex uyumsuzluğuna işaret edebilir

Eğer rx_crc_errors sürekli artıyorsa kabloyu değiştirin ya da SFP modülünü kontrol edin. rx_missed_errors artıyorsa ring buffer boyutunu artırmayı deneyin:

# Mevcut ring buffer boyutlarını gör
ethtool -g eth0

# Ring buffer boyutunu artır
ethtool -G eth0 rx 4096 tx 4096

Offload Ayarları: Performans Sorunlarının Gizli Nedeni

Bazen ağ sorunları bant genişliği veya hata değil, beklenmedik davranışlar şeklinde görünür. Paket yakalama aracı kullanıyorsunuz ama paketler garip görünüyor, checksum hataları var gibi. Bu genellikle offload ayarlarıyla ilgili.

# Tüm offload ayarlarını göster
ethtool -k eth0

# Yaygın offload özelliklerini kontrol et
ethtool -k eth0 | grep -E "tcp-segmentation|generic-segmentation|receive-offload"

Offload özellikleri:

  • tx-checksumming: TX checksum hesaplamayı NIC yapıyor
  • rx-checksumming: RX checksum doğrulamasını NIC yapıyor
  • tcp-segmentation-offload (TSO): Büyük TCP segmentlerini NIC böluyor
  • generic-receive-offload (GRO): Gelen paketleri birleştirerek CPU yükünü azaltıyor
  • large-receive-offload (LRO): GRO’nun donanım versiyonu

Wireshark veya tcpdump ile paket yakaladığınızda checksum hataları görüyorsanız, bu aslında offload’ın devrede olduğu anlamına gelir ve genellikle sorun değildir. Ama bazen bu özellikler gerçekten sorun yaratır:

# TSO'yu kapat (troubleshooting için)
ethtool -K eth0 tso off

# GRO'yu kapat
ethtool -K eth0 gro off

# Birden fazla özelliği aynı anda değiştir
ethtool -K eth0 tso off gso off gro off lro off

Pratik Senaryo: Yüksek Paket Kaybı Analizi

Bir uygulama ekibinden şikayet geliyor: “Veritabanına bağlantılar arada bir kopuyor, timeout alıyoruz.” Klasik intermittent sorun. Sistematik yaklaşalım:

# Önce arayüz hatalarını anlık izle
watch -n 1 'ethtool -S eth0 | grep -E "error|drop|miss"'

# Paralel terminalde ip istatistiklerine bak
watch -n 1 'ip -s link show eth0'

# Routing'de sorun var mı?
ip route get <veritabani_ip>

# Paket kaybını doğrula
ping -c 100 -i 0.2 <veritabani_ip> | tail -5

ip -s link show çıktısında TX ve RX paketlerini, hataları ve dropped paketleri görebilirsiniz. Eğer dropped sayısı artıyorsa:

# Kernel receive buffer boyutlarını kontrol et
sysctl net.core.rmem_max
sysctl net.core.rmem_default

# Ring buffer yetersizse artır
ethtool -G eth0 rx 4096

# Interrupt coalescing ayarlarını kontrol et
ethtool -c eth0

# Daha agresif coalescing (daha az interrupt, biraz daha latency)
ethtool -C eth0 rx-usecs 50 tx-usecs 50

Eğer rx_missed_errors artıyorsa IRQ affinity sorununa bakın:

# Hangi CPU'nun bu NIC interrupt'larını işlediğine bak
cat /proc/interrupts | grep eth0

# IRQ numarasını bul ve hangi CPU'larda çalıştığına bak
cat /proc/irq/<irq_no>/smp_affinity

Yoğuk trafikli sunucularda IRQ’ların tek bir CPU’ya yığılması ciddi performans sorununa neden olabilir. irqbalance servisinin çalıştığından emin olun veya manuel affinity ayarlayın.

Bağlantıyı Takip Etmek: ss ve ip Kombinasyonu

Ağ sorunları bazen arayüzde değil, bağlantı durumlarında gizlenir. ip ve ss komutlarını birlikte kullanmak güçlü bir kombinasyon sunar:

# Tüm TCP bağlantılarını göster
ss -tunapl

# Belirli bir port veya IP'ye olan bağlantılar
ss -tn dst 192.168.1.100

# TIME_WAIT durumundaki bağlantı sayısı (yüksekse sorun işareti)
ss -tan | grep TIME_WAIT | wc -l

# CLOSE_WAIT durumundaki bağlantılar (uygulama kapatmıyorsa sorun)
ss -tan | grep CLOSE_WAIT

# Bağlantı istatistiklerini özetle
ss -s

TIME_WAIT sayısı çok yüksekse ve bu sorun yaratıyorsa:

# TIME_WAIT reuse'u aktif et
sysctl -w net.ipv4.tcp_tw_reuse=1

# Kalıcı yapmak için /etc/sysctl.conf'a ekle
echo "net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.conf

Namespace ve VLAN Ortamlarında Hata Ayıklama

Modern altyapılarda container’lar, namespace’ler ve VLAN’lar işi karmaşıklaştırır.

# Tüm network namespace'leri listele
ip netns list

# Belirli bir namespace içinde komut çalıştır
ip netns exec <namespace_adi> ip link show
ip netns exec <namespace_adi> ip route show

# VLAN arayüzlerini göster
ip link show type vlan

# Bond arayüzlerini göster
ip link show type bond

# Bridge arayüzlerini göster
ip link show type bridge

# Belirli bir arayüzün istatistiklerini takip et
ip -s -s link show eth0

Container ortamlarında (Docker, Podman) sorun yaşıyorsanız ve container’dan dışarı çıkamıyorsanız:

# Container'ın network namespace'ine gir
# Önce container PID'ini bul
docker inspect <container_id> | grep Pid

# Namespace'e gir
nsenter -t <pid> -n ip route show
nsenter -t <pid> -n ip link show

Hızlı Tanı Script’i

Bir sunucuya ilk bağlandığınızda çalıştırabileceğiniz, durumu hızlıca özetleyen küçük bir script:

#!/bin/bash
echo "=== ARAYUZ DURUMU ==="
ip link show | grep -E "^[0-9]+:|flags"

echo ""
echo "=== IP ADRESLERI ==="
ip address show | grep -E "inet |^[0-9]"

echo ""
echo "=== DEFAULT ROUTE ==="
ip route show default

echo ""
echo "=== ARP TABLOSU ==="
ip neighbour show | grep -v FAILED

echo ""
echo "=== NIC HIZLARI ==="
for iface in $(ip link show | grep -E "^[0-9]+" | awk -F': ' '{print $2}' | grep -v lo); do
    echo -n "$iface: "
    ethtool $iface 2>/dev/null | grep -E "Speed|Duplex|Link detected" | tr 'n' ' '
    echo ""
done

echo ""
echo "=== HATA SAYACLARI ==="
for iface in $(ip link show | grep -E "^[0-9]+" | awk -F': ' '{print $2}' | grep -v lo); do
    errors=$(ethtool -S $iface 2>/dev/null | grep -E "error|drop" | grep -v "^0$" | awk '{sum += $2} END {print sum}')
    if [ ! -z "$errors" ] && [ "$errors" -gt 0 ]; then
        echo "$iface: Toplam hata/drop = $errors"
        ethtool -S $iface 2>/dev/null | grep -E "error|drop" | grep -v " 0$"
    fi
done

Bu script’i /usr/local/bin/netcheck olarak kaydedin, çalıştırılabilir yapın ve herhangi bir ağ sorununda ilk olarak bu script’i çalıştırın.

Yaygın Sorunlar ve Hızlı Çözümler

Deneyimlerimden derlediğim, en sık karşılaştığım sorunlar ve birinci adım çözümleri:

  • Arayüz UP ama ping çalışmıyor: ip route get ile route kontrolü, sonra ip neighbour show ile ARP durumu
  • Yavaş bağlantı, yüksek latency: ethtool -S eth0 | grep error ile hata sayaçları, ethtool eth0 ile duplex kontrolü
  • Arayüz tekrar tekrar DOWN oluyor: journalctl -u NetworkManager -f ve dmesg | grep eth0 ile log analizi
  • MTU uyumsuzluğu şüphesi: ping -M do -s 1472 ile MTU path discovery, ip link set eth0 mtu 1500
  • Bond failover çalışmıyor: cat /proc/net/bonding/bond0 ile bond durumu, slave arayüzlerin link durumu
  • IPv6 bağlantı sorunları: ip -6 address show ve ip -6 route show, gerekirse sysctl -w net.ipv6.conf.eth0.disable_ipv6=1

Sonuç

Ağ sorunları her zaman net belirtilerle gelmez. Bazen yavaşlama, bazen aralıklı kopma, bazen sadece belirli servislerin etkilenmesi şeklinde karşınıza çıkar. Ama yaklaşım her zaman aynı: fiziksel katmandan başla, yukarı çık.

ethtool ile fiziksel bağlantı ve NIC istatistiklerini, ip ile Layer 3 route ve adres yapılandırmasını kontrol etmek, sorunların büyük çoğunluğunu çözmenizi sağlar. Bu araçları refleks haline getirmek için düzenli çalışan sistemlerde bile ara ara bu komutları çalıştırıp “normal” durumun nasıl göründüğünü aklınıza kazımanızı öneririm. Sorun çıktığında normalden sapmaları anında fark edersiniz.

Son olarak: her değişikliği kayıt altına alın. history komutunun çıktısını, değişiklik öncesi ve sonrası ethtool -S çıktısını, sorunun ne zaman başladığını ve ne yaptığınızda düzeldiğini. Bir sonraki seferde hem siz hem de ekibinizdeki herkes çok daha hızlı çözüme ulaşır.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir