У меня есть блейд-корпус HP c7000, который содержит коммутаторы Cisco 3120X и Cisco 3120G под управлением ios 12.2 (58) SE1. Сами блейды загружены очень слабо, но многие интерфейсы на различных блейд-коммутаторах в шасси показывают довольно большое количество выходных падений. Если я проверяю количество выходных падений несколько раз, я не только вижу увеличение счетчика, но иногда оно уменьшается. Числа не коррелируют с пакетами / с, записанными на интерфейсе. Настройки QoS по умолчанию для платформы.
Следующие образцы были взяты в течение 30 секунд:
bc1019-3120-stack> sh int gi2 / 0/7 | я выводил капли Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Всего выпадений: 2255550 bc1019-3120-stack> sh int gi2 / 0/7 | я выводил капли Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Всего выпадений: 2255550 bc1019-3120-stack> sh int gi2 / 0/7 | я выводил капли Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Всего выпадений: 2255550 bc1019-3120-stack> sh int gi2 / 0/7 | я выводил капли Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Всего выпадений: 2255550 bc1019-3120-stack> sh int gi2 / 0/7 | я выводил капли Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Всего выпадений: 2255550 bc1019-3120-stack> sh int gi2 / 0/7 | я выводил капли Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Всего выпадений: 2255550 bc1019-3120-stack> sh int gi2 / 0/7 | я выводил капли Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Общее количество выпадений: 451110 bc1019-3120-stack> sh int gi2 / 0/7 | я выводил капли Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Общее количество выпадений: 451110 bc1019-3120-stack> sh int gi2 / 0/7 | я выводил капли Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Всего выпадений: 902220 bc1019-3120-stack> sh int gi2 / 0/7 | я выводил капли Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Всего выпадений: 1353330 bc1019-3120-stack> sh int gi2 / 0/7 | я выводил капли Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Общее количество выпадений: 1804440 bc1019-3120-stack> sh int gi2 / 0/7 | я выводил капли Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Общее количество выпадений: 1804440 bc1019-3120-stack> sh int gi2 / 0/7 | я выводил капли Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Общее количество выпадений: 1804440 bc1019-3120-stack> sh int gi2 / 0/7 | я выводил капли Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Общее количество выпадений: 451490 bc1019-3120-stack> sh int gi2 / 0/7 | я выводить скорость 5-минутная скорость вывода 301000 бит / с, 119 пакетов / с
1) Есть ли что-то еще, что может вызвать падение производительности, кроме того, что сервер не получает кадры достаточно быстро?
2) Какое максимальное количество выходных падений может записывать счетчик интерфейса? Это опрокидывается, когда достигает максимума?
3) Что можно считать нормальным снижением производительности?
источник
Ответы:
Если кто-то не очищает счетчики, вы никогда не увидите счетчиков типа одометра (которые увеличиваются в зависимости от действия пакета), они должны всегда увеличиваться. Эта часть звучит как ошибка.
Что касается, в частности, причин снижения производительности, существует так много разных причин, что очень трудно точно определить это. Иногда внутри объединительной платы коммутатора возникает перегрузка, которая может отображаться как падение выходного сигнала на исходящем интерфейсе. В редких случаях вы также можете получить микровзрывы, которые не отображаются при опросе с интервалом в 1 минуту, которые быстро перезагружают интерфейс, но затем очень быстро падают вниз. Я бы предложил захватить OMP SNMP для снижения производительности, а затем отобразить его и посмотреть, как он соответствует счетчику CLI.
Вообще говоря, вы не хотите никаких отбрасываний вывода, поскольку они указывают на пакет, который не добрался до места назначения. Но, если вы используете горячие ссылки (что, как вы говорите, нет), они в некоторой степени неизбежны, в основном из-за внутренней буферизации переключателей и т. Д.
источник
Моя первая мысль - это одноадресное наводнение, особенно если счетчики увеличиваются в унисон для нескольких портов в одном и том же vlan. Я согласен с Аароном, что уменьшение счетчика звучит как ошибка. Счетчик, вероятно, перевернется на 2 ^ 64, но это не произойдет в течение нескольких секунд. Я бы посчитал, что нормальный уровень снижения производительности равен нулю, но это нереально - даже в центре обработки данных. Вы делаете 10G Uplink?
источник
Похоже, вы попали в ошибку CSCtq86186. Эта ошибка была обнаружена в 3750-х, 2960-х годах, но она также может влиять на блейд-переключатели.
источник
Если вы испытываете одноадресное наводнение, запуск wireshark на одном из хостов или охват одного из портов должен показать это довольно быстро.
Похоже, у вас есть избыточные ядра в квадратной топологии? Если это так, попробуйте добавить эту команду в ваш интерфейс VLAN:
Таблицы CAM содержат записи в течение 5 минут, в то время как таблицы ARP хранятся в течение четырех часов (по умолчанию). Установка ARP для соответствия CAM может устранить одноадресное наводнение за счет небольшого увеличения ЦП. Устранение неполадок в таблицах ARP или CAM коммутаторов Catalyst 6500/6000
источник
Отбрасывание вывода довольно распространено на меньших коммутаторах с небольшими буферами, так как любой пакет истощает буфер. Я не очень знаком с 3120, поэтому я не могу говорить о размере его буфера, но, по крайней мере, это обычная причина, до которой можно получить снижение производительности.
Особые причины - блокировка заголовка линии (HOLB), когда несколько исходных портов отправляются в один пункт назначения, и поэтому мы получаем перегрузку. Другая распространенная причина - при переходе от более высокой скорости порта к более низкой, то есть от 10G до 1G или от 40G до 10G.
Я рекомендую вам запустить show controllers ethernet-controller X, где X - ваш порт. Вы должны получить некоторую информацию о сбоях вывода, например, если что-то пытается вывести на большие кадры, что может произойти, если у вас нет согласованного MTU в вашей сети.
источник