После перехода на Firmware версии 2.82.B19, появилась проблема с обработкой трафика - приоритеты обработки коммутатором определённого вида трафика на локально подключенных IPv4 интерфейсах (с транзитным трафиком такой проблемы не наблюдалось). Например UDP пакеты размером менее 1500 байт доходят с ощутимой задержкой (примерно от 2 до 20 минут).

После отключения функции "cpu_rx_rate_control":



Проблема устраняется, но при этом, примерно раз в 3-4 дня наблюдается загрузка CPU коммутатора до 100%, при этом коммутатор начинает работать нестабильно, до тех пор пока функция "cpu_rx_rate_control" не будет включена обратно.

Вы разжимаете канал для пакетов идущих на CPU с приоритетом от 0 до 2, нужно смотреть в какое время это происходит и с какой периодичность. В принципе, можно снять информацию какие пакетики идут на CPU с помощью debug команд и проанализировать их, и далее предпринять меры.

_________________
С уважением,
Бигаров Руслан.

Каким образом это можно сделать?

Firmware: Build 2.80.B35 Наблюдаем аналогичные симптомы. Проблема всегда оказывается в одном конкретном пользователе с узла. Его отключение сразу снимает загрузку, подключение наоборот. Что интересно загрузка появляется и снимается очень резко. Буквально за 2 секунды происходит скачок с 20 до 100% и наоборот. Выезды на место (2 случая) пока ничего не дали (возможно подчистили следы к нашему приезду). Подумываем над выездом на место и включением миррора на порту аксес свича. Если есть возможность как то подебажить или будут какие мысли на этот счёт будем очень признательны. Проблема пока не носит массовый харектер, но нужно как то понять причину, чтобы бороться.

А трафик на порту этого абонента чего кажет?
show packet port XX

Ничего особенного, от других абонентов ничем не выделяется.

Опытным путём было определенно, что к вышеописанным проблемам приводит включение cpu_rx_rate_control с приоритетом 2:





Остальные приоритеты (0 и 1) на передачу трафика не влияет (по крайней мере этого не было замечено).

1. Кто нибудь может подтвердить это на своём оборудовании?
2. Каким образом можно проследить какие фреймы попадают в очередь с приоритетом 2 и по каким критериям?

На коммутаторах DGS-3600 есть настройка:
config 802.1p user_priority 0 2
Т.е. клиентский трафик, приходящий на порт коммутатора доступа красится приоритетом 0, а попадая на коммутатор агрегации он попадает во второй класс(CoS), поэтому вам и помогает отключение.
Если на работу сети не влияет разжимание канала для CoS 2, то так и оставьте для безопасности сети.

P.S.: Но я советую присмотреться к флудящему клиенту.

_________________
С уважением,
Бигаров Руслан.

Нашли способ как снять загрузку проца после возникновения проблемы. Помогает чистка таблицы arp.
Руслан, можно ли как то подебажить на 3627 в эту сторону?
Как временное решение: опрашиваем свичи раз в минуту по snmp, далее если загрузка выше 90% - чистим таблицу arp по snmp. Сразу скажу что safeguard_engine проблему не решает, во всяком случае у нас.
anim, можете проверить на своей сети, поможет ли данное действие при возникновении проблемы?

И всё таки это не панацея, помогает в лишь 50-70% случаев с высокой загрузкой. Остальные 30-50% только отключение абона. Радует что появился абонент, трафик которого второй день подряд вызвал проблему на узле. Не радует продолжительность, пока собирались туда ехать загрузка спала.

Сколько записей в ARP таблице и какой arp_aging_time выставлен?!

_________________
С уважением,
Бигаров Руслан.

От 200 до 2500 arp-записей. С количеством записей проблема судя по всему никак не связана. На тех узлах где сегодня была проблема было около 400 arp-записей. ARP Aging Time : 30. Проблема обычно длится от минуты до часа, если ничего не делать. Либо спадает после cle arp.
Радует то, что какой либо видимой деградации для абонентов в это время судя по всему не наблюдается. Во всяком случае мы явных проблем не увидели (трафик на район не проседал). При трейсе конечно есть задержки на первом хопе от абонента, т.к. cpu загружен, но дальше всё гуд.
Включение cpu_rx_rate_control в момент проблемы так же не снижает нагрузки.
Очень хочется снять дамп в момент проблемы, но пока к сожалению это не удаётся.

Руслан?

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.

2 AndreiP > Указанные значения, это не нагрузка для данного коммутатора, нужно анализировать хар-р трафика и среднестатистическую загрузку коммутатора. Как я уже писал нужно смотреть в сторону обычного клиентского трафика. Вы раз в минуту опрашиваете коммутатор по SNMP только загрузку CPU или что-то ещё!? Вы трафик красите в сети?!

P.S.: Можно с помощью debug режима снять информацию какие пакетики приходят на CPU коммутатора.

_________________
С уважением,
Бигаров Руслан.

С какой версии прошивки доступен этот функционал. И хотелось бы получить инструкцию как посмотреть что сыпется на CPU коммутатора.