Comments 98
Офигенно!
Можете выложить полный конфиг htb?
пожалуйста, выложил
спасибо, очень актуально!
Не нашел пакет HTB в своей Ubuntu 9.04 Server. Т.е., там нет /etc/htb/*.
В репозиториях тоже нет.
Значит собирать надо самому?
В репозиториях тоже нет.
Значит собирать надо самому?
HTB — это дисциплина шейпера, который встроен в ядро и управляется командой tc
то что мы тут назвали «конфиг htb» — это куча файликов, которые парсит скрипт htb.init и превращает их в команды tc. htb.init есть в пакетах или нет — не помню, фактически это bash-скрипт, его можно скачать с оффсайта sourceforge.net/projects/htbinit/
то что мы тут назвали «конфиг htb» — это куча файликов, которые парсит скрипт htb.init и превращает их в команды tc. htb.init есть в пакетах или нет — не помню, фактически это bash-скрипт, его можно скачать с оффсайта sourceforge.net/projects/htbinit/
Спасибо, добавил с мемориз.
UFO just landed and posted this here
UFO just landed and posted this here
Отлично будет работать, только наверное надо будет как то автоматизировать генерацию конфигов классов пользователей, чтоб вручную потом не править 40 файликов, когда надо измениь скорость. Или же отказаться от htb.init и напрямую управлять шепером с помощью утилиты tc
Главная проблема — это как будет фильтроваться трафик и попадать в тот или иной класс. для 30-40 человек и 10МБит — это не критично, а вот если у вас 10к пользователей, то могут возникнуть проблемы. Если кому-то интересно — могу расписать чуть подробнее.
Да, интерессно :)
Конечно интересует! Пока моя сеть настолько не выросла, но возможно в будущем ;-)
А в принципе — пакеты фильтруются с помощью маркировки файрволом,
в /usr/src/linux-2.5.73/include/linux/netfilter_ipv4/ipt_mark.h марки объявлены как unsigned longs,
тоесть может быть 2^32 марок пакетов, тоесть 4 294 967 296 классов трафика или пользователей =)
А в принципе — пакеты фильтруются с помощью маркировки файрволом,
в /usr/src/linux-2.5.73/include/linux/netfilter_ipv4/ipt_mark.h марки объявлены как unsigned longs,
тоесть может быть 2^32 марок пакетов, тоесть 4 294 967 296 классов трафика или пользователей =)
существует две популярные схемы создания соответствия ip->htb class: «ipmark» и «ipclassify».
Первая реализуется маркировкой в iptables, вторая использование tc filter u32(с хэшами).
У первой схемы недостаток в разрастании таблиц iptables. При существовании 10к пользователей мы имеем 10к правил iptables(через все проходит каждый пакет) и 10k фильтров tc. При большом потоке пакетов ksoftirqd уходит в вечный луп, загружая одно ядро сервера.
У второй схемы недостаток в абсолютной адском синтаксисе настройки и жуткой глючности при изменении(удалении) фильтров. При существовании статических классов и фильтров не плохое решение, если использовать хэш таблицы.
Не так давно в ядро добавили новую схему tc filter flow(разработанная изначально для sfq кудиска). Она лишена всех описанных недостатков, только совершенно не документирована и может быть использована только адептами, читающими исходный код. =)
зы марков 2^32, а вот классов увы может быть только 0xffff
зыы на днях соберусь — распишу подробно все три схемы с примерами.
Первая реализуется маркировкой в iptables, вторая использование tc filter u32(с хэшами).
У первой схемы недостаток в разрастании таблиц iptables. При существовании 10к пользователей мы имеем 10к правил iptables(через все проходит каждый пакет) и 10k фильтров tc. При большом потоке пакетов ksoftirqd уходит в вечный луп, загружая одно ядро сервера.
У второй схемы недостаток в абсолютной адском синтаксисе настройки и жуткой глючности при изменении(удалении) фильтров. При существовании статических классов и фильтров не плохое решение, если использовать хэш таблицы.
Не так давно в ядро добавили новую схему tc filter flow(разработанная изначально для sfq кудиска). Она лишена всех описанных недостатков, только совершенно не документирована и может быть использована только адептами, читающими исходный код. =)
зы марков 2^32, а вот классов увы может быть только 0xffff
зыы на днях соберусь — распишу подробно все три схемы с примерами.
Если напишите статью — пожалуйста, оставьте тут ссылку на нее.
А по поводу разрастания таблиц iptables — товарищ когда то писал самодельный патч для ядра, для того чтоб фильтровать трафик по большому черному списку IP. Чем нравится linux — если тебе перестает хватать стандартных вещей — ты можешь написать что то специализированное и очень быстрое, но такая необходимость возникает редко, все обычно уже написано =)
А по поводу разрастания таблиц iptables — товарищ когда то писал самодельный патч для ядра, для того чтоб фильтровать трафик по большому черному списку IP. Чем нравится linux — если тебе перестает хватать стандартных вещей — ты можешь написать что то специализированное и очень быстрое, но такая необходимость возникает редко, все обычно уже написано =)
я думаю вы имеете ввиду ipset. Да, это известный и удобный патч, но в данном случае использовать его не получится, тк нам нужно уникальное правило ip->ipmark.
Нет, тот патч в свободное плавние не вышел.
Можно сделать гораздо проще, пропачить ядро так, чтоб класс назначался так:
допустим исходящий или входящий адрес 192.168.0.x тогда назначить класс x
тогда просто для других целей, не идентификации пользователей, надо использовать классы > 255
Можно сделать гораздо проще, пропачить ядро так, чтоб класс назначался так:
допустим исходящий или входящий адрес 192.168.0.x тогда назначить класс x
тогда просто для других целей, не идентификации пользователей, надо использовать классы > 255
tc filter flow как раз так и делает.
www.mail-archive.com/netdev@vger.kernel.org/msg60638.html
www.mail-archive.com/netdev@vger.kernel.org/msg60638.html
Познавательно, большое спасибо
А как сделать что-то похожее на домашнем виндовс? Только чтобы не разграничивать не по пользователям, а по приложениям.
купить NetLimiter
Купить cfosspeed.
насколько хорошо работает динамический шейпинг входящего трафика для торрентов? я когда пробовал, у меня торренты все время сжирали канал по-максимуму. В итоге закачки через wget или aria2c еще как-то отбирали канал у торрентов, но серфинга фактически не было.
Я не ставил своей целью сделать так, чтоб каждый пользователь мог одновременно и серфить и качать торренты на полную, просто разделил канал, чтоб условно говоря торренты первого не мешали серфинуг второго. И это прекрасно работает, значит ничего не мешает сделать и чтоб у одного пользователя торренты не мешали серфингу. Чтоб это сделать — надо всего лишь добавить каждому пользователю по два класса — http, а так же аська, jabber, игры — в один класс, которому назначен высокий приоритет и гарантированная полоса, и все остальное — во второй класс, с минимальным приоритетом.
К сожалению отфильтровать трафик торрентов не так просто, поэтому и прийдется действовать методом исключения. Хотя я уже видел патчи для ядра, позволяющие фильтровать по протоколу третьего уровня.
К сожалению отфильтровать трафик торрентов не так просто, поэтому и прийдется действовать методом исключения. Хотя я уже видел патчи для ядра, позволяющие фильтровать по протоколу третьего уровня.
торрент трафик грубо это все по портам 10000+ (может даже 1000+). Кроме редчайших исключений, потому фильтровал я так. Делал
Немного ошибся, фильтры 7 уровня (имеется в виду уровень модели OSI) вот их страничка l7-filter.sourceforge.net/
делал так и торренты съедали все из ceil. на серфинг не хватало.
В таком случае можно разделить канал на много больше полос, отдельно для http, jaber, ssh и т.д. А весь остальной трафик сделать низкоприоритетным
а зачем? в моем случае низкоприоритетный трафик от торрентов забивал практически весь канал и серфинг не работал.
ммм… Странно. Я видимо чего-то недопонимаю в условии задачи.
2 варианта
1) Вы — провайдер и режете канал в соответствии с аккаунтами пользователей. И вам всеравно как тот или иной юзер использует выделенную ему полосу.
2) Офис. Не много машин. Около N мегабит канал. Все равноправны. Мы сразу разделим его на полосы с различными приоритетами. А потом все это добро распределим между пользователями. Во 2м случае влияние низкоприотетного трафика не должно сказываться на высокоприоритетном (в идеале конечно). Если у вас к примеру X машин. То вы указываете минимально гарантированную скорость равную ширине канала без поправки в 2-3% от первого параметра и поделенную на кол-во пользователей (X). Максимальное же пропускную способность можно установить как (0,9*N)/X.
Указанные параметры притянуты за уши, дабы проиллюстрировать решение. Не более того
2 варианта
1) Вы — провайдер и режете канал в соответствии с аккаунтами пользователей. И вам всеравно как тот или иной юзер использует выделенную ему полосу.
2) Офис. Не много машин. Около N мегабит канал. Все равноправны. Мы сразу разделим его на полосы с различными приоритетами. А потом все это добро распределим между пользователями. Во 2м случае влияние низкоприотетного трафика не должно сказываться на высокоприоритетном (в идеале конечно). Если у вас к примеру X машин. То вы указываете минимально гарантированную скорость равную ширине канала без поправки в 2-3% от первого параметра и поделенную на кол-во пользователей (X). Максимальное же пропускную способность можно установить как (0,9*N)/X.
Указанные параметры притянуты за уши, дабы проиллюстрировать решение. Не более того
>Вы — провайдер и режете канал в соответствии с аккаунтами пользователей. И вам всеравно как тот или иной юзер использует выделенную ему полосу.
Нууу… Это так, если Вы честный, богатый и процветающий провайдер, канал Вам обходится дешево, клиенты платят много и нет конкурентов. Но наверняка в такой вселенной давно уже победил бы коммунизм.
Реально же многие (если не все) мелкие провайдеры продают больше полосы, чем имеют. Вот и приходиться шейпить все кроме веба, игр и VoIP.
Нууу… Это так, если Вы честный, богатый и процветающий провайдер, канал Вам обходится дешево, клиенты платят много и нет конкурентов. Но наверняка в такой вселенной давно уже победил бы коммунизм.
Реально же многие (если не все) мелкие провайдеры продают больше полосы, чем имеют. Вот и приходиться шейпить все кроме веба, игр и VoIP.
UFO just landed and posted this here
Тян.
симпатишный траффик… ;)
viperet почему именно пингвин и htb? Какие преимущества дает это по сравнению например с бсд? Сижу выбираю для себя решение, хотелось бы услышать ваше мнение.
Я уже описывал в комментариях к другой статье, про объединение каналов, но напишу еще раз :-)
Linux потому что…
У меня в качестве сервера/роутера используется старый компьютер, на основе Celeron 300 MHz, со 128 MB памяти и HDD на 4 GB. Поэтому к выбору ОС я подходил очень основательно! Вначале правда HDD там вообще небыло, поэтому использовал специализированный дистрибутив для роутеров Zeroshell linux на livecd, кстати в новой версии добавили кучу вкусного, практически все что я долгими трудами и кропотливой настройкой сделал у себя на стандартном дистрибутиве там есть из коробки. Тогда еще пробовал несколько дистрибутивов для роутеров на FreeBSD но они не пошли на том железе (я очень удивился). Когда появился жесткий диск, стал выбор нового дистрибутива, zeroshell уже не устраивал. Выбрал Ubuntu Linux, потому что пакеты скачиваютя уже собраными, их ненадо самому компилировать. На таком процессоре, как у меня, сборка скажем Samba затянулась бы надолго, а пересобрать ядро — вообще долгий процесс и даже для временных файлов места бы нехватило. К тому же у меня был слабый интернет-канал, и я специально перемерял — скомпилированные бинарники весили меньше, чем их исходники.
Так что выбор был вполне осознанным, до этого я администрировал и Red Hat и Debian и FreeBSD.
А htb потому что вначале сделал QoS на cbq, но его возможностей явно нехватало, вот и перешал на htb
Linux потому что…
У меня в качестве сервера/роутера используется старый компьютер, на основе Celeron 300 MHz, со 128 MB памяти и HDD на 4 GB. Поэтому к выбору ОС я подходил очень основательно! Вначале правда HDD там вообще небыло, поэтому использовал специализированный дистрибутив для роутеров Zeroshell linux на livecd, кстати в новой версии добавили кучу вкусного, практически все что я долгими трудами и кропотливой настройкой сделал у себя на стандартном дистрибутиве там есть из коробки. Тогда еще пробовал несколько дистрибутивов для роутеров на FreeBSD но они не пошли на том железе (я очень удивился). Когда появился жесткий диск, стал выбор нового дистрибутива, zeroshell уже не устраивал. Выбрал Ubuntu Linux, потому что пакеты скачиваютя уже собраными, их ненадо самому компилировать. На таком процессоре, как у меня, сборка скажем Samba затянулась бы надолго, а пересобрать ядро — вообще долгий процесс и даже для временных файлов места бы нехватило. К тому же у меня был слабый интернет-канал, и я специально перемерял — скомпилированные бинарники весили меньше, чем их исходники.
Так что выбор был вполне осознанным, до этого я администрировал и Red Hat и Debian и FreeBSD.
А htb потому что вначале сделал QoS на cbq, но его возможностей явно нехватало, вот и перешал на htb
Спасибо, попробу настроить на роутере!
Подскажите по каким критериям можно выделить трафик skype?
выделить скайп по портам так просто не получится, помочь сделать это вам могут фильтры L7, читайте l7-filter.sourceforge.net/protocols, там указано что уже написаны фильтры для выделения Skype
Вот так надо Линукс подавать, загорелой и в халате.
А что делать если скорость соединения зависит от времени? У меня скорость в интернет днем 512кбит, а ночью 1мбит(«сильной» ночью и того больше), и не охота чтобы ночью полоса простаивала… можно ли динамически менять значения скорости? И как это сделать?
Та же примерно проблема… По тарифу скорость одна, и довольно большая, но на деле сильно зависит от загрузки внешнего канала и сильно прыгает…
можно указать параметр TIME для того чтобы запрограммировать зависимость ширины канала от времени:
### Time ranging parameters
#
# TIME=[.../]-;[/][,[/]]
# TIME=60123/18:00-06:00;256Kbit/10Kb,384Kbit
# TIME=18:00-06:00;256Kbit
#
# This parameter allows you to change class bandwidth during the day or
# week. You can use multiple TIME rules. If there are several rules with
# overlapping time periods, the last match is taken. The , ,
# and fields correspond to parameters RATE, BURST, CEIL
# and CBURST.
#
# is single digit in range 0-6 and represents day of week as
# returned by date(1). To specify several days, just concatenate the
# digits together.
только там тонкость есть - чтоб это првило работало надо htb.init. вызывать с каким то параметром по крону, читайте маны ;-)
Друзья, вроде бы по теме, но немного офтопик. У меня тут VServer, доступ через рут, апач2, установлен Plesk, несколько vhost'ов, висит всё это дело на debian (etch).
Так вот для одного vhost'а нужно ограничить трафик. Ну что бы с ip качалось только в несколько кбпс. Но только на этот vhost.
Там специальный файл для этого уже выделен, vhost.conf, туда можно писать всё то, что обычно в конфиге апача светится.
Пробовал установить (apt-get) libapache2-mod-bw, но после вроде бы успешной инсталяции его не видно ни в каталогах апача (mods) и нельзя установить волшебной командой «a2enmod bw».
Может это вообще не тот метод и есть что-то поинтереснее?
Так вот для одного vhost'а нужно ограничить трафик. Ну что бы с ip качалось только в несколько кбпс. Но только на этот vhost.
Там специальный файл для этого уже выделен, vhost.conf, туда можно писать всё то, что обычно в конфиге апача светится.
Пробовал установить (apt-get) libapache2-mod-bw, но после вроде бы успешной инсталяции его не видно ни в каталогах апача (mods) и нельзя установить волшебной командой «a2enmod bw».
Может это вообще не тот метод и есть что-то поинтереснее?
Тут есть одна проблемка…
Вот у вас канал 2 Мбит. Причём и на вход и на выход. Но контролировать вы можете только исходящий поток, но никак не входящий. Входящий шейпить бесполезно, поскольку провайдер зарежет трафик по-тупому ещё у себя. Торренты идут на UDP и контроль потока там достаточно агрессивный, даже в случае потерь пакеты будут долбится.
То же самое с телефонией (SKYPE, SIP) и много с чем ещё. Даже простые закачки (на базе TCP) одного из пользователей могут занять входящий канал по-полной, наплевав на остальных. Хотя TCP это сделать сложнее, поскольку в случае потерь идёт существенный срез по скорости.
Вот у вас канал 2 Мбит. Причём и на вход и на выход. Но контролировать вы можете только исходящий поток, но никак не входящий. Входящий шейпить бесполезно, поскольку провайдер зарежет трафик по-тупому ещё у себя. Торренты идут на UDP и контроль потока там достаточно агрессивный, даже в случае потерь пакеты будут долбится.
То же самое с телефонией (SKYPE, SIP) и много с чем ещё. Даже простые закачки (на базе TCP) одного из пользователей могут занять входящий канал по-полной, наплевав на остальных. Хотя TCP это сделать сложнее, поскольку в случае потерь идёт существенный срез по скорости.
Машина на той стороне не будет посылать ещё, если не будет подтверждений от нашей машины — на этом можно играть.
можно, но это верно только для TCP, где есть congestion control. У битторента через удп(и скайпа), есть похожий механизм, но он более «жадный»(агресивный, как зметил shandor). При большом количестве коннектов у торрент клиента входящий поток пакетов может существенно превышать выделенный вам лимит.
А битторрент через удп вообще есть? У меня все клиенты что я знаю умеют только TCP.
Насчёт скайпа — он поддаётся L7 анализу и тем более у него фиксированная ширина полосы, он около 8 килобайт в секунду ест и ему как раз надо наименьшую задержку.
Насчёт скайпа — он поддаётся L7 анализу и тем более у него фиксированная ширина полосы, он около 8 килобайт в секунду ест и ему как раз надо наименьшую задержку.
кстати даже у TCP может быть очень агрессивный контроль потока.
Теоретически входящий поток могут регулировать шейперы на стороне клиента — например, известнейший cFosSpeed — www.cfos.de/speed/cfosspeed_e.htm.
К сожалению, пока он не умеет взаимодействовать с другими компьютерами по сети, но вроде разработчики планировали внедрить такую функциональность.
К сожалению, пока он не умеет взаимодействовать с другими компьютерами по сети, но вроде разработчики планировали внедрить такую функциональность.
> взаимодействовать с другими компьютерами по сети
в нашем случае требуется взаимодействие роутера (домашнего сервера) и сервера провайдера. Ни один провайдер на такое не пойдёт.
в нашем случае требуется взаимодействие роутера (домашнего сервера) и сервера провайдера. Ни один провайдер на такое не пойдёт.
Это понятно. Ну хотя бы управлять каналом на участке от компа до домашнего роутера — к примеру…
а смысл управлять этим каналом? он как правило 100Мбит и проблем особых нет.
Ну лучше как-то управлять, чем никак не управлять — особенно если в сети много компьютеров, а узким местом является интерфейс домашнего роутера. Было бы неплохо, чтобы на него и от него важные пакеты шли с большим приоритетом.
Вдумайтесь в то что вы говорите.
Управлять = резать, дропать.
По дорогущему каналу пришёл пакет, а вы его собираетесь убрать только потому, что пользователь «превысил» лимит? Совсем неразумная политика.
Управлять = резать, дропать.
По дорогущему каналу пришёл пакет, а вы его собираетесь убрать только потому, что пользователь «превысил» лимит? Совсем неразумная политика.
Сейчас использую pf+priq. канал 2мегабита. 5 юзеров.
Когда rtorrent-у было позволено создавать 100+ одновременных соединений — приоритезация нифига не работала (работала, но я этого не чувствовал). Тупило все и у всех. Ограничил 32 соединениями — и о чудо — все летает.
Однажды обнаружил, что «чтото тормозит все». 2000 соединеий от одного чела на 25 порт :)
Нет больше исходящих соединений на 25 порт :)
Может ктото смог сделать деление трафика, если есть 2 vpn соединения с провайдером?
ng_one2many курить? и что с MPD делать?
Когда rtorrent-у было позволено создавать 100+ одновременных соединений — приоритезация нифига не работала (работала, но я этого не чувствовал). Тупило все и у всех. Ограничил 32 соединениями — и о чудо — все летает.
Однажды обнаружил, что «чтото тормозит все». 2000 соединеий от одного чела на 25 порт :)
Нет больше исходящих соединений на 25 порт :)
Может ктото смог сделать деление трафика, если есть 2 vpn соединения с провайдером?
ng_one2many курить? и что с MPD делать?
Вы случаем не через ADSL работаете? Ну и еще некоторые провайдеры для домашних тарифов ограничивают число одновременных соединений.
> Может ктото смог сделать деление трафика, если есть 2 vpn соединения с провайдером?
Вам надо объеденить два интернет-канала? Тогда вам сюда habrahabr.ru/blogs/linux/54748/ (на линуксе)
> Может ктото смог сделать деление трафика, если есть 2 vpn соединения с провайдером?
Вам надо объеденить два интернет-канала? Тогда вам сюда habrahabr.ru/blogs/linux/54748/ (на линуксе)
Еще подумал, хорошим противодествием должно быть указание скоростей открытия соединений в единицу времени. А то получается лавинообразное образование огромного кол-ва соединение, даже если данных нужно реально мало.
Уважаемый автор, не могли бы вы создать подробную инструкцию по настройке динамического шейпинга с целью разделения приоритетов трафика в пределах одной машины? А то с переходом на linux найти аналог cFosSpeed так и не удалось, а по этой инструкции настроить уровня знаний не хватает.
Желательно бы готовое решение с уже описанными в правилах программами для торрентокачалки, аськи, браузеров. Я и многие страждущие был бы премного благодарен.
Желательно бы готовое решение с уже описанными в правилах программами для торрентокачалки, аськи, браузеров. Я и многие страждущие был бы премного благодарен.
А как причесать voip трафик?
а что у вас делает файлик eth1-2:10.local?
# root class containing total bandwidth
RATE=100Mbit
RULE=192.168.0.75,
RULE=194.9.14.86,Интерфейс eth1 — смотрит у меня в локальную сеть. Соответственно на нем шейпим исходящий трафик пользователей, и этот класс, в который попадает трафик от пользователей до сервера (тут указаны его внутренний и внейшний адреса), пришлось создать, чтоб не ограничивать скорость аплоада файлов на сервер.
То есть если бы небыло этого класса, то скорость скажем заливки фильма на сервер шейпилась бы на уровне моего исходящего интернет-канала.
Надеюсь объяснил понятно )))
То есть если бы небыло этого класса, то скорость скажем заливки фильма на сервер шейпилась бы на уровне моего исходящего интернет-канала.
Надеюсь объяснил понятно )))
да вполне, спасибо, у меня та же схема — eth1-провайдер, eth0-локалка. А еще такой вопросик если к внутреннему интерфейсу подключены следующие сети 192.168.0.0/18, 192.168.64.0/18, 172.17.0.0/16, 10.0.0.1/24 адрес сервера. как быть тогда?=) Внешний адрес скажем 194.9.14.86
с Вашими конфигами (разница в ip-адресах) в логах пишет:
Почитал такое тоже у многих хотя работает, но подтупливает. Пробовал увеличить параметр r2q до 5 — пишет тоже самое, ставлю 6 — пишет наоборот что quantum маленький. Единственный выход уменьшать RATE.
Кстати можно шейпить исходящий канал путем создания правил для второго интерфейса и маркировкой пакетов. Viperet может дополните статью?
HTB.upload
Jan 24 00:42:01 promeline kernel: [227188.455801] HTB: quantum of class 10002 is big. Consider r2q change.
Jan 24 00:42:01 promeline kernel: [227188.468883] HTB: quantum of class 10010 is big. Consider r2q change.
Jan 24 00:42:01 promeline kernel: [227188.505408] HTB: quantum of class 10020 is big. Consider r2q change.
Jan 24 00:42:01 promeline kernel: [227188.523841] HTB: quantum of class 10030 is big. Consider r2q change.
Jan 24 00:48:49 promeline kernel: [227596.549608] HTB: quantum of class 10002 is big. Consider r2q change.
Jan 24 00:48:49 promeline kernel: [227596.554105] HTB: quantum of class 10010 is big. Consider r2q change.
Jan 24 00:48:49 promeline kernel: [227596.567500] HTB: quantum of class 10020 is big. Consider r2q change.
Jan 24 00:48:50 promeline kernel: [227596.597421] HTB: quantum of class 10030 is big. Consider r2q change.
Почитал такое тоже у многих хотя работает, но подтупливает. Пробовал увеличить параметр r2q до 5 — пишет тоже самое, ставлю 6 — пишет наоборот что quantum маленький. Единственный выход уменьшать RATE.
Кстати можно шейпить исходящий канал путем создания правил для второго интерфейса и маркировкой пакетов. Viperet может дополните статью?
HTB.upload
Так а в чем проблема шейпить исходящий канал? У меня там в конфиге правила для интерфейса eth1 — они и шейпят исходяший трафик пользователей.
ну в Ваших конфигах просто выделяется полоса в 2 мегабита, насколько я понял, а маркировка позволяет каждому юзеру давать разную полосу
а как сделать так чтоб канал делился равномерно по ip, а не по потокам? Выходит что один Download Master c 8 потоками забирает на себя весь rate класса.
создавайте под каждый IP свой класс HTB, как в примере.
неправильно выразился, весь ceil класса,
то есть, канал раскидан всем ip с одинаковым CEIL класса, но если с одного ip включается многопоточная закачка, то шейпер делит поровну скорость между потоками, а хотелось бы чтоб делил скорость поровну между адресами.
P.S.Слышал про flow classifier но как и с чем его едят, так толком и не вразумляю.
то есть, канал раскидан всем ip с одинаковым CEIL класса, но если с одного ip включается многопоточная закачка, то шейпер делит поровну скорость между потоками, а хотелось бы чтоб делил скорость поровну между адресами.
P.S.Слышал про flow classifier но как и с чем его едят, так толком и не вразумляю.
Sign up to leave a comment.
Причесываем трафик — динамический шейпер на Linux