Уважаемые господа! Прошу помочь мне разобраться в следующем вопросе:
Построенная нами сеть основана на управляемых свитчах. 3-4 назад на одном сегменте сети произошел полный пипец...
сеть легла напрочь на несколько дней, пока не нашли виновника....
Для предотвращения возникновения подобной ситуации хочу попытаться разобраться в причинах происшедшего.
Кратко и упрощенно изложу схему сегмента сети.
1 На одном из узлов стоит DES3010FL (в дальнейшем - №1)
Boot PROM Version Build 1.01.009
Firmware Version Build 4.30.B20
Hardware Version A3
порты устройства 1-8 подключены к абонентам
9 порт на магистраль
на устройстве для абонентов определены VLAN212
для самого устройства определен VLAN130
config ipif System ipaddress 192.168.130.250/24 vlan vlan130
9 порт - тэгированный трафик с vlan130 и с VLAN212
Для устройства также задействованы trusted_host, включен address_binding для каждого из 8 портов абонентов
2 Цетральный узел (в дальнейшем №2). На нем стоит DES3828. На каждом порту тэгированные VLAN.
Для каждого VLAN определен ipif. Системный интерфейс вынесен в отдельный VLAN.
Задейстовано ip_mac_binding, acl, trust host, acl cpu .....
№2 приходит во второй порт №1. На других портах №1 также есть VLAN212. VLAN130 также имеется надругих портах.
В принципе всю необходимую информацию о настройках оборудования могу в дальнейшем более подробно выложить.
Итак в день Х VLAN212 и VLAN130 лег на всей зоне покрытия.
После ночных бдений вышли на направление которое являлось причиной возникшей проблемы - абоненская сторона - №1 порт 8.
ну и соответственно приходит на №2 порт-2.
Симптомы - на абонентских машинах полностью отсутствуют ARP таблицы и как следствие сеть не работает.
Причем сталкивались с фактом когда они и не были пустые, но в них было конечно же не то что нужно:) Ну об этом чуть позже.
С устройством №1 связи не было. С подобными №1 устройствами на том же сегменте связь была.
Разница было только в наличии cpu acl... на устройстве №1 он в спешке не был введен.
Установили acl cpu на №1 - связь не пропадает. Наблюдаем дальше. BlockByAddrBind - прет со страшно силой.
Причем идет подмена (и я бы даже не сказал что это подмена потому что нарушитель - не компьютер) работающих в сети ip и mac.
К сожалению не знаю в каком случае срабатывает ipmac_biding в случае пересылки траффика проверяется связка - ip-mac или при ARP запросе.
Итак обнаружили 8 порт на устройстве №1. В стороне от этого устройства но на том же VLAN стоят две тестовые машины.
С них запущен тестовый пинг между собой и по всем возможным устройствам сети VLAN212.
При disable порт 8 на устройстве №1 - все работает. делаем enable порта 8 (на устройстве №1 покатили сообщения BlockByAddrBind)
тестовые машины теряют пинги со всеми кроме как между собой. Причем теряют не сразу. Один пропал, через один пропал, через 5 пропал
и так до полного пропадания. ARP таблицы - чистые. Вносим статику - все равно не катит.
ВЫрубаем 8 порт - мгновенно все нормально (ну понятно таблицы чистые - сразу заполнились). На 2 порту устройства №2 арп записи
тестовых машин есть и они верные. на устройстве №2 сообщения possible spoof atack.
Тестов проводилось много и разных. Потому как работали три дня и работали уже с условием не устранения а изучения проблемы.
Поэтому задавайте вопросы - я постараюсь на них ответить. Единственно к сожалению не делались тесты на анализ
полного проходящего траффика по портам - такой возможности к сожалению не было.
Виновник был найден. Им оказалось устройство стоящее у абонента - switch DES1005D. На нем 2 порта не работают, а с первого порта
прет вот такое Мы выкупили его для дальнейших экспериментов и поставили новое подобное устройство абоненту.
Для определенности взяли это устройство и воткнули его патч кордом в другой сегмент сети ... Сегмент сразу лег. Т.е. есть возможность
проводить эксперименты. Больше всего смущает что за траффик должно создать такое устройство чтобы при организованной защите на
управляемом оборудовании получить такую картину. И что нужно предпринять чтобы в дальнейшем подобного не возникало?!
С уважением, Виктор. Надеюсь на помощь по данному вопросу.
P.S. сейчас начало месяца (идет отчетность), поэтому ориентировочно в субботу ставлю нарушителя на стенд. Ставлю снифер (надеюсь
на повторяемость картины) и весь траффик смогу увидеть и детально изложить.

В первую очередь нужно действительно изучить структуру генерируемого флуда и по результатам использовать функционал loopdetect, traffic control, port_security.

Сталкивались с такой ситуацией, когда строили некоммерческую сеть с применением DES-1008 и DES-1005. Ситуация там такая: при убивании хотябы одного порта на коммутаторе, если он (порт) не заглушен, то через какое-то время коммутатор начинает дублировать пакеты во все порты, но подставляет в них рандомные маки.
Тогда управляемых свитчей не было, поэтому бороться не могли никак. Способ был один, под страхом отключения на месяц запрещали дома ставить д-линковские мыльницы. И сами поменяли все 1008 и 1005 (тогда на компехи).
У меня лежит дома такой 1005, но никак не могу заняться и поэкспериментировать с ним.

дело действительно как писал Alteron и loopdetect эту ситуацию решает.
У меня попутно другой вопрос. Модель DES 3016 и IP-MAC bindig.
На порту данного свитча включена данная функция. Если абонент сменил ip адрес его MAC попадает в таблицу блокированных адресов и уйти оттуда он может только если сбросить его вручную со свитча. Т.е. если абонент переустановил ОС и ошибся с настройками ip то даже если он потом и поставит правильный адрес - работать он сможет только после удаления администратором его блокированной записи со свитча. Это крайне неудобно. Можно использовать Address Binding Auto Recovery Interval - установить например 60 сек. В этом случае запись удалится самостоятельно, но при этом возникает другой момент. Если выполнить несанкционированное подключение выбрать любой свободный ip и с произвольным MAC адресом - то данное подключение будет заблокировано только на время - Address Binding Auto Recovery Interval. По истечению которого сетевая активность данного подключения восстанавливается. Другими словами берем компьютер, подключаемего в порт свитча с включенной функцией IP-MAC bindig и с отсутствующей записью для данного компьютера. Запскаем ping на рессурс в сети. И пот истечении времени Address Binding Auto Recovery Interval - пинг начинает идти, ну и все остальные сетевые возможности становятся доступными.
Подскажите как можно решить данный вопрос для данной модели оборудования?
Спасибо

На DES-3016 эта проблема не решается, Вам надо использовать коммутаторы более старших моделей - DES-3028, DES-3200