Re: [Comm] Расширенный синтаксис классификатора u32 для iproute2 tc filter

[Anton Farygin <rider@altlinux.com>]

On 18.11.2014 18:41, Eugine Kosenko wrote:
> Да, как я и думал.
>
> http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.qdisc.filters.html
>
> Если нет желания учить tc, то рекомендуют использовать критерий fw,
> опираясь на маркеры iptables, а не критерий u32.

Конечно, я на предыдущее письмо и хотел ответить в таком же макаре - 
зачем u32 для системы из двух хостов ?

iptables в этом плане намного удобнее.


>
> 2014-11-18 14:38 GMT+00:00 Eugine Kosenko <eugine.kosenko@gmail.com
> <mailto:eugine.kosenko@gmail.com>>:
>
>     В целом я описал проблему тут:
>
>     http://lists.altlinux.org/pipermail/community/2014-November/683031.html
>
>     В общем, испытываю все прелести разделенного узкого канала.
>
>     Кроме описанных бед есть еще несколько. Например, на обеих машинах
>     стоят менеджеры закачек: на Linux (роутере) это aria2, на Windows
>     (клиенте) ---- некий Download Manager. Менеджеры закачек ведут себя
>     настолько агрессивно, что во время их работы невозможно даже открыть
>     страницу в браузере. Очень часто не удается добраться до ftp при
>     выполнении apt-get.
>
>     Можно, конечно же, подрезать скорость пакетной закачки средствами
>     самих менеджеров. Но тогда они не используют всю ширину канала, если
>     никто не работает в браузере.
>
>     Трафик из браузера можно назвать "интерактивным" и обеспечить ему
>     приоритет обслуживания и гарантированную скорость. Но это не совсем
>     та интерактивность, которую предлагают обеспечить, например, тут:
>
>     http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.interactive-prio.html
>
>     Дело в том, что закачки почти всегда идут через HTTP, изредка через
>     FTP. Такой трафик неразличим по порту назначения. Важен не порт, а
>     процесс, который является источником трафика. Например, в упомянутом
>     мною Download Master есть возоможность автоматически снижать
>     скорость закачки при обнаружении активности браузера. Но у aria и
>     apt-get ведь такой возможности нет.
>
>     Более абстрактно могу поставить задачу так. Есть два типа приложений
>     --- "интерактивные", которым нужно первоочередное обслуживание и
>     гарантированная полоса, и "пакетные", которым неважна очередность и
>     скорость, но при отсутствии "интерактивного" трафика им должна быть
>     предоставлена вся максимально возможная полоса. При этом в каждом
>     классе приоритеты, в принципе, неважны, достаточно любой "честной"
>     дисциплины типа той же SFQ. И еще неважно, на какой из машин
>     генерируется трафик --- на роутере или на клиенте. И та и та станция
>     генерируют трафик обоих типов (хотя иногда хочется предоставить
>     больше возможностей моему трафику на роутере под Linux, то есть,
>     выделить его в промежуточный класс с определенными гарантиями
>     обслуживания).
>
>     Пока что вижу решение в том, чтобы дисциплинарно направить весь
>     "интерактивный" трафик на squid-прокси, а ему предоставить
>     необходимые гарантии обслуживания (в перспективе кроме squid можно
>     направить туда же еще пару "критичных" приложений типа того же apt).
>     Однако в целом это решение выглядит криво. Во-первых, на уровне
>     iptables придется выделять пакеты в цепочке OUTPUT по признаку
>     pid-owner, где должен быть подставлен pid прокси (а их ведь
>     несколько). Кроме того, это означает искусственную донастройку
>     iptables в момент старта squid в обход etcnet, что тоже некрасиво.
>     Во-вторых, непонятно, что с этими выделенными пакетами делать ---
>     маркировать или направить на виртуальный "интерфейс для
>     балансировки". С интерфейсом примерно понятно, но такое решение
>     кажется слишком сложным и включает, как мне кажется, ненужный
>     форвардинг. А вот можно ли при балансировке классифицировать пакеты
>     по поставленым ранее меткам --- это я и хотел выяснить.
>
>     Ну и вообще смотрю, что можно еще сделать в этой ситуации.
>
>
>     2014-11-18 10:50 GMT+00:00 Anton Farygin <rider@altlinux.com
>     <mailto:rider@altlinux.com>>:
>
>         On 17.11.2014 21:10, Eugine Kosenko wrote:
>
>             2014-11-17 13:55 GMT+02:00, alexei@taf.ru
>             <mailto:alexei@taf.ru> <alexei@taf.ru <mailto:alexei@taf.ru>>:
>
>                 Хм... Я не понял что вас еще надо от u32 помимо того,
>                 что уже есть в
>                 указанной доке.
>
>
>             Конкретно интересует именно содержимое раздела 12.1.3:
>
>             http://lartc.org/howto/lartc.__adv-filter.html#AEN1327
>             <http://lartc.org/howto/lartc.adv-filter.html#AEN1327>
>
>             Именно в этом разделе описаны те самые специфичные
>             селекторы, которые
>             меня интересует. Увы, раздел по большей части состоит из
>             процитированных мной FIXME. То есть, такая таблица есть, но
>             вынесена в
>             отдельный файл, ссылки на который в тексте не дается. Хотя я
>             очень
>             хотел бы увидеть именно эту таблицу, даже если она на
>             польском языке.
>
>             Отдельные примеры дают только общее представление. Меня,
>             например,
>             интересует, можно ли понятным образом проанализировать метки
>             пакета
>             после прохождения iptables? Я не силен в RFC и боюсь
>             наделать ошибки,
>             вычисляя смещения и двоичные значения полей.
>
>             Ну и вообще, как мне кажется, документация должна быть
>             полной, не так ли?
>
>
>         Нет желание рассказать конечную цель, которую вы пытаетесь
>         достигнуть чтением документации ?
>
>         Я для u32 пользуюсь такой штукой как shapercontrol - всё просто
>         и понятно.
>
>         Да, на последних ядрах u32 сломан для i586. Имейте это ввиду.
>
>
>
>
>         _________________________________________________
>         community mailing list
>         community@lists.altlinux.org <mailto:community@lists.altlinux.org>
>         https://lists.altlinux.org/__mailman/listinfo/community
>         <https://lists.altlinux.org/mailman/listinfo/community>
>
>
>
>
>
> _______________________________________________
> community mailing list
> community@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/community
>