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

[Ivan Rostovikov]

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

 

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

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

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

 

[voron]

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

[DemYaN]

вот как раз в тему http://marc.info/?l=linux-netdev&m=125...1806138&w=2

[Ivan Rostovikov]

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

[voron]

2Ivan Rostovikov

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

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

http://lists.netfilter.org/pipermail/netfi...ary/010179.html как пример

 

2DemYaN

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

 

[photon]

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

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

Edited October 20, 2009 by photon

[nuclearcat]

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

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

 

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

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

[photon]

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

Edited October 20, 2009 by photon

[nuclearcat]

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

 

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

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

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

[voron]

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

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

[nuclearcat]

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

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

[Ivan Rostovikov]

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

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

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

 

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

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

[voron]

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

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

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

[azlozello]

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

[voron]

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

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

Edited October 22, 2009 by voron

[photon]

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

 

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

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

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

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

[nuclearcat]

Это трактовка 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 прекрасно подпадают под это описание.

 

 

[photon]

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

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

Edited October 22, 2009 by photon

[nuclearcat]

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-вский термин.

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

[inkelyad]

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

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

 

[photon]

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

Edited October 22, 2009 by photon

[Ivan Rostovikov]

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

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

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

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

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

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

Edited October 22, 2009 by Ivan Rostovikov

[nuclearcat]

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

Где-то так

[desperado]

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

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

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

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

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

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

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

[Max P]

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

 

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