Jump to content
Калькуляторы

Linux. Входящий на интерфейс трафик и маркировка iptables

Такой вопрос:

 

Необходимо шейпить входящий на интерфейс маркированый трафик.

Как выяснилось маркеры iptables не доступны в дисциплине ingress. А жаль...

Как еще можно отфильтровать по маркерам входящий трафик, чтоб все это зашейпить в рамках одного интефейса. (без использования псевдоинтерфейсов) ?

 

Share this post


Link to post
Share on other sites

tc filter с матчем по нужным байтам пакета. Но это будет не шейпер, а полисер. Входящий шейпер работает до iptables (http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png), поэтому маркеры iptables ничем не помогут.

Share this post


Link to post
Share on other sites
There are many ways to mark the packets before they get to the socket.

tc ingress provides at least two ways (ipt action and recently posted

patch by me on skbedit);

че такое "ipt action" ?

Share this post


Link to post
Share on other sites

2Ivan Rostovikov

А какое правило iptables вы использовали для маркирования?

че такое "ipt action" ?
http://lists.netfilter.org/pipermail/netfi...ary/010179.html как пример

 

2DemYaN

я так понимаю, ТС хочет маркать трафик iptables'ами и на основании марков шейпить.

 

Share this post


Link to post
Share on other sites

Необходимо шейпить входящий на интерфейс маркированый трафик.

Постановка задачи дважды идиотична. Во-первых, входящий трафик по определению нельзя шейпить, можно лишь ограничивать его пакетрейт путем отбрасывания пакетов. Во-вторых, входящий трафик по определению не имеет маркировки, поскольку маркировка iptables имеет смысл только внутри адресного пространства данного ядра ОС и не передается между машинами, т.к. не соответствует какому-либо полю внутри передаваемого пакета.

Edited by photon

Share this post


Link to post
Share on other sites

photon - можно шейпить, ifb

Может иметь, например ToS/DSCP, хотя не факт, что автор именно это имеет ввиду.

 

По человечески можно будет маркировать наверное в 2.6.33 через skbedit (патч не вошел в 2.6.32, похоже)

Но пока, если в вашем дистрибуте работает action ipt - то можно и так

Share this post


Link to post
Share on other sites

Использование IFB/IMQ -- это копирование входящего трафика на псевдоустройство. Применение дисциплины очереди к такому трафику не гарантирует сохранности данных и точности в получаемой полосе пропускания, нельзя вносить слишком большие задержки, т.к. переполнится rx-буфер. Поэтому в любом случае это получится не нормальный shaping, а policing.

Edited by photon

Share this post


Link to post
Share on other sites

Да, копирование, т.к. в Линуксе не задумывались очереди на входе интерфейса.

 

Не переполнится. Я применяю (обьемы 40 мбит и карта реалтек) с достаточно большими буферами, и кучей классов, и ничего не переполняется.

Задержки тоже можно вносить по собственному усмотрению. Работает так же как и на исходе.

Конечно рассчитывать ограничить траффик с точностью 100% от провайдера сильно не стоит, но при грамотном подходе подровнять вполне можно. Хотя запас прийдется оставлять и решение неидеально, но значительно лучше, чем совсем ничего.

Share this post


Link to post
Share on other sites

Но пока, если в вашем дистрибуте работает action ipt - то можно и так

Я так понимаю, ТС хочет маркать iptables'ами с хитрыми матчами, которые нельзя сделать в tc, и на основании этих марков - шейпать.

Share this post


Link to post
Share on other sites

Тогда собрать траффик с исходов(egress) через mirred в ifb и там шейпить.

Без псевдоинтерфейсов (типа ifb) здесь никак...

Share this post


Link to post
Share on other sites

>Постановка задачи дважды идиотична. Во-первых, входящий трафик по определению нельзя шейпить

Это риторика. А она у всех разная. Шейпингом я называю любое ограничение трафика, что соответствует нормам языка.

Я прекрасно понимаю, что нельзя сделать очередь на входе, да она мне там и ненужна. Простое обрезание устроит.

 

>Во-вторых, входящий трафик по определению не имеет маркировки

Как выясняется - имеет. Например если применить action ipt.

Share this post


Link to post
Share on other sites
>Во-вторых, входящий трафик по определению не имеет маркировки

Как выясняется - имеет. Например если применить action ipt.

это подмена понятий. Даже если применить action ipt, tc в ingress не увидит этих маркировок.
Edited by voron

Share this post


Link to post
Share on other sites

А если входящий трафик уже промаркирован ToS/DSCP?

Тогда фильтры tc в состоянии проматчить пакеты сами.

Edited by voron

Share this post


Link to post
Share on other sites

Таким образом, разумная постановка задачи звучит так: policing входящего трафика в соответствии с ToS/DSCP.

 

>Постановка задачи дважды идиотична. Во-первых, входящий трафик по определению нельзя шейпить

Это риторика. А она у всех разная. Шейпингом я называю любое ограничение трафика, что соответствует нормам языка.

Я прекрасно понимаю, что нельзя сделать очередь на входе, да она мне там и ненужна. Простое обрезание устроит.

Это не риторика, а техническая терминология, которой следует придерживаться, если вы хотите, чтобы вас понимали другие. Есть четкие определения shaping и policing, давайте не будем их смешивать. http://www.cisco.com/en/US/tech/tk543/tk54...0800a3a25.shtml
Edited by photon

Share this post


Link to post
Share on other sites

Это трактовка Cisco. А вот правильная:

http://tools.ietf.org/html/rfc2475#section-2.3.3.3

2.3.3.3 Shapers

 

 

Shapers delay some or all of the packets in a traffic stream in order

to bring the stream into compliance with a traffic profile. A shaper

usually has a finite-size buffer, and packets may be discarded if

there is not sufficient buffer space to hold the delayed packets.

mirred + ifb + скажем HTB + bfifo прекрасно подпадают под это описание.

 

 

Share this post


Link to post
Share on other sites

Это трактовка Cisco. А вот правильная:

Не вижу какой-либо существенной разницы, там тоже речь идет о том, что shapers и droppers -- это разные вещи. Топикстартер не хочет использовать псевдоустройства для буферизации, что уже говорит о policing, а не shaping.

Edited by photon

Share this post


Link to post
Share on other sites
Note that a dropper

can be implemented as a special case of a shaper by setting the

shaper buffer size to zero (or a few) packets.

Т.е. дроппер по сути шейпер с нулевым буфером. Термин полисинг - исключительно Cisco-вский термин.

И вы все таки утверждаете, что входящий траффик нельзя шейпить, где такое написано?

Share this post


Link to post
Share on other sites

На самом деле, трафик идущий от абонента при известной(довольно большой, если абонентов нужно различать) ловкости можно шейпить на исходящем интерфейсе маршрутизатора.

В этот момент все маркеры iptables доступны.

 

Share this post


Link to post
Share on other sites

Policing -- это термин из теории очередей, а не цисковский. В любом случае шейпинг сам по себе немыслим без очереди, отправляющей трафик куда-либо, будь то очередь исходящего интерфейса или псевдоустройства. Входящий трафик приходит сам из внешнего источника, на источник нельзя повлиять, можно либо принять его пакеты, либо отбросить. Контролировать задержку можно только у принятого и отправляемого (пересылаемого) куда-либо трафика. Если RX-буфер не переполняется, входящий трафик принимается и буферизуется в очереди псевдоустройства, то он все равно потом куда-то отправляется через некий исходящий интерфейс.

Edited by photon

Share this post


Link to post
Share on other sites
Тогда собрать траффик с исходов(egress) через mirred в ifb и там шейпить.

Без псевдоинтерфейсов (типа ifb) здесь никак...

Попробую обьяснить почему мне не подходит идея псевдоинтерфейса:

Управлять трафиком мне нужно на NAS. Т.е. 500-900 абонентов = 500-900 фильтров.

Что бы не строить длинный список фильтров на одном интерфейсе, я шейпы вешаю непосредственно на PPP интерфейсы. Тут пропадает необходимость в фильтрах. Но если использовать псевдоинтерфейс то придется заворачивать в него трафик от всех абонентов. А значит придется фильтровать каждый шейп (каждого абонента) отдельно. У меня это список из 500-900 фильтров = тормоза.

Возможно я неверно понимаю идею ifb ? Может на каждый PPP можно и нужно создавать свой IFB ?

Edited by Ivan Rostovikov

Share this post


Link to post
Share on other sites

RX так же шейпится, как и TX. Очереди можно создавать и там и там. Если создавать "полисинг" - но очередь ставится равной нулю.

 

Если ставить шейпер ДО узкого места, это вообще архитектурно неправильно, но если очень хочется - можно дропами и задержками подстраивать используемую полосу. На входящий траффик повлиять можно, если у протокола есть congestion control. А у большинства он есть.

 

А шейпить на входящем интерфейсе иногда надо. Например если я хочу, чтоб на ppp юзеров уходило в сумме не больше 1 Мбит.

 

Тогда собрать траффик с исходов(egress) через mirred в ifb и там шейпить.

Без псевдоинтерфейсов (типа ifb) здесь никак...

Попробую обьяснить почему мне не подходит идея псевдоинтерфейса:

Управлять трафиком мне нужно на NAS. Т.е. 500-900 абонентов = 500-900 фильтров.

Что бы не строить длинный список фильтров на одном интерфейсе, я шейпы вешаю непосредственно на PPP интерфейсы. Тут пропадает необходимость в фильтрах. Но если использовать псевдоинтерфейс то придется заворачивать в него трафик от всех абонентов. А значит придется фильтровать каждый шейп (каждого абонента) отдельно. У меня это список из 500-900 фильтров = тормоза.

Возможно я неверно понимаю идею ifb ? Может на каждый PPP можно и нужно создавать свой IFB ?

У меня сделано по другому.

На ppp стоит mirred на ifb0, и заодно пакет маркируется (в моем случае костыль - skbedit priority)

 

filter add dev $2 parent ffff: protocol ip prio 10 u32 \

match u32 0 0 flowid 1:1 \

action skbedit priority 0x${lowid} pipe \

action mirred egress redirect dev ifb0"

 

На ifb0 создано дерево, корень скажем 100 Мбит, и на каждый ppp интерфейс - класс с бендвичем равным бендвичу юзерского аплоада... ну и очередь (qdisc).

$TC qdisc add dev ifb0 root handle 1: htb default 1000

 

$TC class add dev ifb0 parent 1:0 classid 1:1 htb rate 100Mbit ceil 100Mbit quantum 1600

 

$TC filter add dev ifb0 parent 1:0 prio 1000 protocol ip u32 match ip dst 0.0.0.0/0 classid 1:131

$TC filter add dev ifb0 protocol ip pref 32 parent 1: handle 1 flow map key priority baseclass 1:64

 

...

echo "class add dev ifb0 classid 1:${id} parent 1:0 htb rate ${rate}bit quantum 1600"

...

echo "qdisc add dev ifb0 parent 1:${id} handle ${id}: bfifo limit ${buffer}"

Где-то так

Share this post


Link to post
Share on other sites
Тогда собрать траффик с исходов(egress) через mirred в ifb и там шейпить.

Без псевдоинтерфейсов (типа ifb) здесь никак...

Попробую обьяснить почему мне не подходит идея псевдоинтерфейса:

Управлять трафиком мне нужно на NAS. Т.е. 500-900 абонентов = 500-900 фильтров.

Что бы не строить длинный список фильтров на одном интерфейсе, я шейпы вешаю непосредственно на PPP интерфейсы. Тут пропадает необходимость в фильтрах. Но если использовать псевдоинтерфейс то придется заворачивать в него трафик от всех абонентов. А значит придется фильтровать каждый шейп (каждого абонента) отдельно. У меня это список из 500-900 фильтров = тормоза.

Возможно я неверно понимаю идею ifb ? Может на каждый PPP можно и нужно создавать свой IFB ?

если все правильно настроить, оверхэд будет небольшим (а то и вообще никаким). 500-900 это не так много. по крайней мере когда я перевесил шейперы с ppp на ifb, то за счет некоторой оптимизации даже выиграл ресурсов. при чем трафик в сторону ppp я тоже перевесил на тот же самый ifb. это дает возможность ограничивать, например, отдельновзятый tx+rx.

Share this post


Link to post
Share on other sites

так всё таки имеет ли смысл переводить юзерский аплоад на ifb, дабы подровнять им скорость и потешить им чсв или всё таки оставить tc ingress policy?

 

ЗЫ. у меня тупой нат, вход от юзеров - на одном интерфейсе, потому дерево tc filter u32 hash

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this