Jump to content

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


Recommended Posts

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

 

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

Edited by vppkn
Link to post
Share on other sites
  • Replies 50
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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

Posted Images

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

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

 

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

Link to post
Share on other sites

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

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

 

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

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

Link to post
Share on other sites

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

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

Link to post
Share on other sites

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

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

 

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

Link to post
Share on other sites
где утечка?

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

 

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

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

 

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

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

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

Link to post
Share on other sites

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

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

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

Link to post
Share on other sites

А у меня вот что с 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 от клиентов?

Link to post
Share on other sites
А кто пробывал ng_nat, как он в работе?

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

 

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

Link to post
Share on other sites

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

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

 

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

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

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.


×
×
  • Create New...