[codegencolix]

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

На нем поднят 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 трафик должен иметь больший приоритет нежели торренты

 

[SokolovS]

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

[codegencolix]

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

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

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

[codegencolix]

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

tc -s class show dev eth1

tc -s filter show dev eth1

 

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

[photon]

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

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

[SokolovS]

Скорости получаются заметно ниже, чем предусмотрено шейпером. Хотя полоса позволяет.

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

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

[codegencolix]

Скорости получаются заметно ниже, чем предусмотрено шейпером. Хотя полоса позволяет.

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

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

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

[photon]

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

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

Изменено 24 декабря, 2010 пользователем photon

[codegencolix]

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

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

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

[photon]

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

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

Изменено 28 декабря, 2010 пользователем photon

[codegencolix]

Ну длина очереди -- это параметр 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

[photon]

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

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

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

Изменено 28 декабря, 2010 пользователем photon

[NiTr0]

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

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

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

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

 

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

[codegencolix]

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

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

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

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

 

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

 

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

1. Интернет

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

 

Задача:

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

 

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

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

 

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

 

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

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

 

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

 

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

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

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

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

Изменено 3 января, 2011 пользователем codegencolix

[NiTr0]

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

ipset и/или хеш-таблицы в помощь. У меня на брасах шейперы на исходящий трафик на диапазон в 2к адресов (ессно, с хеш-таблицами) - и ничего, все прекрасно работает.

 

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

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

 

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

[codegencolix]

ipset и/или хеш-таблицы в помощь. У меня на брасах шейперы на исходящий трафик на диапазон в 2к адресов (ессно, с хеш-таблицами) - и ничего, все прекрасно работает.

Смотрел уже в сторону хеш-таблиц. Пока не совсем понял как реализовать. Надо покурить в эту сторону =)

 

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

Ээм. Действительно. Никакой цели нет =)

 

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

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

 

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

 

[NiTr0]

Смотрел уже в сторону хеш-таблиц. Пока не совсем понял как реализовать.

Ничего там особо сложного нет. Лучше всего понимается на простом примере, коих в инете предостаточно.

 

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

здесь выкладывал свой. Выглядит страшновато, грузится долго, но работает эффективно.

Изменено 4 января, 2011 пользователем NiTr0

[photon]

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

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

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

[codegencolix]

Остановлюсь пока на варианте с 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.

 

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

[codegencolix]

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

 

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

Изменено 6 января, 2011 пользователем codegencolix

[photon]

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

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

Изменено 6 января, 2011 пользователем photon

[codegencolix]

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

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

 

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

[NiTr0]

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

Угу, с падением производительности при работе с базой в итоге.

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

Изменено 6 января, 2011 пользователем NiTr0

[photon]

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

sc -d 2 -v 2 <command>

 

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

[codegencolix]

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

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

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

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