Перейти к содержимому
Калькуляторы

lessless

Пользователи
 Просмотреть профиль  Активность

  • Публикации

    10

  • Зарегистрирован

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем lessless

  2. Опубликовано · Жалоба на ответ

    вот стандартно

    burst 2kbit

    quantum 1500

     

    тарифы до 50мб, режет тютелька в тютельку

    Это у вас фактически полисиер вышел. Причем - без урезания траффика пропорционально скорости для rate<ceil при оверкоммите (если все дочерние классы захотели траффика больше, чем рейт родительского) - резаться будет всем поровну Т.е. при наличии к примеру 5 качков по 50 мбит и 3 качков по 30 мбит и внешнем канале в 200 мбит - скорость между качками распределится поровну и будет составлять по 25 мбит. Благодаря фиксированному quantum' у.

     

    По поводу r2q - для скоростей от 4 мбит он должен быть равен 300 - при этом минимально возможный quantum получается где-то на 3.6 мбит, максимальный - на 150 мбит.

    звучит безвыходно :(

  4. Опубликовано · Изменено пользователем lessless · Жалоба на ответ

     

    т.е. iptables -t mangle -A POSTROUTING -d 172.15.1.2 -j CLASSIFY --set-class

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

     

     

    Ага! Меня задним умом эта мысль накрыла.

     

    Ребята, все оказалось действительно просто с iptables classify

     

    iptables -t mangle -A POSTROUTING -m set --match-set uaix src -j CLASSIFY --set-class 1:1

    tc class r dev ppp0 parent 1: classid 1:1 htb rate 512kbit burst 5k

    и трафик с юа-икса идет потоком в 60Кбайт

     

    Всем спасибо за предложения, полезные советы и варианты - особенно NiTr0 за доходчивые объяснения, Lynx10 - за работающее предложение и Deathman за интересное предложение на будущее ;)

    Когда перейдем на L3 свичи буду так же резать на исходящем в сторону клиента интерфейсе, точно так же без ifb - как заворачивать на него трафик так и не разобрался.

  5. Опубликовано · Жалоба на ответ

    BRAIN - извращенная фантазия на основе CLASSIFY классифифицирущий по интерфейсу от которого пришел пакет, и занимающийся выставлением бит, отвечающих за приоритет. Как бы ни фильтров ни хешей, да ограничение в 2^12 на колличество ppp интерфейсов

    классифицируется так 12 бит на номер ppp интерфейса (pppX) 3 бита на приоритет 1 бит указывает на безлимитность :)

    у впна 2 интерфейса internet и local :) на internet вешаются исходячие классы для шейпинга

    Вобщем если оно интересно пишите

    Давай попробуем, оно по-всякому интересно.

     

    NiTr0,

    эх, Вы разрушаете все мои идеи - я только подумал, что соответствие есть и цепочка для VPN выглядит так

     

    eth0|||||||\=========================\ppp0

    prerouting|/===========FORWARD=======/POSTROUTING

     

    1)пакет пришел на eth0

    2)принято решение о маршрутизации на клиентский ip через ppp0

    3)пакет доставлен на интерфейс ppp0 для дальнейшей отправки и это и есть POSTROUTING :(

    т.е. iptables -t mangle -A POSTROUTING -d 172.15.1.2 -j CLASSIFY --set-class при

    ppp0---------Клиентский-ПК

    172.15.1.1---172.151.1.2

    отправит пакет в класс 1:2 существующий на ppp0

     

    эх, а такой идеальный вариант выходил.

  6. Опубликовано · Изменено пользователем lessless · Жалоба на ответ

    Входящий (т.е. от сервера абоненту) прекрасно шейпится на самом ppp. А до того - маркируете его как угодно по любым критериям.

    Фильтры - тоже прекрасно удаляются, только по id который нужно указывать при создании.

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

    Спасибо, это то, что нужно!

    Прошу помочь еще с пониманием такого: при шейпинге на pppX я не могу использовать классификацию iptables -t mangle -A POSTROUTING ..., т.к. это таблица FORWARD, правильно ?

    Вместо этого могу использовать фильтры tc выделяя нужный мне трафик в отдельный класс и этим решаю свою задачу? Это ведь пара-тройка тысяч правил на каждый интерфейс или есть возможность устроить их в одном месте а-ля в ipset?

  7. Опубликовано · Изменено пользователем lessless · Жалоба на ответ

    пришел к схеме iptables+ifb как самой оптимальной по настройке и производительности

    Если вы имеете ввиду заворот траффика с pppX в ifb - иптейблс не поможет, т.к. траффик попадет в ifb до того как попадет в prerouting

    Если вы заворачиваете уже исходящий траффик с eth (после маршрутизации) - то я вообще не вижу смысла в ifb, с тем же успехом можете шейпить на eth

     

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

     

    я набросал пару схем, что бы четче выразить мысль

     

    вариант1

     

    routev1.png

     

    вариант2

     

    routev1.png

     

    Исходящий шейпится на на pppX

    Входящий разруливается с eth0 (nat) или по 2м ifb или через один ifb, но по разным классам в одной дисциплине, так же, как это сделано на pppX.

    NiTr0, вы предлагаете шейпить входящий на eth0?

    Я к тому-же понял, что фильтры tc очень сложно (невозможно) удалять, - пока получается только с корневой дисциплиной :)

    Может быть вообще делать для каждого pppX свой ifb ?

  10. Опубликовано · Изменено пользователем lessless · Жалоба на ответ

    Здравствуйте! Помогите разобраться с темой: мы начинающий провайдер, но хотим сделать тарифы с более высокой скоростью в пириниг, чем в мир.

    Например мир 1 мбит, UA-iX 5 мбит.

    Поскольку я раньше больше был системным администратором, чем сетевым то начал изучать материал с самого начала и пришел к схеме iptables+ifb как самой оптимальной по настройке и производительности:

    1) весь входящий трафик из пиринга заворачивается на ifb0 средствами iproute2

    2) на ifb0 весит множество классов каждый из которых соответствует одному абоненту. Условно такого вида:

    tc class 1:1 - 172.15.1.2

    tc qdisc parent 1:1 handle 2: htb rate 1mbit burst 15k

    1:2 - 172.15.1.3

    tc qdisc parent 1:2 handle 3: htb rate 1mbit burst 15k

    3)когда трафик попадает на ifb0 iptables классифицирует траффик по точкам отправления и назначения

     

    iptables -t mangle -A POSTROUTING -o ifb0 -m set uaix src -d 172.15.1.2 -j CLASSIFY --set-class 1:1

     

    заворачивая его в необходимый класс на ifb0!

     

    пока я пробую и у меня не срабатывает фильтр заворачивающий на eth0

     

    tc filter add dev eth0 parent 1: protocol ip u32 match ip src 217.20.163.94/32 action mirred egress redirect dev ifb0

     

    подскажите, такая схема вообще не будет работать или у нее все-же есть какие-то шансы ? ))