Ağ Arayüzü Sorunları: ip link ve ethtool ile Derinlemesine Analiz
Ağ sorunları sysadmin hayatının kaçınılmaz bir parçası. Sabah 3’te telefon çalıyor, kritik bir sunucu erişilemez durumda ve ilk sorunuz şu oluyor: “Ağ arayüzü düzgün çalışıyor mu?” İşte tam bu noktada ip link ve ethtool araçları hayat kurtarıcı oluyor. Bu yazıda, ağ arayüzü sorunlarını sistematik olarak nasıl analiz edeceğinizi, gerçek dünya senaryolarıyla birlikte anlatacağım.
Temel Kavramlar: Neden ip link ve ethtool?
Eski nesil sysadminler ifconfig ve mii-tool kullanırdı. Bu araçlar hala işe yarasa da modern Linux sistemlerinde iproute2 paketinin bir parçası olan ip komutu ve ethtool çok daha fazla bilgi sunuyor. ifconfig deprecated sayılıyor ve birçok minimal kurulumda artık varsayılan olarak gelmiyor.
ip link size Layer 2 düzeyinde arayüz bilgilerini gösterirken, ethtool donanım seviyesine inerek NIC’in gerçek durumunu, hız/duplex ayarlarını, sürücü bilgilerini ve hatta offload özelliklerini incelemenizi sağlıyor.
ip link ile Hızlı Durum Tespiti
Bir sorunla karşılaştığınızda ilk komutunuz şu olmalı:
ip link show
Çıktı şuna benzer bir şey olacak:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 52:54:00:ab:cd:ef brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
Burada dikkat etmeniz gereken birkaç kritik nokta var. state DOWN görüyorsanız, arayüz fiziksel olarak kapalı demektir. UP,LOWER_UP kombinasyonu hem yazılım hem fiziksel bağlantının aktif olduğunu gösterir. UP ama LOWER_UP yoksa, interface administratively up fakat kablo bağlı değil veya link yok demektir.
Bayrakları daha iyi anlamak için:
- UP: Arayüz administratively aktif
- LOWER_UP: Fiziksel link (kablo/sinyal) mevcut
- BROADCAST: Broadcast paket gönderebilir
- MULTICAST: Multicast destekliyor
- NO-CARRIER: Taşıyıcı sinyal yok, kablo sorunu olabilir
Belirli bir arayüzü incelemek için:
ip link show dev eth0
ip -s link show dev eth0 # istatistiklerle birlikte
-s parametresi RX/TX paket sayıları, hata sayıları ve drop’ları gösterir. Eğer errors veya dropped sayıları sürekli artıyorsa ciddi bir problem var demektir.
Gerçek Dünya Senaryosu 1: Kablo Sorunu mu Yazılım Sorunu mu?
Diyelim ki bir uygulama sunucusu intermittent bağlantı sorunları yaşıyor. Önce şunu çalıştırın:
watch -n 2 'ip -s link show dev eth0'
Bu komutu birkaç dakika izleyin. Eğer RX errors veya TX errors artıyorsa donanım veya fiziksel katman sorunu var. dropped artıyorsa bu genellikle yazılım tarafında buffer dolması anlamına gelir.
Şimdi arayüzü reset etmeden önce mevcut durumu kaydedin:
ip link show eth0 > /tmp/eth0_before.txt
ip -s link show eth0 >> /tmp/eth0_before.txt
Eğer arayüz DOWN durumundaysa ve bunu elle kaldırmak istiyorsanız:
ip link set eth0 up
Bu komut işe yarıyorsa ve arayüz UP oluyor ama kısa süre sonra tekrar DOWN düşüyorsa, ya NetworkManager çakışması var ya da donanımsal bir problem söz konusu.
ethtool ile Derinlemesine Analiz
ethtool gerçek gücünü burada gösteriyor. Temel kullanım:
ethtool eth0
Çıktı şuna benzer:
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Speed: 100Mb/s
Duplex: Half
Auto-negotiation: on
Link detected: yes
Burada alarm zillerini çaldıran şey: Speed: 100Mb/s ve Duplex: Half. Gigabit destekleyen bir NIC’de 100Mb/s Half Duplex görüyorsanız, auto-negotiation problemi var demektir. Bu durum performans sorunlarına ve yüksek hata oranlarına yol açar.
ethtool Parametreleri
- -i: Sürücü bilgilerini gösterir
- -S: Detaylı istatistikler
- -k: Offload özelliklerini listeler
- -a: Pause parametrelerini gösterir
- -c: Coalescing ayarlarını gösterir
- -g: Ring buffer boyutlarını gösterir
- -l: Kanal sayısını gösterir
- -s: Ayarları değiştirir
Sürücü bilgilerini görmek için:
ethtool -i eth0
driver: virtio_net
version: 1.0.0
firmware-version:
expansion-rom-version:
bus-info: 0000:00:03.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
Bu çıktıdan hangi kernel modülünün kullanıldığını görebilirsiniz. Sürücü versiyonu eski veya bilinen bir bug içeriyorsa, bu önemli bir ipucu olabilir.
Gerçek Dünya Senaryosu 2: Duplex Mismatch Sorunu
Şirketteki bir veritabanı sunucusu yüksek network latency yaşıyordu. ping sonuçları tutarsızdı, bazen 1ms bazen 50ms. ethtool çıktısına baktığımızda şunu gördük:
Speed: 1000Mb/s
Duplex: Half
Auto-negotiation: on
Switch tarafında ise Full Duplex zorlanmıştı. Klasik duplex mismatch! Bu durumda bir taraf half duplex çalışırken diğeri full duplex çalışıyor ve collision detection mekanizmaları devreye giriyor.
Çözüm için önce mevcut ayarları not alın, sonra düzeltin:
# Mevcut ayarları kaydet
ethtool eth0 > /tmp/eth0_ethtool_before.txt
# Hızı ve duplexı zorla
ethtool -s eth0 speed 1000 duplex full autoneg off
# Veya auto-negotiation'ı düzgün çalıştırmak için
ethtool -s eth0 autoneg on
Dikkat: Bu değişiklikler geçici. Sistem yeniden başladığında kaybolur. Kalıcı yapmak için dağıtımınıza göre network konfigürasyon dosyasına eklemeniz gerekir. RHEL/CentOS için /etc/sysconfig/network-scripts/ifcfg-eth0 dosyasına ETHTOOL_OPTS parametresi eklenebilir.
ethtool ile İstatistik Analizi
Donanım seviyesi istatistikler için -S parametresi çok değerli:
ethtool -S eth0
Bu komut NIC’e özgü sayaçları döker. Intel kartlarda onlarca farklı sayaç görebilirsiniz. Özellikle dikkat edilmesi gerekenler:
ethtool -S eth0 | grep -E "error|miss|drop|overflow|fifo"
Bu filtre ile sadece sorun göstergesi olabilecek sayaçlara odaklanabilirsiniz. rx_fifo_errors, tx_fifo_errors, rx_missed_errors gibi değerler sıfırdan farklıysa araştırmanız gerekir.
Zaman içindeki değişimi izlemek için:
# İlk snapshot
ethtool -S eth0 > /tmp/stats_before.txt
sleep 60
ethtool -S eth0 > /tmp/stats_after.txt
diff /tmp/stats_before.txt /tmp/stats_after.txt
Offload Özellikleri ve Performans Sorunları
Modern NIC’ler birçok işlemi CPU’dan alıp kendi üzerinde yapabilir. Bu “offload” özellikleri bazen sorunlara yol açabiliyor:
ethtool -k eth0
Çıktıda göreceğiniz önemli özellikler:
- tx-checksumming: Gönderilen paketlerde checksum hesaplama NIC’e devredilir
- rx-checksumming: Alınan paketlerde checksum doğrulama
- scatter-gather: Büyük paketleri parçalı bellek bölgelerinden toplayabilme
- tcp-segmentation-offload (TSO): Büyük TCP segmentlerini NIC böler
- generic-receive-offload (GRO): Alınan paketleri birleştirme
- large-receive-offload (LRO): Donanım seviyesi paket birleştirme
Sanal makinelerde veya container ortamlarında bazen TSO veya GRO sorunlara neden olabilir. Bir şüpheniz varsa test için kapatın:
ethtool -K eth0 tso off
ethtool -K eth0 gro off
Bunları kapattıktan sonra sorun çözüldüyse, offload özelliği ile sürücü veya hypervisor arasında bir uyumsuzluk var demektir.
Gerçek Dünya Senaryosu 3: Sanal Makine Ağ Problemi
Bir Kubernetes worker node’unda pod’lar arası iletişimde paket kayıpları yaşanıyordu. ip -s link show komutunda sürekli artan RX dropped değerleri dikkat çekti:
ip -s link show ens3
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether fa:16:3e:xx:xx:xx brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
15234567890 12345678 0 45678 0 0
TX: bytes packets errors dropped carrier collsns
8765432100 9876543 0 0 0 0
RX dropped 45678 ve artmaya devam ediyordu. Önce ring buffer durumuna baktık:
ethtool -g ens3
Ring parameters for ens3:
Pre-set maximums:
RX: 1024
RX Mini: 0
RX Jumbo: 0
TX: 1024
Current hardware settings:
RX: 256
TX: 256
Ring buffer sadece 256 olarak ayarlanmıştı, maksimum 1024 destekleniyordu. Yüksek trafik altında buffer dolup paketler düşüyordu. Çözüm:
ethtool -G ens3 rx 1024 tx 1024
Bu değişiklikten sonra dropped sayıları artmayı durdurdu. Ring buffer tuning özellikle yüksek throughput gerektiren sunucularda kritik.
MTU Sorunları ve ip link ile Analiz
MTU (Maximum Transmission Unit) uyumsuzlukları özellikle VPN, tünel veya jumbo frame kullanılan ortamlarda sık karşılaşılan bir sorun:
ip link show eth0 | grep mtu
Mevcut MTU değerini görmek için veya değiştirmek için:
# MTU değiştirme
ip link set eth0 mtu 9000 # Jumbo frames için
# Test etmek için belirli boyutta ping
ping -M do -s 8972 192.168.1.1 # 9000 - 28 byte header = 8972
Eğer büyük boyutlu ping başarısız oluyorsa ama küçük boyutlar çalışıyorsa, MTU sorununu teyit etmiş olursunuz.
Bağlantı Durumunu Sürekli İzleme
Arayüzün durumunu gerçek zamanlı izlemek için birkaç yöntem var:
# ip monitor ile link değişikliklerini izle
ip monitor link
# Belirli aralıklarla durumu kontrol et
watch -n 1 'ip link show eth0; echo "---"; ethtool eth0 | grep -E "Speed|Duplex|Link"'
ip monitor link komutu özellikle değerli. Bir arayüzün ne zaman down-up yaptığını gerçek zamanlı gösterir. Flapping durumlarında (sürekli up-down) bu komutu açık tutun ve zamanlama bilgilerini kaydedin.
Daha gelişmiş loglama için:
ip monitor link >> /var/log/link-monitor.log &
Bu işlemi bir systemd servisine dönüştürmek uzun vadeli izleme için çok daha sağlıklı olur.
Sürücü Sorunları ve Modül Analizi
NIC sürücüsüyle ilgili sorunlarda ethtool -i çıktısını aldıktan sonra kernel mesajlarına da bakın:
# Belirli bir sürücüyle ilgili kernel mesajları
dmesg | grep -i "$(ethtool -i eth0 | grep driver | awk '{print $2}')"
# Genel ağ arayüzü mesajları
dmesg | grep -i eth0
dmesg | grep -i "link"
Kernel logunda şunlara dikkat edin:
Link is DownveLink is Upmesajlarının sıklığıReset adaptermesajları, bu ciddi bir sürücü veya donanım sorununa işaret ederNETDEV WATCHDOGmesajları, TX queue’nun takılı kaldığını gösterirNIC Link is Up X Mbps Full Duplexmesajları, link parametrelerini doğrulamanızı sağlar
Birden Fazla Arayüz Karşılaştırması
Aynı sistemde birden fazla NIC varsa ve sadece biri sorun çıkarıyorsa karşılaştırmalı analiz yapın:
for iface in $(ip link show | grep -E '^[0-9]+:' | awk '{print $2}' | tr -d ':' | grep -v lo); do
echo "=== $iface ==="
ethtool $iface 2>/dev/null | grep -E "Speed|Duplex|Link detected|Auto-neg"
echo ""
done
Bu script tüm arayüzlerin hız, duplex ve link durumlarını tek seferde gösterir. Sorunlu arayüzü sağlıklılarla karşılaştırınca farklar hemen göze çarpar.
NetworkManager ile Çakışma Durumları
Manuel yaptığınız değişiklikler kısa süre sonra geri alınıyorsa, NetworkManager devreye giriyor olabilir. Bunu anlamak için:
# NetworkManager'ın arayüzü yönetip yönetmediğini kontrol et
nmcli device status
# Belirli arayüzü NetworkManager'dan çıkarmak için
nmcli device set eth0 managed no
# Veya /etc/NetworkManager/conf.d/ altına dosya oluştur
cat > /etc/NetworkManager/conf.d/99-unmanaged-eth0.conf << EOF
[keyfile]
unmanaged-devices=interface-name:eth0
EOF
systemctl reload NetworkManager
Bonding ve Team Arayüzlerinde Analiz
Yüksek erişilebilirlik için bonding kullanılan ortamlarda sorun analizi biraz farklı:
# Bond arayüzü durumu
ip link show bond0
cat /proc/net/bonding/bond0
# Her slave'in durumu
ethtool bond0
ethtool eth0
ethtool eth1
/proc/net/bonding/bond0 çıktısı aktif slave’i, link durumlarını ve failover geçmişini gösterir. Bir slave sürekli failover yapıyorsa, o slave’in ethtool -S çıktısına bakın.
Hızlı Referans: Sorun Giderme Akışı
Bir ağ arayüzü sorunuyla karşılaştığınızda şu sırayla ilerleyin:
- Adım 1:
ip link showile arayüzün UP/DOWN durumunu kontrol edin - Adım 2:
ip -s link showile hata ve drop sayılarına bakın - Adım 3:
ethtool eth0ile hız, duplex ve link durumunu doğrulayın - Adım 4:
ethtool -i eth0ile sürücü bilgilerini alın - Adım 5:
dmesg | grep eth0ile kernel mesajlarını inceleyin - Adım 6:
ethtool -S eth0ile donanım seviyesi istatistikleri analiz edin - Adım 7:
ethtool -g eth0ile ring buffer ayarlarını kontrol edin - Adım 8:
ethtool -k eth0ile offload özelliklerini gözden geçirin
Sonuç
ip link ve ethtool kombinasyonu, ağ arayüzü sorunlarının büyük çoğunluğunu teşhis etmek için yeterli. Fiziksel bağlantı sorunlarından duplex mismatch’e, ring buffer yetersizliğinden offload bug’larına kadar geniş bir yelpazeyi kapsıyor.
En önemli nokta sistematik yaklaşım. Panikleyip her şeyi aynı anda değiştirmeye çalışmak yerine, yukarıdaki akışı takip etmek hem daha hızlı sonuç verir hem de değişikliklerinizi geri almanız gerektiğinde nerede durduğunuzu bilirsiniz.
Bir de şunu söyleyeyim: Bu araçların çıktılarını baseline olarak kaydetme alışkanlığı edinin. Sorun yokken ethtool -S ve ip -s link çıktılarını haftalık olarak arşivleyin. Sorun çıktığında neyin değiştiğini görmek, saatlik debug oturumlarından çok daha verimli. Monitoring sistemlerinize bu metrikleri eklemek ise uzun vadede en doğru yatırım.
