Это на какой версии прошивки происходит?

Впервые я с таким столкнулся давно на прошивке 2.5х. Ничего полезного тогда не нашли, поставили замену из 3610. С тех пор долго не встречалось. Затем вылезло на 2.84.B18, обновление до 2.84.B35 не помогло.

В таком случае пришлите мне пожалуйста, описание топологии с указанием портов подключения. Конфигурацию устройства и выводы отладочных команд, которые Вы запрашивали в этой теме + полный вывод команды "sh tech", "sh fdb" и "sh arptable"

Сейчас я убрал с коммутатора несколько подсетей, в связи с чем уменьшился размер арп таблицы. Коммутатор не ребутился - просто ушло несколько интерфейсов. Я так понимаю, вывод нужно именно в момент, когда наличиствует проблема?

Да, чтобы было видно, что на CPU попадают пакетики, которых там не должно быть.

Отправил на почту.

Ответил Вам в почту.

Уже неделю как на одном из коммутаторов 3627G CPU нагружается на 100%
Настроен он вторым уровнем, перед ним как Л3 работает ДГС-3620.
Пробовали отключать все порты кроме входящего на проблемном 3627Г- иногда помогает, иногда нет.

Отправьте мне тоже на почту как можно диагностировать проблему.
Либо если знаете решение как устранить её, подскажите пожалуйста.

Boot PROM Version : Build 1.10-B09
Firmware Version : Build 2.84.B31
Hardware Version : 1A1G

Выслал

Можно мне тоже инструкцию?

Судя по всему, у нас такая же проблема, как и у shulik.

Время от времени (пару раз в месяц) в совершенно разных частях сети появляется абонент, у которого жуткие пинги до всего, что стоит за 3627G. При этом своя подсеть работает нормально, пинги от абонента к шлюзу(интерфейс на 3627G) и с коммутатора до этого абонента нормальные. Если в момент проблемы пользователю сменить IP - все тут же начинает летать, также быстро проблемы исчезает после clear arptable.

Не знаю поможет ли - в ходе разбирательства сошлись в том, что переполнялся HW L3 таблица, размер которой составляет 8к записей. У нас проблема появилась после включения IPv6, каждая запись которого занимала две записи в таблице. Также шла речь о том, что часть записей в таблице резервируется под статику, а значит под динамику остается около 7к записей. В итоге кому не повезло - ходит мимо таблицы через CPU.
Попробуйте сосчитать: (show ipv6 neighbor_cache ipif all all) * 2 + (show arpentry)

Хм, действительно, show ipv6 neighbor_cache ipif all all выдает 1600 записей, а вечерами 3800-4200 ipv4 arp entries, что в сумме больше 7000.
Спасибо большое, будем копать в эту сторону дальше.

Насколько я понял, штатными средствами (прошивка 2.84.B35) ipv6 отключить нельзя.
Поможет ли
create access_profile ip source_ipv6_mask 0:0:0:0:0:0:0:0 destination_ipv6_mask 0:0:0:0:0:0:0:0 profile_id 1
config access_profile profile_id 1 add access_id 1 ip source_ip 0:0:0:0:0:0:0:0 destination_ip 0:0:0:0:0:0:0:0 deny
?

Изучение link_local адресов IPv6 при выключенном IPv6 пофиксили, ЕМНИП, с прошивки 2.84-B40.

Похоже, что ipv6 ни при чем. Только что проблема повторилась при 3800 arp записей и 500 ipv6 соседей. Вроде как ничего не переполнилось. Победили опять с помощью clear arptable.
Продолжаю ждать волшебных дебаг команд от длинка.