[Dyr]

У меня как раз под 500k стейтов с 80 kpps, нет вообще ни единой проблемы. Что я делаю не так,a?

 

 

 

 

По поводу pf с netgraph, то была такая идея. Автор темы (Ermal Luçi), кстати, активно запилил ещё кучу всего полезного для PF и IPFW в pfSense (например, поддержку dummynet для первого и L7 classify для второго.)

Изменено 8 февраля, 2012 пользователем Dyr

[^rage^]

У меня как раз под 500k стейтов с 80 kpps, нет вообще ни единой проблемы. Что я делаю не так,a?

железо?

 

 

По поводу pf с netgraph, то была такая идея

и оно теперь в базе или портах?

[lagman]

2)как удалить запись из state table в ipfw/ng_nat по событию/из внешнего мира?

ЗАЧЕМ

[SpheriX]

ЗАЧЕМ

Это расценивать как "не работает"?

[lagman]

ЗАЧЕМ

Это расценивать как "не работает"?

Это расценивать как вопрос "ЗАЧЕМ".

[Dyr]

железо?

 

Платформа Supermicro 5016T-MTFB, Xeon E3-1270, 8Гб памяти, Intel QuadPort I350-T4 (реально используется по одному порту).

 

Вот прямо сейчас, не в час пик, после отключения шейпера:

 

# atop -1 2 

ATOP - Stella             			2012/02/08  16:35:57             			---1--                          2s elapsed
PRC | sys    0.00s | user   0.00s | #proc 	47 | #trun      1 | #tslpi    46 | #tslpu 	0 | #zombie    1 | #exit    0/s |
CPU | sys      12% | user      0% | irq      74% | idle    314% | wait      0% | guest 	0% | curf 3.39GHz | curscal 100% |
cpu | sys   	4% | user      0% | irq      19% | idle 	77% | cpu001 w  0% | guest 	0% | curf 3.39GHz | curscal 100% |
cpu | sys   	3% | user      0% | irq      20% | idle 	77% | cpu003 w  0% | guest 	0% | curf 3.39GHz | curscal 100% |
cpu | sys   	2% | user      0% | irq      19% | idle 	79% | cpu002 w  0% | guest 	0% | curf 3.39GHz | curscal 100% |
cpu | sys   	3% | user      0% | irq      17% | idle 	81% | cpu000 w  0% | guest 	0% | curf 3.39GHz | curscal 100% |
CPL | avg1    0.04 | avg5    0.03 | avg15   0.01 |              | csw 134328/s | intr 62554/s |              | numcpu 	4 |
MEM | tot 	8.0G | free    4.5G | cache   0.8M | inact   2.1G | wired   1.0G | activ  48.6M |              |              |
SWP | tot 	1.0G | free    1.0G |              |              |              |              | vmcom   0.0M | vmlim   0.0M |
DSK |          ad4 | busy      0% | read 	0/s | write    4/s | KiB/w 	24 | MBr/s   0.00 | MBw/s   0.08 | avio 0.26 ms |
DSK |          ad6 | busy      0% | read 	0/s | write    4/s | KiB/w 	24 | MBr/s   0.00 | MBw/s   0.08 | avio 0.25 ms |
NET | transport    | tcpi 	1/s | tcpo 	1/s | udpi 	0/s | udpo    87/s | tcpao    0/s | tcppo    0/s | tcprs    0/s |
NET | network      | ipi 121928/s | ipo    101/s | ipfrw 12e4/s | deliv   13/s |              | icmpi    1/s | icmpo    4/s |
NET | igb1 	57% | pcki 52126/s | pcko 63440/s | si  239 Mbps | so  578 Mbps | erri 	0/s | erro 	0/s | drpo 	0/s |
NET | igb0 	57% | pcki 69446/s | pcko 52160/s | si  573 Mbps | so  241 Mbps | erri 	0/s | erro 	0/s | drpo 	0/s |
NET | vlan305  56% | pcki 52262/s | pcko 63424/s | si  239 Mbps | so  569 Mbps | erri 	0/s | erro 	0/s | drpo 	0/s |
NET | vlan400   0% | pcki 	0/s | pcko    88/s | si    0 Kbps | so 1048 Kbps | erri 	0/s | erro 	0/s | drpo 	0/s |
NET | gif0    ---- | pcki    12/s | pcko 	9/s | si   19 Kbps | so    7 Kbps | erri 	0/s | erro 	0/s | drpo 	0/s |
NET | pflog0  ---- | pcki 	0/s | pcko 	4/s | si    0 Kbps | so    1 Kbps | erri 	0/s | erro 	0/s | drpo 	0/s |

# pfctl -si
No ALTQ support in kernel
ALTQ related functions disabled
Status: Enabled for 15 days 23:04:19          Debug: Urgent

State Table                          Total 			Rate
 current entries       			324134
 searches                    239500450505   	173669.5/s
 inserts           			8706979300 		6313.7/s
 removals                      8706861308 		6313.6/s
Counters
 match             			8813322182 		6390.8/s
 bad-offset                 			0            0.0/s
 fragment               			28479            0.0/s
 short                   			9063            0.0/s
 normalize                          42008            0.0/s
 memory                     			0            0.0/s
 bad-timestamp                          0            0.0/s
 congestion                 			0            0.0/s
 ip-option             			235564            0.2/s
 proto-cksum                      1209890            0.9/s
 state-mismatch       			5256054            3.8/s
 state-insert                        1077            0.0/s
 state-limit                          828            0.0/s
 src-limit             			119227            0.1/s
 synproxy                   			0            0.0/s

 

Стейтов, правда, маловато, подождём до вечера. ;)

 

 

По поводу pf с netgraph, то была такая идея

и оно теперь в базе или портах?

 

Да как бы всем опять-таки нафиг это не надо. ;)

[Ivan_83]

т.е. это такой сферический конь в вакууме, не говоря о других проблемах zero copy sockets во freebsd, о которых писал Сысоев

 

за 2005 год. С тех пор много всего изменилось.

 

400-500k при пакетрейте в 70-80kpps уже того... всмысле netstat -I em0 -w 1 начинает показывать провалы до 5kpps и периодическим "подвисанием" физической консоли. если поискать тут по форуму по "реклама ipfw nat" и "профилирование hwpmc pf" - можно много чего найти.

 

Также поиск по форуму покажется много тех у кого работает на PF и гораздо больше сессий / ппс / трафика.

 

 

[^rage^]

2)как удалить запись из state table в ipfw/ng_nat по событию/из внешнего мира?

ЗАЧЕМ

причин может быть много. например, наша суперкрутая ids обнаружила, что через tcp-соединение от пользователя из нашей "серой" сети за nat заливается в интернеты детское порно защищённый авторским правом контент.

[Deac]

причин может быть много. например, наша суперкрутая ids обнаружила, что через tcp-соединение от пользователя из нашей "серой" сети за nat заливается в интернеты детское порно защищённый авторским правом контент.

Так это повод накатать телегу в соотв. органы, блочить кого-то, не по решения суда - грубое нарушение закона.

[Dyr]

А что, руки линуксовых администраторов не умеют настраивать сервера с суперкрутыми ids таким образом, чтобы при добавлении ip пользователя в запрещающее правило стейты отваливались по таймауту?

[pfexec]

Загрузчик не есть частью оси в общем-то.

дак и ОС у вас нет, а только ядро. лол.

1)как скрестить ng_tag + pf?

есть нативные средства, а есть портированные. ipfw обучен netgraph'у, свои задачи выполняет. зачем скрещивать pf с нетграфом как-то не ясно. ну так то можно подумать и сделать ng_pf ноду, по аналогии с ng_ipfw. только зачем ? утомиться мержить код из openbsd после обновления версии pf ?

2)как удалить запись из state table в ipfw/ng_nat по событию/из внешнего мира?

а зачем её удалять ?

только в stateless mode. когда стейтов наберёт - начинает нещадно дропать трафик.

ну низнаю, у меня такого не было. наверно я что то не так делал. :(

причин может быть много. например, наша суперкрутая ids обнаружила, что через tcp-соединение от пользователя из нашей "серой" сети за nat заливается в интернеты детское порно защищённый авторским правом контент.

охлол, да ладно, вы серъезно, ids ? по-мойму всё это тянет на пример никому не нужной функциональности и притягивание за уши. линагзойды этим характеризуются тоже, ага.

[sirmax]

Куча ответов в стиле "никому такое не нужно" достаточно хорошо характерезуют отвечающих людей.

Пожалуйста, говорите за себя.

 

Или может сказать проще - "то чего нет в БСД - никому не нужно"?

 

PS

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

[pfexec]

2sirmax: ну я объективно не знаю зачем нужен netgraph в pf, зачем инстанс ната уничтожать каким-то событием и так далее. с системой управления процессами умеющей селфхилинг и зависимости еще можно как-то согласится с её нужностью, но с остальным как-то вряд ли.

Изменено 8 февраля, 2012 пользователем pfexec

[nuclearcat]

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

1)У клиента скажем был обмен с определенным сайтом по UDP, IPTV, у клиента изменился динамический фейковый ИП, а траффик валит на старый. Надо убрать стейт, чтобы не валил траффик с сайта. Также разумно убирать старые стейты клиента который разлогинился или для которого изменились какие-то условия, требующие сброса старых соединений.

2)Синхронизация стейтов для failover NAT. Для этого в частности есть conntrackd.

[Dyr]

У pf можно всё вышеперечисленное.

[lagman]

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

1)У клиента скажем был обмен с определенным сайтом по UDP, IPTV, у клиента изменился динамический фейковый ИП, а траффик валит на старый

Что за протоколы такие? Имя, сестра, имя!

[zvtorero]

У клиента скажем был обмен с определенным сайтом по UDP, IPTV, у клиента изменился динамический фейковый ИП, а траффик валит на старый.

А почему траФик продолжает ехать на старый IP? Должен резаться фаерволом хотя бы, что ли. Не говоря уже о том, что скорее всего в таблице форвардинга коммутатора не останется старого адреса.

[NiTr0]

Этим должны заниматься специализированные супервайзоры, а никак не инит скрипты. И тут тем более нет никакой разницы между системами, если учесть, что daemontools или monit работают везде одинаково.

Накой к иниту плодить еще супервайзора? 2 в 1 совместить что, религия не позволяет? Или любовь к костылям? Ах да, в бзде этого нет - значит ононикому не надо :)

 

Странно, что Вас это смущает. Меня вот не смущает наличие шестиногого пятихуя в виде наличия десятков фронтендов к iptables.

natd - юзерленд, ng_nat - нода нетграфа. Каким образом они могут вообще пересекаться? :)

 

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

Если есть несколько инструментов - да, значит как минимум один из них (если не все) неполноценен. LILO, бывший изначально загрузчиком, похоронен (ибо неудобен до ужаса, и нет кучи плюшек по сравнению с грабом). grub - да, хорош, но бутаться с сд к примеру или по сети - AFAIK не умеет. grub2 - пока еще до stable недорос, хотя обещает очень много плюшек. syslinux/isolinux/pxelinux - минималистичные загрузчики ядра в первую очередь для PXE/CD. Embedded ессно не рассматриваем - там отдельная история, и развитие embedded сектора логике подчиняется слабо, говнокод там торжествует (спасибо китайцам и индусам).

 

дак и ОС у вас нет, а только ядро. лол.

ОС - это собссно ядро + базовая обвязка (системные сервисы и утилиты). Ну и + тулчейн/SDK для сборки софта. А то, что дистрибутив некоторые путают с осью - это их личное горе. Для них и frenzy или m0n0wall - это не более чем сборка типового дистрибутива FreeBSD :D

[pfexec]

1)У клиента скажем был обмен с определенным сайтом по UDP, IPTV, у клиента изменился динамический фейковый ИП, а траффик валит на старый. Надо убрать стейт, чтобы не валил траффик с сайта. Также разумно убирать старые стейты клиента который разлогинился или для которого изменились какие-то условия, требующие сброса старых соединений.

чота какой венегред и много "если". давайте уж сразу определим сценарий про который ведем речь. предположим речь про хоминет, окей. что за "динамический фейковый ип" ? рискну предположить что речь про "серый" внутрений адрес получаемый через dhcp, окей. что мешает приколачивать по opt82 или по макам адрес гвоздями и не думать как решить надуманные проблемы ?

2)Синхронизация стейтов для failover NAT. Для этого в частности есть conntrackd.

сто лет в бсд есть pfsync, может еще и пораньше ваших контрактд.

[lagman]

Накой к иниту плодить еще супервайзора? 2 в 1 совместить что, религия не позволяет? Или любовь к костылям? Ах да, в бзде этого нет - значит ононикому не надо :)

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

 

natd - юзерленд, ng_nat - нода нетграфа. Каким образом они могут вообще пересекаться? :)

Они и не пересекаются. Первый использует libalias.so, второй использует ядерный libalias.ko.

 

Если есть несколько инструментов - да, значит как минимум один из них (если не все) неполноценен.

Кто более неполноценен, yum или apt?

Изменено 8 февраля, 2012 пользователем lagman

[SpheriX]

grub - да, хорош, но бутаться с сд к примеру или по сети - AFAIK не умеет.

Позор Вам, это GRand Unified Boot loader, читайте по большим буквам.

http://www.gnu.org/software/grub/manual/html_node/Making-a-GRUB-bootable-CD_002dROM.html

Это с сидюка.

Grub опционально по сети грузится. USE-флаг netboot в генте на это намекает. По дефолту отключен. Удобно с принесенных на восстановление винды ноутбуков перед началом работы данные бекапить по сети. Поддерживает немало сетевушек. Одно время дома юзал под это дело.

Изменено 8 февраля, 2012 пользователем SpheriX

[nuclearcat]

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

1)У клиента скажем был обмен с определенным сайтом по UDP, IPTV, у клиента изменился динамический фейковый ИП, а траффик валит на старый

Что за протоколы такие? Имя, сестра, имя!

Без понятия, но траффик валит.

 

А почему траФик продолжает ехать на старый IP? Должен резаться фаерволом хотя бы, что ли. Не говоря уже о том, что скорее всего в таблице форвардинга коммутатора не останется старого адреса.

Какой коммутатор? BRAS 3G оператора.

[nuclearcat]

чота какой венегред и много "если". давайте уж сразу определим сценарий про который ведем речь. предположим речь про хоминет, окей. что за "динамический фейковый ип" ? рискну предположить что речь про "серый" внутрений адрес получаемый через dhcp, окей. что мешает приколачивать по opt82 или по макам адрес гвоздями и не думать как решить надуманные проблемы ?

Не угадали.

Доступ 3G оператора. Там IP де-факто по своим причинам серые и динамические.

[zvtorero]

Какой коммутатор? BRAS 3G оператора.

Тогда он тем более никуда не приедет

[nuclearcat]

zvtorero, а я наблюдал как приезжает, детали обсуждать все равно не получится, NDA.

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

 

Кстати еще вспомнил причину, достаточно забавную, и глубоко нетехническую, по которой FreeBSD была изгнана из сети одного из зарубежных провайдеров. Логотип.

В религиозных странах очень не любят чертей, а в некоторых, за них могут и башку отрубить. В данном случае владелец провайдера дошел до этого сам, потом еще прошелся сраной метлой по не очень правильным с точки зрения религии названиям серверов. Теперь они называются цивильно, backup, mail, etc.

Если у владельцев есть налет религиозности (а в некоторых даже очень цивилизованных странах - он есть), то изгнать FreeBSD из какого-то места не составляет труда :) Достаточно удивленно обьяснить владельцу, что у него стоит система, логотипом которой есмь черт, или дьявол, и вопросить, неужель он дьяволопоклонник?