Почему мы получаем высокую флуктуацию на графике Cacti измерения пропускной способности?

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

Схема:

Хронология теста:
[t0] Ссылка на порт te1 / 1/14 была физически удалена. Te2 / 1/14 активен. Po1 работает.
[t0 + 15] Ссылка на порт Te1 / 1/14 вернулась в сервис и проверила, что порт обратно в etherchannel Po1
[t0 + 20] Ссылка на порт te1 / 1/14 была физически удалена. Te2 / 1/14 активен. Po1 работает.
[t0 + 35] Ссылка на порт Te1 / 1/14 вернулась в сервис и проверила, что порт вернулся в etherchannel Po1

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

Два интерфейса 10G связаны на Etherchannels с настроенным LACP. Внутри эфирного канала их 2 vlans. Один для многоадресного трафика и другой для Интернета / всего трафика.

Вы знаете возможную причину такого поведения?

Чтобы расширить комментарий YTTI.

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

Сторона оборудования:

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

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

• Точно ли опрашивает опросник на интервале, и если нет, то вводит ли его результат с фактическим временем опроса (например, x бит в yz секундах), чтобы можно было рассчитать разумную скорость
• Что происходит, когда счетчики сбрасываются или SNMP GET не отвечают, разные инструменты реагируют на них по-разному

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

Теперь я собираюсь предложить одно решение, но, пожалуйста, проверьте это с кем-то, кто имеет поверхностное понимание математики.

Сначала выясните интерфейс, который вас интересует (если ge-1/1/1):

ПЕРЕКЛЮЧАТЕЛЬ snmpbulkwalk 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 секунд.

К вашему сведению, это скрытая команда.