Здравствуйте!
Не подскажете, чем может быть вызвана высокая (100% !) загрузка cpu на указанном в шапке свиче? На портах все очень скромно:



Прошивка - последняя из доступных (получена от сотрудников D-Link по почте):
Boot PROM Version : Build 2.01-B01
Firmware Version : Build 4.50-B09
Hardware Version : 5A1.2A1

Никаких сильно умных функций в свиче не используется:


Стоит 9 штук Vlan'ов, 5 ip интерфейсов.... Таблицы ip и mac свободны:


Как выяснилось методом тыка, всю нагрузку на процессор создает один порт (номер 5 - если судить по таблице выше, то загрузка там крайне небольшая), на котором висит 3526 (управляющий интерфейс в отдельном нетэгированном vlan - для будущих обновлений, клиенты в другом тэгированном vlan), в который вставлены клиенты. На 3526 клиенты режутся acl'ами - бродкасты остаются только arp, убираются левые порты и т.п. Т.е. на dxs-3326 трафик поступает уже более-менее "нормализованный" - полностью очищен от всех бродкастов, кроме arp, нет повышенной активности на netbios'овских портах, убираются все ip-пакеты, исходящие от адресов не принадлежащих этой подсети...
Вопрос вполне очевиден: куда копать, чтобы понять, что именно грузит CPU? Если надо что-то на нем фильтровать - то что именно для примера?

Сначала надо определить что конкретно грузит устройство. Вы можете поснифферить сеть на этом порту?

Естесственно, я это сделал сразу же. Отмиррорил порт на подключенный к этому же коммутатору компьютер и посмотрел tcpdump'ом - навскидку ничего подозрительного не увидел. Сейчас смотрю trafshow - тоже самое. Трафик как трафик... Обычный интернетовский у тех пользователей, которые сидят без VPN, трафик до VPN-сервера у остальных, ну и внутрисетевой...
Собственно, я этого и хотел изначально: чтобы вы подсказали, чего именно мне искать. Т.е. какие в принципе пакеты могут грузить процессор коммутатора. А уж фильр для tcpdump я сам сооружу.
Спасибо заранее!

ARP спуфинг, большое кол-во IGMP запросов. Вы можете кстати сказать кол-во записей в ARP-таблице.

Мммм... Поставил на компьютере, на который миррорится трафик, arpwatch - там ничего подозрительного нет. Мирно появляются хосты, изредка пробегают 0.0.0.0, которые еще не получили адреса... Но ни одного flip flop'а или даже просто изменения mac-адреса нет. Собственно, это логично, потому что подопытный сегмент достаточно небольшой, одновременно с включением его в dxs там сменили полностью адресацию и "спуферам" там взяться просто неоткуда...


Вообще нет. IGMP полностью фильтруется на 3526


Хотя это даже лишнее, потому что ACL'ами вообще зарезаны все ethernet'овские бродкасты, кроме arp.
Я же говорю - на dxs трафик поступает абсолютно нормализованный, "причесанный" и без каких-либо аномалий - я его весь в tcpdump, trafhsow, а теперь еще и в arpwatch'е отсмотрел...





Между прочим, самое интересное, что несмотря на перманентные 100% загрузки, коммутатор работает отлично: потерь нет, по telnet'у и snmp доступен, пользователи через него подключенные не жалуются... Еще пару дней пройдет и я начну думать, что это все - нормальная ситуация и переживать не стоит. ))

А вы не могли бы прислать полный конфиг устройства?

Итак, проблема решена, но чтобы поставить точки над i, стоит обнародовать суть, чтобы другие не наступали на те же грабли. А суть очень простая: нужно выносить управляющий ipif/vlan от всех возможных трафиковых потоков. Т.е. это штука известная, но в основном применительно к L2 свичам, а мне почему-то казалось, что у L3 другие правила и хуже не будет, если ipif System станет смотреть в ядро. В общем, на собственном опыте могу сказать, что ipif System больше 30-50 мегабит переварить не в состоянии в принципе, да и те - с потерями и загрузкой CPU под 100%. Сейчас после вынесения интерфейса управления в отдельный vlan (как раз где ipif System от разных 3526 находятся...), где данных по сути вообще нет - коммутатор воспрял и начал вовсю молотить трафик с загрузкой cpu меньше 10%.
Надеюсь, эта информация кому-нибудь поможет.