1. Как Вы используете PF ?

[Giga-Byte]

ты как-то говорил, мол mpd с ng_car используют только идиоты, ввиду того что "имеются косяки с нодами"

вот меня интересует, какие это косяки? в чем оно выражается.

Тогда был целый поток жалоб на кучу глюков в 7.1 (? или в 7.2?) при mpd5 с ng_car. ( В dummynet кстати тоже тогда накосячили ) Подозрения были на сбой нумерации и потерю orphans. Конкретику сейчас вспомнить трудно, уже несколько месяцев прошло, а ng_car и mpd5 я в продакшине не держу.

ясно, буду изучать майл-листы.

 

запустил в тест 7.2+mpd5.3 (поднимаемый car&bpf его силами динамически от радиус-сервера)

пока работает

[jab]

запустил в тест 7.2+mpd5.3 (поднимаемый car&bpf его силами динамически от радиус-сервера)

пока работает

Как-то я не совсем понимаю необходимость шейпить на NAS'е.

[XeonVs]

запустил в тест 7.2+mpd5.3 (поднимаемый car&bpf его силами динамически от радиус-сервера)

пока работает

Как-то я не совсем понимаю необходимость шейпить на NAS'е.

удобно передать через радиус атрибуты.

[jab]

удобно передать через радиус атрибуты.

Тоже мне проблема, я через rsh/ssh что угодно передам, еще и обработаю по дороге.

[XeonVs]

удобно передать через радиус атрибуты.

Тоже мне проблема, я через rsh/ssh что угодно передам, еще и обработаю по дороге.

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

 

да и сдается мне, распаралеливаться ноды будут намного лучше чем статиком все сливать на одну железку. Имхо надо потестировать, оба варианта.

[promSSe]

Господа, подниму старую тему но не менее актуальную.

У меня на работе порядка 400 пользователей, сейчас в качестве гейта стоит FreeBSD 7.2 с pf (только нат) + ipfw (фаервол +dummynet). Собственно решил отказаться от pf в пользу ipnat. Покритикуйте такой вариант замены при том что доп. функционала на гейте нет. Как себя ведёт ipnat по сравнению с натом от pf при большой загрузке (знаю что они оба выполняются в пространстве ядра)? Вообще кто-нибудь использует ipnat? Google при поиске выдаёт очень мало информации на тему ipnat.

[photon]

Может быть вы имеете в виду ipfw kernel nat, который на основе libalias? IPNat из IPFilter является общепризнанным глюкалом с утечками памяти. Кроме того, 400 пользователей -- небольшая нагрузка, pf вполне справится.

Изменено 20 декабря, 2009 пользователем photon

[jab]

Как себя ведёт ipnat по сравнению с натом от pf при большой загрузке (знаю что они оба выполняются в пространстве ядра)? Вообще кто-нибудь использует ipnat?

Хреново он себя ведет на загрузке. А для мелкой сетки на 400 юзеров может и подойтить, очень прост в конфигурировании.

[promSSe]

Господа, дело не в простоте конфигурирования. А в возрастающей нагрузке, кол-во пользователей скоро возрастёт на ~ 100. jab считаете соит оставить всё как есть?

 

[jab]

 

И сколько гигабит нагрузки ?

[promSSe]

jab

Точно не скажу, но учитывая что всего 400 офисных юзеров то совсем не операторская.

[Dyr]

Надо сначала задаться вопросом, чем вас не устраивает существующий pf nat.

[jab]

Надо сначала задаться вопросом, чем вас не устраивает существующий pf nat.

Меня не устраивает тем, что при попытке распараллелить нагрузку на несколько ядер, происходит резкая деградация пропускной способности.

 

 

Кто-нибудь ng_nat на пиковую пропускную способность гонял ?

[Dyr]

jab, вопрос был обращён к автору темы. Сомневаюсь, что на 400 пользователях он упирается по PF в одно ядро, и по этой причине решил перейти именно на ipnat.

Кроме того, насколько мне известно, попытки распараллелить pf вообще бесплодны, посколько он строго придерживается политики использования одного ядра.

[jab]

Кроме того, насколько мне известно, попытки распараллелить pf вообще бесплодны, посколько он строго придерживается политики использования одного ядра.

Он - это кто ? Бесноватый Тео ? Так он не вечен :-)))

[photon]

Дело не в Тео, а в более объективных причинах. У OpenBSD сетевой стек 4.4BSD, использующий гигантские блокировки (когда в пространстве ядра может одновременно выполняться только один kernel thread, а остальные находятся в состоянии wait). PF всего лишь продолжает эту традицию, т.к. писать приложения работающие на одном thread намного проще. OpenBSD -- это не Linux и не FreeBSD. Никем не финансируемые хоббисты не в состоянии переписать тонны кода. Вы наверное помните, насколько болезненным был переход от FreeBSD 4 к 6? В 5-й ветке гигантские блокировки начали устранять, а более-менее завершилось это дело только в 7-й, и то в некоторых подсистемах они еще есть. Кроме того, любое фундаментальное переписывание может привнести массу новых ошибок, что в свою очередь подрывает единственное достоинство OpenBSD -- безопасность.

Изменено 22 декабря, 2009 пользователем photon

[jab]

 

Это все очевидные и много где написанные вещи. Однако общее движение индустрии в сторону массовой многоядерности не оставит опятам выбора.

И не только опятам, в самой freebsd это тоже под большим вопросом. Уважительной причиной тут служит то, что NAT на гигабитных скоростях вообще

в мире довольно редкое приложение, и еще более оно редкое на pf под freebsd.

[pfexec]

Думаете, на чем крутится их веб-сервер www.openbsd.org? На Solaris, т.к. OpenBSD элементарно не выдержит большого числа запросов.

они хостинг по халяве просто замутили, а на хостинге солярис, да, маркетинговая ниудача. :'(