Проблема в следующем: существует достаточно большой сегмент сети, построенный на коммутаторах данных моделей. Если смотреть трафик tcpdump'ом, то сразу видны некоторые недобросовестные товарищи, от которых постоянно льется куча arp-запросов на несуществующие сети и адреса (не broadcast!!!). причем видно, что идет просто явный перебор всех ip адресов в сети с определенной маской, прописанной у пользователя. Что это такое, к сожалению так выяснить и не удалось (вирус или червь???), с пользователями тоже бороться устал. Есть ли способ избавиться от такой активности и отрезать эти запросы прямо на коммутаторах без вреда остальной сети. Спасибо.

Я так понимаю у Вас проблема ARP-spoofing-а? Отсечь подобную активность можно только на коммутаторах серии DES-35XX в вашем случае при помощи механизма SafeGuard Engine. http://www.dlink.ru/technical/faq_hub_switch_77.php

ИМХО это деятельность вирусов sasser, blaster и им подобных.
Для прекращения этой деятельности нужно заблокировать порты 135, 445. До кучи ещё можно заблокировать 137, 138, 139 и 113 (через последний валятся частенько irc-атаки).
После запретов этих портов перестанет валиться вирусный трафик, юзеры перестанут звонить и говорить, что их атакуют, но при этом перестанет работать сетевое окружение, а магистральное железо вздохнёт свободнее.

На самом деле пробовали. Не помогает. У меня после таких настроек правда коммутаторы, которые расположены за тем, на котором эта опция была включена, начали отваливаться. Дело-то ведь не в том, что коммутаторы не выдерживают, а в том, что от этого трафика дохнет Cisco!!! Она это воспринимает как DoS-атаку и перестает принимать и передавать трафик на интерфейсе. Пробовал также играться с Broadcast Storm Control и DLF, но тоже результата не было. Может быть еще есть какие-нибудь механизмы?

Я же вам говорил про ограничение на DES-35XX ARP и IP Broadcast при помощи SafeGuard Engine.

т.е. при постоянно флудящем 1 компе - будут блокироваться ARP пакеты от всех добросовестных позьзователей?
а если у меня CPU не сильно перегружен и нижнее пороговое значение установить не так просто? но вышеуказанный трафик продолжает сыпатся?
имхо, это не решение. точнее решение, но не той проблемы

На данный момент эта функция срабатывает глобально на коммутаторе.

Проблема-то в том, что загрузка цпу на коммутаторе не превышает 20-30%. Вообщем более менее помогло коплексное решение: QoS + ACL. Закрыл часть ненужного трафика с помощью ACL и с помощью них же стал метить трафик, проходящий внутри сети (меньший приоритет) и уходящий наружу (наивысший приоритет).

SafeGuard Engine корректно не работает на 6500, принося только проблемы (не отрабатываеться arp запросы, что приводит к увеличению арп шторма). Как этот функционал будет работать на 3526, не скажу, не поднимаеться рука проверить на рабочей сети.
Вот типичный лог на коммутаторе (прошивки всех модклей и процессора последние).

Для представителей Д-Линк - все дополнительные подробности можно узнать в питерском представительстве.

А для больших сегментов, пока единственное лекарство - блокировака tcp/udp портов 135, 137-139, 445. Установка traffic control (ограничение броадкастов и мультикастов), dlf будет работать только при включенном stp (смотри фак на сайте).
Желательно использовать acl для отсечения трафика не принадлежащего сети.

Вышлите пожалуйста полное описание проблемы по SafeGuard Engine с графической схемой сети, конфиг файлом коммутатора и пошаговым описанием воспроизведения проблемы. Желательно чтобы это описание было и у нас именно от Вас.

И очень правильное лекарство, потому что
1. пользователи не будут заражать друг друга
2. неразумные пользователи не смогут выложить свой жёсткий диск по сетевому окружению с правами записи.