[RootConf] IPFW: несколько наборов правил и другие предполагаемые изменения

Apr 06, 2009 00:14

===
В марте, помнится, я написал в ipfw@ предложения по архитектурным улучшениям ipfw, как кандидат на GSoC 2008. Никто не отреагировал (многабукаф, фигли). Дальше, в конце мая в RU.UNIX.BSD разгорелся спор - народ хотел изменения "как Cisco ACLs, но лучше", однако конкретики не было, хотя со временем что-то уже вырисовалось, я поглядел на идеи для ( Read more... )

сети, netgraph, лытдыбр, freebsd, ipfw, админское

Leave a comment

Re: Для 17 адресов уже однозначно таблицу nuclight April 6 2009, 15:28:46 UTC
Хм, выглядит неплохо, на первый взгляд технических возражений нет, хотя надо еще подумать. Есть, впрочем, несколько туманных соображений, исходя из планов дальнейшего развития:
1) текущая максимальная длина такого списка без таблицы - 30 (из длины опкода), то есть предлагаемые изменения касаются диапазона 11-30 адресов, и вопрос, скольким людям это реально надо. Хотя, конечно, чуть менее ленивый юзер может извратиться и сделать блок { src-ip 1.2.3.4,... or src-ip 5.6.7.8,... or ... }, но тогда:
2) необходимо добавлять оптимизатор в парсер, чтобы он это мог ловить (а пока что, исходя из нагрузок, юзер может расположить их нужным в перечислении, чтобы линейный поиск самых частых срабатывал сразу же, это эффективнее и таблиц) - но оптимизатор туда и так неплохо бы добавить. Правда, другим путем - ввести вместо правил отдельный язык, и плоский набор опкодов (не поделенный на правила), пускай сразу весь оптимизирует. Здесь эта идея, кстати, пригодится для счетчиков count/log, потому что рулесет с точки зрения локов на SMP следует держать в read-only.
3) также, из (1) и планируемых изменений адресации таблиц/portset и регистров, не хочется вводить лишнюю сущность, не адресуемую машиной (уже упоминал, что возможность машинного управления неплохо б сохранить).

В общем, мысль интересная, но замеры бы не помешали.

Reply


Leave a comment

Up