_dx Posted September 30, 2014 · Report post Всем привет! Заранее пардон, если тут строго провайдерское применение линукса обсуждают..У меня применение не провайдерское, но знаю, что адекватный ответ от хороших спецов получить здесь проще всего. В общем есть очень дохлый роутер/файлопомойка на Debian 6(VIA C3 700MHZ, 512RAM, 1TB RAID1, Intel 82546GB), ну нравится мне выжимать всё из старого железа :) Весь траффик LAN части аггеригуется на двух ifb(для ingress и egress шейпинга) и делится между юзерами(HTB), фильтры на хэшах(ибо смотри пункт первый про дохлость сервера). Весь шейпинг получается на этих двух ifb. Роутер связан с внешним миром через интерфейс ppp0, который естественно NATится, поэтому шейпить на ppp0 не получается. Ах да, там еще весь LAN на squid transparent загоняется. Для LAN юзеров всё прекрасно шейпится, но хотелось бы, чтобы и сам роутер выходил в инет через те-же ifb и его трафик шейпился наравне с LANовскими юзерами. А то сейчас если роутер что-то качает - все курят бамбук. Даже наверное лучше не так сформулировать, через какой интерфейс всё это пройдет наверно не важно - важно, чтобы траффик самого роутера отъедал кусок пирога от того-же HTB класса что и LAN юзеры, очень хотелось бы, чтобы он постоянно что-то качал с низким приоритетом и никому не мешал. Идеи по этому поводу у меня такие: 1. как-то накрутить source routing и направлять пакеты не сразу через ppp0,а каким-то образом сделать так, чтобы роутер сам себя обманывал и свои пакеты считал транзитными, пришедшими с LAN стороны...далее бы эти пакеты попадали в те-же ifb и прекрасно шейпились... это только идея, пока не представляю можно ли реализовать это дело на практике 2. поговаривают, что IMQ в тесном сотрудничестве в iptables мог бы выручить меня, но во-первых там патчить придется дофига, а во-вторых многое из того что есть придется переделывать, в третьих по скорости всё это будет явно хуже фильтров на хэшах. пока в общем с IMQ связываться не хотелось бы. 3. возможно еще какие-то извращения придумать.. допустим всех юзеров(включая сам роутер) подключить через openvpn к одному tun и шейпить уже там всё это дело... но тут снова куча дополнительного гемора получается, может даже лучше тогда с IMQ заморочиться.. Интересно узнать что кто думает по этому вопросу? Что же делать как же быть? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SABRE Posted October 1, 2014 · Report post 1. как-то накрутить source routing и направлять пакеты не сразу через ppp0,а каким-то образом сделать так, чтобы роутер сам себя обманывал и свои пакеты считал транзитными, пришедшими с LAN стороны...далее бы эти пакеты попадали в те-же ifb и прекрасно шейпились... Поздравляю, Вы придумали IMQ. Это тот самый редкий случай, когда на ifb не выедешь. 2. поговаривают, что IMQ в тесном сотрудничестве в iptables мог бы выручить меня, но во-первых там патчить придется дофига, а во-вторых многое из того что есть придется переделывать, в третьих по скорости всё это будет явно хуже фильтров на хэшах. пока в общем с IMQ связываться не хотелось бы. iptables там только для перенаправления трафика на IMQ. А дальше уже можете спокойно использовать хэши(а сколько юзеров, если не секрет) 3. возможно еще какие-то извращения придумать.. допустим всех юзеров(включая сам роутер) подключить через openvpn к одному tun и шейпить уже там всё это дело... но тут снова куча дополнительного гемора получается, может даже лучше тогда с IMQ заморочиться.. Ото Вы нагородили. Проще использовать netns. http://www.opennet.ru/tips/info/2683.shtml http://wiki.sirmax.noname.com.ua/index.php/NetworkNamespaces Тогда маршрутизатор будет работать в дефолтном namespace, а все качалки и программы потребляющие интернет - в каком нибудь дополнительном, связанным с основным с помощью veth линка, и для маршрутизатора это будет видится, как еще одна машина со своим ip и подключенная отдельным интерфейсом, что позволит с легкостью добавить ее в существующую схему. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
_dx Posted October 1, 2014 · Report post Юзеров не много, 10 машин. Скорость инета до 20мбит. Честно сказать, на хэщах я сделал больше из соображений перфекционизма, но нагрузка на проц снизилась и скорость скачивания файла через гигабитный линк возросла ) Уже понял, что придется заморочиться с IMQ. netns наверно будет более затратно по ресурсам, хотя идея прикольная, спасибо за наводку! Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SABRE Posted October 2, 2014 · Report post Уж лучше штатный механизм, чем костыль, к тому-же настолько жуткий. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
_dx Posted October 2, 2014 · Report post Уж лучше штатный механизм, чем костыль, к тому-же настолько жуткий. Я правда не очень понял, жуткий - это про IMQ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted October 2, 2014 · Report post где вы вообще IMQ раскопали? его ж вроде никогда не было в (ванильном) ядре и сейчас оно не пилится под новые ядра. или я что-то пропустил? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
m0xf Posted October 2, 2014 · Report post 1. как-то накрутить source routing и направлять пакеты не сразу через ppp0,а каким-то образом сделать так, чтобы роутер сам себя обманывал и свои пакеты считал транзитными, пришедшими с LAN стороны...далее бы эти пакеты попадали в те-же ifb и прекрасно шейпились... Я делал адский костыль с помощью виртуальных адаптеров (veth). Биндим приложение на veth1 (192.168.16.2), траффик с veth0 маршрутизируем как внешний (и натим). Пакет, отправляется с 192.168.16.2, уходит в veth1, применяется статический nat, и выходит из veth0 как внешний пакет с адреса 192.168.17.2. Назад в обратном порядке. ################################################ # virtual ethernet init # torrent ---> veth1 - -> veth0 ---> ifb0 ################################################ ip link delete veth0 > /dev/null 2>&1 ip link add name veth0 type veth peer name veth1 ip link set veth0 down ip link set veth1 down ip link set veth0 address f0:00:00:00:00:00 ip link set veth1 address f0:00:00:00:00:01 ip link set veth0 up ip link set veth1 up ip addr flush dev veth0 ip addr flush dev veth1 ip addr add 192.168.17.1/24 dev veth0 ip addr add 192.168.16.2/24 dev veth1 ip neigh add 192.168.17.2 lladdr f0:00:00:00:00:01 nud permanent dev veth0 ip neigh add 192.168.16.1 lladdr f0:00:00:00:00:00 nud permanent dev veth1 tc qdisc del dev veth1 root > /dev/null 2>&1 tc qdisc del dev veth1 ingress > /dev/null 2>&1 tc qdisc add dev veth1 root handle 1: prio tc qdisc add dev veth1 ingress tc filter add dev veth1 parent 1: pref 1 protocol ip u32 match ip dst 192.168.16.0/24 action nat ingress 192.168.16.0/24 192.168.17.0 continue tc filter add dev veth1 parent 1: pref 2 protocol ip u32 match ip src 192.168.16.0/24 action nat egress 192.168.16.0/24 192.168.17.0 continue tc filter add dev veth1 parent ffff: pref 1 protocol ip u32 match ip src 192.168.17.0/24 action nat egress 192.168.17.0/24 192.168.16.0 continue tc filter add dev veth1 parent ffff: pref 2 protocol ip u32 match ip dst 192.168.17.0/24 action nat ingress 192.168.17.0/24 192.168.16.0 continue IF_QOS=veth0 tc qdisc del dev $IF_QOS root > /dev/null 2>&1 tc qdisc del dev $IF_QOS ingress > /dev/null 2>&1 tc qdisc add dev $IF_QOS root handle 1: prio tc qdisc add dev $IF_QOS ingress tc filter add dev $IF_QOS parent 1: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 tc filter add dev $IF_QOS parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb1 ip route del default table 100 > /dev/null 2>&1 ip route add default via 192.168.16.1 dev veth1 src 192.168.16.2 table 100 ip rule del from 192.168.16.0/24 table 100 > /dev/null 2>&1 ip rule add from 192.168.16.0/24 table 100 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SABRE Posted October 2, 2014 · Report post это про IMQ? Ага, про него. m0xf Поздравляю, Вы повторили мое предложение. Только с лишней нагрузкой в виде ната, можно его вполне исключить. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
_dx Posted October 2, 2014 · Report post На самом деле я немного погуглил и уже начал понимать, что IMQ по ходу заброшен.... Потом я ооочень хорошо подумал реально надо ли мне, чтобы роутер что-то качал и учитывая объем заморочек я подумал, что ну его в болото ))) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SABRE Posted October 2, 2014 · Report post _dx ip netns полностью решит проблему, попробуйте - отказаться всегда успеете. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
_dx Posted October 2, 2014 (edited) · Report post ip на netns ругнулся. Там в Debian 6 чё-то доставить надо или обновляться на седьмую/убунту? LXC это как раз оно ж? https://linuxcontainers.org/ https://wiki.debian.org/LXC Кстати IMQ по ходу жив еще https://github.com/imq/linuximq/tree/master/latest Edited October 2, 2014 by _dx Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
rdc Posted October 2, 2014 · Report post …тем временем, на фряхе эта задача решается левым мизинцем… Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
GrandPr1de Posted October 2, 2014 (edited) · Report post …тем временем, на фряхе эта задача решается левым мизинцем… Созданием ещё 1 пайпа. Edited October 2, 2014 by GrandPr1de Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SABRE Posted October 3, 2014 · Report post LXC это как раз оно ж? Нет, LXC использует штатный механизм namespace`ов, а не предоставляет их. В Wheezy уже есть. Обновите iproute. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
_dx Posted October 3, 2014 · Report post Я тут на ЛОРе задал тот-же вопрос https://www.linux.org.ru/forum/admin/10897061 И там товарищ под ником Pinkbyte утверждает, что шейпер входящего траффика на IFB это вроде как и не шейпер вовсе, а просто дропалка. На что я заявил, что в конечном итоге любой шейпинг входящего это в конце концов дропалка пакетов... В общем там не много, кому не лень может перечитает нашу переписку, но вкратце суть такова Код смотрел. Более того я подобный шейпер у себя юзал, пока не снял статистику и не ужаснулся количеству дропов. С IMQ их почти в два раза меньше при таких же классах HTB.Тут вся проблема в том КАК осуществляется редирект. Если есть ingress очередь(а она у вас есть) - это УЖЕ полисинг. Получается вот тут он уже видит полисинг eval tc qdisc add dev "${iface}" ingress eval tc filter add dev "${iface}" parent ffff: protocol ip \ u32 match u32 0 0 action mirred egress redirect dev "${lan_ingress_ifb}" При этом человек осознает, что дальше на egress ifb цепляется HTB со SFQ по краям, всё как положено. > ifb от imq в этом плане абсолютно ничем не отличается. Я проводил замеры именно используя редирект с ingress очереди. > Так что если у вас когда-то был неудачный опыт использования ifb в какой-то не известной нам конфигурации - не стоит обобщать его и заявлять, что где есть ingress - там полисинг. Это не так. Ага, этот опыт был у меня, у моего напарника на другой конфигурации и еще у кучи народа. Напарник, вдохновленный данным тредом, недавно попытался повторить подобную конфигурацию чтобы выкинуть IMQ, ради которого приходится патчить ядро. Итог теста неутешителен - дропов пакетов не в 2 раза больше, а всего в полтора. Не пойми неправильно, я активно использую IFB там, где у меня шейпинг ТОЛЬКО исходящего трафика и он работает просто прекрасно. Но в сочетании с redirect на ingress queue(для чистоты эксперимента - на другом ifb устройстве, чтобы в очередях не путаться) начинается сракотан - это видно уже на 10-20 мегабитах. А у меня кое-где надо шейпить все 150. И если IMQ уменьшит дропы, увеличив при этом задержки(но пакеты БУДУТ доходить) - я буду использовать IMQ. Повторюсь - если тебя всё устраивает в твоей конфигурации с IFB - не надо ничего менять. Если нет - не надо цепляться за IFB как за панацею от всех болезней. Я ж не утверждаю, что IMQ нужно пихать везде :-) Я предположил, что дело в длине очереди, чем она длиннее - тем на дольше можно задержать пакет. В общем мне теперь стало интересно, товарищ что-то не то курил и спорит не о чем или действительно такое может быть и я чего-то не понимаю?? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SABRE Posted October 3, 2014 (edited) · Report post Я тут на ЛОРе задал тот-же вопрос Еще бы на mail.ru спросили - результат сравним. Нет. IFB не позволяет шейпить ВХОДЯЩИЙ трафик. Входящий трафик нельзя шейпить в ванильном ядре ничем, только полисинг. IMQ превращает входящий трафик как бы в исходящий. После этого дальше даже читать не стал - мисье застрял в 2000х. Edited October 3, 2014 by SABRE Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
