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

IFB + iptables classify помогите разобраться нарезка скорости ua-ix

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

Например мир 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

 

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

Edited by lessless

Share this post


Link to post
Share on other sites

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

/sbin/tc filter add dev $1 parent 1: protocol ip u32 match u32 0 0 flowid 1:11 action mirred egress redirect dev ifb0

по аналогии попробуйте добавить flowid 1:11. Помоему, когда тестировал, эти цифры (1:11) ни на что не влияли, но без этого flowid не срабатывало перенаправление.

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites

UA-IX и мир на бордер разными интерфейсами приходят? Мне понравилось красивое решение, подсмотренное в "Designing and Implementing Linux Firewalls and QoS" - ставить разные DSCP-метки на входящие пакеты в mangle/PREROUTING и уже на NAS-е на их основании создавать два фильтра и iptables уже для собственно локальной разметки не использовать.

Share this post


Link to post
Share on other sites

Метки - это хорошо, но ТС они не помогут, т.к. надобно шейпить исходящий траффик.

Share this post


Link to post
Share on other sites

пришел к схеме 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 ?

Edited by lessless

Share this post


Link to post
Share on other sites

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

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

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

Edited by NiTr0

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Edited by lessless

Share this post


Link to post
Share on other sites

Если интересно, у меня сделанно примерно так на впнах:

 

Chain FORWARD (policy ACCEPT)

target prot opt source destination

NIGHT all -- 0.0.0.0/0 0.0.0.0/0 TIME from 21:00:00 to 05:00:00 UTC

DAY all -- 0.0.0.0/0 0.0.0.0/0

 

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

 

Chain POSTROUTING (policy ACCEPT)

target prot opt source destination

 

Chain DAY (1 references)

target prot opt source destination

CLASSIFY all -- 0.0.0.0/0 0.0.0.0/0 CLASSIFY set 1:0

CLASSIFY all -- 0.0.0.0/0 0.0.0.0/0 match-set UNLIMIT src CLASSIFY set 1:4000

CLASSIFY all -- 0.0.0.0/0 0.0.0.0/0 match-set UNLIMIT dst CLASSIFY set 1:4000

BRAIN all -- 0.0.0.0/0 0.0.0.0/0

 

Chain NIGHT (1 references)

target prot opt source destination

CLASSIFY all -- 0.0.0.0/0 0.0.0.0/0 CLASSIFY set 1:4000

BRAIN all -- 0.0.0.0/0 0.0.0.0/0

ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

 

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

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

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

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

Edited by Dethman

Share this post


Link to post
Share on other sites

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

С какой радости? Фильтры/классы/etc вешаются на интерфейс (вход, если ingress, или выход если обычный), соответственно, либо отрабатывают до маршрутизации/фильтрации/прочего пережевывания траффика (как с ingress IFB), либо - после. И никакого отношения к цепочкам iptables не имеют. Вообще.

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

сорцы можно взять сорцы, сразу предупреждаю писалось на ходу и оформлением не занимался совсем. Там в корне лежит сорц под iptables и в директории kernel сам модуль (я собирал под 2.6.35 и 2.6.37 в других не пробовал, может и не собраться :)).

Вот этот скриптик для выставления приоритетов по портам :) список портов лежит в

/etc/brain/ports.class_1, /etc/brain/ports.class_2, /etc/brain/ports.class_3, в /etc/brain/ports.drop лежит список портов которые нужно просто дропать :)

#!/bin/sh
for class_1 in $(cat /etc/brain/ports.class_1);do
       echo "S ${class_1}=13" > /proc/brain/ctl
done
for class_2 in $(cat /etc/brain/ports.class_2);do
       echo "S ${class_2}=12" > /proc/brain/ctl
done
for drop in $(cat /etc/brain/ports.drop);do
       echo "D ${drop}" > /proc/brain/ctl
done

 

для Ifup пользуется вот такая штука:

#!/usr/bin/perl
$root_qdisc='/sbin/tc qdisc add dev %s root handle 1: htb default %x'."\n";
$add_qdisc=
'/sbin/tc qdisc add dev %s parent 1:%x handle %x sfq perturb 30'."\n";
$root_class=
'/sbin/tc class add dev %s '.
       'parent 1:%x '.
       'classid 1:%x '.
       'htb prio %u rate %u '.
       'quantum 1500 burst 64k'."\n";

$add_class=
'/sbin/tc class add dev %s '.
       'parent 1:%x '.
       'classid 1:%x '.
       'htb prio %u rate 1mbit '.
       'ceil %u quantum 1500 burst 64k'."\n";
       #dev class prio speed
$del_class=
'/sbin/tc class del dev %s classid 1:%x'."\n";

$mbit=1048576;
$ppp_device=shift;
if ($ppp_device=~/^ppp(\d+)$/) {
               $pppnum=$1;
} else {
               print "device error\n";
               exit 1;
}
$speed=shift;
$speed=100 if (!$speed);
$unlim_speed=100;

$p[1]=1<<13;
$p[2]=1<<12;
$p[3]=1<<11;
$un=1<<14;
$base_class=(1<<15);
for ($i=1;$i<=3;$i++) {
               $unlim[$i]=$base_class|$p[$i]|$un;
               $limit[$i]=$base_class|$p[$i];
}
$unlim_class=$base_class|$un;
$limit_class=$base_class;
$out_name='internet';
sub setup_input  ($$) {
               my $pppnum=shift;
               my $speed=shift;
               $ppp_name = sprintf('ppp%u',$pppnum);
               system sprintf("/sbin/tc qdisc del dev $ppp_name root\n");
               system sprintf($root_qdisc,$ppp_name,$limit[3]);
               system sprintf($root_class,$ppp_name,0,$unlim_class,0,(2*$unlim_speed*$mbit));
               system sprintf($add_class,$ppp_name,$unlim_class,$base_class,0,(2*$speed*$mbit));
               for ($i=1;$i<=3;$i++) {
                               system sprintf($add_class,$ppp_name,$unlim_class,$unlim[$i],$i,100*$mbit);
                               system sprintf($add_class,$ppp_name,$base_class,$limit[$i],$i,$speed*$mbit);
                               system sprintf($add_qdisc,$ppp_name,$unlim[$i],$unlim[$i]);
                               system sprintf($add_qdisc,$ppp_name,$limit[$i],$limit[$i]);
               }
}

sub setup_output ($$) {
               my $pppnum=shift;
               my $speed =shift;
               $pppnum++;
               for ($i=1;$i<=3;$i++) {
                       system sprintf($del_class,$out_name,$unlim[$i]|$pppnum);
                       system sprintf($del_class,$out_name,$limit[$i]|$pppnum);
               }
               system sprintf($del_class,$out_name,$base_class|$pppnum);
               system sprintf($del_class,$out_name,$unlim_class|$pppnum);

               system sprintf($root_class,$out_name,1,$unlim_class|$pppnum,4,(2*$unlim_speed*$mbit));
               system sprintf($add_class, $out_name,$unlim_class|$pppnum,$base_class|$pppnum,0,(2*$speed*$mbit));
               for ($i=1;$i<=3;$i++) {
                               system sprintf($add_class,$out_name,$unlim_class|$pppnum,$unlim[$i]|$pppnum,$i,100*$mbit);
                               system sprintf($add_class,$out_name,$base_class|$pppnum,$limit[$i]|$pppnum,$i,$speed*$mbit);

                               system sprintf($add_qdisc,$out_name,$unlim[$i]|$pppnum,$unlim[$i]|$pppnum);
                               system sprintf($add_qdisc,$out_name,$limit[$i]|$pppnum,$limit[$i]|$pppnum);
               }
}
setup_input($pppnum,$speed);
setup_output($pppnum,$speed);

 

Если где-то чето-то забыл, вы пишите, вспомню :)

Share this post


Link to post
Share on other sites

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

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

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

А чем много ifb плохо?

Share this post


Link to post
Share on other sites

когда то было реализировано так :

 

1 патчили квагу на предмет того чтобы по бгп маршруты метились разными метками - например всё что с IX метилось одним остальное другим (патч в интернете есть)

 

Пример:

neighbor х.х.х.х remote-as хххх

neighbor х.х.х.х realm 10

10 - метка Все маршруты от х.х.х.х - метятся меткой 10

 

 

 

2 использовали в tc фильтр который умел работать с маршрутами и метками маршрутов - и заворачивали в разные класы htb

Пример

tc filter add dev ppp0 parent 1: protocol ip prio 1 route from 10 classid 1:50

tc class add dev ppp0 parent 1:10 classid 1:50 htb rate XXXXKbit burst 4k prio 1

 

 

но эта схема работает хорошо для входящего для абонента... исходящий по скоростям не делился - одна труба на всё! Схема НАМНОГО проще чем с ifb imq и тд

Edited by Lynx10

Share this post


Link to post
Share on other sites

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

Пакет на интерфейс (и шейперы) доставляется только тогда, когда он покинет все цепочки.

 

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

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

 

А чем много ifb плохо?

А чем хорошо, если они в данной ситуации не нужны?

 

патчили квагу на предмет того чтобы по бгп маршруты метились разными метками

А почему бы просто вам было не поднять для каждого направления свой влан, и метить уже иптейблсом соответственно интерфейсу? Зачем такие непонятные костыли-то?

Share this post


Link to post
Share on other sites

патчили квагу на предмет того чтобы по бгп маршруты метились разными метками

А почему бы просто вам было не поднять для каждого направления свой влан, и метить уже иптейблсом соответственно интерфейсу? Зачем такие непонятные костыли-то?

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

Share this post


Link to post
Share on other sites

 

т.е. 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 - как заворачивать на него трафик так и не разобрался.

Edited by lessless

Share this post


Link to post
Share on other sites

Заворачивается в IFB стандартно. Но вот он отрабатывается до того как пакет попадет в iptables. Т.е. - никаких меток.

Или на свой страх и риск пользовать IMQ - на старых ядрах работало прекрасно, на новые вроде как пилят (или уже напилили) патчи, проверять не доводилось.

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