[_dx]

Всем привет! Заранее пардон, если тут строго провайдерское применение линукса обсуждают..У меня применение не провайдерское, но знаю, что адекватный ответ от хороших спецов получить здесь проще всего.

 

В общем есть очень дохлый роутер/файлопомойка на 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 заморочиться..

 

Интересно узнать что кто думает по этому вопросу? Что же делать как же быть?

[SABRE]

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 и подключенная отдельным интерфейсом, что позволит с легкостью добавить ее в существующую схему.

[_dx]

Юзеров не много, 10 машин. Скорость инета до 20мбит. Честно сказать, на хэщах я сделал больше из соображений перфекционизма, но нагрузка на проц снизилась и скорость скачивания файла через гигабитный линк возросла ) Уже понял, что придется заморочиться с IMQ. netns наверно будет более затратно по ресурсам, хотя идея прикольная, спасибо за наводку!

[SABRE]

Уж лучше штатный механизм, чем костыль, к тому-же настолько жуткий.

[_dx]

Уж лучше штатный механизм, чем костыль, к тому-же настолько жуткий.

Я правда не очень понял, жуткий - это про IMQ?

[s.lobanov]

где вы вообще IMQ раскопали? его ж вроде никогда не было в (ванильном) ядре и сейчас оно не пилится под новые ядра. или я что-то пропустил?

[m0xf]

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

[SABRE]

это про IMQ?

Ага, про него.

m0xf

Поздравляю, Вы повторили мое предложение. Только с лишней нагрузкой в виде ната, можно его вполне исключить.

[_dx]

На самом деле я немного погуглил и уже начал понимать, что IMQ по ходу заброшен....

Потом я ооочень хорошо подумал реально надо ли мне, чтобы роутер что-то качал и учитывая объем заморочек я подумал, что ну его в болото )))

[SABRE]

_dx

ip netns полностью решит проблему, попробуйте - отказаться всегда успеете.

[_dx]

ip на netns ругнулся. Там в Debian 6 чё-то доставить надо или обновляться на седьмую/убунту?

LXC это как раз оно ж?

https://linuxcontainers.org/

https://wiki.debian.org/LXC

 

Кстати IMQ по ходу жив еще

https://github.com/imq/linuximq/tree/master/latest

Изменено 2 октября, 2014 пользователем _dx

[rdc]

…тем временем, на фряхе эта задача решается левым мизинцем…

[GrandPr1de]

…тем временем, на фряхе эта задача решается левым мизинцем…

Созданием ещё 1 пайпа.

Изменено 2 октября, 2014 пользователем GrandPr1de

[SABRE]

LXC это как раз оно ж?

Нет, LXC использует штатный механизм namespace`ов, а не предоставляет их.

 

В Wheezy уже есть. Обновите iproute.

[_dx]

Я тут на ЛОРе задал тот-же вопрос 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 нужно пихать везде :-)

Я предположил, что дело в длине очереди, чем она длиннее - тем на дольше можно задержать пакет.

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

[SABRE]

Я тут на ЛОРе задал тот-же вопрос

Еще бы на mail.ru спросили - результат сравним.

Нет. IFB не позволяет шейпить ВХОДЯЩИЙ трафик. Входящий трафик нельзя шейпить в ванильном ядре ничем, только полисинг. IMQ превращает входящий трафик как бы в исходящий.

После этого дальше даже читать не стал - мисье застрял в 2000х.

Изменено 3 октября, 2014 пользователем SABRE