Jump to content
Калькуляторы

Шейпинг TC HTB Покритикуйте схему шейпинга вх/исх трафика

Добрый день. Есть софт-роутер с линуксом

На нем поднят PPPOE сервер.

Одним интерфейсом (eth0) он смотрит в локальную сеть, другим (eth1) в интернет. Полоса интернет 100 мегабит.

Задача шейпить трафик в сеть интернет. Между пользователями скорость ограничиваться не должна.

Сейчас все сделано след образом:

 

При загрузке системы выполняется след

 

tc qdisc add dev eth1 root handle 1: htb # СОздаем корневую дисциплину HTB для управления исходящим трафиком
tc class add dev eth1 parent 1: classid 1:1 htb rate 1048576kbit # Указываем макс. скорость на интерфейсе

 

При поднятии pppoe соединения выполняется след скрипт:

 

 
       $tc qdisc del dev $PPP_IFACE root
        # Трафик к клиенту (вход)
        $tc qdisc add dev $PPP_IFACE root handle 1: htb default 20
        $tc class add dev $PPP_IFACE parent 1: classid 1:1 htb rate ${allspeed}kbit # Общая скорость на ppp интерфейсе
        $tc class add dev $PPP_IFACE parent 1:1 classid 1:10 htb rate ${vspeed}kbit # Скорость между ppp соединениями
        $tc class add dev $PPP_IFACE parent 1:1 classid 1:20 htb rate ${speed}kbit # Скорость в сеть интернет

        $tc filter add dev $PPP_IFACE protocol ip parent 1:0 prio 1 u32 match ip dst 195.88.*.*/24 match ip src 195.88.*.0/24 flowid 1:10 # Тут мы устанавливаем фильтры на наших ip
        dev_out=eth1
        X=`echo $PPP_IFACE | cut -d'p' -f4`
        let "X = $X + 2"

        $tc class add dev $dev_out parent 1: classid 1:$X htb rate ${ishspeed}kbit ceil ${ishspeed}kbit prio 3 # Исходящая скорость
        $tc qdisc add dev $dev_out parent 1:$X handle $X: sfq perturb 10
        $tc filter add dev $dev_out protocol ip parent 1: prio $X u32 match ip src $PPP_REMOTE flowid 1:$X

 

ПОкритикуйте пожалуйста схему. Как ко всему этому можно прикрутить прриоритезацию. Например HTTP трафик должен иметь больший приоритет нежели торренты

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Схема вполне жизнеспособная, шейпится интерфейс юзера, тоже так делал, пока не потребовались тарифы с разным приоритетом трафика. Приоритезацию по типу трафика лучше делать не на терминирующем сервере, а не следующей после него железке, об этом уже писали в других топиках.

Спасибо за совет по приоритезации. Тоже об этом думал. А по поводу этой схемы... Скорости получаются заметно ниже, чем предусмотрено шейпером. Хотя полоса позволяет.

P.S. На сервере порядка 300-350 pppoe сессий

Share this post


Link to post
Share on other sites

Уж слишком много фильтров и классов получается при выводе след. команд:

tc -s class show dev eth1

tc -s filter show dev eth1

 

Приоритезацию, как и сказали, разделил на другой сервер. А как на этом грамотнее шейпить исход. трафик? Может в ifb интерфейс засунуть и там шейпить?

Share this post


Link to post
Share on other sites

Приоритезацию, как и сказали, разделил на другой сервер. А как на этом грамотнее шейпить исход. трафик? Может в ifb интерфейс засунуть и там шейпить?

Можно просто полисеры создавать на виртуальных интерфейсах. Так даже лучше, потому что не надо возиться с IFB.

Share this post


Link to post
Share on other sites
Скорости получаются заметно ниже, чем предусмотрено шейпером. Хотя полоса позволяет.

P.S. На сервере порядка 300-350 pppoe сессий

У вас htb+sfq, добавляйте +5% тогда будет по тарифу )

Share this post


Link to post
Share on other sites
Скорости получаются заметно ниже, чем предусмотрено шейпером. Хотя полоса позволяет.

P.S. На сервере порядка 300-350 pppoe сессий

У вас htb+sfq, добавляйте +5% тогда будет по тарифу )

=) Было бы все так просто. У http трафика стоит самый высокий приоритет,а спидтест при 12Мегабит в сек показывает только 4-5 =(

Share this post


Link to post
Share on other sites

=) Было бы все так просто. У http трафика стоит самый высокий приоритет,а спидтест при 12Мегабит в сек показывает только 4-5 =(

Для достижения номинальной скорости надо увеличивать размер очереди. Еще я прозреваю использование HTB для приоритизации типов трафика с ограничениями по скоростям. Это неправильно. Во-первых, для приоритизации надо использовать prio. Во-вторых, зачем вам какие-то HTB+SFQ при наличии PPPoE? На каждом виртуальном интерфейсе достаточно создать бесклассовую дисциплину TBF и полисер. Трафик фильтровать не надо, т.к. клиент привязан к конкретному интерфейсу. HTB с мудреными хэш-фильтрами нужны, когда на шейпере просто IP поверх Ethernet.

Edited by photon

Share this post


Link to post
Share on other sites
На каждом виртуальном интерфейсе достаточно создать бесклассовую дисциплину TBF и полисер. Трафик фильтровать не надо, т.к. клиент привязан к конкретному интерфейсу. HTB с мудреными хэш-фильтрами нужны, когда на шейпере просто IP поверх Ethernet.

Так и делали, но потом появилась необходимость скорости до определенных сетей. Пиринг - 100 мегабит, инет - по тарифу. К сожалению TBF classless =(

По увеличению очереди можно поподробнее? Каким именно образом?)

Share this post


Link to post
Share on other sites

По увеличению очереди можно поподробнее? Каким именно образом?)

Ну длина очереди -- это параметр limit для дисциплин bfifo или pfifo, которые рекомендуется использовать вместо SFQ. SFQ ест дополнительные ресурсы, это станет заметно, когда число пользователей перевалит за 2000. Другой причиной недобора полосы может быть лишний шейпинг с помощью HTB, который вы вероятно делаете на следующей машине, где трафик приоритизируется по типам. Там надо использовать дисциплину prio.

Edited by photon

Share this post


Link to post
Share on other sites
Ну длина очереди -- это параметр limit для дисциплин bfifo или pfifo, которые рекомендуется использовать вместо SFQ.
Попробую сегодня вечером.

 

Другой причиной недобора полосы может быть лишний шейпинг с помощью HTB, который вы вероятно делаете на следующей машине, где трафик приоритизируется по типам. Там надо использовать дисциплину prio.

Я использую prio там.

$tc qdisc add dev $dev2 root handle 1: htb default 115
    $tc class add dev $dev2 parent 1: classid 1:1 htb rate ${int}kbit
....
    $tc class add dev $dev2 parent 1:1 classid 1:10 htb rate ${speed}kbit
    $tc class add dev $dev2 parent 1:1 classid 1:13 htb rate ${peer}kbit prio 5

#    $tc class add dev $dev2 parent 1:10 classid 1:111 htb rate ${p2p}kbit ceil ${speed}kbit prio 7
    $tc class add dev $dev2 parent 1:10 classid 1:112 htb rate ${www}kbit ceil ${speed}kbit prio 3
    $tc class add dev $dev2 parent 1:10 classid 1:113 htb rate ${udp}kbit ceil ${speed}kbit prio 3
    $tc class add dev $dev2 parent 1:10 classid 1:115 htb rate ${other}kbit ceil ${speed}kbit prio 5

    $tc qdisc add dev $dev2 parent 1:13 handle 13: sfq perturb 10


    $tc qdisc add dev $dev2 parent 1:112 handle 112: sfq perturb 10
    $tc qdisc add dev $dev2 parent 1:113 handle 113: sfq perturb 10
    $tc qdisc add dev $dev2 parent 1:115 handle 115: sfq perturb 10

 

Ну а ниже u32 match

Share this post


Link to post
Share on other sites
Я использую prio там.

$tc qdisc add dev $dev2 root handle 1: htb default 115

Вы как раз на htb делаете (с параметром prio), как я и предполагал, и получаете двойной шейпинг. Я говорю о дисциплине prio. См. пример: http://lartc.org/howto/lartc.qdisc.filters.html
Edited by photon

Share this post


Link to post
Share on other sites

Несколько замечаний:

1) Зачем на pppX фильтровать пакеты по dst в фильтре локального траффика?

2) Добавить на каждый класс sfq/esfq qdisc

3) Переделать шейпер исходящего трафа с пользованием хешей если абонентов более 100-200.

 

А вообще - в такой задаче напрашивается шейпинг на бордюре...

Share this post


Link to post
Share on other sites
Несколько замечаний:

1) Зачем на pppX фильтровать пакеты по dst в фильтре локального траффика?

2) Добавить на каждый класс sfq/esfq qdisc

3) Переделать шейпер исходящего трафа с пользованием хешей если абонентов более 100-200.

 

А вообще - в такой задаче напрашивается шейпинг на бордюре...

 

Вобщем ситуация следующая. Есть PPPOE сервер, выше него стоят два шлюза.

1. Интернет

2. Пиринговый шлюз

 

Задача:

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

 

Казалось бы - самое оптимальное это повесить шейпер на Интернет шлюз, НО получается слишком много правил. Процессор не справляется.

Трафик до пирингового шлюза уходит через тот же интерфейс, что и до интернета.

 

Сейчас все организовано таким вот способом, поторый я описал в верхних постах.

 

Сейчас вот думаю как бы пустить торрент трафик мимо шейпера?

Если использовать вариант с маркировкой пакетов с TOS=8 на пиринге и пускать его мимо шейпера на pppX ?

 

P.S. ЧТо такое ROW трафик?

 

ПОдсказали тут вариант:

на ppp только вход для клиентов и тот не весь

есть row трафик, который пускаем мимо шейпера, а все остальное через шейпер.

Так и непонял что за ROW трафик =)

Edited by codegencolix

Share this post


Link to post
Share on other sites
Казалось бы - самое оптимальное это повесить шейпер на Интернет шлюз, НО получается слишком много правил. Процессор не справляется.
ipset и/или хеш-таблицы в помощь. У меня на брасах шейперы на исходящий трафик на диапазон в 2к адресов (ессно, с хеш-таблицами) - и ничего, все прекрасно работает.

 

Если использовать вариант с маркировкой пакетов с TOS=8 на пиринге и пускать его мимо шейпера на pppX ?
Можно. Однако позаботиться, чтобы всем другим пакетам TOS сбрасывался, иначе будет кому-то особо хитрому дешевый полный анлим :)

 

Кстати вы так и не ответили, с какой целью матчите пакеты по dst, которые уходят во вполне конкретный туннель вполне конкретному получателю???

Share this post


Link to post
Share on other sites
ipset и/или хеш-таблицы в помощь. У меня на брасах шейперы на исходящий трафик на диапазон в 2к адресов (ессно, с хеш-таблицами) - и ничего, все прекрасно работает.
Смотрел уже в сторону хеш-таблиц. Пока не совсем понял как реализовать. Надо покурить в эту сторону =)

 

Кстати вы так и не ответили, с какой целью матчите пакеты по dst, которые уходят во вполне конкретный туннель вполне конкретному получателю???
Ээм. Действительно. Никакой цели нет =)

 

Остановлюсь пока на варианте с TOS, как осилю хеш-таблицы - так сразу на них.

У вас есть примерчик шейпера на таблицах? =)

 

P.S. С Наступившим всех Новым Годом!

 

Share this post


Link to post
Share on other sites
Смотрел уже в сторону хеш-таблиц. Пока не совсем понял как реализовать.
Ничего там особо сложного нет. Лучше всего понимается на простом примере, коих в инете предостаточно.

 

У вас есть примерчик шейпера на таблицах? =)
здесь выкладывал свой. Выглядит страшновато, грузится долго, но работает эффективно.
Edited by NiTr0

Share this post


Link to post
Share on other sites
Остановлюсь пока на варианте с TOS, как осилю хеш-таблицы - так сразу на них.

У вас есть примерчик шейпера на таблицах? =)

Есть генератор для правил шейпинга с хэш-фильтрами: http://forum.nag.ru/forum/index.php?showtopic=48301

Share this post


Link to post
Share on other sites
Остановлюсь пока на варианте с TOS, как осилю хеш-таблицы - так сразу на них.

У вас есть примерчик шейпера на таблицах? =)

Есть генератор для правил шейпинга с хэш-фильтрами: http://forum.nag.ru/forum/index.php?showtopic=48301

Очень интересный генератор.

Правда почему то появляется ряд ошибок.

Использую mysql.

В конфиге прописал

network = 195.88.132.0/24

filter_network = 195.88.132.0/24

 

Теперь пытаюсь

 # sc dbadd 195.88.132.130 2048Kbit

Все проходит успешно

Далее

# sc dbadd 195.88.132.129 2048Kbit
DBD::mysql::st execute failed: Duplicate entry '2147483647' for key 'PRIMARY' at /usr/local/sbin/sc line 2067.
DBD::mysql::st execute failed: Duplicate entry '2147483647' for key 'PRIMARY' at /usr/local/sbin/sc line 2067.

 

В чем может быть проблемка?

Share this post


Link to post
Share on other sites

Проблема решилась изменением в таблице rates типа поля ip с INT(11) на VARCHAR(11)

 

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

Edited by codegencolix

Share this post


Link to post
Share on other sites

Проблема решилась изменением в таблице rates типа поля ip с INT(11) на VARCHAR(11)

Странно. С хранилищем SQLite таких проблем не было. Надо будет поэкспериментировать с другими базами. Следует отметить, что это решение для IPoE, а не для PPPoE. Нужно будет что-то менять в коде, чтобы часть правил создавалась на виртуальных интерфейсах.

Edited by photon

Share this post


Link to post
Share on other sites
Проблема решилась изменением в таблице rates типа поля ip с INT(11) на VARCHAR(11)
Странно. С хранилищем SQLite таких проблем не было. Надо будет поэкспериментировать с другими базами. Следует отметить, что это решение для IPoE, а не для PPPoE. Нужно будет что-то менять в коде, чтобы часть правил создавалась на виртуальных интерфейсах.

 

Этот шейпер я буду использовать на вышестоящем роутере. А как посмотреть какие правила будут создаваться без их применения?

Share this post


Link to post
Share on other sites
Проблема решилась изменением в таблице rates типа поля ip с INT(11) на VARCHAR(11)
Угу, с падением производительности при работе с базой в итоге.

А подумать, что INT не вмещает адреса больше 127.255.255.255 (7FFFFFFF), и сменить тип на UNSIGNED INT?

Edited by NiTr0

Share this post


Link to post
Share on other sites
Этот шейпер я буду использовать на вышестоящем роутере. А как посмотреть какие правила будут создаваться без их применения?
sc -d 2 -v 2 <command>

 

По поводу других опций -- man sc.

Share this post


Link to post
Share on other sites

Всем огромное спасибо. Установил sc на шлюз, все настроил. Проц не наргужен совсем. Скорости соответствуют ТП.

Нерешенной осталась только одна проблема. speedtest.net и другие онлайн замерители упорно показывают скорость максимум в 4 мегабита (при 12 положенных).

Хотя скорость загрузки с трекеров выдает все положенное.

Спасет ли policing per interface на PPPoE серверах в данном случае?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this