1.1, bga83 (ok), 14:27, 09/04/2012 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +/– |
пропускная способность такого решения упрется в цифру 150-180 Мбит/сек. Больше pf просто не в состоянии обработать. Связано с тем, что он работает только в дин поток, в отличие от ipfw.
Касаемо непосредственно правил: наличие в правилах quick крайне нежелательно и можно отнести к ошибке автора, хотя с чисто формальной точки зрения все будет работать. К тому же есть подозрение, что не совсем корректно идет заворачивание трафика в очереди(надо более детально разбираться, но поверхностный анализ говорит именно об этом). По умолчанию все правила pf имеют keep state, а это значит, что обратные пакеты будут попадать под тоже самое правило и значит проходить те же очереди, что не является корректным.
| |
|
2.4, mma (?), 05:46, 10/04/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
>пропускная способность такого решения упрется в цифру 150-180 Мбит/сек
Ерунда, все упрется в железо(проц и сетевухи) а не в ядро и софт
>наличие в правилах quick крайне нежелательно и можно отнести к ошибке автора
Это почему?
>По умолчанию все правила pf имеют keep state, а это значит, что обратные пакеты будут попадать под тоже самое правило и значит проходить те же очереди, что не является корректным.
Все ведь зависит от политики: допустим statefull или только stateless
| |
2.21, Andrew Kolchoogin (?), 00:51, 12/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Нет, не будет проходить, и это FAQ.
ALTQ появляется в ядре путём патча сетевых драйверов -- макрос IF_DEQUEUE() заменяется на IFQ_DEQUEUE(). IFQ_ENQUEUE() не существует в природе -- ALTQ работает ТОЛЬКО с исходящими пакетами.
| |
|
1.5, unscrubber2 (?), 07:29, 10/04/2012 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– |
>Связано с тем, что он работает только
> в один поток, в отличие от ipfw.
возможно это проблема если адаптеров несколько (при нагруженном хостинге vds например, виртуализации)
> это, похоже, девиз FreeBSD
PF был портирован с OpenBSD, наезд не засчитан.
да и вообще, я использую и linux и freebsd, можно не придираться а просто использовать то что в определенных условиях и задачах лучше/удобней работает.
сборка мира сама по себе и коллекция портов стоят того чтобы познакомится/использовать freebsd.
! про SMP - скоро (с релизом 6 OpenBSD версии, щас бета есть) можно будет желающим использовать NPF (много общего вижу по возможностям и синтаксису с PF, смhttp://netbsd.gw.com/cgi-bin/man-cgi?npf.conf++NetBSD-current), https://www.opennet.ru/opennews/art.shtml?num=27955 , мне лично больше всего конечно интерпретатор байткода и прочие новшества нравятся.
| |
|
2.6, artemrts (ok), 09:41, 10/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>[оверквотинг удален]
> да и вообще, я использую и linux и freebsd, можно не придираться
> а просто использовать то что в определенных условиях и задачах лучше/удобней
> работает.
> сборка мира сама по себе и коллекция портов стоят того чтобы познакомится/использовать
> freebsd.
> ! про SMP - скоро (с релизом 6 OpenBSD версии, щас бета
> есть) можно будет желающим использовать NPF (много общего вижу по возможностям
> и синтаксису с PF, смhttp://netbsd.gw.com/cgi-bin/man-cgi?npf.conf++NetBSD-current),
> https://www.opennet.ru/opennews/art.shtml?num=27955 , мне лично больше всего конечно
> интерпретатор байткода и прочие новшества нравятся.
А вот это уже интересно. Я так понял планируется NPF портировать в Опенок? Так а сам то он в Нете уже работает?
| |
|
1.9, Аноним (-), 01:40, 11/04/2012 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –1 +/– |
> Скорость от провайдера - 5 Мбит/c, к провайдеру - 850 Кбит/c.
И вот для этого предлагается ставить здоровый гроб с бсдой? Да с этим тплинк 1000-рублевый справится. Который места занимает чисто символически, можно считать что ничего не жрет и у него не забьется пылью вентиль на проце или в бп.
| |
|
2.10, Alexander Sheiko (?), 03:28, 11/04/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
Сейчас есть множество решений на Intel Atom, что куда функциональней китайских поделок с встроенной ОС при сравнимом энергопотреблении и размерах.
По сути статьи - с какой-то версии OpenBSD для раскидывания по очередям удобнее вместо совмещения правил "pass" /"queue" использовать "match" / "queue", а правила "pass" использовать отдельно.
Кроме того - забыли про FTP трафик и прогу ftp-proxy, формируемый которой трафик следует загонять в 2 очереди (ACK и FTP), используя тегирование пакетов.
| |
|
|
4.17, Alexander Sheiko (?), 16:49, 11/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
В пассивном тоже полезно, если открыты только определённые разрешённые порты. PF будет динамически открывать доступ к "левым" портам только для FTP DATA трафика.
| |
|
|
6.20, Alexander Sheiko (?), 20:21, 11/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Может быть при "драконовской" конфигурации, когда открыто пол-десятка портов. Но при такой, как в этом куске конфига, данные будут попадать в INET_OTHER очередь.
Я на пятом опёнке раскидываю так:
ps ax | grep ftp
21897 ?? Is 0:00.04 /usr/sbin/ftp-proxy -T ftp-proxy
pfctl -sa | grep ftp-proxy
match on pppoe0 proto tcp all queue(def, pri) tagged ftp-proxy
anchor "ftp-proxy/*" all
pass in on pppoe0 inet proto tcp all flags S/SA tagged ftp-proxy
ACK пакеты попадают в приоритетную очередь.
| |
|
|
|
3.13, Аноним (-), 14:14, 11/04/2012 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +/– |
> Сейчас есть множество решений на Intel Atom
Только они куда крупнее и прожорливее и не конфигурируются на 100% ремотно как правило. Еще не хватало - мыши, клавы и дисплеи к роутерам цеплять.
> куда функциональней китайских поделок с встроенной ОС
В почти все таковые при желании льется openwrt, после чего вопрос функциональности отпадает. Оно умеет сразу дофига всего что нужно от роутера. В том числе и приоритеты. При том большинство типовых операций еще и делаются через удобную вебморду, хардкорить со скриптами приходится только в каких-то совсем нестандартных раскладах.
| |
|
4.18, Alexander Sheiko (?), 16:56, 11/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
Да ну - 15-25 Вт максимум при 100% загрузке двухъядерного Атома. Клава и монитор нужны только для установки ОС.
Вебморда - это нечто домохозяйское :). Если мне захочется веб моруду - это будет pfSense .
| |
|
3.23, ragus (ok), 03:09, 12/04/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +1 +/– |
> Сейчас есть множество решений на Intel Atom, что куда функциональней китайских поделок
> с встроенной ОС при сравнимом энергопотреблении и размерах.
а не затруднит вас подтвердить ваши слова ссылками на предложения с ценниками и условиями доставки?
| |
|
|
|
6.81, Аноним (-), 16:54, 14/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Разумеется - в формате mini-ITX. Вот такое, к примеру:
Вот незадача то: оно стоит как _три_ тплинка (являющихся законченной системой в сборе готовой к работе) которые разрулят все перечисленное на канале с указанной скорсотью ни разу не икнув. И не является при этом готовой системой - надо еще корпус, БП, ... - обалденный "выигрыш".
| |
|
5.56, ragus (ok), 23:33, 12/04/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +1 +/– |
>> а не затруднит вас подтвердить ваши слова ссылками на предложения с ценниками
>> и условиями доставки?
> Выбирайте:
> http://hotline.ua/computer/materinskie-platy/7284-29309/
по ссылке какие-то комплектующие для PC
1)блок питания?
2)корпус?
3)память
4)на чём-то ещё надо хранить ОС
5)там всего 1 ethernet, т.е. рядом ещё и коммутатор.
мой вариант: D-link DIR-620 + openwrt. не шумит, пассивное охлаждение, коммутатор на 4 порта с поддержкой vlan'ов. цена вопроса 57$
| |
|
|
7.60, ragus (ok), 01:42, 13/04/2012 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +/– |
>> по ссылке какие-то комплектующие для PC
>> 1)блок питания?
>> 2)корпус?
>> 3)память
> На любой выбор.
да, ещё у dir-620 на борту 802.11n wifi адаптер.
| |
|
|
|
|
|
2.11, artemrts (ok), 09:48, 11/04/2012 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +/– |
>> Скорость от провайдера - 5 Мбит/c, к провайдеру - 850 Кбит/c.
> И вот для этого предлагается ставить здоровый гроб с бсдой? Да с
> этим тплинк 1000-рублевый справится. Который места занимает чисто символически, можно
> считать что ничего не жрет и у него не забьется пылью
> вентиль на проце или в бп.
Дело в том, что такой "гроб" имеет больше возможностей. Например, на этом сервере запущен Астериск. Например, у другого клиента при похожей конфигурации PF, существуют удаленные подсети по IPSec. Потребуется клиенту еще какая-нибудь функциональность - без проблем. А что вы с вашим тплинком сделаете?
| |
|
3.14, Аноним (-), 14:22, 11/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Дело в том, что такой "гроб" имеет больше возможностей.
Да ничего он не имеет. В каждую первую железку за тыщщу льется тот же опенврт и дальше - ну вы поняли.
> Например, на этом сервере запущен Астериск.
Этого для начала не было указано нигде. Впрочем астериск можно и на опенврт поставить. На тысячерублевую железку, да.
> А что вы с вашим тплинком сделаете?
Залью openwrt, далее то же самое что и вы, только 95% типовых задач роутера там уже разрюханы удобной аяксной вебмордой к тому же, где только параметры вписать и готово. А если чего-то нет то в конечном итоге это обычный пингвин. Даже пакеты можно доустановить.
| |
|
|
|
|
7.100, Аноним (-), 20:49, 16/04/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
> За "Изю" когда-нибудь ты ответишь.
А ты когда-нибудь ответишь за свои килобайты ламерского бреда. Это хуже. Поэтому давай ты будешь разевать рот только если хоть немного разбираешься в вопросе.
| |
|
6.51, Аноним (-), 16:23, 12/04/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
> вот только:
>1)возможностей у iptables больше
Бред. даже коментировать лениво.
> 2)не нуждается в костылях для трансляции "сложных" протоколов.
это connection tracking не костыль ?! с его линейным поиском конекта к которому относится данный пакет ?!
> 3)для netfilter есть модули аппаратной акселерации nat для роутерных SoC
Апаратный NAT это да.. это 10 даже а не 5. пиши бред дальше - хочется посметься.
| |
|
7.57, ragus (ok), 23:40, 12/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>> вот только:
>>1)возможностей у iptables больше
> Бред. даже коментировать лениво.
когда сказать нечего - лучше молчать.
>> 2)не нуждается в костылях для трансляции "сложных" протоколов.
> это connection tracking не костыль ?! с его линейным поиском конекта к
> которому относится данный пакет ?!
анонимные эксперты на марше. в conntrack хэш-таблица и поиск в ней O(1)
>> 3)для netfilter есть модули аппаратной акселерации nat для роутерных SoC
> Апаратный NAT это да.. это 10 даже а не 5. пиши бред
> дальше - хочется посметься.
смейтесь дальше: http://www.ralinktech.com/en/02_products/product.php?sn=1040
раздел features.
| |
|
|
5.109, alex.h (??), 00:23, 23/04/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
>> Даже пакеты можно доустановить.
> Вот достижение! А на FreeBSD можно не только доустановить, но и собрать
> ПО с нужными опциями ШТАТНО. Сюрприз?
Вот плохо даже не то, что Вами тут написано, а то, что не написано!
В то время, как человек указывает на систему, которая после инсталляции даёт готовый маршрутизатор и может быть установлена внутрь SOHO-коробочки (а OpenWRT можно и на x86, на том же Атоме использовать), Вы ему рассказываете как это замечательно точить маршрутизатор из системы общего назначения вручную.
Вот лучше бы рассказали про BSDRP и pfSence! А так получается, что на аргументы об удобстве системы, которая позволяет быстро получить типовой функционал и по желанию его расширить, приводятся аргументы: зато посмотрите, какая свобода творчества - каждый раз результат уникален!
| |
|
|
|
2.16, artemrts (ok), 15:57, 11/04/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
Ну это в этом случай такие скорости. А сколько есть провайдеров, предоставляющих Инет в десятки мегабит по кабелю к клиенту и несколько мегабит от него. Да в таком случае, если кто-то потянет с вас торрент, например, или вы будете заливать на аплоадер какой-нибудь файл, то вы толком даже страничку не загрузите. Так устроен ТСР...
Когда я начал на все роутеры внедрять в обязательном порядке QоS, я вам скажу, что качество работы пользователей в Инете значительно возросло.
Вот если у вас будет _гарантированный_ синхронный канал мегабит в 20, вот тогда можно и без приоритизации:-)
| |
|
3.25, ragus (ok), 03:14, 12/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Ну это в этом случай такие скорости. А сколько есть провайдеров, предоставляющих
> Инет в десятки мегабит по кабелю к клиенту и несколько мегабит
> от него. Да в таком случае, если кто-то потянет с вас
> торрент, например, или вы будете заливать на аплоадер какой-нибудь файл, то
> вы толком даже страничку не загрузите. Так устроен ТСР...
1)форвардить сотню мегабит на современных SoC не проблема даже софтварно.
2)проблемы возникают из-за nat
3)современные SoC имеют на борту аппаратную акселерацию nat
> Когда я начал на все роутеры внедрять в обязательном порядке QоS, я
> вам скажу, что качество работы пользователей в Инете значительно возросло.
> Вот если у вас будет _гарантированный_ синхронный канал мегабит в 20, вот
> тогда можно и без приоритизации:-)
а что вы подразумеваете под синхронным каналом? SDH/PDH?
| |
|
|
1.29, ragus (ok), 09:45, 12/04/2012 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +1 +/– |
2 вопроса к автору:
1)какова судьба торрент-трафика и как вы его класифицируете?
2)какова судьба https-трафика? как я понимаю, его ждёт судьба торрентов?
| |
|
2.32, artemrts (ok), 10:01, 12/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> 2 вопроса к автору:
> 1)какова судьба торрент-трафика и как вы его класифицируете?
> 2)какова судьба https-трафика? как я понимаю, его ждёт судьба торрентов?
После таких вопросов я могу сделать вывод, что читали статью через строчку, соответсвенно таков и ответ.
| |
|
3.34, ragus (ok), 10:04, 12/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
>> 2 вопроса к автору:
>> 1)какова судьба торрент-трафика и как вы его класифицируете?
>> 2)какова судьба https-трафика? как я понимаю, его ждёт судьба торрентов?
> После таких вопросов я могу сделать вывод, что читали статью через строчку,
> соответсвенно таков и ответ.
я то читал внимательно.
вы пишете:
>Трафик классифицируется как относительно сервиса/протокола (HTTP, FTP, Torrent) так и относительно пользователя, т.е. трафик от/к компьютера, например, бухгалтера может быть весь помечен как с высоким приоритетом, независимо от того Торрент это или FTP.
и я в упор не вижу классификацию по протоколу. всё что вы делаете - это сливаете трафик от разных хостов в соотв. очередь, т.е. при запущенных торрентах мы гарантированно получим хлюпающий/булькающий голос в voip.
а вот вы, судя по всему, ответить затрудняетесь.
| |
|
4.35, artemrts (ok), 13:05, 12/04/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
Еще раз внимательно читайте.
Трафик для сип пиров попадаеет в *_hipri, торрент в *_other, у каждой очереди своя _гарантированная_ полоса. Я потому и задействую ALTQ, что бы не было "бульканья", когда кто-то тянет торрент. Это практическая реально работатющая конфигурация.
А вы походу больше теоретик. Я же говорю поднимайте виртуалку смоделируйте, а потом будем спорить. Ок?
| |
|
5.37, ragus (ok), 13:16, 12/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
> Еще раз внимательно читайте.
> Трафик для сип пиров попадаеет в *_hipri, торрент в *_other, у каждой
> очереди своя _гарантированная_ полоса. Я потому и задействую ALTQ, что бы
> не было "бульканья", когда кто-то тянет торрент. Это практическая реально работатющая
> конфигурация.
в _hipri у вас попадёт только sip, но никак не rtp. rtp у вас попадёт в _other и будет делить полосу вместе с торрентами.
https у вас тоже свалится в _other.
> А вы походу больше теоретик. Я же говорю поднимайте виртуалку смоделируйте, а
> потом будем спорить. Ок?
я практик с опытом построения реально работающего call-центра с двумя офисами под операторов и факсами по g711(с t.38 тогда в астериске было совсем плохо).
| |
|
6.39, artemrts (ok), 13:23, 12/04/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
>> Еще раз внимательно читайте.
>> Трафик для сип пиров попадаеет в *_hipri, торрент в *_other, у каждой
>> очереди своя _гарантированная_ полоса. Я потому и задействую ALTQ, что бы
>> не было "бульканья", когда кто-то тянет торрент. Это практическая реально работатющая
>> конфигурация.
> в _hipri у вас попадёт только sip, но никак не rtp. rtp
> у вас попадёт в _other и будет делить полосу вместе с
> торрентами.
> https у вас тоже свалится в _other.
Блин. ну яж говорю через строчку читаете.
pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \
$mst queue (d_other d_ack) tag INET_OTHER
pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \
port {20 21 25 110 143 5190 8080 081} $mst queue (d_lowpri d_ack) tag INET_LOWPRI
pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \
port 443 $mst queue (d_pri d_ack) tag INET_PRI
Да в идеале, использовать еще и HTTPS прокси, груповой политикой настроить клинтов, но не хотел с этим заморачиваться.
>> А вы походу больше теоретик. Я же говорю поднимайте виртуалку смоделируйте, а
>> потом будем спорить. Ок?
> я практик с опытом построения реально работающего call-центра с двумя офисами под
> операторов и факсами по g711(с t.38 тогда в астериске было совсем
> плохо).
А, пипетками буим меряться? :-)
| |
|
7.41, ragus (ok), 13:26, 12/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>[оверквотинг удален]
> $mst queue (d_other d_ack)
> tag INET_OTHER
> pass in log on $int_if inet proto tcp from
> ($int_if:network) to !(self:network) \
> port {20 21 25
> 110 143 5190 8080 081} $mst queue (d_lowpri d_ack) tag INET_LOWPRI
> pass in log on $int_if inet proto tcp from
> ($int_if:network) to !(self:network) \
> port 443 $mst queue
> (d_pri d_ack) tag INET_PRI
и где тут RTP?
> А, пипетками буим меряться? :-)
мы же с вами профессионалы. давайте достанем и померяемся! (с)
| |
|
|
|
4.38, artemrts (ok), 13:19, 12/04/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
>[оверквотинг удален]
>>> 1)какова судьба торрент-трафика и как вы его класифицируете?
>>> 2)какова судьба https-трафика? как я понимаю, его ждёт судьба торрентов?
>> После таких вопросов я могу сделать вывод, что читали статью через строчку,
>> соответсвенно таков и ответ.
> я то читал внимательно.
> вы пишете:
>>Трафик классифицируется как относительно сервиса/протокола (HTTP, FTP, Torrent) так и относительно пользователя, т.е. трафик от/к компьютера, например, бухгалтера может быть весь помечен как с высоким приоритетом, независимо от того Торрент это или FTP.
> и я в упор не вижу классификацию по протоколу. всё что вы
> делаете - это сливаете трафик от разных хостов в соотв. очередь,
> т.е. при запущенных торрентах мы гарантированно получим хлюпающий/булькающий голос в voip.
Смотрите. Трафик весь идет с высоким приоритетом (hipri) для отдельных хостов, потому что эти пользователи гарантированно торент качать не будут. Стоит система клиент-банк и всякие там отчетности в налоговую\ПФ и т.д. Да в эту очередь я направляю траф к сип пирам, который класифицируется протоколом, портом и адресами назначения. Торрент, восновном - это UDP с портами > 1024 - это очередь *_other, через ТСР\80 не пройдет, так как там прозрачный прокси.
| |
|
5.40, ragus (ok), 13:23, 12/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Да в эту
> очередь я направляю траф к сип пирам, который класифицируется протоколом, портом
> и адресами назначения.
вы туда направляете только сигнализацию, но никак не пакетики с голосом.
всё что вы таким образом добиваетесь - это потенциально более быстрое установление/завершение сессии итп. на качество голоса это никак не повлияет и в вашем варианте он будет булькать/хлюпать итп.
> Торрент, восновном - это UDP с портами >
торрент - это tcp. utp провайдеры режут достаточно успешно.
| |
|
6.44, artemrts (ok), 13:37, 12/04/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
> торрент - это tcp. utp провайдеры режут достаточно успешно.
Совершенно ошибочное мнение. У меня процент ТСР трафика торрента не более 20. Мониторил через ng_netflow + pmacct
| |
|
7.46, ragus (ok), 13:49, 12/04/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>> торрент - это tcp. utp провайдеры режут достаточно успешно.
> Совершенно ошибочное мнение. У меня процент ТСР трафика торрента не более 20.
> Мониторил через ng_netflow + pmacct
а как вы отличаете торрент от не торрента? :)
и в таком случае по вашим же правилам торрент свалится в u_pri вместе c rtp.
| |
|
6.104, Аноним (-), 21:06, 16/04/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
> торрент - это tcp. utp провайдеры режут достаточно успешно.
Во первых, не все провы, а только мелкотравчатые мелкие локалки с черти-чем вместо роутеров.
Во вторых, оно первым делом сносит роутеры у хомяков, что способствует росту их мощности :)
В третьих, в бсдах он не то чтобы тривиально режется :)
| |
|
7.110, XoRe (ok), 23:16, 07/05/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>> торрент - это tcp. utp провайдеры режут достаточно успешно.
> Во первых, не все провы, а только мелкотравчатые мелкие локалки с черти-чем
> вместо роутеров.
Ага.
Qwerty (Москва) и Beeline (там же).
> Во вторых, оно первым делом сносит роутеры у хомяков, что способствует росту
> их мощности :)
Роутеры у хомяков часто вполне осиляют, конечно, если канал не сильно большой.
> В третьих, в бсдах он не то чтобы тривиально режется :)
В бсдах как раз есть очень эффективный механизм в виде ng_bpf, который позволяет L7 фильтрацию.
Конкретно для uTP:
http://vurd.name/2011/09/03/%D0%B1%D0%BB%D0%BE&
| |
|
|
|
|
|
|
1.113, Андрей (??), 09:04, 18/07/2013 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– |
Подскажите пожалуйста, как правильно прописать ограничение по скорости при ширине канала в 15-20 Мегабит?
Заранее благодарен.
| |
|
2.114, artemrts (ok), 10:15, 18/07/2013 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Подскажите пожалуйста, как правильно прописать ограничение по скорости при ширине канала
> в 15-20 Мегабит?
> Заранее благодарен.
А разве в статье об этом не сказано?
Назначаем очередь на внешнем интерфейсе. Величина bandwidth должна быть 96% от предоставляемой вышестоящим роутером. Здесь же перечисляем все дочерние очереди.
altq on $ext_if hfsc bandwidth 800Kb queue ...
| |
|
1.115, Андрей (??), 16:29, 23/07/2013 [ответить] [﹢﹢﹢] [ · · · ] [↑] [к модератору]
| +/– |
Пробовал, но при загрузке правил вылетает вот такие ошибки
pfctl: the sum of the child bandwidth higher than parent "root_bce1"
pfctl: linkshare sc exceeds parent's sc
/etc/pf.conf:65: errors in queue definition
parent inetq not found for d_std
/etc/pf.conf:66: errors in queue definition
parent inetq not found for d_ack
/etc/pf.conf:67: errors in queue definition
parent inetq not found for d_dns
/etc/pf.conf:68: errors in queue definition
parent inetq not found for d_hipri
/etc/pf.conf:69: errors in queue definition
parent inetq not found for d_pri
/etc/pf.conf:70: errors in queue definition
parent inetq not found for d_lowpri
/etc/pf.conf:71: errors in queue definition
parent inetq not found for d_other
/etc/pf.conf:72: errors in queue definition
| |
|