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

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

 

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

Изменено пользователем lessless

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

у меня при поднятии 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 не срабатывало перенаправление.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем lessless

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Изменено пользователем NiTr0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Изменено пользователем lessless

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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 вешаются исходячие классы для шейпинга

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

Изменено пользователем Dethman

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

сорцы можно взять сорцы, сразу предупреждаю писалось на ходу и оформлением не занимался совсем. Там в корне лежит сорц под 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);

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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 и тд

Изменено пользователем Lynx10

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

Изменено пользователем lessless

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.