>>> повторяю: цифры, тесты?
>>> раз вы упомянули pf:
>>> 1)http://forum.nag.ru/forum/index.php?showtopic=47497
>>> 2)http://forum.nag.ru/forum/index.php?showtopic=18744
>> Здесь с тем же успехом могли вылезти тормоза из-за переброса пакетов между
>> фаерволами. А тут сравнивают «PF+ipfw+клей vs. ipfw» вместо «PF vs. ipfw».
> Если вас это интересует, могу сделать тест на 2х сокетном quad core
> Nehalem и гигабитной сетке.Сделайте. Если можно, пожалуйста, на отдельной страничке где-нибудь выложите результаты, вместе с dmesg и описанием всех использованных sysctl-ек, а здесь просто ссылку киньте. Сам постараюсь сделать такой тест вечером (в дополнение к обещанному) на третьем пеньке, который у меня домашнюю локалку обслуживает: гигабитного Intel'а с двух сторон, думаю, будет достаточно.
>> Вот другой пример, именно сравнения равного функционала: http://lists.freebsd.org/pipermail/freebsd-performance/2010-...
>> ; не то чтобы конкретный слив, но преимущество PF заметно.
> Test scheme:
> laptop(192.168.0.188)-->age0(192.168.0.1)-->rl0(10.1.2.142)-->internet
> после этого можно дальше не читать. 1GE/10GE во внешний мир уже не
> редкость.
Если бы всё упиралось в скорость канала, то и заметной разницы между фильтрами бы не было, м-м-м?
>[оверквотинг удален]
> 2)выкручиваем таймауты до 2х часов
> 3)настраиваем nat транслировать всё из сети /8
> 4)с помощью ядерного генератора трафика создаём 1.4mpps udp-пакетами из сети /8 с
> рандомными src port.
> Так вот, при ~ 200-300k стейтов в топе оказывается pfpurge и swi1:net.
> При этом видно, что на исходящем интерфейсе начинаются провалы по pps
> а сам pf начинает просто дропать трафик.
> С netfilter всё было куда скучнее: медленная деградация производительности по мере увеличения
> числа стейтов. при 2млн стейтов на выходе было ~ 700kpps и
> почти полная загрузка всех ядер.
А это уже интереснее, несмотря на искусственность условий. Можно поподробнее? Списки правил и статистику фаерволов («pfctl -si» и «iptables -n -L -v») хотя бы.
BTW, о птичках: какие версии netfilter и PF? А то был у меня один знакомый любитель сравнивать PF из 2006 года и netfilter из 2010. А в PF за последние несколько лет много чего улучшили (уж не знаю, портировали последние изменения во фряху). На http://pf4freebsd.love2party.net/ вообще пишут, что во фряхе сейчас PF из OpenBSD 4.1, то есть четырёхлетней давности. Производительность у PF из 4.1 и 4.9 на большом количестве стейтов может различаться в несколько раз запросто: в промежутке были переписаны в том числе как раз NAT-подсистема и таблица стейтов; помню пример с Soekris'ом, производительность которого после одного из нововведений поднялась аккурат в два раза.
>[оверквотинг удален]
> см. мои тесты выше.
>> Только фряху, боюсь, я туда не вкорячу ради эксперимента, ибо уволился.
>> :) А так — http://www.mail-archive.com/freebsd-pf@freebsd.org/msg0...
>> , например.
> там чистый роутинг. вот подробнее и с NAT:
> https://calomel.org/network_performance.html
> "When the MTU is limited to 1500 (standard MTU for most of
> the Internet) we hit almost 10 million packets over sixty secods
> (9,666,777 packets or 161,112 pps) and 1.9333 gigabits per second."
> 161kpps. посмотрите на моих цифры и подумайте еще раз про скорость :)
Ваши цифры, если вы вспомните, взяты из трафикогенератора. То есть не учитывают обработку входящих пакетов и переброску между интерфейсами. Так что напрямую сравнивать результаты ваши и у Саломеи, мягко говоря, некорректно.
>> Инсталяция базовой системы, поднятие pfsync (одна команда ifconfig) и CARP (ещё 1-2
>> команды ifconfig). Всё, дальше оно само. Ну, ещё не грех те
>> же команды в /etc/rc.conf записать, разумеется. :) Остальное — написание правил
>> собсно фаервола (для ленивых есть Firewall Builder, например).
> pfsync в GENERIC нет. ALTQ тоже.
Ага, виноват: повторюсь, не слежу внимательно за фряхой. Кстати, вы NPF не пробовали? А то у меня руки так и не дошли его нагрузить...
