Paket kaybını nasıl teşhis edersiniz?

Bunun çok öznel olduğunu ve bir dizi değişkene bağlı olduğunu biliyorum, ancak belirli bir sistemde paket kaybını teşhis etmeleri gerektiğinde çoğu insanın hangi adımları geçtiğini merak ediyorum.

Ben bir ağ mühendisiyim, bu yüzden bunu benim açımdan tarif edeceğim.

Benim için, paket kaybının teşhisi genellikle "çok iyi çalışmıyor" ile başlar. Oradan, genellikle iletişimin her iki ucuna da yakın (genellikle bir ofiste bir iş istasyonunda ve bir yerde bir sunucuda) kit bulmaya çalışıyorum ve diğer uca mümkün olduğunca yakın ping (ideal olarak "uzak uç nokta"), ama bazen ping gönderemediğim bir güvenlik duvarı var, bu yüzden yönlendiricideki bir LAN arayüzü için yerleşmek zorunda kalacağım) ve herhangi bir kayıp görüp görmediğime bakacağım.

Eğer kaybı görebiliyorsam, bu genellikle "yeterli bant genişliği" veya "aralarında bir sorun" olan bir durumdur, bu nedenle ağ üzerinden rotayı bulun ve ortasından başlayın, bu genellikle size bir son veya diğerini verir.

Kaybı göremezsem, sonraki iki adım "daha fazla ping gönderme" veya "daha büyük ping gönderme" olma eğilimindedir. Eğer bu sıralama böyle olmazsa, sorunun ne olduğuna dair bir gösterge verirseniz, son noktalar arasındaki tüm yol boyunca QoS politikalarına ve arayüz istatistiklerine bakmanın zamanı gelmiştir.

Bu bir şey bulamazsa, varsayımlarınızı sorgulamaya başlamanın zamanı geldi, aslında paket kaybından muzdaripsiniz. Bunu bulmanın tek kesin yolu, ana bilgisayarlarda WireShark (veya eşdeğeri) kullanarak veya ağ muslukları aracılığıyla sniffer makinelerini (muhtemelen WireShark veya benzerini kullanarak) kullanarak aynı anda her iki uçta yakalama yapmaktır. Sonra iki paket yakalamasının karşılaştırılması eğlencesi geliyor ...

Bazen, "paket kaybı" olarak adlandırılan şey, sunucu tarafında sadece gözle görülür derecede yavaş olan bir şeydir (örneğin, veritabanını "aynı LAN'daki" den "20 ms uzağa" taşımak ve çok fazla soru gerektiren sorguları kullanmak gibi. ön uç ve veritabanı arasında ileri geri).

Bir Linux sistemi açısından önce ağ arabiriminde paket kaybını arayacağım ethtool -S ethX.

Çoğu zaman, halkalı tamponu arttırmak bunu ethtool -G ethX rx VALUEçözer.

Bazen kesintiler dengelenmiyor, çünkü sistem dengesizlik servisini kaçırıyor, bu yüzden bu servisin çalışıp çalışmadığını görmek için chkconfig(EL) veya update-rc(Debuntu) bölümüne bakın. Kesintilerin dengelenmediğini söyleyebilirsiniz, çünkü /proc/interruptstüm IRQ kanallarına servis veren sadece Core 0 gösterecektir.

Bunu başaramazsanız net.core.netdev_max_backlog, sistem bir kaç gigabit trafikten daha fazlasını geçiyorsa ve belki de artarsanız, artırmanız gerekebilir net.core.netdev_budget.

Bu işe yaramazsa, kesme birleştirici değerleri ile ince ayar yapabilirsiniz ethtool -C.

Ağ arayüzünde paket damlası yoksa, bakın netstat -sve yuva arabelleklerinde bir damla olup olmadığına bakın, bunlar " pruned from receive queue" ve " dropped from out-of-order queue" gibi istatistiklerle raporlanır .

Uygun protokol için varsayılan ve maksimum soket tamponlarını artırmayı deneyebilirsiniz (örneğin: net.ipv4.tcp_rmemTCP için).

Uygulama kendi soket arabelleği boyutunu ayarlarsa, uygulamanın yapılandırma değişikliklerine ihtiyacı olabilir. Uygulamanızın kodlanmış soket arabellek boyutları varsa, uygulama satıcınıza başvurun.

Şahsen ben değersiz daha fazla sorun neden gibi görünüyor NICs (checksumming, segmentasyon boşaltımı, büyük alma boşaltma) üzerine protokol boşaltma sevmiyorum. Bu ayarları kullanarak ethtool -Kuğraşmanız bir çekim olabilir.

modinfo <drivername>Bazı özellikleri değiştirmeniz gerekebileceğinden NIC'nizin modül seçeneklerine bakın . Bir örnek vermek gerekirse, Intel'in Flow Director'ı büyük bir TCP akışını yöneten bir sistemde kullanmak, muhtemelen bu akışın verimliliğine zarar vereceği için FDir'i kapatın.

Bunun ötesinde, bu belirli sistemi kendi iş yükü için elle ayarladığınızdan eminim, sanırım sorunuzun kapsamı dışında.

Paket yakalama aracını kullanarak başlayacağım: wireshark (Windows'ta) ve tcpdump (Linux terminalinde).

Ayrıca güvenlik duvarı yapılandırmasını da kontrol edeceğim (ana bilgisayar güvenlik duvarı ve ağ güvenlik duvarı).

İzole et, sonra yok et.

Sorunu olan yolların en küçük alt kümesini bulun. Bunu farklı kombinasyonları test ederek ve / veya kullanıcı raporlarını distile ederek yapın. Eşittir zaman faktörü unutma. Belki de sadece belirli bir ağa giden tüm trafikte paket halindedir, ya da belki sadece kablosuz istemciler acı çekmektedir. Farklı trafik türlerini hesaba katın (ping'lerdeki ücret sınırı). Test etmenin en güvenilir ve kolay tekrarlanabilir yolunu bulun.

Ardından olası nedenleri ortadan kaldırın. Bağlantılardaki trafiği azaltın (geçici olarak), parazit kaynaklarını spektrumdan kaldırın, belirli müşterilerin bağlantısını kesin. Sonunda sorunun kaynağını bulacaksınız.

Bazen paket dökümlerine bakarak ya da tahminlerde bulunarak kısayolları alabilirsiniz (bu her zaman acıdır). Ayrıca, profesörünüze sunucu arızalarının mükemmel olduğunu söyleyin.

Büyük ping göndermediğiniz sürece pingler paket kaybı göstermeyebilir! Ağımda ping paket büyüklüğümü artırana kadar görünmeyen paket kaybı yaşadım.

Pencereler için:

ping -n 30 -l <largevalue> <target>

İçin largevalue40960 (40k paket) kullandım.

Çünkü targetilk birkaç IP adresini kullandım.tracert google.com

(yönlendiricilerim ve kablo modemim) Zincirdeki diğer cihazlardan biri, büyük paketler için korkunç bir paket kaybına (>% 60), küçük paketler için ise% 0'a sahipti. Yeniden başlatarak düzelttim ama aynı zamanda bir kablo ya da değiştirilmesi gereken bir şey olabilir.