Перейти до

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


Рекомендованные сообщения

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

 

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

Відредаговано vppkn
Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 50
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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

Posted Images

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

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Ссылка на сообщение
Поделиться на других сайтах
где утечка?

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

 

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

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

 

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах
А кто пробывал ng_nat, как он в работе?

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.


×
×
  • Створити нове...