LAN içinde TCP yeniden iletiminin nedenini bulma

25

Merhaba Sunucu Arızası

Yaklaşık 100 bilgisayar, 2 Windows etki alanı sunucusu ve 12 VoIP telefonlu LAN ile ilgili rahatsız edici bir sorunum var. Yaklaşık bir yıl önce kurulumlarından bu yana, her hafta ya da öylesine, bir aramanın ortasında bazen kendi kendini sıfırlayan bir VoIP telefonu görüyoruz. Eşzamanlı olarak bilgisayarlarda genellikle geçici olarak bağlantı kaybının belirtileri vardır: ağ paylaşımlarına erişirken kaşifte donar, yönetim yazılımımızda veritabanı sunucusuyla bağlantı kopması nedeniyle donar.

VoIP PBX ile ağın geri kalanı arasındaki bağlantıda bazı Wireshark izleme işlemleri yapıyorum. Wireshark, telefonun yeniden başlatıldığını kaydettiğimiz zamanlarda yeniden iletilen TCP paketlerinin bir kümesini alıyor. Wireshark logu 5 paket ile yüzlerce arasında değişen günde yaklaşık 2 yeniden iletim kümesi gösterir. Her bir kümedekiler temel olarak PBX ile bazı VoIP telefonlarının arasındadır, ancak her zaman aynı değildir. Çoğunlukla aynı anda yapılan aktarımlar aynı anahtara bağlı telefonlara yöneliktir, ancak bazen ağın karşıt uçlarındaki telefonlara birlikte yapılan aktarmalar da gerçekleşir. Genellikle TCP trafiğini geçerken, örneğin istemci makineleri ve dosya sunucuları arasında bazı çakışmalar vardır.

Yeniden aktarımlardaki ve telefon sıfırlamalarındaki ani artışlar, ağın yoğun bir şekilde yüklendiği zamanlar ile iyi bir ilişki kurmaz. Gündüzleri biraz daha fazla gözüküyorlar, ancak çoğu akşam trafiğin azalması gereken yerlerde. Çoğu bilgisayar kapatıldığı ve trafiğin en düşük olduğu yerlerde gece geç saatlerde oldukça sık görülür.

Bu gibi sorunların nedenini teşhis etmeye yardımcı olabilecek herhangi bir fikriniz var mı? Henüz denemediğim, ama yapmam gereken bir şey, tüm anahtarların ürün bilgisini güncellemektir.

networking tcp voip

— gerçeküstü
kaynak

1

Hangi model değişir? İşlemci, memeory vb istatistikleri nasıl görünüyor? Bir yayın alanında mısın? Ağda maksimum verime ne kadar yaklaşıyorsunuz?

— Zypher

Hangi VoIP protokolünü kullanıyorsunuz? Ayrıca, UDP veya TCP kullanarak?

— Chris S

Tüm anahtarlar 3Com'dur: Temel 2924 - PWR Plus (3CBLSG24PWR) x 2,4200 (3C17304A) x 3, 4200 (3C17304) x 2,2824 (SPC Artı) (3C16487), 2250 artı (3C16476CS). İşlemci ya da bellek hakkında istatistikler verdiklerini sanmıyorum, ancak aksini öğrenmekten çok memnun olurum. Evet, bir yayın alanındayız. Verimliliği bilmiyorum, ölçmeye çalışacağım.

— Gerçeküstü

17

TCP yeniden iletimleri genellikle ağ tıkanıklığı nedeniyledir. Sorunun gerçekleştiği sırada çok sayıda yayın paketini arayın. Yakalamalarınızdaki yayın trafiği yüzdesi, yakalanan toplam trafiğin yaklaşık% 3'ünden fazlaysa, kesinlikle tıkanıklık yaşarsınız. Ağdaki hem fiziksel katman (ARP) hem de ağ katmanı (ad çözümlemesi) yayınlarını arayın. Yüksek miktarda yayın trafiği bulursanız, onu yakalama verilerinden kaynağa kadar izleyebilirsiniz.

— joeqwerty
kaynak

9

Buna ek olarak, TCP yeniden iletimi, sorununun nedeni değil, sorunun bir belirtisidir.

— joeqwerty

UDP yayınlarına bir göz attığımı ve yeniden iletimle bağdaşmadıklarını söylemeliydim. Yeniden iletme olaylarından birkaçı UDP yayınlarındaki ani yükselmelerle çakışıyor, ancak çoğu yok. Başka bir bakış açtım ve UDP yayınlarının 10 dakikalık herhangi bir zaman diliminde trafiğin% 1,5'ini (yaklaşık 350 paket) aşmadığını ve bu seviyeye ulaşmanın nadir olduğunu gördüm. Ancak ethernet yayınlarına bakmadım. Şimdi tüm wireshark günlüklerimi filtrelemek için bir komut dosyası çalıştırıyorum. UDP yayınları ve ethernet yayınları için% 3 genel kural tek tek mi yoksa bir arada mı?

— Gerçeküstü

1

% 3, gerçekten bir kural değil. Bana söylenenler ve kendi çevremde gördüklerim. % 10 ila% 20 arasında değişen sayılar duydum ancak% 3 ila% 5'i aştığında, genellikle sorunlara neden olduğunu gördüm. Tüm yayın trafiğine bakmanız gerekir: ethernet, ağ ve çok noktaya yayın yayınları, hepsi tıkanmaya neden olabilir. Temel olarak, tüm anahtar bağlantı noktalarına yayınlanan herhangi bir trafik, analiz edilmesi ve azaltılması veya ortadan kaldırılması gereken trafiktir.

— joeqwerty

Uzun bir süre boyunca iyi bir korelasyon olup olmadığını kontrol etmek için hala birlikte güzel bir grafiğe sahip değilim, ancak ethernet yayınları oldukça umut verici görünüyor. Yeniden iletimin gerçekleştiği bir günlük,% 3’ün hemen üzerinde yayın yapıyordu, diğeri ise% 6’ydı. En azından bir problem buldum: eski bir sunucu, sabit ARP paketlerini sürekli olarak yayınlıyor.

— Gerçeküstü

1

Aşırı ARP girişlerini Wireshark filtresi arp- kullanarak ve yalnızca yayınları görmek içineth.addr==ff:ff:ff:ff:ff:ff

— mlhDev

2

Anahtarlarınız için trafik istatistiklerini toplamak, kapasitenizde veya yakınında çalıştığınız sürelere sahip olduğunuzu gösterebilir. Bu, cevaplar inital zaman aşımı süresi içinde geri gelmediğinde (genellikle 3 saniye) tekrar denemelere neden olabilir. Bu, tıkanıklığı azaltma mekanizmaları devreye girene kadar anlık olarak tıkanıklığı artırır.

Akış ortamını kullanan kişileri arayın; bu, bant genişliğini hızla emdirebilir.

Trafik şekillendirme ile telefonlarda problemi azaltabilirsiniz. Bu sadece sorunu diğer kullanıcılara taşıyacaktır.

— BillThor
kaynak

2

Yayılan bir ağaç döngüsüne veya bana bir yayın fırtınası gibi geliyor, özellikle de yeniden iletimler ve sorunlar aynı anahtara lokalize edilmişse (farklıdır). Bu olduğunda, L2 cihazınızdaki port durumları nelerdir? Muhtemelen kötü bir anahtar veya kötü bir kök köprü öncelikleri? İlginç bir problem.

— McJeff
kaynak

Benden cahilce cahil olduğum yayılan ağaçları okumamı istediğin için teşekkür ederim. Bununla birlikte, yayılan bir ağaç döngüsü olabileceğini düşünmüyorum, çünkü ağımızda fazladan bağlantı yok (muhtemelen kendi içinde bir sorun var). "L2 cihazınızdaki port durumları" ile, yayılan ağaç algoritması neticesinde anahtarların hangi portları etkinleştirdiğini söylüyorsunuz? Bir kök köprüsünü el ile yapılandırmadık, bunu yapmak iyi bir fikir olabilir mi?

— Gerçeküstü

STP'yi tanımak iyi bir fikirdir, ancak herhangi bir gereksiz bağlantınızın olmadığından eminseniz, STP sorunu olmaz.

— joeqwerty

Evet, fazladan bağlantınız yoksa, sorun olmaz. Liman devletleriyle, evet, hangisinin ileri / engellendi / öğrendiğini kastediyorum.

— McJeff

2

Muhtemelen çok uzun zamandan beri bu sorunu çözdünüz, ancak esas olarak uç noktaları olan bağlantı noktalarında (voip telefonlar, iş istasyonları, sunucular) "hızlı bağlantı noktasını" etkinleştirmeniz gerekir. Bir telefon PDU'ları gönderebilir, böylece eğer bu adam yeniden başlatılırsa bir STP yakınlaşmasına neden olur, böylece FDB tablasının yıkanmasına ve tüm cihazların 4/5 adım STP eğlencesine girmesine neden olur. Uç noktası olan bağlantı noktalarını "bağlantı noktası hızlı" konumuna getirerek beklemeyi atlarlar ve doğrudan ileri sarma moduna giderler.

— barak s.
kaynak

1

Umarım telefonlarınız diğer bilgisayarlardan farklı bir alt ağda ve VLAN'dadır?

— Greg Askew
kaynak

Hayır, aynı IP alt ağındalar ve aynı VLAN'dan da eminim. Bu ciddi bir problem mi? Kesinlikle iyi bir fikir olacak gibi geliyor. Telefonlar için yayın alanlarını ve diğer her şeyi ayıracağını görebiliyorum. Başka bir avantajı olur mu?

— Gerçeküstü

Evet telefonları kesinlikle özel bir VLAN'a koyardım.

— Greg Askew

1

Ayrıca hatalı bir anahtar gibi hatalı bir ekipman parçası olabilir. Yeniden iletimler, ağın belirli bir anahtarındaki veya bir bölümündeki telefonlar / bilgisayarlarla ilişkili mi?

Sadece cevabımı biraz uzatmak için. Tüm anahtarlar aynı özelliklere sahip olsalar bile eşit yaratılmazlar. Bazıları diğerlerinden çok daha fazla yük ile başa çıkabilirler çünkü içeride daha hızlı işlemcileri vardır. Anahtarların çok yüksek değil.

En sıkıntılı VOIP telefonlarınızdan bazılarını kendi fiziksel anahtarlarına koyarak başlar ve bu cihazlardaki sıfırlama işlemlerinin devam edip etmediğini görürsünüz. Eğer giderse, o zaman çok yakında çözme yolundasınız demektir.

— Mat
kaynak

Keşke yapabilselerdi. Ağın karşıt uçlarında bulunan iki anahtara bağlı cihazlarda en çok sorun olduğu görülüyor. Ancak, şebekenin diğer bölümlerinde de telefonlara önemli miktarda yeniden aktarım var.

— Gerçeküstü