Mengapa kita mendapatkan fluktuasi tinggi pada pengukuran bandwidth, grafik Cacti?


14

Kami berada di uji redundansi Etherchannel dan Routing di jaringan kami. Selama intervensi ini kami melakukan beberapa pengukuran. Alat pemantauan kami adalah Cacti untuk grafik. Peralatan yang dipantau adalah 4.500-X pada VSS. Setiap tautan ada pada sasis fisik yang berbeda.

Skema:

etherchannel 1

Kronologi uji:
[t0] Tautan pada port te1 / 1/14 telah dihapus secara fisik. Te2 / 1/14 aktif. Po1 operasional.
[t0 + 15] Tautan pada Te1 / 1/14 port kembali ke layanan dan memeriksa bahwa port kembali dalam etherchannel Po1
[t0 + 20] Tautan pada port te1 / 1/14 secara fisik dihapus. Te2 / 1/14 aktif. Po1 operasional.
[t0 + 35] Tautan pada port Te1 / 1/14 kembali berfungsi dan memeriksa bahwa port tersebut kembali dalam etherchannel Po1

Dalam pengujian kami, kami memantau etherchannel Po1 lalu lintas melalui Cacti (grafik di bawah) dan melihat perubahan signifikan dalam nilai aliran ketika kami menonaktifkan tautan te1 / 1/14 (tautan aset te / 1/14) yang agak stabil selama proses sebaliknya. . Kami memeriksa juga penghitung pada int Po1 dan ini dipertahankan cukup stabil.

Grafik

Dua antarmuka 10G dibundel pada Etherchannels dengan LACP dikonfigurasi. Di dalam etherchannel mereka adalah 2 vlan. Satu untuk lalu lintas Multicast dan lainnya untuk Internet / Semua Lalu Lintas.

Apakah Anda tahu kemungkinan penyebab perilaku ini?


Berapa lama Anda mengikuti setiap tes?
laf

Setiap pemutusan port memakan waktu 15 menit seperti yang Anda lihat pada kronologi.
cgasp

Apa tipe konfigurasi port-channel dan load-balance Anda di kedua sisi? Apa yang dapat Anda ceritakan tentang rangkaian uji dan parameter yang menghasilkan lalu lintas itu - satu aliran, banyak aliran, protokol, dll.
generalnetworkerror

Dua antarmuka 10G dibundel pada Etherchannels dengan LACP dikonfigurasi. Di dalam etherchannel mereka adalah 2 vlan. Satu untuk lalu lintas Multicast dan lainnya untuk Internet / Semua Lalu Lintas. Pertanyaan diperbarui.
cgasp

Tes ini pada tes redundansi generalis pada protokol routing dan etherchannels. Jika tautan turun apa yang terjadi. Semua tes berjalan seperti yang diharapkan tetapi kami bertanya-tanya mengapa perilaku ini pada pengukuran bandwitdh.
cgasp

Jawaban:


11

Untuk memperpanjang komentar ytti.

Interval jajak pendapat Anda tampaknya sangat kecil, setiap 10 detik jika saya membaca dengan benar. Ada beberapa alasan Anda bisa mendapatkan hasil itu.

Sisi peralatan:

  • Pilihan penghitung yang buruk, jika Anda menggunakan penghitung 32-bit, penghitung bisa berguling setiap ~ 3,4 detik jika Anda menjalankan antarmuka 10g dengan laju garis
  • Pembaruan konter, banyak perangkat yang lebih besar hanya memperbarui penghitung dua atau tiga kali dalam satu menit, dan mereka tidak pernah bisa diandalkan untuk sinkron. Setiap 30 detik adalah serendah aku akan mengganggu polling, dan bahkan kemudian aku selalu ingin setidaknya dua poin sebelum memicu waspada atau mengambil tindakan
  • Mungkin ada gotcha karena paket yang dikirim untuk pemrosesan CPU (netflow mungkin) dapat langsung dihitung vs mereka yang tidak akan RE sedang batch (telah melihat ini di Juniper MX)

Sisi Poller:

  • Apakah polling polling akurat pada interval, dan jika tidak apakah itu menyuntikkan hasilnya dengan waktu polling yang sebenarnya (misalnya, x bit dalam yz detik) sehingga laju yang masuk akal dapat dihitung
  • Apa yang terjadi ketika penghitung diatur ulang, atau SNMP GET tidak ditanggapi, alat yang berbeda meresponsnya dengan cara yang berbeda

1
Bahkan jika Anda melakukan polling dengan sangat akurat pada setiap N, kotak tersebut mungkin tidak meng-polling penghitung HW pada interval yang akurat, membuatnya tampak seperti t1, t2 tidak melihat peningkatan traffic dan t2, t3 melihat over linerate. Sekarang hasil yang paling akurat yang bisa Anda dapatkan mungkin dalam ranah math.stackexchange, tapi saya yakin yang terbaik yang dapat Anda lakukan adalah 2 * the_slowest_update_interval, jika kotak memperbarui setiap 10an, Anda dapat memiliki data pengukuran setiap 20an. Tetapi mungkin dengan beberapa sihir statistik Anda dapat membuatnya lebih dekat dengan 10-an (masalahnya di sini adalah bahwa interval pembaruan tidak waktunya tepat)
ytti

1
Juga, polling mana yang Anda gunakan dengan Cacti penting pada interval polling 10 detik. Saya memiliki pengalaman buruk dengan poller default pada interval polling rendah. Tidak disebutkan apakah mereka menggunakan Spine atau poller default.
Brett Lykins

6

Masalah Anda adalah demikian, sehingga pengambilan sampel router dan polling Anda sendiri tidak mengenai momen yang sama. Artinya, meskipun interval pemungutan suara adalah statis, interval pemungutan suara berisi jumlah sampel yang berbeda, yang perhitungan matematika Anda tidak diperhitungkan.
Pertimbangkan Anda telah melakukan polling pada t1, t2, t3 tetapi router tidak mengambil sampel apa pun pada interval t1, t2, sehingga semua lalu lintas antara t1, t3 berakhir pada t2, nilai polling t3. Menyebabkan rate Anda menjadi 0 pada t1, t2 dan lebih linerate pada t2, t3

Sekarang saya akan menyarankan satu solusi, tapi tolong verifikasi ini dengan seseorang yang memiliki pemahaman matematika sepintas.

Antarmuka gambar pertama yang Anda minati (jika ge-1/1/1):

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

Maka Anda akan melihat nomor ifIndex-nya, mari kita asumsikan '42'.

Kemudian lakukan sesuatu seperti:

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

Sekarang menganalisis hasil untuk menentukan seberapa sering rata-rata counter benar-benar diperbarui. (Saya dapat menghasilkan skrip untuk analisis jika diperlukan)

Kemudian muncul bagian di mana kita membutuhkan matematika, tetapi saya akan menyarankan satu solusi naif.

Jika interval pembaruan Anda adalah 10 detik, pilih kotak setiap 5 detik, yaitu dua kali lebih sering saat diperbarui. Maka sampel Anda akan menjadi

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

Sekarang ini akan menjadi data mentah Anda, yang tidak akan Anda gunakan, tetapi Anda lebih suka memulihkan sampel aktual dari itu seperti ini

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

Alasannya di sini adalah, bahwa kami ingin membocorkan batas untuk mengurangi efek interval pemungutan suara yang tidak akurat pada saklar Anda.

Anda kemudian akan memplot s1, s2, s3 dan Anda akan mendapatkan hasil yang jauh lebih mulus / akurat daripada yang Anda lihat sekarang.

Namun saya yakin ini bukan masalah baru dan saya yakin ada solusi formal bagaimana memulihkan akurasi yang optimal, sayangnya menghasilkan solusi itu di luar keahlian saya. Sesuatu matematika. Pertukaran orang akan lebih siap untuk mengatasi.


3

Karena Anda memberikan suara dengan kecepatan yang sama dengan penghitung yang diperbarui, Anda kemungkinan besar tidak sinkron.

Dengan mengkonfigurasi

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

Anda dapat mengurangi interval penghitung SNMP diperbarui menjadi sekitar 1 detik. Ini akan menghasilkan nilai yang lebih akurat untuk throughput ketika Anda melakukan polling setiap 10 detik.

FYI, ini adalah perintah tersembunyi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.