Есть коммутатор выполняющий роль шлюза, в теме про "Постоянный EXHAUSTED mode на DES-3852" я уже писал что коммутатор уходит в режим с высокой нагрузкой CPU при работающих ACL и без них одинаково часто и почти постоянно.

Если я запрещаю все (т.е. все вообще) TCP/UDP, разрешаю только ICMP пакеты в правилах CPU Interface Filtering, то нагрузка входит в норму, но вот что странно, хотя при этом не должно быть влияния на трафик идущий не в коммутатор, а через него, но все же время от времени сеть у клиентов останавливается и пока принудительно не сделать ping до удаленного узла, то обмен трафиком не начинается.

Как мне изолировать именно коммутатор, учитывая тот факт, что у коммутатора на разных портах несколько IP адресов из разных подсетей и правил для блокировки именно из мне в CPU Interface Filtering не хватит просто никак даже при условии что адресов сейчас 8, а будет 24-32 ....

Как защищать коммутатор от лавинообразного трафика? Запрещать клиентам обмен с коммутаторам т.к. для них он является шлюзом полностью нельзя ... это приведет в блокировке сети.

Что делать в такой ситуации ... снифферить трафик и вырезать его в ACL - это каменный век ... никаких ACL не хватит, чтобы вырезать весь трафик (даже netbios блокировки съедают 520 правил для данного коммутатора, не говоря уже о чем-то серъезном).

Клиентов в сети на 8 интерфейсах коммутатора сидит около 250.

Все мучаюсь вопросом, способен ли 3852 заменить даже самый простейший linux-роутер или он неспособен форвардить трафик так же как это делают pc на базе linux?

Т.е. отказываться мне от pc или рассчитывать сделать сеть, способную на высокие скорости, на коммутаторах?

Задержки icmp при простейшем ping от 10 до 15 мс под нагрузкой коммутатора в 30%-50% неприемлемы, в то время как в спокойном состоянии они от 0.2 до 0.5 мс. Фактически при задержках выше 20 мс сеть практически неработоспособна.

А убить весь трафик, с dst_ip_mask ipif коммутатора пробовали?
Вообще, какие ACL создавались на коммутаторе?

Из предыдущего вашего поста я никакой конкретной информации не узнал

У коммутатора несколько IP в разных подсетях и убить весь такой трафик мне просто не хватит правил т.к. правила блокировки netbios по tcp и udp съели почти все возможные варианты. А адресов у коммутатора будет от 24 до 32 и по ICMP он должен быть доступен 100%.

ACL блокирующие 135-139, 445 TCP и UDP порты, больше там ничего нет. Эти ACL вполне стандартны, ошибок в них тоже нет.

Коммутатор при запуске пишет в логи следующую информацию.

Configuration had 0 syntax error and 6 execute error)

Пока придумал тут решение, благо портов свободных на разных коммутаторах много.
Беру 3550 и в него загоняю линки из подсетей в различные vlan'ы, а уже потом отдаю это все на 3852 в готовом почти пережеванном виде.
Пока (тьфу-тьфу-тьфу) работает и даже какая-то нагрузка на портах пошла. Отклики стали нормальными.
Жаль что пришлось одну подсеть на 255 адресов разбить на 4 vlan, но возможно проблема была в ней. Буду мониторить - отпишусь.
А по поводу ошибки в логах при запуске коммутатора вопрос актуален.
Вот такой текст что может значить? Configuration had 0 syntax error and 6 execute error)
Также интересно чем отличаются правила в CPU Interface Filtering от правил в ACL ?

А-а-а-а, только не это снова

13 2008/06/29 21:25:34 SafeGuard Engine enters EXHAUSTED mode и началось снова ...

Несколько дней бьюсь и все без толку, а нагрузка только 5-7% от рабочей но коммутатор стоит раком ... прошивал, перешивал, конфиги менял.

Нагружается и не выходит долгое время из штопора.

Посоветуйте стабильную прошивку или модель коммутатора, которую с уверенностью можно использовать в ядре и организовать транки с DGS-3100-48 (на связке этих коммутаторов я уже крест поставил), не умеют они транки между собой делать. Разве такое бывает?

DGS-3100-48 вообще интерфейсом поражает все мое воображение. Теперь все такие будут?

Пока обратно пересел на linux-роутер. На дома ставить 3026, 3526, 3550, 3052 и в таком духе можно, но как быть с ядром в котором хотелось бы если не стабильности на 100%, то хотя бы предсказуемости поведения оборудования.

А тут даже непонятно куда рыть.

ну с такими описаниями проблем можно их долго искать и не находить.

про отличия ACL и CPU ACL:
http://dlink.ru/technical/faq_hub_switch_68.php

Но если у меня этих интерфейсов CPU не один, а 32 (ведь при режиме работы коммутатора в качестве роутера все интерфейсы доступны для всех, независимо от подключенного vlan)?
Коммутатор имеет IP почти на каждом порту, как запретить атаки на эти IP? Правил не хватит, сразу скажу, т.к. IP коммутатора являются шлюзами клиентских сетей.

Я бы хотел узнать в чем принципиальные отличия этих двух настроек, а не как настроить и создать правило? Или для того, чтобы защитить коммутатор надо создавать правила в ACL и в CPU одновременно?

Решение должно быть в одном месте, а не в CPU и в ACL сразу.
=============================

NoFX, а какие могут быть описания, если рабочий коммутатор при почти нулевой нагрузке сам по себе уходит в EXHAUSTED mode (самое смешное что он это делает и без клиентов вообще) и при перезагрузке пишет 6 execute error? Он при этом продолжает работать и ничего с ним не происходит, кроме увеличенной нагрузки на CPU и увеличенных откликов при ICMP запросах.

Могу скинуть конфиги. Версию прошивки я указывал Build 4.00.B55.

Коммутатор DES-3550, через в который я собираю линки от подсетей, а потом переправляю на 3852 от подобных проблем не страдает и в EXHAUSTED mode не сваливается ни разу с теми же подключенными подсетями. Проблема в коммутаторе (аппаратно) или в нестабильной прошивке, которую, если возможно есть другая версия, то хотелось бы обновить.

делай раз - разрешаем ходит через свич железячному VLAN:

делай два - запрещаем всем видеть железную подсеть:

делай три - разрешаем пинговать интерфейсы свича и ходить через свич трейсам:

что имеем на выходе - юзеру можно пингануть адрес шлюза, сиречь интерфейс свича, через него можно пустить трейс в другую подсеть но при этом не видно ни железной подсети, ни каких либо ф-ций управления свичом ... да, для юзера ни веб, ни telnet, ни SNMP этого свича не видны ...


для эконовмии профилей/правил на 3526 я делал так:

и так:

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


если Вас всерьез мучает этот вопрос, то Вам просто необходимо понять что никакой linux роутер не сможет соперничать с L3 свичом, т.к. свич все делает аппаратно, в ASIC-ах и именно поэтому wire speed фильтрации/роутинга/etc. в linux Вы не получите никогда! про создание на базе linux 48-ми портового свича с теми же характеристиками что и у DES-3852 я просто скажу что это невозможно ... если я Вас не убедил - готов принять в дар Ваш DES-3852, всеравно ему с Вашим линухом не тягаться ...

_________________
с уважением, БП

replicant, Вы пробовали работать с официальным релизом прошивки (3.00.b57) - тем, который лежит на фтп-сервере?
Сразу скажу, что с я моделью DES-3852 не общался, однако имею дело с его "младшим братом" DES-3828. На четвёртых версиях фирмвари мне так и не удалось с ним подружиться - постоянный EXHAUSTET MODE абсолютно не даёт работать - а вот с третьей версией (3.00.b57 или с любезно высланной мне Иваном неофициальной версией 3.00.b59) коммутатор ведёт себя вполне удовлетворительно. Предолагаю, что и с DES-3852 ситуация в вашем случае может быть спасена "откатом" на более старый официальный релиз.

У меня почти так же и сделано, но:

Правил не хватает, потому что коммутатор автоматически превращает auto_assign port 1-50 в 50 независимых правил, а значит что мне 800 правил не хватит.

Он не хочет понимать запись вида port 1-50, ему надо по каждому порту отдельно! Я бы заблокировал, если бы их хватило.

А в CPU Interface Filtering вообще всего 5 профилей и 5 правил можно сделать. Остальное он не примет т.к. лимит.

А можно мне перебросить 3.00.b59 тоже, с сайта я скачаю версию постарее попробую прошить. Если что можно скинуть прошивку на verbascum'at'inbox.ru ? Буду любезен за стабильную версию.

да, интерфейсы видны всем IP адресам которые этот свич роутит


свич имеет IP интерфейсы во VLAN-ах, на тех портах которые в эти VLAN входят


см. выше


с приведенными выше настройками всего занято 2 шт. ACL профилей и 3 шт. CPU ACL профилей конструкция подобная приведенной выше у меня работает и не мешает роутингу между подсетями ... что я не так делаю?


CPU ACL регулируют трафик направленный непосредственно на CPU самого свича, т.е. интерфейс(ы), управление и др. ф-ции выполняемые CPU
обычные ACL регулируют трафик входящий в порт и не позволяют регулировать трафик направленный непосредственно на этот свич


да, т.к. разные ACL выполняют разные ф-ции ...


чем не подходит решение "обычные ACL + CPU ACL"? оно не кошерно?


это потому что 3550 осуществляет коммутацию на 2-м уровне, в то время как 3852 осуществляет роутинг на 3-м ... разницу улавливаете? для простоты понимания - 3550 - это хаб, 3852 - это роутер, т.е. каждый из них решает разные задачи ... так понятнее?

_________________
с уважением, БП

это by design так, тут ничего не поделаешь ... auto_assign, IMHO, вообще сделан для того удобнее работать ...


мысль о том чтобы блокировать тот же netbios не в агрегации а непосредственно на доступе в голову не приходила? 3550 это прекрасно может, перенесите чать правил на него, незачем усложнять конфиг 3852 ...


см. выше ... там вообще всего 3 профиля

_________________
с уважением, БП

это by design так, тут ничего не поделаешь ... auto_assign, IMHO, вообще сделан для того удобнее работать ...


мысль о том чтобы блокировать тот же netbios не в агрегации а непосредственно на доступе в голову не приходила? 3550 это прекрасно может, перенесите чать правил на него, незачем усложнять конфиг 3852 ...


см. выше ... там вообще всего 3 профиля

_________________
с уважением, БП