Мы проходили тестирование избыточности 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 секунд, если я читаю правильно. Есть несколько причин, по которым вы могли бы получить такой результат.
Сторона оборудования:
Сторона поллера:
источник
Ваша проблема такова, что выборка вашего маршрутизатора и ваш собственный опрос не попадают в один и тот же момент. То есть, хотя интервал опроса является статическим, интервалы опроса содержат разное количество выборок, которое ваша математика не учитывает.
Предположим, что вы опрашивали t1, t2, t3, но маршрутизатор не делал выборки с интервалом t1, t2, поэтому весь трафик между t1, t3 оказался на уровне t2, t3. Причинение вашей скорости будет 0 в t1, t2 и выше линейной скорости в t2, t3
Теперь я собираюсь предложить одно решение, но, пожалуйста, проверьте это с кем-то, кто имеет поверхностное понимание математики.
Сначала выясните интерфейс, который вас интересует (если ge-1/1/1):
Затем вы увидите его номер ifIndex, давайте предположим, что это 42.
Затем сделайте что-то вроде:
Теперь проанализируйте результаты, чтобы определить, как часто в среднем обновляются счетчики. (При необходимости могу изготовить скрипт для анализа)
Затем наступит момент, когда нам понадобится математика, но я предложу одно наивное решение.
Если ваш интервал обновления составляет 10 с, опрашивайте каждые 5 с, то есть в два раза чаще, чем он обновляется. Тогда ваши образцы будут
t0, t5, t10, t15, t20, t25, t30
Теперь это будут ваши необработанные данные, которые вы бы не использовали, но вы бы предпочли восстановить реальные образцы из них, как это
Обоснование здесь заключается в том, что мы хотим просочиться через границы, чтобы уменьшить влияние неточных интервалов опроса на вашем коммутаторе.
Затем вы построите график s1, s2, s3, и вы получите гораздо более плавный / точный результат, чем вы видите сейчас.
Однако я уверен, что это не новая проблема, и я уверен, что есть формальное решение, как восстановить оптимальную точность, к сожалению, создание этого решения выходит за рамки моих навыков. Что-то в математике. Обмен людьми был бы лучше подготовлен для решения.
источник
Поскольку вы опрашиваете с той же скоростью, что и счетчики, вы обновляетесь, вероятно, вы не синхронизированы.
Путем настройки
Вы можете уменьшить интервал обновления счетчиков SNMP примерно до 1 секунды. Это должно привести к более точному значению пропускной способности при опросе каждые 10 секунд.
К вашему сведению, это скрытая команда.
источник