Ivan Rostovikov Опубликовано 20 октября, 2009 · Жалоба Такой вопрос: Необходимо шейпить входящий на интерфейс маркированый трафик. Как выяснилось маркеры iptables не доступны в дисциплине ingress. А жаль... Как еще можно отфильтровать по маркерам входящий трафик, чтоб все это зашейпить в рамках одного интефейса. (без использования псевдоинтерфейсов) ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 20 октября, 2009 · Жалоба tc filter с матчем по нужным байтам пакета. Но это будет не шейпер, а полисер. Входящий шейпер работает до iptables (http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png), поэтому маркеры iptables ничем не помогут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 20 октября, 2009 · Жалоба вот как раз в тему http://marc.info/?l=linux-netdev&m=125...1806138&w=2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 20 октября, 2009 · Жалоба 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" ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 20 октября, 2009 · Жалоба 2Ivan Rostovikov А какое правило iptables вы использовали для маркирования? че такое "ipt action" ? http://lists.netfilter.org/pipermail/netfi...ary/010179.html как пример 2DemYaN я так понимаю, ТС хочет маркать трафик iptables'ами и на основании марков шейпить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 20 октября, 2009 (изменено) · Жалоба Необходимо шейпить входящий на интерфейс маркированый трафик. Постановка задачи дважды идиотична. Во-первых, входящий трафик по определению нельзя шейпить, можно лишь ограничивать его пакетрейт путем отбрасывания пакетов. Во-вторых, входящий трафик по определению не имеет маркировки, поскольку маркировка iptables имеет смысл только внутри адресного пространства данного ядра ОС и не передается между машинами, т.к. не соответствует какому-либо полю внутри передаваемого пакета. Изменено 20 октября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 20 октября, 2009 · Жалоба photon - можно шейпить, ifb Может иметь, например ToS/DSCP, хотя не факт, что автор именно это имеет ввиду. По человечески можно будет маркировать наверное в 2.6.33 через skbedit (патч не вошел в 2.6.32, похоже) Но пока, если в вашем дистрибуте работает action ipt - то можно и так Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 20 октября, 2009 (изменено) · Жалоба Использование IFB/IMQ -- это копирование входящего трафика на псевдоустройство. Применение дисциплины очереди к такому трафику не гарантирует сохранности данных и точности в получаемой полосе пропускания, нельзя вносить слишком большие задержки, т.к. переполнится rx-буфер. Поэтому в любом случае это получится не нормальный shaping, а policing. Изменено 20 октября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 20 октября, 2009 · Жалоба Да, копирование, т.к. в Линуксе не задумывались очереди на входе интерфейса. Не переполнится. Я применяю (обьемы 40 мбит и карта реалтек) с достаточно большими буферами, и кучей классов, и ничего не переполняется. Задержки тоже можно вносить по собственному усмотрению. Работает так же как и на исходе. Конечно рассчитывать ограничить траффик с точностью 100% от провайдера сильно не стоит, но при грамотном подходе подровнять вполне можно. Хотя запас прийдется оставлять и решение неидеально, но значительно лучше, чем совсем ничего. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 20 октября, 2009 · Жалоба Но пока, если в вашем дистрибуте работает action ipt - то можно и так Я так понимаю, ТС хочет маркать iptables'ами с хитрыми матчами, которые нельзя сделать в tc, и на основании этих марков - шейпать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 20 октября, 2009 · Жалоба Тогда собрать траффик с исходов(egress) через mirred в ifb и там шейпить. Без псевдоинтерфейсов (типа ifb) здесь никак... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 21 октября, 2009 · Жалоба >Постановка задачи дважды идиотична. Во-первых, входящий трафик по определению нельзя шейпить Это риторика. А она у всех разная. Шейпингом я называю любое ограничение трафика, что соответствует нормам языка. Я прекрасно понимаю, что нельзя сделать очередь на входе, да она мне там и ненужна. Простое обрезание устроит. >Во-вторых, входящий трафик по определению не имеет маркировки Как выясняется - имеет. Например если применить action ipt. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 21 октября, 2009 (изменено) · Жалоба >Во-вторых, входящий трафик по определению не имеет маркировкиКак выясняется - имеет. Например если применить action ipt. это подмена понятий. Даже если применить action ipt, tc в ingress не увидит этих маркировок. Изменено 21 октября, 2009 пользователем voron Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azlozello Опубликовано 22 октября, 2009 · Жалоба А если входящий трафик уже промаркирован ToS/DSCP? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 22 октября, 2009 (изменено) · Жалоба А если входящий трафик уже промаркирован ToS/DSCP? Тогда фильтры tc в состоянии проматчить пакеты сами. Изменено 22 октября, 2009 пользователем voron Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 22 октября, 2009 (изменено) · Жалоба Таким образом, разумная постановка задачи звучит так: policing входящего трафика в соответствии с ToS/DSCP. >Постановка задачи дважды идиотична. Во-первых, входящий трафик по определению нельзя шейпитьЭто риторика. А она у всех разная. Шейпингом я называю любое ограничение трафика, что соответствует нормам языка. Я прекрасно понимаю, что нельзя сделать очередь на входе, да она мне там и ненужна. Простое обрезание устроит. Это не риторика, а техническая терминология, которой следует придерживаться, если вы хотите, чтобы вас понимали другие. Есть четкие определения shaping и policing, давайте не будем их смешивать. http://www.cisco.com/en/US/tech/tk543/tk54...0800a3a25.shtml Изменено 22 октября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 22 октября, 2009 · Жалоба Это трактовка 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 прекрасно подпадают под это описание. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 22 октября, 2009 (изменено) · Жалоба Это трактовка Cisco. А вот правильная: Не вижу какой-либо существенной разницы, там тоже речь идет о том, что shapers и droppers -- это разные вещи. Топикстартер не хочет использовать псевдоустройства для буферизации, что уже говорит о policing, а не shaping. Изменено 22 октября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 22 октября, 2009 · Жалоба 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-вский термин.И вы все таки утверждаете, что входящий траффик нельзя шейпить, где такое написано? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
inkelyad Опубликовано 22 октября, 2009 · Жалоба На самом деле, трафик идущий от абонента при известной(довольно большой, если абонентов нужно различать) ловкости можно шейпить на исходящем интерфейсе маршрутизатора. В этот момент все маркеры iptables доступны. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 22 октября, 2009 (изменено) · Жалоба Policing -- это термин из теории очередей, а не цисковский. В любом случае шейпинг сам по себе немыслим без очереди, отправляющей трафик куда-либо, будь то очередь исходящего интерфейса или псевдоустройства. Входящий трафик приходит сам из внешнего источника, на источник нельзя повлиять, можно либо принять его пакеты, либо отбросить. Контролировать задержку можно только у принятого и отправляемого (пересылаемого) куда-либо трафика. Если RX-буфер не переполняется, входящий трафик принимается и буферизуется в очереди псевдоустройства, то он все равно потом куда-то отправляется через некий исходящий интерфейс. Изменено 22 октября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 22 октября, 2009 (изменено) · Жалоба Тогда собрать траффик с исходов(egress) через mirred в ifb и там шейпить.Без псевдоинтерфейсов (типа ifb) здесь никак... Попробую обьяснить почему мне не подходит идея псевдоинтерфейса:Управлять трафиком мне нужно на NAS. Т.е. 500-900 абонентов = 500-900 фильтров. Что бы не строить длинный список фильтров на одном интерфейсе, я шейпы вешаю непосредственно на PPP интерфейсы. Тут пропадает необходимость в фильтрах. Но если использовать псевдоинтерфейс то придется заворачивать в него трафик от всех абонентов. А значит придется фильтровать каждый шейп (каждого абонента) отдельно. У меня это список из 500-900 фильтров = тормоза. Возможно я неверно понимаю идею ifb ? Может на каждый PPP можно и нужно создавать свой IFB ? Изменено 22 октября, 2009 пользователем Ivan Rostovikov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 22 октября, 2009 · Жалоба 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}" Где-то так Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
desperado Опубликовано 22 октября, 2009 · Жалоба Тогда собрать траффик с исходов(egress) через mirred в ifb и там шейпить.Без псевдоинтерфейсов (типа ifb) здесь никак... Попробую обьяснить почему мне не подходит идея псевдоинтерфейса:Управлять трафиком мне нужно на NAS. Т.е. 500-900 абонентов = 500-900 фильтров. Что бы не строить длинный список фильтров на одном интерфейсе, я шейпы вешаю непосредственно на PPP интерфейсы. Тут пропадает необходимость в фильтрах. Но если использовать псевдоинтерфейс то придется заворачивать в него трафик от всех абонентов. А значит придется фильтровать каждый шейп (каждого абонента) отдельно. У меня это список из 500-900 фильтров = тормоза. Возможно я неверно понимаю идею ifb ? Может на каждый PPP можно и нужно создавать свой IFB ? если все правильно настроить, оверхэд будет небольшим (а то и вообще никаким). 500-900 это не так много. по крайней мере когда я перевесил шейперы с ppp на ifb, то за счет некоторой оптимизации даже выиграл ресурсов. при чем трафик в сторону ppp я тоже перевесил на тот же самый ifb. это дает возможность ограничивать, например, отдельновзятый tx+rx. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 22 октября, 2009 · Жалоба так всё таки имеет ли смысл переводить юзерский аплоад на ifb, дабы подровнять им скорость и потешить им чсв или всё таки оставить tc ingress policy? ЗЫ. у меня тупой нат, вход от юзеров - на одном интерфейсе, потому дерево tc filter u32 hash Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...