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 Down ve Link is Up mesajlarının sıklığı
  • Reset adapter mesajları, bu ciddi bir sürücü veya donanım sorununa işaret eder
  • NETDEV WATCHDOG mesajları, TX queue’nun takılı kaldığını gösterir
  • NIC Link is Up X Mbps Full Duplex mesajları, 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 show ile arayüzün UP/DOWN durumunu kontrol edin
  • Adım 2: ip -s link show ile hata ve drop sayılarına bakın
  • Adım 3: ethtool eth0 ile hız, duplex ve link durumunu doğrulayın
  • Adım 4: ethtool -i eth0 ile sürücü bilgilerini alın
  • Adım 5: dmesg | grep eth0 ile kernel mesajlarını inceleyin
  • Adım 6: ethtool -S eth0 ile donanım seviyesi istatistikleri analiz edin
  • Adım 7: ethtool -g eth0 ile ring buffer ayarlarını kontrol edin
  • Adım 8: ethtool -k eth0 ile 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.

Benzer Konular

Bir yanıt yazın

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