[DiM_TauRus]

Дело скорее не в производительности, а в привычках и личных привязанностях пользователей к интерфейсам тех или иных подсистем ядра и к форматам конфигурационных файлов. Например, многих раздражает синтаксис правил iptables и tc, поэтому они всегда будут делать файрволы и QoS с помощью ipfw/dummynet. Другим больше нравится mpd, чем линуксовая реализация VPN.

 

Коротко и в самое основное. Понимаю что возможно не максимально рационально было бы использовать BSD, но все равно именно для этих задач мне удобно и приятно ее использовать - все остальное тоже можно, но на linux удобнее - в общем сплошной субъективизм ))

[sirmax]

Иказа - продался Мелкософту.

и потому сидит на маке :)

Тут разговор о десктопе или о серверах?

Я тоже сижу в том числе и на маке, ну так что? На десктопе что удобно то и ставить, гном/KDE что во фре что в линуксе что под соляркой одинаковые...

 

PS

Фрю не использую потому что плохо знаю потому воздерживаюсь от оценок

[Ivan_83]

Тут разговор о десктопе или о серверах?

О человеке который долго сидел на линуксах, много писал под них а потом ему это всё надоело :)

[sirmax]

Тут разговор о десктопе или о серверах?

О человеке который долго сидел на линуксах, много писал под них а потом ему это всё надоело :)

ну так он же не на фрю уполз ) А на Макось ))

Дык я его понимаю - она,ссуко, удобная, я сам тоже пользую маконоут.

 

 

Кстати, а есть какой то нормальный мануал по файрволлу и нату в МАкосе? А то как то я не проникся тамошним ipfw ...

[adsh]

попробуйте реализовать относительно простую вещь: соединения, через которые пробежало более 2Мбайт трафика автоматически попадают в низкоприоритетный класс.

надо это для того, чтобы торренты и всякое качающее не влияло на скорость открытия страниц в браузере.

 

Да - запросто: https://calomel.org/pf_hfsc.html (сам сайт - копилка фич *BSD)

 

см. "nonlinear service curve (NLSC or just SC)"

 

Задаём m1 и d.

 

Сам использую altq на OpenBSD, но altq портировано во FreeBSD и нормально себе в ней работает.

 

Характерные фичи:

 

altq - нарезка гарантированной и динамической (в т. ч. - от времени) полосы для заданного типа трафика и / или заданного числа клиентов

 

dummynet - справедливое распределение канала для любого числа клиентов, нарезка трафика для любого числа клиентов (умеет делать автоматическое создание правил по шаблону с маской)

 

Во FreeBSD их можно совмещать: через ipfw можно загнать выбранный трафик в нужную очередь altq, можно использовать последовательно pf и ipfw, altq и dummynet. И к этому ещё добавить третий конструктор на базе Netgraph - собирай из всех трёх, что хочешь ;) .

Изменено 27 июля, 2013 пользователем adsh

[^rage^]

попробуйте реализовать относительно простую вещь: соединения, через которые пробежало более 2Мбайт трафика автоматически попадают в низкоприоритетный класс.

надо это для того, чтобы торренты и всякое качающее не влияло на скорость открытия страниц в браузере.

 

Да - запросто: https://calomel.org/pf_hfsc.html (сам сайт - копилка фич *BSD)

 

см. "nonlinear service curve (NLSC or just SC)"

 

Задаём m1 и d.

зевая... да знаю я про HFSC/NLSC. только не то это. если я вас попрошу нарисовать "лесенку"(выкачал 1Мб - скорость упала в 2 раза, через следующий - в 4 итп)?

или же распихивать по классам в зависимости от пакетрейта?

 

altq - нарезка гарантированной и динамической (от времени) полосы для заданного типа трафика и / или заданного числа клиентов

dummynet - справедливое распределение канала для любого числа клиентов, нарезка трафика для любого числа клиентов (умеет делать автоматическое создание правил по шаблону с маской)

заверните rtp-трафик в отдельный класс. порты - динамические, сигналка - sip/h.323

Изменено 27 июля, 2013 пользователем ^rage^

[Ivan_83]

аверните rtp-трафик в отдельный класс.

отловить их в ng_bpf

[adsh]

если я вас попрошу нарисовать "лесенку"(выкачал 1Мб - скорость упала в 2 раза, через следующий - в 4 итп)?

Можно сделать вложенные очереди. Но - зачем? Почти всегда достаточно просто расставить относительные приоритеты и максимальный / гарантированный канал.

 

заверните rtp-трафик в отдельный класс. порты - динамические, сигналка - sip/h.323

У людей и вот такое работает:

 

http://fido7.ru.unix.bsd.narkive.com/6XAbIjTL/altq-rtp

 

Можно, как указано выше, ng_bpf - так, например, успешно торренты ловят.

 

P.S. Вам то шашечки нужны или ехать ;)?

Изменено 27 июля, 2013 пользователем adsh

[photon]

Характерные фичи:

 

altq - нарезка гарантированной и динамической (в т. ч. - от времени) полосы для заданного типа трафика и / или заданного числа клиентов

 

dummynet - справедливое распределение канала для любого числа клиентов, нарезка трафика для любого числа клиентов (умеет делать автоматическое создание правил по шаблону с маской)

Кстати, наплодить несколько неполноценных подсистем ядра, вместо того, чтобы реализовать все необходимые функции в какой-то одной - это тоже характерный для FreeBSD подход. В результате имеем: три файрвола, три реализации шейпинга (altq, dummynet, ng_car), пять способов настроить NAT, три кинокамеры, три портсигара, куртки замшевые - три.

Изменено 27 июля, 2013 пользователем photon

[^rage^]

аверните rtp-трафик в отдельный класс.

отловить их в ng_bpf

сурьёзно? бинарный h.323, базирующийся на asn.1 ber разбирать bpf-машиной? )))) там и с сипом уже непросто, потому надо до sdp добраться.

[^rage^]

если я вас попрошу нарисовать "лесенку"(выкачал 1Мб - скорость упала в 2 раза, через следующий - в 4 итп)?

Можно сделать вложенные очереди. Но - зачем? Почти всегда достаточно просто расставить относительные приоритеты и максимальный / гарантированный канал.

пример покажите. потому что по ссылке, мягко говоря, не то.

начиная от того, что приоритезации сигнализации(5060) и небольшого диапазона udp-портов, заканчивая тем что у автора астериск подконтролен(а он может быть кастомера или же вообще совсем не астериск).

 

заверните rtp-трафик в отдельный класс. порты - динамические, сигналка - sip/h.323

У людей и вот такое работает:

http://fido7.ru.unix.bsd.narkive.com/6XAbIjTL/altq-rtp

Можно, как указано выше, ng_bpf - так, например, успешно торренты ловят.

торренты - это 1 пакет поймать и отбить. чтобы пиры не пытались по uTP работать.

полноценный разбор сложных протоколов есть в libalias. и мне интересно, как вы эту конструкцию скрестите с altq(вы же утверждали что всё можно, не так ли?).

 

P.S. Вам то шашечки нужны или ехать ;)?

мне бы полноценное решение, а не костыли. т.е. честно разобрали SIP, выдрали из него SDP, из SDP - порты для NAT. Та же самая фигня с H.323, FTP и прочими недружественными к МСЭ протоколами.

Изменено 27 июля, 2013 пользователем ^rage^

[Ivan_83]

Кстати, наплодить несколько неполноценных подсистем ядра, вместо того, чтобы реализовать все необходимые функции в какой-то одной - это тоже характерный для FreeBSD подход. В результате имеем: три файрвола, три реализации шейпинга (altq, dummynet, ng_car)

И что?

Хочешь, напиши свою.

Всё модульно и прекрасно взаимодействует.

 

сурьёзно? бинарный h.323, базирующийся на asn.1 ber разбирать bpf-машиной? )))) там и с сипом уже непросто, потому надо до sdp добраться.

asn.1 имеет постоянную структуру и оффсеты для конкретного применения, потому матчинг там не должен быть проблемным.

В крайнем случае нарисовать ноду для матчинга нужного.

[^rage^]

Кстати, наплодить несколько неполноценных подсистем ядра, вместо того, чтобы реализовать все необходимые функции в какой-то одной - это тоже характерный для FreeBSD подход. В результате имеем: три файрвола, три реализации шейпинга (altq, dummynet, ng_car)

И что?

Хочешь, напиши свою.

Всё модульно и прекрасно взаимодействует.

начнем с тэгов pf и их использования в рамках ipfw.

 

сурьёзно? бинарный h.323, базирующийся на asn.1 ber разбирать bpf-машиной? )))) там и с сипом уже непросто, потому надо до sdp добраться.

asn.1 имеет постоянную структуру и оффсеты для конкретного применения, потому матчинг там не должен быть проблемным.

В крайнем случае нарисовать ноду для матчинга нужного.

когда мне понадобилось разбирать BER, хотелось просто плакать(грамматики то у меня не было). с учётом того, что каждый вендор понимает стандарт по-своему, это такая особая боль.

а мысль "можно взять и написать"... ну давайте посчитаем стоимость такого счастья(зп программисту на время написания и отладки). не говоря уже о том, что в таком ключе можно сравнивать с некоей абстрактной, ненаписанной ОС.

[Ivan_83]

начнем с тэгов pf и их использования в рамках ipfw.

И что?

 

когда мне понадобилось разбирать BER, хотелось просто плакать(грамматики то у меня не было). с учётом того, что каждый вендор понимает стандарт по-своему, это такая особая боль.

ASN1 вcё очень чётко описывает.

[^rage^]

начнем с тэгов pf и их использования в рамках ipfw.

И что?

теги в pf - это своя, особенная сущность. номера тего в pf вычисляются pfctl при компиляции правил. в отличие от ipfw, где всё это статично и всё это не "поедет" после релоада правил.

 

когда мне понадобилось разбирать BER, хотелось просто плакать(грамматики то у меня не было). с учётом того, что каждый вендор понимает стандарт по-своему, это такая особая боль.

ASN1 вcё очень чётко описывает.

если есть грамматика и все пользуются только ей в кач-ве эталона.

[snvoronkov]

echo deadline > /sys/block/sdb/queue/scheduler

echo 1024 > /sys/block/sdb/queue/nr_requests

 

Дома не проканало. На одном ядре с дедлайном один жоркий до додиска процесс ставит колом всю файлуху.

Изменено 27 июля, 2013 пользователем snvoronkov

[NiTr0]

к слову, в 3.10 (или 3.9? не смотрел) BFQ включен уже в ядро...

[adsh]

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

А Вы не думаете, что это и есть т. н. unix way - собирать нужную функциональность из множества отдельных узко специфических программ вместо попытки лепить всё в один универсальный кривой комбайн.

 

В результате имеем: три файрвола, три реализации шейпинга (altq, dummynet, ng_car), пять способов настроить NAT

 

Так это же хорошо - есть из чего выбирать для решения конкретных задач.

 

пример покажите. потому что по ссылке, мягко говоря, не то.

Пример чего? Вот хороший практический пример из жизни:

 

https://calomel.org/pf_hfsc.html

 

См. "Can I use Pf's HFSC with my ISP's implementation of SpeedBoost or PowerBoost" ?

 

Эти провайдеры зажимают полосу как раз после выкачивания ххх Мб.

 

полноценный разбор сложных протоколов есть в libalias. и мне интересно, как вы эту конструкцию скрестите с altq(вы же утверждали что всё можно, не так ли?).

 

ipfw add altq <имя очереди> <условие срабатывания>

 

Та же самая фигня с ... FTP.

 

Что не так с FTP? У меня прекрасно работает задание приоритетов для ftp, как в активном, так и в пассивном режиме, да ещё и с заданием отдельного приоритета для ACK пакетов этого трафика. А контрольное соединение попадает в отдельную приоритетную очередь. Для этого удобно использовать тегирование:

 

anchor "ftp-proxy/*"

 

pass in quick inet proto tcp to !(self) port ftp divert-to 127.0.0.1 port 8021

 

match on $ext_if inet proto tcp tagged ftp_data queue (www ack)

match out on $ext_if inet proto tcp to port (ftp ssh telnet) queue (pri ack)

 

/usr/sbin/ftp-proxy -T ftp_data

 

(кто не в курсе - программа ftp-proxy просто ковыряет контрольное соединение и, ни в коей мере, не пропускает через себя реальный ftp_date трафик)

Изменено 27 июля, 2013 пользователем adsh

[NiTr0]

собирать нужную функциональность из множества отдельных узко специфических программ вместо попытки лепить всё в один универсальный кривой комбайн

Вы сможете собрать что-то из нескольких недоделанных реализаций? Скрестить pf с ipfw к примеру? :)

 

Так это же хорошо - есть из чего выбирать для решения конкретных задач.

5 натов, 3 из которых крутятся в юзерспейсе (с диким оверхидом) - что ж тут хорошего? Как юзерспейс нат еще не вымер-то как класс? В чем его профит?

[Ivan_83]

Вы сможете собрать что-то из нескольких недоделанных реализаций? Скрестить pf с ipfw к примеру? :)

Отсутствие второстепенного функционала не есть недоделаный основной функционал.

 

5 натов, 3 из которых крутятся в юзерспейсе (с диким оверхидом) - что ж тут хорошего? Как юзерспейс нат еще не вымер-то как класс? В чем его профит?

Там профит во всяких хелперах для фтп и пр.

[NiTr0]

Отсутствие второстепенного функционала не есть недоделаный основной функционал.

Второстепенность - вещь сугубо субъективная однако... Вместо того, чтобы впиливать нужный функционал в готовую реализацию - почему-то изобретается свой новый нескучный велосипед.

Не, с сугубо академической т.з. это можно понять, кто-то диплом защитил на новом велосипеде, но использовать это на практике...

 

Там профит во всяких хелперах для фтп и пр.

И что, перед каждым админом стоит диллема - то ли юзать быстрый нат, но позабыть об активном фтп/sip/pptp/прочем, или юзать тормозную юзерспейс реализацию, но с плюшками?

А в ядро хелперы перенести (как в лине) - чего не выходит?

[Ivan_83]

Второстепенность - вещь сугубо субъективная однако... Вместо того, чтобы впиливать нужный функционал в готовую реализацию - почему-то изобретается свой новый нескучный велосипед. Не, с сугубо академической т.з. это можно понять, кто-то диплом защитил на новом велосипеде, но использовать это на практике...

Всего 3 диплома?) Не маловато?

Допиливают фичи в имеющемся. Кому то ближе пф, кому то ипфв.

 

А в ядро хелперы перенести (как в лине) - чего не выходит?

хз, не интересовался.

[adsh]

Вы сможете собрать что-то из нескольких недоделанных реализаций? Скрестить pf с ipfw к примеру? :)

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

Типичный прикладной пример - можно НАТить GRE при помощи ipfw nat и остальное - через pf nat.

 

5 натов, 3 из которых крутятся в юзерспейсе (с диким оверхидом) - что ж тут хорошего? Как юзерспейс нат еще не вымер-то как класс? В чем его профит?

Обманывать публику то зачем? На самом деле в юзерспейсе там не три, а один - natd, остальные работают в ядре. Фактически же - функционал natd сейчас используется в ядерном ipfw nat. Только не говорите, что pf НАТит FTP "в юзерспейсе (с диким оверхидом)" - это от непонимания того, как оно на самом деле работает. Откуда придумали ещё один юзерспейс нат (кроме natd)?

 

И что, перед каждым админом стоит диллема - то ли юзать быстрый нат, но позабыть об активном фтп/sip/pptp/прочем, или юзать тормозную юзерспейс реализацию, но с плюшками?

А в ядро хелперы перенести (как в лине) - чего не выходит?

Да нет там никакой дилеММы. Хелперы давно уже в ipfw nat. Просто не всегда он самый удобный для конкретных задач.

 

Вы судите о возможностях FreeBSD по версии 4.х, да и то - с ошибками. Даже тогда в ней уже был ядерный ipnat, умеющий FTP.

[NiTr0]

Всего 3 диплома?) Не маловато?

Только по одной подсистеме :)

 

Типичный прикладной пример - можно НАТить GRE при помощи ipfw nat и остальное - через pf nat.

И в пул адресов без проблем занатится, без горки правил на каждый адрес пула? А как с распределением нагрузки по ядрам? pf nat уже научился ее балансировать?

 

Просто не всегда он самый удобный для конкретных задач.

Я ж и говорю - гора неполноценных подсистем... Вместо того, чтобы довести до ума одну из них (да хоть тот же ng-nat), и сделать юзерспейсовые прослойки-эмуляторы для простой миграции с прочих натов - тянется сразу 5 вариаций, одну из которых давным-давно надо закопать (natd) - но при этом почему-то именно natd рекомендуется в качестве ната в документации...

[Ivan_83]

А как с распределением нагрузки по ядрам? pf nat уже научился ее балансировать?

Уже есть многопоточный пф.

 

Я ж и говорю - гора неполноценных подсистем...

А в линухе и выбирать то не из чего :)

Сплошная не полноценность, никто под него ничего не пишет, только старьё переписывают да костылей добавляют :)

 

но при этом почему-то именно natd рекомендуется в качестве ната в документации...

Пора тебе обновить документацию :)