Bant genişliği ölçümü Kaktüs grafiği üzerinde neden yüksek dalgalanma oluyor?

Ağımızda Etherchannel ve Routing yedeklilik testindeydik. Bu müdahale sırasında bazı ölçümler yaptık. İzleme aracımız grafik kaktüsleridir. İzlenen ekipman VSS'de 4500-X'dir. Her bağlantı farklı bir fiziksel kasa üzerindedir.

Şema:

Test kronolojisi:
[t0] te1 / 1/14 bağlantı noktasındaki bağlantı fiziksel olarak kaldırıldı. Te2 / 1/14 aktif. Po1 çalışır durumda.
[t0 + 15] Te1 / 1/14 bağlantı noktasındaki bağlantı hizmete döndü ve eterchannel Po1'deki bağlantı noktasının
[t0 + 20] te1 / 1/14 bağlantı noktasındaki bağlantının fiziksel olarak kaldırıldığını kontrol etti. Te2 / 1/14 aktif. Po1 çalışır durumda.
[t0 + 35] Te1 / 1/14 bağlantı noktasındaki bağlantı hizmete döndü ve tekrar eterchannel Po1'deki bağlantı noktasının kontrol edildiğini kontrol etti

Testlerimizde, Kaktüslerden Po1 trafik eterkanalını izledik (aşağıdaki grafik) ve ters yönde oldukça kararlı te1 / 1/14 bağlantısını (bağlantı te2 / 1/14 varlıkları) devre dışı bıraktığımızda akış değerinde önemli bir değişiklik fark ettik. . Biz de int Po1 sayaçları kontrol ve bunlar oldukça kararlı tutuldu.

LACP yapılandırılmış Etherchannels'da 10G'nin iki arayüzü paketlenmiştir. Eterchannelin içinde 2 vlans vardır. Biri Çok Noktaya Yayın trafiği ve diğeri İnternet / Tüm Trafik için.

Bu davranışın olası bir nedenini biliyor musunuz?

Ytti'nin yorumunu uzatmak için.

Eğer doğru okursam 10 saniyede bir anket aralığınız gerçekten küçük görünüyor. Bu sonucu elde etmenizin birkaç nedeni var.

Ekipman tarafı:

• Kötü sayaç seçimi, 32 bitlik sayaçlar kullanıyorsanız, hat hızında 10g arayüz çalıştırıyorsanız her ~ 3.4 saniyede bir dönüyor olabilirler
• Sayaç güncelleme, birçok büyük cihaz sayacı yalnızca dakikada iki veya üç kez günceller ve senkronize olmalarına asla güvenilemez. Her 30 saniyede bir oylamayı rahatsız edebileceğim kadar düşük ve o zaman bile herhangi bir uyarıyı tetiklemeden veya harekete geçmeden önce her zaman en az iki puan isterim
• CPU işlemesi için gönderilen paketler (belki de netflow), toplu olarak RE'ye gitmeyecek olanlara (Juniper MX'de görmüş) karşı hemen sayılabileceğinden bir gotcha olabilir.

Poller tarafı:

• Poller aralıkta doğru bir şekilde yoklanıyor mu ve eğer değilse, gerçek yoklama süresi ile sonucunu enjekte ediyor mu (örneğin, yz saniye cinsinden x bit), böylece makul bir oran hesaplanabilir
• Sayaçlar sıfırlandığında veya SNMP GET'lere yanıt verilmediğinde ne olur, farklı araçlar bunlara farklı şekillerde yanıt verir

Sorununuz, yönlendirici örneklemeniz ve kendi yoklamanız aynı anda çarpmıyor. Yani, yoklama aralığı statik olsa da, yoklama aralıkları, matematiğinizin dikkate almadığı farklı miktarda örnek içerir.
T1, t2, t3'ü yokladığınızı düşünün, ancak yönlendirici t1, t2 aralığında hiçbir şey örneklemedi, bu nedenle t1, t3 arasındaki tüm trafik t2, t3 yoklamalı değerde sona erdi. Oranınızın t1, t2'de 0 ve t2, t3'te aşırı hıza neden olması

Şimdi bir çözüm önereceğim, ama lütfen bunu matematik anlayışına sahip biriyle doğrulayın.

İlgilendiğiniz ilk arayüzü (eğer ge-1/1/1 ise):

snmpbulkwalk ANAHTARI ifDescr | grep ge-1/1/1

Sonra onun ifIndex numarasını göreceksiniz, diyelim ki '42'.

Sonra şöyle bir şey yapın:

while true; do
  snmpbulkwalk SWITCH ifHCInOctets.42 >> DATA
  date >> DATA
  sleep 1
done

Şimdi sayaçların ortalama olarak ne sıklıkta güncellendiğini belirlemek için sonuçları analiz edin. (Gerekirse analiz için senaryo üretebilirim)

Sonra matematiğe ihtiyaç duyacağımız kısım geliyor, ama saf bir çözüm önereceğim.

Güncelleme aralığınız 10s ise, her 5 saniyede bir anket yapın, yani güncellenen sürenin iki katı. Sonra örnekleri olurdu

t0, t5, t10, t15, t20, t25, t30

Şimdi bu, kullanamayacağınız ham verileriniz olurdu, ancak gerçek örnekleri bundan böyle kurtarmayı tercih edersiniz

s1 = (t0+t5+t10)/3
s2 = (t10+t15+t20)/3
s3 = (t20+t25+t30)/3

Buradaki gerekçe, anahtarınızdaki hatalı yoklama aralıklarının etkisini azaltmak için sınırların üzerinden sızmak istiyoruz.

Daha sonra s1, s2, s3'ü çizerdiniz ve şimdi gördüğünüzden çok daha düzgün / doğru bir sonuca sahip olmalısınız.

Ancak bunun yeni bir sorun olmadığından eminim ve en uygun doğruluğu nasıl elde edeceğime dair resmi bir çözüm olduğundan eminim. Bir şey math.stackexchange insanlar mücadele için daha iyi donanımlı olacaktır.

Sayaçlar güncellendiğinde aynı oranda yoklama yaptığınız için eşzamanlı olmayacaksınız.

Yapılandırarak

snmp-server hc poll <<hundredths of a second>>

SNMP sayaçlarının 1 saniye gibi bir sürüme güncellenme aralığını azaltabilirsiniz. Bu, her 10 saniyede bir yoklama yaparken verim için daha doğru bir değerle sonuçlanmalıdır.

Bilginize, bu gizli bir komut.