Перейти к содержимому
Калькуляторы

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

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

 

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2Ivan Rostovikov

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

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

 

2DemYaN

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем voron

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Изменено пользователем Ivan Rostovikov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Где-то так

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.