[Comm] Расширенный синтаксис классификатора u32 для iproute2 tc filter
Anton Farygin
rider на altlinux.com
Ср Ноя 19 14:11:32 MSK 2014
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
>
Подробная информация о списке рассылки community