> Система выполняет свои фугкции полностью и ни один компонент не является
> узким местов - вот принцип сбалансированности. Ваш подход к сбалансированности системе
> чисто юзерский).

скажите, лично вы роутили 10 гигабит на PC?
для описанной вами в статье задаче достаточно dir-620 + openwrt.

хотя, раз вы всё пытаетесь оценить мой уровень, то в 2010 году вы задавали такие вопросы:

http://www.opennet.ru/openforum/vsluhforumID1/88075.html

>> уважаемый Артём! Если вы с чем-то не согласны, попробуйте хоть как-то аргументировать
>> свою точку зрения. Если вы считаете, что время state lookup в
>> pf не зависит от числа стейтов - подтвердите это чем-то(например, рассказав
>> про используемую структуру данных и время поиска/вставки/удаления элемента в ней).
> Зависит, но не так критично как вы думаете. Чисто из практики.

чисто из практики - это на forum.nag.ru
там вопрос выбора пакетного фильтра затёрт до дыр, даже профайлили его через hwpmc.

>По умолчанию кол-во стейтов ограничено 10000. Когда число стейтов будет равно 10000
> ПФ будет нормально работать и не "умрет" как вы пишите.

я писал про 600k стейтов. это в 60 раз больше дефолта, который вы озвучили.
600к набираются достаточно легко в сети не очень большого провайдера.

>Но просто не будет создавать новые подключения.

как мило. "дорогой пользователь, вы не можете сходить на любимый вконтактик, т.к. у нас на
NAS исчерпан лимит стейтов".

> Видел системы, построеные не мной, где кол-во было ограничено
> 200к и проблем с нагрузкой не было.

я ещё раз напоминаю про 600k стейтов :)
вообще, на стенде я создавал ~ 2млн стейтов.

>> afaik, в pf state table в openbsd защищена giant lock'ом(хотя, во freebsd
>> это несколько  иначе).
> Во freebsd скоро совсем  будет иначе. Имею ввиду PF SMP friendly
> :-)

1)до этого далеко
2)на текущий момент всё и так работает в однопоточном режиме
3)glebius довольно сильно переписывает pf, так что скорее будет openbsd pf и freebsd pf, достаточно сильно между собой отличающиеся.