а как бы мне равномерно распределить канал?

esfq |SFQ flow classification | u32 hash+sfq

из за ната могут понадобиться извращения.

спасибо. а какие у нас есть варианты извращений...?
1. imq (но надо патчить ядро)
2. iptables mark(даже я знаю, что это медленно)
3.... ?

ipmark - это быстро.Если вы хотите делить поровну то нужно шейпить на аплинк интерфейсе, вот только проблема с натом. А у сервера несколько интерфейсов или опенвпн слушает на том же через который трафик в инет идет?

>Если вы хотите делить поровну то нужно шейпить на аплинк интерфейсе
поняяятное дело
интерфейс пока один.

вот тут про IFB накопал. штука немного не такая удобная, как IMQ, но вроде как более православная....

ipmark - это быстро.

ну если это правда, тогда может маркировать до ната, а фильтры на аплинке пускай ловят по меткам...?

но я всё равно почему-то склоняюсь к чему-то типа IMQ/IFB... это что-нибудь даст, кроме дополнительно геморроя?

esfq должен помочь, но оно помоему deprecated

если найдешь решение - отпиши пожалуйста

фильтры tc на аплинке работают до нетфильтра и до ната. Потому трафик который придет на интерфейс(который вы наверное хотите на ifb отправить) там будет без меток.

Да, с ifb и метками там засада, уже выяснил. На imq точно помню - делал с метками, но imq отпадает сразу.

Так что же делать?
Ооу,стойте! Есть же интерфейсы tun(у каждого openvpn демона), на который можно sfq и повесить. Там как раз и будут же айпишники клиентов.

Правильно я мыслю?

И даже не прсто на tun sfq вешать, а со всех tun'ов загонять на ifb, а потом уж туда sfq прикрутить. Таким образом получим более-менее справедливое распределение между всеми клиентами на всех демонах openvpn(а их будет по кол-ву ядер).

Остаётся только входящая очередь... всё-таки voip.. думаю, что желательно бы и входящую очередь тоже поровну раздавать всем клиентам, а не как придётся...
И тут что, снова IFB получается надо лепить? И опять этот косяк с NATом вылазит.

В общем пока как-то не совсем понятно...

у тебя не будет по одному tun на каждого клиента ведь, а один общий

А зачем на каждого клиента то?
На tun'е ещё видны айпишники клиентов(до NATа то дело не дошло), а значит их можно классифицировать и засунуть в очередь.

Про tun что то я и не подумал.То что один общий - это как раз плюс - чтобы делить поровну должны быть какие то общие классы. Возможно, только нужно будет в tс фильтрах смещения менять, тк tun это л3 интерфейс и там л2 уровня нет вообще.

ну это понятно. и все эти tun'ы вместе зарулить на ifb. да. тогда будет всё поровну.
А как входящий траффик то разделять?

ну tun же один на всех клиентов, откуда у вас много тюнов?

openvpn не форкает себя для каждого клиента и делает всё в один поток.
Для утилизации 4х ядер нужно запустить 4 демона, которые поднимут 4 tun'a. Ну и при подключении идёт распределение нагрузки между этими демонами.
Вот сейчас задумался..может и есть какой-то хитрый способ заставить их всех использовать один tun.. но я не уверен.

А может быть и входящий трафик с tun'ов точно так-же заворачивать на ifb? и можно будет фильтровать по серым айпишникам не взирая на NAT.

Алсо нашел вот интересный шедулер http://www.linuxhowtos.org/manpages/8/tc-drr.htm

Для утилизации 4х ядер нужно запустить 4 демона, которые поднимут 4 tun'a. Ну и при подключении идёт распределение нагрузки между этими демонами.

чет я такое впервые слышу

да хотя-бы вот это почитайте
http://readlist.com/lists/lists.sourceforge.net/openvpn-users/3/16167.html

The current version of openvpn (2.x series) is a single-threaded program
on every platform. There are advantages and drawbacks to this . The main
advantages are simplicity of the code and robustness. The main drawbacks
are the fact that it does not scale very well on modern
multicore/multithreaded CPUs.
There are workarounds for that where you can run multiple instances of
openvpn on a single machine

естественно, когда я писал про распределение нагрузки - имел ввиду, что это делается средствами iptables отдельно и не является частью функционала openvpn.

спасибо, я думал нативная фича такая есть у openvpn

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

конфиги немного разные получаются
каждый демон слушает свой порт и свой ip на tun вешает. иначе будет каша же)

хм, ну так распределение нагрузки получается совсем даже не полуавтоматическое

надо пилить клиентов на 4 части, каждой части давать свой конфиг со своим портом

неудобно совсем, жаль.

я же говорю, iptables раскидывает запросы по разным портам. наружу смотрит один порт и все клиенты щимятся на него... что не так то?

по поводу sfq flows вы спрашивали на наге:

http://www.linuxquestions.org/questions/linux-networking-3/shaping-traffic-with-sfq-external-classifier-flow-hash-key-dst-no-packet-forward-718763/

http://www.linux.org.ru/forum/admin/5917090

спасибо.
я тут вчера нашел немного интресного
http://oneitguy.com/blogs/netprince/fair-traffic-sharing-esfq-broken-switchin...
*пройти по ссылкам Links for research:

особенно мне понравилось это
http://www.wlug.org.nz/TrafficControl


в общем теперь всё более-менее в голове уложилось..буду экспериментировать...

кстати, а в чем суть flow map? c flow hash более-менее ясно вроде...

Если вы про это, то судя по всему работает как и u32 hash.

- Map destination IPs of 192.168.0.0/24 to classids 1-257:

  tc filter add ... flow map \
  	key dst addend -192.168.0.0 divisor 256

Однако я не пробовал, ничего не могу точно сказать)) Я использую u32 хеширование и работает оно очень быстро, вобщем пока что менять мне лень. Вы кстати тоже можете сделать каждому клиенту свой класс с rate=100k ceil=весь канал к примеру и хешфильтрами раскидать трафик в классы, просто esfq | sfq flow позволяет меньше строк писать.

про map да, тоже потом обратил внимание имнно на эту строку.

просто esfq | sfq flow позволяет меньше строк писать.

ну и проца ест наверно меньше, чем HTB с кучей классов + sfq на концах )

сейчас странность обнаружил одну:
заворачиваю входящий траффик с tun0 на ifb0 вот так:
tc filter add dev tun0 parent ffff: protocol ip\
u32 match u32 0 0 action mirred egress redirect dev ifb0
правильно же заворачиваю??

однако в iptables -i не срабатывает на ifb0. только на tun0.
так и должно быть?
я предполагал, что поскольку заворот траффика срабатывает раньше - iptables должен верить в то, что пакет пришел ему с ifb0.
баг или фича?

tcpdump на ifb0 при этом пакеты видит(правда толком ничего не понимает. видимо потому, что нет там level2).

ifb для iptables не существует, ifb работает на уровне очередей устройства где работает tc - это лишь промежуточное слой для навешивания шейпинга. Потому для iptables все прозрачно, и нужно работать с tun

хорошо, понятно.
но я кажется запутался что есть egress а что ingress
с обычной сетевушкой всё ясно: после egress идёт кабель.

но egress у tun0 НА СЕРВЕРЕ это то, что отправляет клиент? правильно я понимаю? вот клиент хочет пингануть сервер и эхо реквесты ложаться в egress tun0? и на egress мы можем спокойно вешать шейпер и без всяких извратов с ifb.
или таки нет? или у tun0 egress по аналогии с сетевухой это кабель и egress идёт к vpn клиенту? вроде так логичнее..да.
но меня смутило вот что:
в интернетах везде пишут
tc filter add dev tun0 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

mirred egress же! т.е. я перенаправляю на ifb0 то, что и так можно шейпить без ifb.
но когда я заменил egress на ingress - получил матюг
mirred ingres not supported at the moment

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

что ж такое, а. как только вопрос задам - сразу ответ нахожу.
дошло в общем.
когда мы задаём tc filter add dev tun0 .. мы уже имеем дело с ingress тюна. а дальше мы говорим action mirred egress redirect dev ifb0 т.е. пакеты из ingress tun0, которые подошли под критерии фильтра редиректить в egress ifb0. )

верно

оо, наконец я добрался до самого главного и правильного источника информации
http://ftp.de.debian.org/debian/pool/main/i/iproute/iproute_20080725.orig.tar.gz

папка doc/actions
красотаааа!))))))))

эххх. всё равно не совсем то, что нужно.
похоже реально нет толковой документации со всеми новыми фичами.
оно то и так вроде становится понятно со временем, но всё равно документации не хватает. много старого материала. пичалька :(

На сервере будет одна сетевуха и я хотел прибить openvpn демоны к 127.0.0.1 а с eth0 форвардить порт для распределения нагрузки.
Но DNAT не хочет перекидывать пакеты на 127.0.0.1
Что в таких случаях делают? Когда одна сетевуха и хочется скрыть сервис?

Тупо фильтровать на INPUTe тоже получается как-то не весело ибо как отличить пакеты, пробравшиеся прямо с eth0 на конкретный порт и перекинутые по DNAT? Получается маркировать надо, а потом по меткам разбирать.. ерунда всё это...

Может какой виртуальный интерфейс поднять тогда?