Чому ми отримуємо великі коливання на графіку вимірювання пропускної здатності кактусів?

Ми проходили тест на надмірність Etherchannel та Routing у нашій мережі. Під час цього втручання ми зробили деяке вимірювання. Наш інструмент моніторингу - кактуси для графіка. Моніторинг обладнання - це 4500-X на VSS. Кожне посилання знаходиться на різному фізичному шасі.

Схема:

Хронологія тесту:
[t0] Посилання на порт te1 / 1/14 було фізично видалено. Te2 / 1/14 активний. Po1 працює.
[t0 + 15] Посилання на порт Te1 / 1/14 повернулося до служби та перевірило, що порт назад в ефірному каналі Po1
[t0 + 20] Посилання на порт te1 / 1/14 було фізично видалено. Te2 / 1/14 активний. Po1 працює.
[t0 + 35] Посилання на порт Te1 / 1/14 повернулося до служби та перевірило, чи порт повернувся в ефірний канал Po1

У наших тестах ми відстежували ефірний трафік Po1 через кактуси (графік нижче) і помітили значну зміну значення потоку, коли ми відключили зв'язок te1 / 1/14 (активність посилання te2 / 1/14) досить стабільним під час зворотного руху . Ми також перевірили лічильники на int Po1, і вони підтримувались досить стабільно.

Два інтерфейси 10G вбудовані в ефірні канали з налаштованим LACP. Всередині ефірного каналу їх 2 влани. Один для багатоадресного трафіку та інший для Інтернет / Весь трафік.

Чи знаєте ви можливу причину такої поведінки?

Щоб продовжити коментар ytti.

Ваш інтервал опитування здається дійсно невеликим, кожні 10 секунд, якщо я читаю правильно. Є кілька причин, за якими ви могли отримати такий результат.

Сторона обладнання:

• Поганий вибір лічильників, якщо ви використовуєте 32-бітні лічильники, вони можуть перевертатися кожні ~ 3,4 секунди, якщо ви користуєтесь 10 г інтерфейсом за лінійною швидкістю
• Під час оновлення, багато великих пристроїв оновлюють лічильники лише два-три рази на хвилину, і вони ніколи не можуть покладатися на синхронізацію. Кожні 30 секунд є меншим, ніж я б заважав опитуванню, і навіть тоді я завжди хотів би принаймні два бали, перш ніж запускати будь-яке попередження або вживати заходів
• Можливо, є патч, оскільки пакети, надіслані на обробку процесора (можливо, потоки потоків), можуть бути зараховані одразу проти тих, хто не збирається перезавантажувати RE (бачили це на Juniper MX)

Сторона Поллера:

• Чи точне опитування опитувача на інтервалі, і якщо ні, то чи вводить його результат у фактичний час опитування (наприклад, х біт за йз секунди), тож можна обчислити розумну швидкість
• Що відбувається, коли лічильники скидаються або SNMP GET не реагує на них, різні інструменти реагують на них по-різному

Ваша проблема полягає в тому, що вибірки маршрутизатора та власне опитування не потрапляють в одну мить. Тобто, хоча інтервал опитування є статичним, інтервали опитування містять різну кількість вибірок, яку ваша математика не враховує.
Подумайте, що ви опитували t1, t2, t3, але маршрутизатор нічого не взяв на вибір в інтервалі t1, t2, тому весь трафік між t1, t3 закінчився на t2, t3 опитуваному значенні. Причиняючи, що ваш показник дорівнює 0 при t1, t2 і перевищує лінійний на t2, t3

Зараз я пропоную одне рішення, але, будь ласка, підтвердьте це тим, хто має побіжне розуміння математики.

Спочатку з’ясуйте інтерфейс, який вас цікавить (якщо ge-1/1/1):

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

Тоді ви побачите його номер ifIndex, припустимо, що він "42".

Тоді зробіть щось на кшталт:

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

Тепер проаналізуйте результати, щоб визначити, як часто в середньому лічильники фактично оновлюються. (Я можу створити сценарій для аналізу, якщо це потрібно)

Потім йде частина, де нам знадобиться математика, але я запропоную одне наївне рішення.

Якщо інтервал оновлення становить 10 секунд, опитуйте поле кожні 5 секунд, тобто вдвічі частіше, ніж оновлення. Тоді ваші зразки були б

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

Тепер це були б ваші необроблені дані, які ви б не використовували, але краще відновити фактичні зразки з них так

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

Обґрунтуванням цього є те, що ми хочемо просочитися за межі, щоб зменшити дію неточних інтервалів опитування на вашому комутаторі.

Потім ви побудуєте s1, s2, s3, і ви повинні мати набагато більш плавний / точний результат, ніж те, що ви зараз бачите.

Однак я впевнений, що це не нова проблема, і я впевнений, що існує формальне рішення, як відновити оптимальну точність, на жаль, виробництво цього рішення не в моєму наборі навичок. Щось із математики. Люди, що обміняються, краще підходити для вирішення.

Оскільки ви опитуєтесь із тією ж швидкістю, що й лічильники, оновлюються, ви, ймовірно, не синхронізовані.

Налаштувавши

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

ви можете зменшити інтервал, в якому лічильники SNMP оновлюються, приблизно на 1 секунду. Це повинно призвести до більш точного значення пропускної здатності, коли ви опитуєте кожні 10 секунд.

FYI, це прихована команда.