LINUX.ORG.RU
ФорумAdmin

шейпер на HTB, как шейпить траффик самого роутера?

 , ,


0

2

Имеется роутер, подключенный во внешний мир через ppp0 на котором, естественно, делается NAT.

LAN сетевухи объединены в бридж, траффик со всех сетевух сходится в ifb, на ifb навешан HTB. Все прекрасно работает за исключением того, что сам интернет-траффик роутера оказывается не классифицирован и шурует прямо на ppp0. Вешать HTB на ppp0 не получится из-за NATa. Как быть? Хочется сделать из роутера торренто-качалку с низким приоритетом, чтоб не мешала остальным. Простое ограничение скорости торрентокачалки не предлагать, хочется нормальное решение, когда роутер использует всю полосу в отсутствии других пакетов на интерфейсе.

Вообще логично было-бы как-то сделать так, чтобы система думала, что генерируемый роутером траффик оказывается на ifb, аналогично с возвратным траффиком. Тогда я бы классифицировал пакеты роутера по LAN адресу и они бы отжирали полосу у того-же HTB с которого кормится вся локалка. Проблем бы не было, но я не знаю можно ли так сделать?

Кажется можно было бы еще маркирвоать пакеты средствами iptables, а шейпить всё-же на ppp0, но роутер ОЧЕНЬ слабый и мне так нравится, что фильтры сейчас на хэшах работают) В общем этот вариант вроде как в последнюю очередь рассматривается..


Ответ на: комментарий от dx_

Так ifb это тоже самое

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

У меня как раз два ifb один для входящего второй для исходящего. Реально вопрос не в этом же! Как шейпить входящий понятно. Непонятно как быть с локальным трафиком самого роутера, который лезет в инет прямо через ppp0.

Аггрегация траффика сделана так

 #load ifb module
eval modprobe ifb numifbs="${numifbs}"
#bring up all ifb devices
for ifbn in `eval seq 0 "$[numifbs - 1]"`
do
        eval ip link set dev "ifb${ifbn}" up
done

#aggregate LAN traffic to ifb
#redirect all LAN traffic(ingress and egress) to ifb devices
for iface in "${lan_iface_list}"
do
        eval tc qdisc del dev "${iface}" root 2>/dev/null
        eval tc qdisc del dev "${iface}" ingress 2>/dev/null

        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}"

        eval tc qdisc add dev "${iface}" root handle 1: htb
        eval tc filter add dev "${iface}" parent 1: protocol ip \
        u32 match u32 0 0 action mirred egress redirect dev "${lan_egress_ifb}"
done


#print some redirect info
#echo "${wan_iface} ingress --> ${wan_ingress_ifb}"
echo "${lan_iface_list} ingress --> ${lan_ingress_ifb}"
echo "${lan_iface_list} egress --> ${lan_egress_ifb}" 

dx_ ()
Ответ на: комментарий от Pinkbyte

Забыл добавить. Debian 6, ничего не патчено, всё из коробки. Всё правильно, мы как раз превращаем входящий траффик как-бы в исходящий на ifb и там всё шейпим. Это достигается тем, что мы на реальный интерфейс цепляем ingress qdisc, позволяющий нам провернуть как раз то что нужно.

eval tc qdisc add dev "${iface}" ingress
а потом копируем этот ingress трафик в egress интерфейса ifb(action mirred egress)
eval tc filter add dev "${iface}" parent ffff: protocol ip \
        u32 match u32 0 0 action mirred egress redirect dev "${lan_ingress_ifb}"

dx_ ()
Ответ на: комментарий от post-factum

Потому что на ppp0 после NAT всё сливается в такую фигю

153-97-91-171.pool.ukrtel <=> ftp.de.debian.org           657Kb   698Kb   711Kb
153-97-91-171.pool.ukrtel <=> srv103-131-240-87.vk.com      0b   1.32Kb   668b
153-97-91-171.pool.ukrtel <=> nsc8.ukrtel.net            1.46Kb  1.08Kb   660b
153-97-91-171.pool.ukrtel <=> resolver1.dyndnsinternetg   988b    994b    573b
153-97-91-171.pool.ukrtel <=> resolver1.opendns.com      1.55Kb   902b    540b
153-97-91-171.pool.ukrtel <=> google-public-dns-a.googl  1.46Kb   883b    533b
153-97-91-171.pool.ukrtel <=> google-public-dns-b.googl  1.46Kb   763b    531b
153-97-91-171.pool.ukrtel <=> nsc7.ukrtel.net             836b    835b    505b
153-97-91-171.pool.ukrtel <=> 111.221.74.30              1.30Kb   266b    198b
153-97-91-171.pool.ukrtel <=> 213.199.179.155               0b    790b    198b
153-97-91-171.pool.ukrtel <=> 111.221.74.32                 0b      0b    118b
153-97-91-171.pool.ukrtel <=> 173.194.113.192               0b    418b    104b
153-97-91-171.pool.ukrtel <=> fa182.43.fix-addr.vsi.ru      0b      0b     83b
153-97-91-171.pool.ukrtel <=> 192.0.80.242                  0b      0b     81b
153-97-91-171.pool.ukrtel <=> 37-144-119-206.broadband.   704b    288b     72b
153-97-91-171.pool.ukrtel <=> 134-249-205-81-gprs.kyivs     0b      0b     59b
153-97-91-171.pool.ukrtel <=> 178.122.25.94              1.08Kb   221b     55b
153-97-91-171.pool.ukrtel <=> nat.jablonka.cz               0b    144b     54b
153-97-91-171.pool.ukrtel <=> nat210-252-205-109.tvoe.t     0b      0b     53b
153-97-91-171.pool.ukrtel <=> host-176-33-167-9.reverse     0b      0b     53b
153-97-91-171.pool.ukrtel <=> 176.120.44.110                0b      0b     53b
153-97-91-171.pool.ukrtel <=> 173.194.113.201             644b    194b     48b
153-97-91-171.pool.ukrtel <=> 173.194.113.198               0b      0b     48b
153-97-91-171.pool.ukrtel <=> 173.194.113.222               0b      0b     48b
153-97-91-171.pool.ukrtel <=> ec2-54-213-47-55.us-west-     0b      0b     46b
153-97-91-171.pool.ukrtel <=> 37-115-200-36-broadband.k     0b    165b     41b
153-97-91-171.pool.ukrtel <=> 81.19.104.129                 0b      0b     32b
153-97-91-171.pool.ukrtel <=> srv120-131-240-87.vk.com    468b     94b     23b
153-97-91-171.pool.ukrtel <=> 83.149.34.137                 0b      0b     19b
153-97-91-171.pool.ukrtel <=> 217.77.215.194              368b     74b     18b

где 153-97-91-171.pool.ukrtel это как раз адресок роутера. Понимаешь? не видно там LAN юзеров. Не знаем мы какой коннект куда идет.

dx_ ()

AFAIR iptables может маркировать пакеты в зависимости от юзера, из под которого запущено сетевое приложение

af5 ★★★★★ ()
Ответ на: комментарий от af5

iptables то может, вот только на ifb траффик заворачивается до netfilter и ничего не получится. Именно этот аргумент и заставлялет смотреть в сторону imq, на который пакеты попадают уже после и маркировка становится доступна

dx_ ()
Ответ на: комментарий от dx_

У меня как раз два ifb один для входящего

Поздравляю - это полисинг даже с таким редиректом - дропов будет больше чем нужно. real-time траффик будет сосать на отлично.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от dx_

а настоящий clafssfull HTB на ifb это полисинг?

Код смотрел. Более того я подобный шейпер у себя юзал, пока не снял статистику и не ужаснулся количеству дропов. С IMQ их почти в два раза меньше при таких же классах HTB.

Тут вся проблема в том КАК осуществляется редирект. Если есть ingress очередь(а она у вас есть) - это УЖЕ полисинг.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

Я может чего-то не понимаю, но любой ingress шейпинг реализуется путем дропов по определению. ingress очереди тут нет, есть редирект всего и вся в egress ifb, а там уже весь шейпинг навешан на egress.

При любом виде ingress шейпинга, когда мы не можем управлять частотой отправки пакетов передатчиком, мы просто вынуждены дропать. Это при любом раскладе так. Даже если я без всяких ifb и imq навешаю по шейперу на egress LAN и WAN интерфейсов, всё равно входящий(со стороны LAN) траффик будет шейпиться дропами. Задумайтесь на секундочку. Вопрос просто в то как эти дропы распределяются между коннектами. Обычный полисинг дропает «всё что, не влазит», HTB дропает на основании более продуманных правил, описанных в классах, при этом работает оно более плавно и правильно. Разница по сути только в этом. Сомневаюсь, что с IMQ дела обстоят как-то иначе. Может быть сам способ заворота траффика там не подразумевает наличия слова ingress и это как-то вводит вас в заблуждение.

dx_ ()
Ответ на: комментарий от dx_

любой ingress шейпинг реализуется путем дропов по определению

Нет. В ванильном линуксе - да.

Задерживать выдачу можно и для входящего трафика. Так же как и дропать для исходящего.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от dx_

Даже если я без всяких ifb и imq навешаю по шейперу на egress LAN и WAN интерфейсов, всё равно входящий(со стороны LAN) траффик будет шейпиться дропами. Сомневаюсь, что с IMQ дела обстоят как-то иначе.

Нет. Кури матчасть.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

Нет, ну понятно, что есть еще очередь и переупорядочивание пакетов(читай задержка), разные приоритеты. Всё это у меня есть и прекрасно работает, но фактически само ограничение скорости как таковое будет в виде дропа, а как иначе то? А потом уже вышестоящий протокол обнаружит дропы и подстроит скорость, всё на этом и держится. Вообще пруфлинк бы, наставляющий меня на путь истинный. Потому что мне кажется у вас какая-то фобия образовалась по поводу ingress, везде вам полисинг мерещится )

dx_ ()
Ответ на: комментарий от dx_

Вообще пруфлинк бы, наставляющий меня на путь истинный

на здоровье

•Ingress shaping: With linux only egress shaping is possible (except for the ingress queue which can only do rate limiting)

Ну и sources is the best documentation (c). Курим сырцы ядра по части QoS.

А насчёт фобии я уже сказал: на той же самой полосе IMQ теряет меньше пакетов, менее рваный график скорости.

Тесты предлагаю сделать самому или нагуглить.

Если устраивает текущее положение дел и нет необходимости пропускать real-time трафик или качество его пропускания не критично(сомневаюсь что такое возможно, но мало ли) - ничего менять не надо. Правила «работает - не трогай» и «лучшее - враг хорошего» придумали не зря :-)

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

Всё правильно, на ingress queue без доп примочек нельзя навесить ничего кроме rate limiting. Но мы просто редиректим и шейпим всё на egress queue другого интерфейса. ifb от imq в этом плане абсолютно ничем не отличается. Основная фишка то в чем: создать очередь и обрадатывать её. Вот мы и создаём очередь(на egress ifb девайса) и по полной программе её обрабатываем HTB со всеми пирогами. Если внимательно почитать http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb станет понятно, что ifb изначально делался как алтернатива IMQ но с некоторыми архитектурными отличиями. Там объясняется и работа редиректа

If you replace mirror with redirect, those packets will be blackholed and will never make it out.

Что означает, что весь входящий траффик будет помещен в egress очередь интерфейса ifb, а дальше любой шейпинг, приоритеты, вся фигня. Так что если у вас когда-то был неудачный опыт использования ifb в какой-то не известной нам конфигурации - не стоит обобщать его и заявлять, что где есть ingress - там полисинг. Это не так.

dx_ ()

Так вот почему все ушли на НТВ+!

menangen ★★★★★ ()
Ответ на: комментарий от dx_

ifb от imq в этом плане абсолютно ничем не отличается.

Я проводил замеры именно используя редирект с ingress очереди.

Так что если у вас когда-то был неудачный опыт использования ifb в какой-то не известной нам конфигурации - не стоит обобщать его и заявлять, что где есть ingress - там полисинг. Это не так.

Ага, этот опыт был у меня, у моего напарника на другой конфигурации и еще у кучи народа. Напарник, вдохновленный данным тредом, недавно попытался повторить подобную конфигурацию чтобы выкинуть IMQ, ради которого приходится патчить ядро. Итог теста неутешителен - дропов пакетов не в 2 раза больше, а всего в полтора.

Не пойми неправильно, я активно использую IFB там, где у меня шейпинг ТОЛЬКО исходящего трафика и он работает просто прекрасно. Но в сочетании с redirect на ingress queue(для чистоты эксперимента - на другом ifb устройстве, чтобы в очередях не путаться) начинается сракотан - это видно уже на 10-20 мегабитах. А у меня кое-где надо шейпить все 150. И если IMQ уменьшит дропы, увеличив при этом задержки(но пакеты БУДУТ доходить) - я буду использовать IMQ.

Повторюсь - если тебя всё устраивает в твоей конфигурации с IFB - не надо ничего менять. Если нет - не надо цепляться за IFB как за панацею от всех болезней. Я ж не утверждаю, что IMQ нужно пихать везде :-)

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от Pinkbyte

Ну ладно, раз всё на столько серьезно и проводились замеры.. Хотя, конечно, абсолютно не понятно в чем корень зла.

Опять же исходя из здравого смысла можно предположить, что пакет тем дольше можно задержать, чем длиннее очередь. Может быть настройки по умолчанию для IMQ предполагают более длинную очередь и это сказывается...

dx_ ()
Ответ на: комментарий от dx_

Опять же исходя из здравого смысла можно предположить, что пакет тем дольше можно задержать, чем длиннее очередь.

Естественно на оконечные узлы я цеплял sfq или pfifo. Потому что если к HTB на оконечные узлы вообще ничего не цеплять - дропы будут огого.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

Короче посоветовали мне такую идею http://wiki.sirmax.noname.com.ua/index.php/NetworkNamespaces

Под локальные приложения создается отдельный нэймспэйс со своим сетевым интерфейсом. Для существующей архитектуры это будет выглядеть как еще один хост в локальной сети и всё будет прекрасно шейпиться... Прикольная идея. И кажется всё это из коробки поддерживается ядром.

dx_ ()
Ответ на: комментарий от dx_

Ну может они и правы, я сам последний раз делал замеры полгода назад, учитывая с какой скоростью развивается ядро - могли и пофиксить.

Pinkbyte ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.