[John_obn]

Я не тестил на Linux, т.к. много придется переписать, но на ваш взгляд, сколько Linux прожует трафика при тех же задачах(NAT в пул адресов, шейпинг/полисинг трафика, netflow) и на том же железе(E3-1270, Intel X520-DA2)?

[Dyr]

Мне осталось только tc настроить для шейпирования, тогда и смогу сказать.

[Giga-Byte]

Я не тестил на Linux, т.к. много придется переписать, но на ваш взгляд, сколько Linux прожует трафика при тех же задачах(NAT в пул адресов, шейпинг/полисинг трафика, netflow) и на том же железе(E3-1270, Intel X520-DA2)?

если это было адресовано мне, то не скажу. реальной нагрузки в 10GE нету.

[John_obn]

Мой вопрос адресован всем, кто использует Линух для таких задач.

[Hawk128]

Недавно тоже вынес НАТ на линух. Работает только НАТ и пока ничего более, как раз конфиг Е3-1270.

Трафика мало, 1.2-1.5 гига на вход, 600-700 на выход, нагрузка 6-8%.

 

С фри ушел, т.к. появилась нестабильность, pf начал впадать в какое-то заклиненное состояние, ошибок не давал.

[Уфаныч]

Об оптимизации ipfw:

 

03000 pipe tablearg ip from any to table(4) { xmit vlan11 or xmit vlan12 } // Incoming traffic shaping
3000 pipe tablearg ip from table(5) to any xmit vlan3918 // Outgoing traffic shaping

Позволю себе заметить, что с таким построением правила вы проверяете не только исходящий трафик, но и входящий. Нет ключевого слова out.

Ведь, не смотря на указание xmit if, у входящего этот if ещё пуст, его проверка впустую тратит время.

Предлагаю первым правилом сделать allow all from any to any in

 

Второе, о чём хотелось бы сказать - размеры таблиц.

rn_match - это поиск по дереву, соответствующему таблице ipfw. Довольно затратная операция.

Может, стоит переписать правила таким образом, чтобы уменьшить размер таблиц или вообще отказаться от них?

 

Ну и напоследок - netflow, наверное, стоило бы снимать на другой машине, зеркалируя на неё трафик.

 

Вы тестировали? Мои тесты показали крайне удручающую картину.

Отдельно отмечу невозможность настроек таймаутов соединений (кроме разве что перекомпилирования?).

А можно поточнее, как про картину так и про таймауты?

Изменено 15 апреля, 2014 пользователем Уфаныч

[DVM-Avgoor]

Об оптимизации ipfw:

 

Он тут с января мучится, ему уже 2 вагона советов дали. Но все равно по-итогу у него pfnat, ipfw pipe, ng_netflow - все невзирая на логику собрано, ох. Хотя все это добро можно было бы собрать в ipfw. А еще у него там ZFS и какой-то ftp_proxy проскакивает (а может там и pcap где-то приделан? кто знает...) Там увы уже ничего не поможет.

 

Поэтому линукс лучший выход - там все эти вещи реализуются не десятком методов, а обычно одним, инвариантным.

[Dyr]

DVM-Avgoor, конкретно от вас вообще ни одного совета не поступало, кроме вопроса "а почему бы не на ipfw nat?", да и собственным опытом "а вот у меня всё на ng_car + ng_nat + ng_netflow" что-то вы не стремитесь похвастать. Поэтому если у вас нечего больше сказать, проходите мимо уже. Заодно почитаете, зачем нужен ftp-proxy для pf.

 

Уфаныч, спасибо за конкретику, попробую.

 

Что вы имеете в виду под первым правилом "allow all from any to any in" и почему это должно помочь при шейпировании?

 

Поиск по таблице, насколько мне известно, как раз наиболее быстрый способ [в ipfw] проверить на соответствие ip. Если оптимизировать, то наверное, уже только с помощью правил ветвлений в отдельные таблицы.

 

По зеркалированию netflow такая мысль была, да.

 

 

 

 

 

 

 

 

[DVM-Avgoor]

DVM-Avgoor, конкретно от вас вообще ни одного совета не поступало, кроме вопроса "а почему бы не на ipfw nat?", да и собственным опытом "а вот у меня всё на ng_car + ng_nat + ng_netflow" что-то вы не стремитесь похвастать. Поэтому если у вас нечего больше сказать, проходите мимо уже. Заодно почитаете, зачем нужен ftp-proxy для pf.

 

Я вам дал самый лучший совет, а вы его игнорите.

[John_obn]

Dyr, мой прошлогодний топик на подобную тему, может что почерпнете для себя.

[DVM-Avgoor]

Там dadv дал дельные советы про выкорчевывание pf`а напрочь из ядра.

 

Всего 3 условия которые были актуальными 10 лет назад, и остаются таковыми до сих пор:

 

1) идеальная таблица роутинга содержит 2 роута

2) идеальный файрвол вообще ничего не содержит

3) идеальный нат имеет столько инстансов сколько ядер есть в системе

 

ТС упорно игнорил мои вопросы про содержимое таблиц, зато обвинить в том что не помогаю успел :)

[pfexec]

Он тут с января мучится, ему уже 2 вагона советов дали. Но все равно по-итогу у него pfnat, ipfw pipe, ng_netflow - все невзирая на логику собрано, ох. Хотя все это добро можно было бы собрать в ipfw. А еще у него там ZFS и какой-то ftp_proxy проскакивает (а может там и pcap где-то приделан? кто знает...) Там увы уже ничего не поможет.

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

т.е. если тебе нужен нат пула адресов, то надо брать pfnat. если тебе нужен удобный портмаппинг, опять же - pfnat.

если тебе нужен адекватный стейтфул фаервол, опять же - pf.

но если тебе нужно на блок адресов по маске полос нарезать - то без dummynet'а никак. а в него кроме как ipfw нечем трафик засовывать. ниудача.

опять же если вам надо pptp+gre nat нормальный, то alias_pptp.ko работает на libalias'е, но не работает в pfnat'е.

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

как итог, чтобы пользоваться всеми вкусняшками в любом случае надо использовать оба фильтра и держать в ядре подгруженные и pf.ko, и ipfw.ko.

ng_netflow ко всему этому имеет слабое отношение: его можно пристегнуть на сам интерфейс. или можно использовать pfflowd для freebsd в случае с pf.

Поэтому линукс лучший выход - там все эти вещи реализуются не десятком методов, а обычно одним, инвариантным.

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

[Dyr]

DVM-Avgoor, вы такой прикольный... Я вас попросил продемонстрировать ваш собственный опыт. То, что dadv дал по pf, как бэ неактуально для 10.0, поскольку glebius глобально переписывал pf на многопоточность, что и зарелизил.

 

Про идеальный файервол смешно, да.

 

Ответ на вопрос по содержимому таблиц:

 

root@nata1:/usr/home/dyr (23745) ipfw table 4 list| wc -l
   4502
root@nata1:/usr/home/dyr (23746) ipfw table 5 list| wc -l
   4502
root@nata1:/usr/home/dyr (23747) ipfw table 2 list| wc -l
   3636
root@nata1:/usr/home/dyr (23748) ipfw table 1 list| wc -l
   3920

 

P.S. Кстати, не прикольно ведёт себя FreeBSD с 82599 картой. В один нифига не прекрасный момент через интерфейс ix0 вообще перестаёт идти трафик, что входящий, что исходящий. tcpdump показывает по нулям. Помогает ifconfig ix0 down/up.

 

 

 

John_obn, спасибо за ссылку, подчерпнул несколько интересный вещей. Итог-то у вас какой, в результате, на Linux перешли или FreeBSD с ipfw nat?

[John_obn]

John_obn, спасибо за ссылку, подчерпнул несколько интересный вещей. Итог-то у вас какой, в результате, на Linux перешли или FreeBSD с ipfw nat?

Сижу на FreeBSD с ipfw nat несколько инстансов, пока не упрусь в производительность. Linux пока в далеких планах потестить, хочется увидеть реальных примеров с подобной нагрузкой.

Кстати, на счет SMP PF во фре 10-й - не тестил ее SMP-шность, но на просторах сети где то встречал графики сравнения ipfw и pf под нагрузкой, pf всего лишь поднялся по производительности до уровня ipfw, но не превзошел, и где то даже был совсем чуть ниже.

После перехода на 82599 иногда под нагрузкой при создании vlan интерфейса Фрю клинило либо на какое то время с последующим появлением ошибок на ix интерфейсе, либо вообще паника. Встречал такое на 8 Stable , под 10-й такое не проверял.

[Dyr]

John_obn, а не покажете свой файервол и генерацию правил, в том числе для ipfw nat? NAT в пул адресов, я так понимаю, у вас отсутствует? Таймауты ipfw nat не тюнили?

 

 

[John_obn]

Правила ipfw не меняются, только добавляются/удаляются нужные ip в таблицы. Некоторые правила можно поудалять уже, еще более соптимизировав, т.к. большинство фильтров можно вынести на доступ или агрегацию.

 

00100 skipto 13390 ip from any to any in
00150 skipto 12400 ip from b.e.e.f/27 to any out xmit vlan*
00200 pipe tablearg ip from "здесь наши сети через запятую" to table(2) out xmit vlan*
00300 skipto 11900 ip from "здесь наши сети через запятую" to table(2) out xmit vlan*
00400 pipe tablearg ip from any to table(4) out xmit vlan*
01000 netgraph 100 udp from table(20) to any dst-port 53 out xmit ix0
01050 skipto 11270 udp from table(20) to any dst-port 53 out xmit ix0
01200 netgraph 102 tcp from table(53) to not table(52) dst-port 80 out xmit ix0
01500 nat tablearg ip from table(11) to not table(50) out xmit ix0
11270 allow ip from table(50) to any out xmit ix0
11900 allow ip from table(52) to any out
11902 allow tcp from any 80 to table(53) out xmit vlan*
12100 deny ip from any to table(53) out xmit vlan*
12300 allow ip from me to any out
12400 deny ip from any to not table(54) out xmit vlan*
12500 allow icmp from any to any out
12800 allow ip from table(50) to table(50) out
12900 deny ip from any to table(57) out xmit vlan*
13200 allow ip from any to table(50) out
13300 deny ip from any to any out
13390 skipto 16000 ip from any to b.e.e.f/27 in recv vlan*
13400 pipe tablearg ip from table(1) to "здесь наши сети через запятую" in recv vlan*
13430 skipto 14000 ip from table(1) to "здесь наши сети через запятую" in recv vlan*
13450 pipe tablearg ip from table(3) to any in recv vlan*
13500 netgraph 101 udp from d.n.s.r 53 to table(20) in recv ix0
13550 netgraph 103 tcp from m.o.n.e 8000 to table(53) in recv ix0
13600 nat tablearg ip from any to table(10) in recv ix0
13700 allow tcp from table(50) to me dst-port 22 in recv ix0
13800 deny tcp from any to me dst-port 22 in recv ix0
13900 allow ip from any to table(50) in recv ix0
14000 allow ip from table(53) to table(52) in recv vlan*
14001 allow tcp from table(53) to any dst-port 80 in recv vlan*
14100 deny ip from table(53) to any in recv vlan*
14205 skipto 14300 udp from any to any in recv vlan*
14210 skipto 15000 icmp from any to any in recv vlan*
14220 skipto 15500 tcp from any to any dst-port 25,587 in recv vlan*
14230 skipto 15990 ip from any to any in recv vlan*
14300 deny udp from any to any dst-port 135-139,445 recv vlan*
14400 deny udp from any to any dst-port 1434 in recv vlan*
14500 deny udp from table(58) to any in recv vlan*
14600 allow udp from table(50) to table(50) in recv vlan*
14700 deny udp from table(59) to any in recv vlan*
14800 allow udp from any to any dst-port 67,68 in recv vlan*
14900 allow udp from table(50) to any in recv vlan*
15000 deny icmp from any to any frag in recv vlan*
15100 deny icmp from table(60) to any in recv vlan*
15200 allow icmp from table(50) to table(50) in recv vlan*
15300 deny icmp from table(61) to any in recv vlan*
15400 allow icmp from table(50) to any in recv vlan*
15500 allow tcp from table(62) to any dst-port 25,587 in recv vlan*
15600 deny tcp from table(64) to any dst-port 25,587 in recv vlan*
15700 allow tcp from table(50) to table(63) dst-port 25,587 in recv vlan* limit src-addr 25
15800 deny tcp from table(65) to any dst-port 25,587 in recv vlan*
15900 allow tcp from table(50) to any dst-port 25,587 in recv vlan* limit src-addr 25
15990 deny tcp from any to any dst-port 135-139,445 recv vlan*
16000 allow ip from table(50) to any in recv vlan*
16100 deny ip from any to any in recv vlan*
65535 allow ip from any to any

 

IPFW nat в пул адресов присутствует, серые сети разбиваются на /27 и хранятся в таблице 11 с tablearg, соответствующем nat instance

Таймауты не тюнил, жалоб не было.

Изменено 16 апреля, 2014 пользователем John_obn

[DVM-Avgoor]

ты не прав. у фряшочки есть больная проблема с фаерволами, - их два

 

Ойвэй. Я все ждал когда же ты добавишь за любимый мертвый pf. Я знаю твоё отношение к этому фаеру, но объективно сказать во фре не так уж сочно и сладко воткнут.

Многое выполняется в локе, хоть и более прецизионном.

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

 

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

 

 

Ну кривизна чьих-то рук не отменяет работоспособности инструмента, так-то :) Вообще нарезка пер-что-то в линуксе тоже возможна несколькими методами. Точнее матчинг под нарезку: хэши, u32, маркировка iptables... Но это тоже не отменяет правил ветвления, tc очень не любит линейные списки из тысяч позиций. У меня есть бохатый опыт с проблемами одного вредного погромиста, который упорно генерит линейные списки, и получается что 16ти ядерная машина под 400мбитами в полочке лежит. Но суровая правда жизни такова, что дабы вкусно кушать - потребно уметь готовить. Такие дела (С)

 

DVM-Avgoor, вы такой прикольный... Я вас попросил продемонстрировать ваш собственный опыт. То, что dadv дал по pf, как бэ неактуально для 10.0, поскольку glebius глобально переписывал pf на многопоточность, что и зарелизил.

 

Про идеальный файервол смешно, да.

А что опыт? До гига трафика на нате я даже не задумывался над кручением-верчением правил в таблицах. ng_nat + ng_ipfw. 512 инстансов, 2 таблицы по 512 правил, 4-5 правил в ipfw суммарно, цпу какой-то холопский 2Ггц хеон на 4ядра. Фрибсд 8.2.

Был в то же время нат-бордер на linux 2.6, 8 сетевых карт, 3 группы агрегации трафика (4г + 2г + 2г), трафик in+out~ 1.4 Mpps/6Gbps. Пришлось долго мучиться, дабы достичь такого результата. Делать наборы ip rule, роутинг укорачивать всевозможными методами. Процессор был Core 2 quad qx6800. Но тоже в последствии все это было убрано в пользу железяк (ибо они рулят).

А файрвол без правил это же лучше всего: ничего не делает - никому не мешает, идиллия. Вот netmap примерно так и работает, там ничего особого не происходит поэтому все быстро и сочно, только без фенечек.

 

Ну и правил в таблицах у вас тоже многовато, radix tree в бсд не отменяет факта того, что надо использовать логическое ветвление. rn_match в профайле как бы намекаэ.

[pfexec]

Многое выполняется в локе, хоть и более прецизионном.

лично мне глубоко пофиг на локи. мне десятки гигабит в нем не натить, мне даже гигабит там натить не надо. а всё что меньше оно справится с любыми локами, еще и бамбук будет успевать курить.

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

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

а вот удобство очень важно. ломать руки не хочется никому. просто ipfw в том виде в каком он есть - это эхо 4.Х. по сути нет разницы у тебя natd или ng_nat, или ipfw nat. конфигурица оно почти одинаково и умеет оно всё одинаковое. т.е. "отнатить в пул" не выйдет. одной строчкой "пробросить порты" тоже: надо сначало сконфигурить инстанс ната, потом еще в него запихать трафик, потом из него его достать. ох.

мне бы для моих целей и openbsd хватило за глаза. только dummynet'а или его аналога там нет. вот незадача то. ох.

 

меня печалит не то что нужно настраивать вместо одного фаервола два и не то что пакет (вот жеж ***ь беда то а, лол) пройдет по им обоим. а то что нету _нормального_ родного средства которое умеет и то, и другое. ты просто вынужден городить эти конвееры. альтернатив нет. или забей, или городи конвееры. ох.

Ну кривизна чьих-то рук не отменяет работоспособности инструмента, так-то :)

ох лол, кто бы говорил

Вообще нарезка пер-что-то в линуксе тоже возможна несколькими методами. Точнее матчинг под нарезку: хэши, u32, маркировка iptables...

это всё говно неюзабельное. но раз вариантов нет, то чобы и не потрахаться с ним. ага.

Но это тоже не отменяет правил ветвления, tc очень не любит линейные списки из тысяч позиций.

дадада, у всех ест друг линуксойд, который хвалит фидору, а у самого tc-правила загружаются несколько минут. стыд и срам.

Но суровая правда жизни такова, что дабы вкусно кушать - потребно уметь готовить. Такие дела (С)

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

[Dyr]

Кстати, по pf с dummynet ещё несколько лет назад один турок запиливал патч, позволяющий pf работать с dummynet нативно. Более того, этот патч вполне успешно был закоммичен в pfSense...но не во FreeBSD, блин. По-моему, его закидали помидорами. С тех пор вот всё и жуём... Для меня pf ужасен тем, что для работы с ftp нужно прогонять трафик через userspace ftp-proxy. Который к тому же до сих пор криво работает, не умея изменять ещё обратный адрес.

 

 

[DVM-Avgoor]

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

 

Купил SRX - избавился от мучений. Хватит ныть.

 

это всё говно неюзабельное. но раз вариантов нет, то чобы и не потрахаться с ним. ага.

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

 

См. выше.

 

дадада, у всех ест друг линуксойд, который хвалит фидору, а у самого tc-правила загружаются несколько минут. стыд и срам.

Ну у кого-то помнится мне тысячи правил в ipfw были, и пичалька была не меньшая да? :)

 

 

ох лол, кто бы говорил

 

Ну у меня-то оно работает, а кто-то не может пересилить себя и сделать разок :)

 

Для меня pf ужасен тем, что для работы с ftp нужно прогонять трафик через userspace ftp-proxy. Который к тому же до сих пор криво работает, не умея изменять ещё обратный адрес.

 

Да pf всем ужасен кроме няшного конфига.

ipfw_nat умеет ядерно через libalias_ftp делать добро.

[pfexec]

Купил SRX - избавился от мучений. Хватит ныть.

ты его в глаза ниразу не видел, а уже "иксперт" и "советчик". ох.

Ну у кого-то помнится мне тысячи правил в ipfw были, и пичалька была не меньшая да? :)

ни у миня жи ! :) вместе жи потешались !

Ну у меня-то оно работает, а кто-то не может пересилить себя и сделать разок :)

ох, у тебя давно уже ничего не работает.

Да pf всем ужасен кроме няшного конфига.

ipfw_nat умеет ядерно через libalias_ftp делать добро.

бабки на лавки сидят, мусолят поросший плесенью ftp. забудьте уже о нём, нашли чем мерять фаервольчики. используйте пассивный режим и будет счастье.

 

я щитаю что и ipfw2 нужно выбросить на свалку, и pf, и родить уже ipfw3, который будет объединять все сочные фишки обоих. об этом даже в жжешечке терки были. а воз и ныне там. видимо утомились. :)

Изменено 16 апреля, 2014 пользователем pfexec

[DVM-Avgoor]

pfexec, хватит сбивать людей странными идеями своего "опыта в гигабитах на писюках". А то тебе кто-то по-случайке ведь и поверить может :D

Изменено 16 апреля, 2014 пользователем DVM-Avgoor

[pfexec]

pfexec, хватит сбивать людей странными идеями своего "опыта в гигабитах на писюках". А то тебе кто-то по-случайке ведь и поверить может :D

эээ... ты странно агришься. я так то могу побрызжать обосновано желчью в ответ, ну да ладно. ну и я вроде писал что _лично_ мне не нужны гигабиты на писюках. вот:

мне десятки гигабит в нем не натить, мне даже гигабит там натить не надо.

кроме тебя и странного клуба любителей ставить рекорды на писюках никому оно и не надо. тебе наверно скучно и ты фрустрируешь не по делу.

 

объективно и так понятно что с фаерволами во фряшечке надо что-то делать. и "что-то делать" - это не значит приколачивать к pf smp или пытаться упихать свои нужды в рамки ipfw + libalias + dummynet. будем надеяться что на netmap'е родится и фаервол, и маршрутизатор. :)

 

btw, то что с этими фаерволами надо что-то делать понимают даже в линагзе и выбрасывают на свалку iptables.

 

ps: dummynet, кстати, по-прежнему однопоточный и почему-то это никого не беспокоит. лол. равно как и деревянный libalias, который много чего не умеет. это к твоей неадекватной тяге полисить и натить терабиты трафика: тунца та лососнешь.

Изменено 16 апреля, 2014 пользователем pfexec

[DVM-Avgoor]

Дык я и говорю: самый простой способ - уйти на линукс. Это как минимум дабы не разбираться кто из них однопоточен, как проходит пакет и почему растет isr.

[Уфаныч]

Уфаныч, спасибо за конкретику, попробую.

 

Что вы имеете в виду под первым правилом "allow all from any to any in" и почему это должно помочь при шейпировании?

 

Поиск по таблице, насколько мне известно, как раз наиболее быстрый способ [в ipfw] проверить на соответствие ip. Если оптимизировать, то наверное, уже только с помощью правил ветвлений в отдельные таблицы.

 

По зеркалированию netflow такая мысль была, да.

Поясняю.

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

Так как правила на шейпер подразумевают исходящий трафик (нахрена шейпить входящий,он уже у нас), но в правилах отсутствует ключевой слово "out", и есть подозрения, что правил (когда то было)/(будет) несколько больше, я и предложил ДО этих правил перманентно исключить из проверки (пустого интерфейса) весь входящий трафик. Путём добавления "allow all from any to any in" перед ними.

Добавленное правило содержит только одну микрокоманду ipfw и выполняется быстрее всего. Проверка на интерфейс выполняется для пустого интерфейса несколько дольше (один вызов подпрограммы).

 

Есть мысль насчёт "оптимизировать ipfw". У ipfw есть замечательная вещь - keep-state (и check-state).

Возможно построить правила таким образом, чтобы в где-то было так:

 

100 check-state  #должно быть одним из первых правил. Перенаправит пакет (как входящий так и исходящий) 
#на правило фаервола 2000 или 2010 или ещё какое, но сразу на микрокоманду правила! то есть на skipto

... (набор правил)

2000 skipto NNN10 all from any to table(1) keep-state // таблица клиентов с тарифом 1
2010 skipto NNN20 all from any to table(2) keep-state // таблица клиентов с тарифом 2
... (ещё набор правил)

NNN10 pipe 1 all from any to any out xmit интерфейс-к-клиенту // отшейпить только исходящий для тарифа 1 в сторону клиента
NNN11 allow all from any to any

NNN20 pipe 2 all from any to any out // отшейпить только исходящий для тарифа 2 и к клиенту, и в апстрим
NNN21 allow all from any to any

таким образом, если пакет добрался до правила 2000 (а первый пакет соединения проскочит мимо check-state) (он уже не отбрасывается по правилам фильтрации, и весь последующий flow тоже будет легитимным,) для него на keep-state-правиле создаётся запись в таблице динамических правил, соответствующая его протоколу, IP-адресам и портам (id пакета). Следующий же пакет, попадающий под этот id, быстрым шагом со строки 100 попадает на 2000, затем так же быстро на NNN10, и тут уже шейпится.

 

Процедура внесения id пакета для TCP происходит намного реже, чем частота прохождения пакетов в потоке этого flow - вот выигрыш по сравнению с поиском IP по таблице для каждого пакета.

Для UDP есть осложнение в виде времени жизни UDP-flow, задаваемого net.inet.ip.fw.dyn_udp_lifetime. И net.inet.ip.fw.dyn_short_lifetime для других протоколов.

 

Процедура поиска соответствия пакета в хэш-таблице завязана на net.inet.ip.fw.dyn_buckets, который не может быть больше 64к. Этот лимит начинает действовать, когда хэш-таблица пуста.

 

Остаётся вопрос - будет ли поиск по хэш-таблице быстрее, чем исходные поиск IP в таблице и взятие tablearg

И второй вопрос - сколько памяти отъест ipfw под динамические правила для кучи клиентов.

 

В принципе, если в правилах нет других keep-state и limit, то эту схему можно протестировать под боевой нагрузкой на каком нибудь узком круге клиентов.

Оценить количество правил и требуемую память можно, поместив перед имеющимся блоком правил для шейпера одно единственное правило:

skipto "следующее правило" all from any to any keep-state

 

и net.inet.ip.fw.dyn_count скажет, сколько динамических правил он насчитал.

ipdw -d show/list покажет их все.

 

Есть подозрение, что на IPv6 схема с keep-state будет более затратной по памяти и времени поиска, но хэш там не по полному ip-адресу, а по 64 битам адреса, только по исходникам не ясно, первым или последним, а проверять лень.

Изменено 16 апреля, 2014 пользователем Уфаныч