Пользователь
0,0
рейтинг
21 мая 2009 в 14:16

Администрирование → Причесываем трафик — динамический шейпер на Linux

причесываем трафик
Предположим у вас есть домашняя сеть (или не домашняя, а сеть небольшого офиса) с выходом в интернет через не очень скоростной канал. А пользователей — много, и каждый хочет что-то скачивать, да с максимальной скоростью. Вот тут перед нами встатет задача, как максимально эффективно распределить наш интернет-канал между пользователями так, чтобы они не мешали друг другу. В этой статье я опишу, как можно решить такую задачу с помощью Linux-сервера.

Сформулируем, что же мы хотим получить в результате:
1. Чтобы канал поровну делился между пользователями.
2. Чтобы канал зря не простаивал.
3. Чтобы онлайн-игры, ssh и telnet не «лагали» даже при полной загрузке канала, например торрентами.


Если интернетом будут одновременно пользоваться 10 пользователей — каждый получит в свое распоряжение 1/10 часть канала, если в данный момент активен только один пользователь — он будет использовать весь канал сам.
Добиться этого можно используя планировщик пакетов HTB, который входит в ядро linux начиная с версии 2.4.20.
image
Можно конфигурировать шейпер с помощью команды tc, но для более удобной и наглядной настройки я рекомендую скачать скрипт htb.init. Они использует для конфигурации htb набор конфигурационных файлов, именуемых так, что при сортировке по алфавиту их имена позволяют визуально представить себе дерево классов шейпера и удобно его редактировать.
Предположим, что у нас на сервере есть интерфейс eth0, через который мы подключены к интернет, и eth1, который «смотрит» в локальную сеть.

Управлять можно только исходящим из интерфейса трафиком, поэтому для eth0 будут правила для upload трафика пользователей, а для — eth1 — download трафика.

По умолчанию конфигурационные файлы htb.init находятся в /etc/htb/. Для начала напишем правила шейпинга для upload трафика, они у нас будут простые.
Создаем файл с именем eth0 (интерейс «смотрящий» в интернет), в него напищем следующие строки:
DEFAULT=20
R2Q=1

Параметр DEFAULT задает номер класса, к которому будет относиться трафик «по умолчанию» — обычно это класс с минимальным приоритетом. Параметр R2Q влияет на работу алгоритма разделения канала и зависит от ширины канала. Я подбирал его значение эмпирическим путем, для моего исходящего канала в 2 Mbit.

Далее, создадим файл eth0-2.full2MBit, для класса включающего в себя весь доступный интернет-канал. Имя файла состоит из имени интерфейса и id класса, после точки идет смысловое имя класса, используется как комментарий и системой игнорируется.
RATE=2Mbit
CEIL=2Mbit

RATE — это наша гарантированная полоса, CEIL — максимальная полоса. Так как у меня канал с гарантированной максимальной полосой в 2 Mbit, то эти параметры у меня равны.

Теперь мы создадим по одному файлу для каждого класса трафика, который у нас будет. Я у себя создал отдельные классы для ssh трафика, а так же трафика игр World Of Warcraft и Counter Strike, хотя вы можете сделать для всего высокоприоритетного трафика один класс.

Пример для ssh — создаем файл eth0-2:10.ssh. В имени файла через двоеточие указан id родительского класса 2 и id текущего класса — 10. Идентификаторы для класса вы можете выбирать произвольно.
# class for outgoing ssh
RATE=128Kbit
CEIL=2Mbit
RULE=*:22
PRIO=1
BURST=100Kb

В параметре RATE указана гарантированная полоса для этого класса, в CEIL — максимальная. Мы выделяем для ssh 128 KBit (как минимум) и разрешаем ему загрузить весь канал (я закачивать файлы по sftp). PRIO задает приоритет класса трафика (1- максимальный, чем больше число — тем меньш приоритет). BURST задает максимальный объем трафика, который будет передан на максимальной скорости перед тем, как перейти к передаче данных из дургих классов. Установив этот параметр в достаточно высокое значение мы добиваемся того, что трафик ssh будет передан с минимальными задержками.
RULE задает правило, по которому будет отбираться трафик в этот класс.
Формат — RULE=[[saddr[/prefix]][:port[/mask]],][daddr[/prefix]][:port[/mask]]
Обратите внимание на запятую! RULE=*:22 обозначает трафик, у которого порт назначения 22, а RULE=*:22, обозначает трафик, у которого исходящий порт — 22.

Создадим так же классы для других видов трафика, и класс для трафика «по умолчанию» с id 20 (мы указали вначале что именно в класс номер 20 надо направлять трафик «по умолчанию»). В нем укажем используемую дисциплину разделения канала LEAF=sfq, для того чтобы upload поровну делился между TCP сессиями разных пользователей.

Для eth1 правила будут почти такие же, только с учетом что общая ширина канала — 100 Mbit, мы ведь хотим чтобы можно было обращаться к локальным ресурсам сервера на полной скорости, для интернет-трафика выделен отдельный класс на 2 MBit, у которого как потомки добавлены классы отдельных пользователей, разделение по классам я делал по IP адресам. Для каждого пользователя можно указать максимальную и гарантированную скорость, а так же приоритет.

После правки конфигурации перезапускаем htb.init:
/etc/init.d/htb.init restart
И правила шейпинга трафика сразу же вступают в силу.

В процессе состевления правил обычно возникает необходимость как-то визуализировать трафик, в целях отладки и мониторинга, поэтому решил написать плагин для системы мониторинга серверов munin, который бы визуализировал распределение по классам HTB трафика. Выводить решил загрузку только классов-листьев дерева, так как именно они обычно несут смысловую нагрузку.
Скачать плагин вы можете из официального репозитория плагинов munin, называется он qos_, просто скопируйте его в папку плагинов munin /usr/share/munin/plugins/ и в папке используемых плагинов /etc/munin/plugins сделайте на него символическую ссылку вида qos_eth1, где eth1 — имя интерфейса, на котором нужно мониторить загрузку.
В файле конфигурации плагинов можно добавить следущее:
[qos_eth1]
env.ignore_queue1_10 yes
env.label_name1_31 Viperet
env.label_name1_32 Cornet

Параметр env.ignore_queue позволяет не отображать на графике состояние класса с указанным id, а параметр env.label_name — задать человекопонятную метку для класса на графике.

В итоге должно получиться что то такое:
image

Хочу заметить, что у меня несколько нетипичная ситуация, два интернет канала на 2 и 1 Mbit, и для каждого пользователя ограничение в 2 Mbit скорости загрузки, поэтому на графике видно, что если активен один пользователь — его скорость урезается на 2 Mbit, а если несколько — суммарная скорость может достигать и трех. На таком достаточно «тесном» канале работают более 20 человек, и вполне комфортно себя чувствуют, не мешая друг другу.
Эта картинка с реально действующего сервера, и она обновляется каждые 5 минут и отображает актуальную картину загрузки канала.

UPD: выложил пример конфига htb.init
viperet @viperet
карма
147,5
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (98)

  • 0
    Офигенно!
  • +2
    Можете выложить полный конфиг htb?
    • +1
      пожалуйста, выложил
      • 0
        спасибо, очень актуально!
      • 0
        Не нашел пакет HTB в своей Ubuntu 9.04 Server. Т.е., там нет /etc/htb/*.
        В репозиториях тоже нет.
        Значит собирать надо самому?
        • 0
          HTB — это дисциплина шейпера, который встроен в ядро и управляется командой tc
          то что мы тут назвали «конфиг htb» — это куча файликов, которые парсит скрипт htb.init и превращает их в команды tc. htb.init есть в пакетах или нет — не помню, фактически это bash-скрипт, его можно скачать с оффсайта sourceforge.net/projects/htbinit/
          • 0
            Я уже начал догадываться. Спасибо за быстрый ответ. :)
  • –2
    Спасибо, добавил с мемориз.
    • –1
      в*
  • +2
    Большое спасибо. Я как раз на днях задумывался об этом.
    Вообще странное творится: только что-то понадобилось — на Хабре или других ресурсах выкладывают про это статью — так держать! :)
    • 0
      Ой, кстати забыл спросить — а как эта система будет работать в сети из 30-40 человек?
      Или нужно что-то другое подыскивать?
      • +1
        Отлично будет работать, только наверное надо будет как то автоматизировать генерацию конфигов классов пользователей, чтоб вручную потом не править 40 файликов, когда надо измениь скорость. Или же отказаться от htb.init и напрямую управлять шепером с помощью утилиты tc
        • 0
          Спасибо :) Меня как раз смущала необходимость ручной правки конифгов
      • +2
        Главная проблема — это как будет фильтроваться трафик и попадать в тот или иной класс. для 30-40 человек и 10МБит — это не критично, а вот если у вас 10к пользователей, то могут возникнуть проблемы. Если кому-то интересно — могу расписать чуть подробнее.
        • 0
          Да, интерессно :)
        • 0
          Конечно интересует! Пока моя сеть настолько не выросла, но возможно в будущем ;-)

          А в принципе — пакеты фильтруются с помощью маркировки файрволом,
          в /usr/src/linux-2.5.73/include/linux/netfilter_ipv4/ipt_mark.h марки объявлены как unsigned longs,
          тоесть может быть 2^32 марок пакетов, тоесть 4 294 967 296 классов трафика или пользователей =)
          • +3
            существует две популярные схемы создания соответствия ip->htb class: «ipmark» и «ipclassify».
            Первая реализуется маркировкой в iptables, вторая использование tc filter u32(с хэшами).

            У первой схемы недостаток в разрастании таблиц iptables. При существовании 10к пользователей мы имеем 10к правил iptables(через все проходит каждый пакет) и 10k фильтров tc. При большом потоке пакетов ksoftirqd уходит в вечный луп, загружая одно ядро сервера.

            У второй схемы недостаток в абсолютной адском синтаксисе настройки и жуткой глючности при изменении(удалении) фильтров. При существовании статических классов и фильтров не плохое решение, если использовать хэш таблицы.

            Не так давно в ядро добавили новую схему tc filter flow(разработанная изначально для sfq кудиска). Она лишена всех описанных недостатков, только совершенно не документирована и может быть использована только адептами, читающими исходный код. =)

            зы марков 2^32, а вот классов увы может быть только 0xffff

            зыы на днях соберусь — распишу подробно все три схемы с примерами.
            • 0
              Если напишите статью — пожалуйста, оставьте тут ссылку на нее.
              А по поводу разрастания таблиц iptables — товарищ когда то писал самодельный патч для ядра, для того чтоб фильтровать трафик по большому черному списку IP. Чем нравится linux — если тебе перестает хватать стандартных вещей — ты можешь написать что то специализированное и очень быстрое, но такая необходимость возникает редко, все обычно уже написано =)
              • 0
                я думаю вы имеете ввиду ipset. Да, это известный и удобный патч, но в данном случае использовать его не получится, тк нам нужно уникальное правило ip->ipmark.
                • 0
                  Нет, тот патч в свободное плавние не вышел.
                  Можно сделать гораздо проще, пропачить ядро так, чтоб класс назначался так:
                  допустим исходящий или входящий адрес 192.168.0.x тогда назначить класс x
                  тогда просто для других целей, не идентификации пользователей, надо использовать классы > 255
                  • 0
                    tc filter flow как раз так и делает.
                    www.mail-archive.com/netdev@vger.kernel.org/msg60638.html
                    • 0
                      Офигеть! Вот и выходит как я говорил — все что надо уже написано )))
  • 0
    Познавательно, большое спасибо
  • 0
    А как сделать что-то похожее на домашнем виндовс? Только чтобы не разграничивать не по пользователям, а по приложениям.
    • +1
      купить NetLimiter
      • 0
        Спс. Посмотрю на триал для начала!
    • 0
      Купить cfosspeed.
  • 0
    насколько хорошо работает динамический шейпинг входящего трафика для торрентов? я когда пробовал, у меня торренты все время сжирали канал по-максимуму. В итоге закачки через wget или aria2c еще как-то отбирали канал у торрентов, но серфинга фактически не было.
    • +1
      Я не ставил своей целью сделать так, чтоб каждый пользователь мог одновременно и серфить и качать торренты на полную, просто разделил канал, чтоб условно говоря торренты первого не мешали серфинуг второго. И это прекрасно работает, значит ничего не мешает сделать и чтоб у одного пользователя торренты не мешали серфингу. Чтоб это сделать — надо всего лишь добавить каждому пользователю по два класса — http, а так же аська, jabber, игры — в один класс, которому назначен высокий приоритет и гарантированная полоса, и все остальное — во второй класс, с минимальным приоритетом.
      К сожалению отфильтровать трафик торрентов не так просто, поэтому и прийдется действовать методом исключения. Хотя я уже видел патчи для ядра, позволяющие фильтровать по протоколу третьего уровня.
      • 0
        торрент трафик грубо это все по портам 10000+ (может даже 1000+). Кроме редчайших исключений, потому фильтровал я так. Делал
        • 0
          World Of Warcraft использует порты 3724, 6112, and 6881-6999 — ваш фильтр даст ему минимальный приоритет…
        • 0
          Делал 2 класса,
      • 0
        Немного ошибся, фильтры 7 уровня (имеется в виду уровень модели OSI) вот их страничка l7-filter.sourceforge.net/
      • 0
        делал так и торренты съедали все из ceil. на серфинг не хватало.
        • 0
          можешь выслать конфиги, попробую подсказать в чем проблема
          • 0
            попробую найти, но в свое время я забил и остановился на статическом шейпинге и простом ограничении скорости в торрент-клиенте.
    • 0
      В таком случае можно разделить канал на много больше полос, отдельно для http, jaber, ssh и т.д. А весь остальной трафик сделать низкоприоритетным
      • 0
        а зачем? в моем случае низкоприоритетный трафик от торрентов забивал практически весь канал и серфинг не работал.
        • 0
          ммм… Странно. Я видимо чего-то недопонимаю в условии задачи.
          2 варианта
          1) Вы — провайдер и режете канал в соответствии с аккаунтами пользователей. И вам всеравно как тот или иной юзер использует выделенную ему полосу.
          2) Офис. Не много машин. Около N мегабит канал. Все равноправны. Мы сразу разделим его на полосы с различными приоритетами. А потом все это добро распределим между пользователями. Во 2м случае влияние низкоприотетного трафика не должно сказываться на высокоприоритетном (в идеале конечно). Если у вас к примеру X машин. То вы указываете минимально гарантированную скорость равную ширине канала без поправки в 2-3% от первого параметра и поделенную на кол-во пользователей (X). Максимальное же пропускную способность можно установить как (0,9*N)/X.
          Указанные параметры притянуты за уши, дабы проиллюстрировать решение. Не более того
          • 0
            >Вы — провайдер и режете канал в соответствии с аккаунтами пользователей. И вам всеравно как тот или иной юзер использует выделенную ему полосу.

            Нууу… Это так, если Вы честный, богатый и процветающий провайдер, канал Вам обходится дешево, клиенты платят много и нет конкурентов. Но наверняка в такой вселенной давно уже победил бы коммунизм.

            Реально же многие (если не все) мелкие провайдеры продают больше полосы, чем имеют. Вот и приходиться шейпить все кроме веба, игр и VoIP.

            • 0
              У меня как раз два провайдера, один честный и багатый, продает только гарантированные каналы, но дорого, а второй — продает гораздо больше чем имеет, но дешево =)
  • 0
    настраивал раньше такое же только средствами tc, если кому интересно пишите в личку. мож выложу
    • 0
      Описаное тут — в принципе тот же tc, только через обертку из htb.init. Как по мне это несколько проще для понимания.
      • 0
        оно то так. проще не всегда лучше
  • –6
    Тян.
  • 0
    симпатишный траффик… ;)
  • 0
    viperet почему именно пингвин и htb? Какие преимущества дает это по сравнению например с бсд? Сижу выбираю для себя решение, хотелось бы услышать ваше мнение.
    • +1
      Я уже описывал в комментариях к другой статье, про объединение каналов, но напишу еще раз :-)
      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
      • 0
        Ок, спасибо.

        ЗЫ что вы, я в мыслях не держал, реально сижу и глаза разбегаются, столько решений. Лет пять назад как то все попроще было.
      • 0
        Плюс не нужны devel пакеты для компиляции.
  • 0
    Спасибо, попробу настроить на роутере!
    • 0
      Удалось? Случайно не ASUS WL-500? ;)
  • 0
    Подскажите по каким критериям можно выделить трафик skype?
    • 0
      выделить скайп по портам так просто не получится, помочь сделать это вам могут фильтры L7, читайте l7-filter.sourceforge.net/protocols, там указано что уже написаны фильтры для выделения Skype
      • 0
        не подскажите, много ресурсов кушает?
        • 0
          Почитайте, там на сайте написано. Правило определения skype-skype быстро работает, а вот skypeout — довольно медленно
  • +1
    Вот так надо Линукс подавать, загорелой и в халате.
  • 0
    А что делать если скорость соединения зависит от времени? У меня скорость в интернет днем 512кбит, а ночью 1мбит(«сильной» ночью и того больше), и не охота чтобы ночью полоса простаивала… можно ли динамически менять значения скорости? И как это сделать?
    • 0
      Та же примерно проблема… По тарифу скорость одна, и довольно большая, но на деле сильно зависит от загрузки внешнего канала и сильно прыгает…
    • +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. вызывать с каким то параметром по крону, читайте маны ;-)
      • 0
        Мне когда надо было — я маркировал трафик через iptables с -m time, ну а остальное уже по накатаной.
  • –1
    Друзья, вроде бы по теме, но немного офтопик. У меня тут VServer, доступ через рут, апач2, установлен Plesk, несколько vhost'ов, висит всё это дело на debian (etch).
    Так вот для одного vhost'а нужно ограничить трафик. Ну что бы с ip качалось только в несколько кбпс. Но только на этот vhost.
    Там специальный файл для этого уже выделен, vhost.conf, туда можно писать всё то, что обычно в конфиге апача светится.

    Пробовал установить (apt-get) libapache2-mod-bw, но после вроде бы успешной инсталяции его не видно ни в каталогах апача (mods) и нельзя установить волшебной командой «a2enmod bw».

    Может это вообще не тот метод и есть что-то поинтереснее?
  • +1
    Тут есть одна проблемка…

    Вот у вас канал 2 Мбит. Причём и на вход и на выход. Но контролировать вы можете только исходящий поток, но никак не входящий. Входящий шейпить бесполезно, поскольку провайдер зарежет трафик по-тупому ещё у себя. Торренты идут на UDP и контроль потока там достаточно агрессивный, даже в случае потерь пакеты будут долбится.

    То же самое с телефонией (SKYPE, SIP) и много с чем ещё. Даже простые закачки (на базе TCP) одного из пользователей могут занять входящий канал по-полной, наплевав на остальных. Хотя TCP это сделать сложнее, поскольку в случае потерь идёт существенный срез по скорости.
    • 0
      Машина на той стороне не будет посылать ещё, если не будет подтверждений от нашей машины — на этом можно играть.
      • +1
        можно, но это верно только для TCP, где есть congestion control. У битторента через удп(и скайпа), есть похожий механизм, но он более «жадный»(агресивный, как зметил shandor). При большом количестве коннектов у торрент клиента входящий поток пакетов может существенно превышать выделенный вам лимит.
        • 0
          А битторрент через удп вообще есть? У меня все клиенты что я знаю умеют только TCP.

          Насчёт скайпа — он поддаётся L7 анализу и тем более у него фиксированная ширина полосы, он около 8 килобайт в секунду ест и ему как раз надо наименьшую задержку.
          • 0
            mutorrent — самый популярный клиент умеет UDP(правда он единственный). но даже в работе в режиме tcp при большом кол-ве коннектов, личеры будут вам слать больше, чем разрешает вам провайдер. Поэтому лучше ограничивать скоростью не двумя мегабитами(для приведенного примера), а меньше.
        • 0
          кстати даже у TCP может быть очень агрессивный контроль потока.
    • 0
      Теоретически входящий поток могут регулировать шейперы на стороне клиента — например, известнейший cFosSpeed — www.cfos.de/speed/cfosspeed_e.htm.

      К сожалению, пока он не умеет взаимодействовать с другими компьютерами по сети, но вроде разработчики планировали внедрить такую функциональность.
      • 0
        > взаимодействовать с другими компьютерами по сети
        в нашем случае требуется взаимодействие роутера (домашнего сервера) и сервера провайдера. Ни один провайдер на такое не пойдёт.
        • 0
          Это понятно. Ну хотя бы управлять каналом на участке от компа до домашнего роутера — к примеру…
          • 0
            а смысл управлять этим каналом? он как правило 100Мбит и проблем особых нет.
            • 0
              Ну лучше как-то управлять, чем никак не управлять — особенно если в сети много компьютеров, а узким местом является интерфейс домашнего роутера. Было бы неплохо, чтобы на него и от него важные пакеты шли с большим приоритетом.
              • 0
                Вдумайтесь в то что вы говорите.
                Управлять = резать, дропать.
                По дорогущему каналу пришёл пакет, а вы его собираетесь убрать только потому, что пользователь «превысил» лимит? Совсем неразумная политика.
                • 0
                  Да почему же дропать? Пропустить с меньшим приоритетом, если в очереди есть пакеты большего приоритета (HTTP, RTP и т.д.)
                  • 0
                    До клиента 100 Мбит как правило — какие там могут быть очереди?
                    • 0
                      Ну почти убедили! :)

                      Так что, cFosSpeed и прочие шейперы фактически бесполезны, что-ли?
                      • 0
                        В рамках задачи «честно поделить канал» — бесполезны.
  • 0
    Сейчас использую pf+priq. канал 2мегабита. 5 юзеров.
    Когда rtorrent-у было позволено создавать 100+ одновременных соединений — приоритезация нифига не работала (работала, но я этого не чувствовал). Тупило все и у всех. Ограничил 32 соединениями — и о чудо — все летает.
    Однажды обнаружил, что «чтото тормозит все». 2000 соединеий от одного чела на 25 порт :)
    Нет больше исходящих соединений на 25 порт :)

    Может ктото смог сделать деление трафика, если есть 2 vpn соединения с провайдером?
    ng_one2many курить? и что с MPD делать?
    • 0
      Вы случаем не через ADSL работаете? Ну и еще некоторые провайдеры для домашних тарифов ограничивают число одновременных соединений.

      > Может ктото смог сделать деление трафика, если есть 2 vpn соединения с провайдером?
      Вам надо объеденить два интернет-канала? Тогда вам сюда habrahabr.ru/blogs/linux/54748/ (на линуксе)
  • 0
    Еще подумал, хорошим противодествием должно быть указание скоростей открытия соединений в единицу времени. А то получается лавинообразное образование огромного кол-ва соединение, даже если данных нужно реально мало.
  • 0
    Уважаемый автор, не могли бы вы создать подробную инструкцию по настройке динамического шейпинга с целью разделения приоритетов трафика в пределах одной машины? А то с переходом на linux найти аналог cFosSpeed так и не удалось, а по этой инструкции настроить уровня знаний не хватает.

    Желательно бы готовое решение с уже описанными в правилах программами для торрентокачалки, аськи, браузеров. Я и многие страждущие был бы премного благодарен.
  • 0
    А как причесать voip трафик?
    • 0
      Нужно каким то образом отфильтровать этот трафик, например файрволом и пометить (MARK)
      а потом в конфигурации класса htb.init указать вместо RULE= такую штуку
      MARK=это значит что в данный класс будут попадать пакеты с данной отметкой
      • 0
        спасибо
  • 0
    а что у вас делает файлик eth1-2:10.local?
    # root class containing total bandwidth
    RATE=100Mbit
    RULE=192.168.0.75,
    RULE=194.9.14.86,
    • 0
      Интерфейс eth1 — смотрит у меня в локальную сеть. Соответственно на нем шейпим исходящий трафик пользователей, и этот класс, в который попадает трафик от пользователей до сервера (тут указаны его внутренний и внейшний адреса), пришлось создать, чтоб не ограничивать скорость аплоада файлов на сервер.
      То есть если бы небыло этого класса, то скорость скажем заливки фильма на сервер шейпилась бы на уровне моего исходящего интернет-канала.
      Надеюсь объяснил понятно )))
      • 0
        да вполне, спасибо, у меня та же схема — 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
        • 0
          да кстати при htb compile пишет
          find: warning: you have specified the -maxdepth option after a non-option argument (, but options are not positional (-maxdepth affects tests specified before it as well as those specified after it).  Please specify options before other arguments.<?source>
          Это что
          • 0
            Это почти у всех так пишет ) у меня тоже, но все работает. на оффсайте htc.init вроде как есть патчи исправляющий это предупреждение.
  • 0
    с Вашими конфигами (разница в ip-адресах) в логах пишет:
    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
    • 0
      Так а в чем проблема шейпить исходящий канал? У меня там в конфиге правила для интерфейса eth1 — они и шейпят исходяший трафик пользователей.
      • 0
        ну в Ваших конфигах просто выделяется полоса в 2 мегабита, насколько я понял, а маркировка позволяет каждому юзеру давать разную полосу
        • 0
          То мне было просто лениво каждому еще и для аплоада правила создавать! Обычно проблемы с даунлоадом, а аплоад не загружен.

          Посмотрел ваши конфиги — маркировать пакеты отдельно через iptables совсем не обязательно, параметр RULE в конфигах htc.init делает то же самое.

          • 0
            Посмотрел ваши конфиги — маркировать пакеты отдельно через iptables совсем не обязательно, параметр RULE в конфигах htc.init делает то же самое.

            так не получается
  • 0
    а как сделать так чтоб канал делился равномерно по ip, а не по потокам? Выходит что один Download Master c 8 потоками забирает на себя весь rate класса.
    • 0
      создавайте под каждый IP свой класс HTB, как в примере.
      • 0
        неправильно выразился, весь ceil класса,
        то есть, канал раскидан всем ip с одинаковым CEIL класса, но если с одного ip включается многопоточная закачка, то шейпер делит поровну скорость между потоками, а хотелось бы чтоб делил скорость поровну между адресами.
        P.S.Слышал про flow classifier но как и с чем его едят, так толком и не вразумляю.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.