greyshadow

Ну есть edge-core ES3550, а есть cisco catalys 3550, если траф маршрутить - то одной кошки может и хватит, а если абонов по многоэтажкам переключать - то пачка edge-core ES3550 как раз и пригодиться

Прямо пропорциональная, вопрос только к коэффициенте пропорциональности и зависимости - экспоненциальная, логарифмическая, квадратическая, гиперболическая... ну и в смещении...

• Blat Attack — These switch result from sending a specially crafted packet to a machine where the source host port is the same as the destination host port. The system attempts to reply to itself, resulting in system lockup. Реакция на SIP или торрент или еще чего, где src port = dst port на L4.

Должна.

Не, классно Вы вообще то айджинг АРП с эйджингом ФДБ сравнили. - Это пять! Ох ёпть... При укзанных данных, проходит 301 секунда (при условии, что клиент уже выключен), свич MAC снес или нет? естественно снесет, сервер будет еще 895 секунд помнить, что у IP 172.17.20.19 мак 00:26:2d:61:76:7d.. и весь трафик для IP 172.17.20.19 будет благополучно инкапсулировать во фрейм с dst MAC 00:26:2d:61:76:7d и футболить в интерфейс... и где тут противоречие??? Что коммутатор будет делать с этим фреймом???

А поточнее? медиаконвертор не подходит?

Может это его нормальный трафик? кинчик качал или еще чего? Хотя пик на 22:00 довольно хорошо накладывется на самую первую картинку, крайний правый пик на 150М какраз примерно в это время...

Берите стаб с запасом минимум 40% от планируемой реальной нагрузки (при пониженном напряжении чтобы нормально вытягивал) и обратите внимание на время переключения. А так - думаю обе марки указанные вами вначале не должны доставить вам хлопот при отсутствии изначального брака в изделии.

Ну это первое, на что надо было проверить

Кстати, насчет dhcp, arp и т.д. с таймаутами, Вот результат вывода arp-а с самого обычного bsd-ного сервера БЕЗ всяких подкруток, тюнингов и вообще с генерик ядром: (172.17.20.19) at 00:26:2d:61:76:7d on vlan0 expires in 1196 seconds [vlan] т.е. сервак будет его помнить еще более получаса!!! А у свичей как травило таймаут небольшой, например edge-core по дефолту show mac-address-table aging-time Status: Enabled Aging time: 300 sec.

собственно есть простой метод предварительной проверки - гасите найденного абонента на сутки например (их там, кстати, как минимум 2!, на графиках в первом сообщении 2 графика нижние, которые полностью видны) там где 150М пики четко виден не только OUT, но и IN трафик, а вот на 50М IN-а уже нет, вероятно выключены были.

Сравните масштабы и шкалы! на высланом вами графике около 12:00 и далее 00:00 есть четкие всплкески в 50М как на вход так и на выход, хороше совпадающие с пиками из первого поста. Вы статистику по unicast, broadcast и multicast фреймам со свича снимаете?? усли еще нет - очень советую начать, на ucast эти пики были бы видны очень хорошо. Кроме того отсутствие подобных пиков на bcast и mcast статистике только подтвердило бы мои слова... или наоборот - наличие бы говорило именно о bcast или mcast шторме.

Надо не забывать, что есть еще протоколы Л2-уровня - arp, dhcp, pppoe. Они умеют срать броадкастом. А arp к тому же еще и умеет засорять МАС-таблицы свичей и роутеров. Так что одного только Л3-фильтра по IP недостаточно, надо бы запретить абону по arp анонсить несвой IP и сильно ограничить пропуск броадкаста (например, 10 пакетов в сек). То, что я показал только некую выжимку из всего, что делал вам в голову не пришло?? После анализа бродкаста и мультикаста предположение о высере бродкаста или мультикаста в сеть было забраковано. Прежде, чем выкатить сюда результаты своих изысканий я про

ув.morfey, вас не затруднит опубликовать график порта свича в сторону шлюза (если возможно - там где именно абонентский трафик гуляет, если у вас на шлюзе 2 или более физических интерфейса) в тот же период, что и графики в первом сообщении??

Увы, чистейшая практика! 2 дня занимался диагностикой, анализом и отловом. Нет там L3 коммутатора агрегации, весь L3 приземлен прям нашлюзе, от абона до шлюза - только L2.

Учитывая, что нормальный УПС сам по себе - уже стабилизатор, да еще и железобетонной синусоидой и напругой на выходе - хочется вам действительно странного Разве что УПС вы планируете ставить эдак года через 2-3. Бюджет какой планируете??

http://local.com.ua/forum/topic/43780-странное-поведение-в-сети-петля/page__st__40

ИМХО. Для серверной стаб менее 600Вт. - выброс денег на ветер. Если для серверной - может таки раскошелиться на UPS??? Имеется ввиду нормальный, инверторный, а не гуано за 100-300 баксов

Ну и есть плешь тому, кто эти тенды выпускает.... Пусть прошивку пилит.

Я запретил на рутере с абонентского интерфейса пакеты с src IP адресами, отличными от абонентских, т.е. по схеме выше, сервак от абонов принимает пакеты только с src_IP из Net_1 и Net_2, но это только часть решения, пришлось так же запретить принимать пакеты вида [src ip <Net_1>; dst ip <Net_2>] и наоборот (т.е. запретил общение между абонами разных подсетей). Эффект практически сошел на нет, но окончательно удалось избавиться только после того, как убрал алиасы.

Очень здравая мысль - мне такое то же в голову приходило. Запросто может быть какое то триперьё которое генерирует пакеты с разными маками, чем перепирает таблицу коммутации на свиче агрегации. А так как все в одном влане, то свич начинает работать как хаб и разливает вполне себе легеминый трафик по всем портам - вот тебе и графики. В таком варианте со стороны сервака не было бы ответной реакции - MAC не его, значит трафик игнорим, а она (реакция) есть....

Как возможный вариант, если на роутере активировано клонирование MAC-а, он может тоже поступать аналогичным образом.

На картинке - примерная сеть. Что было обнаружено: Роутеры A,B,C работают, все нормально, все хорошо. Вдруг B "гаснет", свич sw1 сносит его mac из таблицы коммутации, но с сервера продолжают еще "долетать" пакеты вида [src IP <a.b.c.d>; dst IP <IP_роутера B>], т.к. сервак ничего не знает о состоянии роутера B и благополучно хранит его MAC в arp-е сервер отправляет соответствующий фрейм в соответствующий интерфейс. Т.к. коммутатор уже MAC для B не помнит, он как и положено футболит фрейм на роутеры A и C, по всем правилам жанра A и C должны его проигнорировать, т.к. dst MAC

Еще вопрос - алиасы на интерфейсе есть? (на интерфейсе в сторону абонентаов)

траф между VLAN-ами на шлюзе запрещен???