FreeBSD: PF NAT против IPFW NAT. Какой быстрее?

[vppkn 102]

Собственно, вопрос весь в названии темы : какой из фрибсдшных натов обеспечивает лучшую производительность?

 

На всякий случай уточню: под IPFW NAT я понимаю ядерный нат (не natd).

Відредаговано 2012-11-19 08:51:23 vppkn

[LV10 275]

pf

[dnn 1]

pf

[TretUliy2 1]

pf

[VitalyMoiseev 111]

а pf уже smp понимает?

[vit_ 35]

ipfw - быстрей был , но там утечка памяти была, это было 1-1.5 назад, как дела сейчас не знаю

pf - ставбильно, без проблем

 

сейчас всех на реальные адреса переводим, это еще быстрей

[andr1y 4]

pf

[VitalyMoiseev 111]

ipfw - быстрей был , но там утечка памяти была, это было 1-1.5 назад, как дела сейчас не знаю

где утечка?

[masters 126]

По скорости одинаковые. Ресурсов жрет больше IPFW.

[rootvm 1]

pf

[Fanat_non_root 88]

ядерный ipfw

[adeep 212]

а кто-нибудь измерял реальную производительность? или хотя бы архитектурные моменты сверял?

[andryas 1 058]

ipfw неплохо паралелиться. pf до недавнего времени жрал лишь одно ядро.

[vppkn 102]

а pf уже smp понимает?

Насколько я в курсе, до сих пор не понимает.

 

ipfw - быстрей был , но там утечка памяти была, это было 1-1.5 назад, как дела сейчас не знаю

Говорят, что уже исправили утечку.

[vppkn 102]

По скорости одинаковые. Ресурсов жрет больше IPFW.

Ну значит получается, что производительность IPFW хуже - когда он уже упрется в процессор PF еще будет иметь запас. Так?

[andryas 1 058]

По скорости одинаковые. Ресурсов жрет больше IPFW.

Ну значит получается, что производительность IPFW хуже - когда он уже упрется в процессор PF еще будет иметь запас. Так?

 

На одноядровом процессоре да.

[nightfly 1 221]

где утечка?

Была вроде во времена 7.1. Некрофилы помнят

 

а pf уже smp понимает?

Не, их разработчикам никто еще не сказал, что оно существует.

 

На одноядровом процессоре да.

Далеко не факт, там один и тот же libalias в кернел спейсе отрабатывает.

Все зависит от подхода и оптимизации правил в ipfw. pf так любим пионерами, только за то, что есть optimization aggressive.

[inco 20]

ipfw

[VitalyMoiseev 111]

сколько не искал РЕАЛЬНЫХ сравнений производительности - нигде нет. Говорят про удобство и читаемость правил и т.п.

У себя использовали ipfw natd, потом kernel nat (как появился), никогда не было вопроса в его производительности (правда, с ростом трафика и число белых ИП выросло)

Тут больше вопрос к ТС - вам сколько трафика для скольких клиентов и на каком железе натить надо?

[sergeev 1]

А у меня вот что с ipfw происходит:

 

 

last pid: 75717; load averages: 4.07, 3.83, 3.86 up 13+07:28:16 20:42:47

394 processes: 8 running, 363 sleeping, 20 waiting, 3 lock

CPU 0: 1.2% user, 0.0% nice, 6.7% system, 42.1% interrupt, 50.0% idle

CPU 1: 0.0% user, 0.0% nice, 14.6% system, 43.7% interrupt, 41.7% idle

CPU 2: 0.0% user, 0.0% nice, 9.1% system, 49.6% interrupt, 41.3% idle

CPU 3: 0.0% user, 0.0% nice, 6.7% system, 75.6% interrupt, 17.7% idle

Mem: 62M Active, 640M Inact, 754M Wired, 72K Cache, 417M Buf, 2475M Free

Swap: 4096M Total, 4096M Free

 

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND

12 root -72 - 0K 400K CPU1 1 84.3H 100.00% intr{swi1: netisr 2}

12 root -72 - 0K 400K *per-i 3 50.0H 46.39% intr{swi1: netisr 1}

11 root 155 ki31 0K 64K RUN 0 188.4H 36.43% idle{idle: cpu0}

11 root 155 ki31 0K 64K RUN 1 211.3H 35.45% idle{idle: cpu1}

12 root -72 - 0K 400K *per-i 2 985:41 32.91% intr{swi1: netisr 0}

12 root -72 - 0K 400K *per-i 3 965:25 31.05% intr{swi1: netisr 3}

12 root -92 - 0K 400K CPU0 3 70.3H 26.86% intr{irq257: bce1}

11 root 155 ki31 0K 64K RUN 2 205.1H 25.73% idle{idle: cpu2}

11 root 155 ki31 0K 64K RUN 3 208.2H 18.41% idle{idle: cpu3}

13 root -16 - 0K 64K sleep 3 44.5H 12.11% ng_queue{ng_queue0}

13 root -16 - 0K 64K CPU3 3 44.5H 11.91% ng_queue{ng_queue2}

13 root -16 - 0K 64K sleep 3 44.5H 11.57% ng_queue{ng_queue3}

13 root -16 - 0K 64K sleep 3 44.3H 11.28% ng_queue{ng_queue1}

12 root -92 - 0K 400K WAIT 1 27.5H 7.96% intr{irq256: bce0}

50191 root 22 0 690M 144M select 0 201:50 3.17% mpd5{mpd5}

12 root -60 - 0K 400K WAIT 2 419:48 1.37% intr{swi4: clock}

0 root -92 0 0K 160K - 3 169:27 1.03% kernel{dummynet}

20 root 16 - 0K 16K syncer 2 45:54 0.15% syncer

 

 

netstat -dw1

input (Total) output

packets errs idrops bytes packets errs bytes colls drops

48639 0 0 25133376 50579 0 37001014 0 0

44903 0 0 23134236 45204 0 32074189 0 0

27293 0 0 23962431 23407 0 13065400 0 0

41376 0 0 20346168 41198 0 27744037 0 0

42476 0 0 20567720 43498 0 30122068 0 0

 

pptp интерфейсов примерно 200-250. Не пингается даже localhost. И если вовремя не передернуть mpd, то сервер уходит в перезагрузку. Но как только удаляю правило с натом всё становится хорошо. Но в час пик при 700-800 интерфейсах и 110 тыс.пакетов/300Мбит, работает замечательно.

 

9.0-RELEASE FreeBSD.

Карточки интегрированные - Ethernet controller: Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet

 

Возможен ли ddos nat от клиентов?

[nightfly 1 221]

Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet

Такое хоронить нужно а не абонентов там держать.

 

http://dadv.livejournal.com/139170.html#cutid1

[sergeev 1]

С Вами полностью согласен но, у нас IBM HS21 и LS20, и увы в них ничего изменить нельзя.

[sergeev 1]

А кто пробывал ng_nat, как он в работе?

[nightfly 1 221]

А кто пробывал ng_nat, как он в работе?

Все так же. Плюс букет детских болезней.

 

Почитайте цикл статей dadv по ссылочке выше, на тему производительности. Человек очень крутые вещи пишет, и расказывает о подводных камнях в net.isr который как вижу у вас и жрет.

[vppkn 102]

У себя использовали ipfw natd, потом kernel nat (как появился), никогда не было вопроса в его производительности (правда, с ростом трафика и число белых ИП выросло)

natd - тормоз из-за переключений контекста, но на небольших нагрузках пригоден.

 

Тут больше вопрос к ТС - вам сколько трафика для скольких клиентов и на каком железе натить надо?

Железо покупается сообразно с задачами, но чтобы не тратить лишнего - надо определиться сколько железа достаточно и какой софт требует меньше железа. Количество клиентов ничего не определяет. Для ната, как и для маршрутизатора, как мне кажется, основной показатель нагрузки - PPS, ну может еще количество потоков и ширина полосы, но в меньшей степени.