lessless Опубликовано 8 апреля, 2011 (изменено) · Жалоба Здравствуйте! Помогите разобраться с темой: мы начинающий провайдер, но хотим сделать тарифы с более высокой скоростью в пириниг, чем в мир. Например мир 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 подскажите, такая схема вообще не будет работать или у нее все-же есть какие-то шансы ? )) Изменено 8 апреля, 2011 пользователем lessless Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XomA Опубликовано 8 апреля, 2011 · Жалоба у меня при поднятии 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 не срабатывало перенаправление. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 9 апреля, 2011 · Жалоба пришел к схеме iptables+ifb как самой оптимальной по настройке и производительности Если вы имеете ввиду заворот траффика с pppX в ifb - иптейблс не поможет, т.к. траффик попадет в ifb до того как попадет в prerouting Если вы заворачиваете уже исходящий траффик с eth (после маршрутизации) - то я вообще не вижу смысла в ifb, с тем же успехом можете шейпить на eth В свое время думали подобным заморачиваться, оптимальным вариантом оказалось гнать украину и мир по разным вланам, и соответственно на эти вланы вешать шейперы - но потом идея отпала ввиду отказа от разделения "украина-мир". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GFORGX Опубликовано 9 апреля, 2011 · Жалоба UA-IX и мир на бордер разными интерфейсами приходят? Мне понравилось красивое решение, подсмотренное в "Designing and Implementing Linux Firewalls and QoS" - ставить разные DSCP-метки на входящие пакеты в mangle/PREROUTING и уже на NAS-е на их основании создавать два фильтра и iptables уже для собственно локальной разметки не использовать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 9 апреля, 2011 · Жалоба Метки - это хорошо, но ТС они не помогут, т.к. надобно шейпить исходящий траффик. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lessless Опубликовано 11 апреля, 2011 (изменено) · Жалоба пришел к схеме iptables+ifb как самой оптимальной по настройке и производительности Если вы имеете ввиду заворот траффика с pppX в ifb - иптейблс не поможет, т.к. траффик попадет в ifb до того как попадет в prerouting Если вы заворачиваете уже исходящий траффик с eth (после маршрутизации) - то я вообще не вижу смысла в ifb, с тем же успехом можете шейпить на eth В свое время думали подобным заморачиваться, оптимальным вариантом оказалось гнать украину и мир по разным вланам, и соответственно на эти вланы вешать шейперы - но потом идея отпала ввиду отказа от разделения "украина-мир". я набросал пару схем, что бы четче выразить мысль вариант1 вариант2 Исходящий шейпится на на pppX Входящий разруливается с eth0 (nat) или по 2м ifb или через один ifb, но по разным классам в одной дисциплине, так же, как это сделано на pppX. NiTr0, вы предлагаете шейпить входящий на eth0? Я к тому-же понял, что фильтры tc очень сложно (невозможно) удалять, - пока получается только с корневой дисциплиной :) Может быть вообще делать для каждого pppX свой ifb ? Изменено 11 апреля, 2011 пользователем lessless Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 11 апреля, 2011 (изменено) · Жалоба Входящий (т.е. от сервера абоненту) прекрасно шейпится на самом ppp. А до того - маркируете его как угодно по любым критериям. Фильтры - тоже прекрасно удаляются, только по id который нужно указывать при создании. Сотни IFB - это вообще бред, да и чем это лучше шейпинга на одном устройстве? Те же накладные расходы на фильтрацию, но гибкость намного хуже. Изменено 11 апреля, 2011 пользователем NiTr0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lessless Опубликовано 12 апреля, 2011 (изменено) · Жалоба Входящий (т.е. от сервера абоненту) прекрасно шейпится на самом ppp. А до того - маркируете его как угодно по любым критериям. Фильтры - тоже прекрасно удаляются, только по id который нужно указывать при создании. Сотни IFB - это вообще бред, да и чем это лучше шейпинга на одном устройстве? Те же накладные расходы на фильтрацию, но гибкость намного хуже. Спасибо, это то, что нужно! Прошу помочь еще с пониманием такого: при шейпинге на pppX я не могу использовать классификацию iptables -t mangle -A POSTROUTING ..., т.к. это таблица FORWARD, правильно ? Вместо этого могу использовать фильтры tc выделяя нужный мне трафик в отдельный класс и этим решаю свою задачу? Это ведь пара-тройка тысяч правил на каждый интерфейс или есть возможность устроить их в одном месте а-ля в ipset? Изменено 12 апреля, 2011 пользователем lessless Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dethman Опубликовано 14 апреля, 2011 (изменено) · Жалоба Если интересно, у меня сделанно примерно так на впнах: 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 вешаются исходячие классы для шейпинга Вобщем если оно интересно пишите Изменено 14 апреля, 2011 пользователем Dethman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 14 апреля, 2011 · Жалоба Прошу помочь еще с пониманием такого: при шейпинге на pppX я не могу использовать классификацию iptables -t mangle -A POSTROUTING ..., т.к. это таблица FORWARD, правильно ? С какой радости? Фильтры/классы/etc вешаются на интерфейс (вход, если ingress, или выход если обычный), соответственно, либо отрабатывают до маршрутизации/фильтрации/прочего пережевывания траффика (как с ingress IFB), либо - после. И никакого отношения к цепочкам iptables не имеют. Вообще. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lessless Опубликовано 14 апреля, 2011 · Жалоба 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 эх, а такой идеальный вариант выходил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dethman Опубликовано 14 апреля, 2011 · Жалоба сорцы можно взять сорцы, сразу предупреждаю писалось на ходу и оформлением не занимался совсем. Там в корне лежит сорц под 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); Если где-то чето-то забыл, вы пишите, вспомню :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 14 апреля, 2011 · Жалоба Входящий (т.е. от сервера абоненту) прекрасно шейпится на самом ppp. А до того - маркируете его как угодно по любым критериям. Фильтры - тоже прекрасно удаляются, только по id который нужно указывать при создании. Сотни IFB - это вообще бред, да и чем это лучше шейпинга на одном устройстве? Те же накладные расходы на фильтрацию, но гибкость намного хуже. А чем много ifb плохо? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 14 апреля, 2011 (изменено) · Жалоба когда то было реализировано так : 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 и тд Изменено 14 апреля, 2011 пользователем Lynx10 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 14 апреля, 2011 · Жалоба 3)пакет доставлен на интерфейс ppp0 для дальнейшей отправки и это и есть POSTROUTING :( Пакет на интерфейс (и шейперы) доставляется только тогда, когда он покинет все цепочки. т.е. iptables -t mangle -A POSTROUTING -d 172.15.1.2 -j CLASSIFY --set-class Идиотизм, это же можно сделать дефолтным правилом. Ибо никаких пакетов, кроме пакетов, предназначеных 172.15.1.2, там не будет. А чем много ifb плохо? А чем хорошо, если они в данной ситуации не нужны? патчили квагу на предмет того чтобы по бгп маршруты метились разными метками А почему бы просто вам было не поднять для каждого направления свой влан, и метить уже иптейблсом соответственно интерфейсу? Зачем такие непонятные костыли-то? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 15 апреля, 2011 · Жалоба патчили квагу на предмет того чтобы по бгп маршруты метились разными метками А почему бы просто вам было не поднять для каждого направления свой влан, и метить уже иптейблсом соответственно интерфейсу? Зачем такие непонятные костыли-то? ну кого как прёт :))) .... Меня маркировка не пёрла - риалм - вполне себе нормальное решение - и в тс нормально поддерживается ... можна было и маркировкой Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lessless Опубликовано 16 апреля, 2011 (изменено) · Жалоба т.е. 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 - как заворачивать на него трафик так и не разобрался. Изменено 17 апреля, 2011 пользователем lessless Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 16 апреля, 2011 · Жалоба Заворачивается в IFB стандартно. Но вот он отрабатывается до того как пакет попадет в iptables. Т.е. - никаких меток. Или на свой страх и риск пользовать IMQ - на старых ядрах работало прекрасно, на новые вроде как пилят (или уже напилили) патчи, проверять не доводилось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...