vppkn 102 Опубликовано: 2012-11-19 00:00:55 Share Опубликовано: 2012-11-19 00:00:55 (відредаговано) Собственно, вопрос весь в названии темы : какой из фрибсдшных натов обеспечивает лучшую производительность? На всякий случай уточню: под IPFW NAT я понимаю ядерный нат (не natd). Відредаговано 2012-11-19 08:51:23 vppkn Ссылка на сообщение Поделиться на других сайтах
LV10 281 Опубліковано: 2012-11-19 00:24:03 Share Опубліковано: 2012-11-19 00:24:03 pf Ссылка на сообщение Поделиться на других сайтах
dnn 1 Опубліковано: 2012-11-19 00:34:20 Share Опубліковано: 2012-11-19 00:34:20 pf Ссылка на сообщение Поделиться на других сайтах
TretUliy2 1 Опубліковано: 2012-11-19 05:56:03 Share Опубліковано: 2012-11-19 05:56:03 pf Ссылка на сообщение Поделиться на других сайтах
VitalyMoiseev 112 Опубліковано: 2012-11-19 06:07:11 Share Опубліковано: 2012-11-19 06:07:11 а pf уже smp понимает? Ссылка на сообщение Поделиться на других сайтах
vit_ 35 Опубліковано: 2012-11-19 07:03:11 Share Опубліковано: 2012-11-19 07:03:11 ipfw - быстрей был , но там утечка памяти была, это было 1-1.5 назад, как дела сейчас не знаю pf - ставбильно, без проблем сейчас всех на реальные адреса переводим, это еще быстрей Ссылка на сообщение Поделиться на других сайтах
andr1y 4 Опубліковано: 2012-11-19 07:04:51 Share Опубліковано: 2012-11-19 07:04:51 pf Ссылка на сообщение Поделиться на других сайтах
VitalyMoiseev 112 Опубліковано: 2012-11-19 07:19:31 Share Опубліковано: 2012-11-19 07:19:31 ipfw - быстрей был , но там утечка памяти была, это было 1-1.5 назад, как дела сейчас не знаю где утечка? Ссылка на сообщение Поделиться на других сайтах
masters 126 Опубліковано: 2012-11-19 07:27:35 Share Опубліковано: 2012-11-19 07:27:35 По скорости одинаковые. Ресурсов жрет больше IPFW. Ссылка на сообщение Поделиться на других сайтах
rootvm 1 Опубліковано: 2012-11-19 07:46:52 Share Опубліковано: 2012-11-19 07:46:52 pf Ссылка на сообщение Поделиться на других сайтах
Fanat_non_root 88 Опубліковано: 2012-11-19 08:25:18 Share Опубліковано: 2012-11-19 08:25:18 ядерный ipfw Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2012-11-19 08:34:28 Share Опубліковано: 2012-11-19 08:34:28 а кто-нибудь измерял реальную производительность? или хотя бы архитектурные моменты сверял? Ссылка на сообщение Поделиться на других сайтах
andryas 1 059 Опубліковано: 2012-11-19 08:39:30 Share Опубліковано: 2012-11-19 08:39:30 ipfw неплохо паралелиться. pf до недавнего времени жрал лишь одно ядро. Ссылка на сообщение Поделиться на других сайтах
vppkn 102 Опубліковано: 2012-11-19 08:52:45 Автор Share Опубліковано: 2012-11-19 08:52:45 а pf уже smp понимает? Насколько я в курсе, до сих пор не понимает. ipfw - быстрей был , но там утечка памяти была, это было 1-1.5 назад, как дела сейчас не знаю Говорят, что уже исправили утечку. Ссылка на сообщение Поделиться на других сайтах
vppkn 102 Опубліковано: 2012-11-19 08:54:35 Автор Share Опубліковано: 2012-11-19 08:54:35 По скорости одинаковые. Ресурсов жрет больше IPFW. Ну значит получается, что производительность IPFW хуже - когда он уже упрется в процессор PF еще будет иметь запас. Так? Ссылка на сообщение Поделиться на других сайтах
andryas 1 059 Опубліковано: 2012-11-19 09:02:11 Share Опубліковано: 2012-11-19 09:02:11 По скорости одинаковые. Ресурсов жрет больше IPFW. Ну значит получается, что производительность IPFW хуже - когда он уже упрется в процессор PF еще будет иметь запас. Так? На одноядровом процессоре да. Ссылка на сообщение Поделиться на других сайтах
nightfly 1 239 Опубліковано: 2012-11-19 10:43:59 Share Опубліковано: 2012-11-19 10:43:59 где утечка? Была вроде во времена 7.1. Некрофилы помнят а pf уже smp понимает? Не, их разработчикам никто еще не сказал, что оно существует. На одноядровом процессоре да. Далеко не факт, там один и тот же libalias в кернел спейсе отрабатывает. Все зависит от подхода и оптимизации правил в ipfw. pf так любим пионерами, только за то, что есть optimization aggressive. Ссылка на сообщение Поделиться на других сайтах
inco 20 Опубліковано: 2012-11-19 12:00:41 Share Опубліковано: 2012-11-19 12:00:41 ipfw Ссылка на сообщение Поделиться на других сайтах
VitalyMoiseev 112 Опубліковано: 2012-11-19 12:08:15 Share Опубліковано: 2012-11-19 12:08:15 сколько не искал РЕАЛЬНЫХ сравнений производительности - нигде нет. Говорят про удобство и читаемость правил и т.п. У себя использовали ipfw natd, потом kernel nat (как появился), никогда не было вопроса в его производительности (правда, с ростом трафика и число белых ИП выросло) Тут больше вопрос к ТС - вам сколько трафика для скольких клиентов и на каком железе натить надо? Ссылка на сообщение Поделиться на других сайтах
sergeev 1 Опубліковано: 2012-11-19 12:32:20 Share Опубліковано: 2012-11-19 12:32:20 А у меня вот что с 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 239 Опубліковано: 2012-11-19 12:37:38 Share Опубліковано: 2012-11-19 12:37:38 Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet Такое хоронить нужно а не абонентов там держать. http://dadv.livejournal.com/139170.html#cutid1 Ссылка на сообщение Поделиться на других сайтах
sergeev 1 Опубліковано: 2012-11-19 12:41:17 Share Опубліковано: 2012-11-19 12:41:17 С Вами полностью согласен но, у нас IBM HS21 и LS20, и увы в них ничего изменить нельзя. Ссылка на сообщение Поделиться на других сайтах
sergeev 1 Опубліковано: 2012-11-19 12:42:37 Share Опубліковано: 2012-11-19 12:42:37 А кто пробывал ng_nat, как он в работе? Ссылка на сообщение Поделиться на других сайтах
nightfly 1 239 Опубліковано: 2012-11-19 12:44:59 Share Опубліковано: 2012-11-19 12:44:59 А кто пробывал ng_nat, как он в работе? Все так же. Плюс букет детских болезней. Почитайте цикл статей dadv по ссылочке выше, на тему производительности. Человек очень крутые вещи пишет, и расказывает о подводных камнях в net.isr который как вижу у вас и жрет. Ссылка на сообщение Поделиться на других сайтах
vppkn 102 Опубліковано: 2012-11-19 13:11:35 Автор Share Опубліковано: 2012-11-19 13:11:35 У себя использовали ipfw natd, потом kernel nat (как появился), никогда не было вопроса в его производительности (правда, с ростом трафика и число белых ИП выросло) natd - тормоз из-за переключений контекста, но на небольших нагрузках пригоден. Тут больше вопрос к ТС - вам сколько трафика для скольких клиентов и на каком железе натить надо? Железо покупается сообразно с задачами, но чтобы не тратить лишнего - надо определиться сколько железа достаточно и какой софт требует меньше железа. Количество клиентов ничего не определяет. Для ната, как и для маршрутизатора, как мне кажется, основной показатель нагрузки - PPS, ну может еще количество потоков и ширина полосы, но в меньшей степени. Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВхід
Уже зарегистрированы? Войдите здесь.
Войти сейчас