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

[Eugine Kosenko]

Да, как я и думал.

http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.qdisc.filters.html

Если нет желания учить tc, то рекомендуют использовать критерий fw,
опираясь на маркеры iptables, а не критерий u32.

2014-11-18 14:38 GMT+00:00 Eugine Kosenko <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>:
>
>> On 17.11.2014 21:10, Eugine Kosenko wrote:
>>
>>> 2014-11-17 13:55 GMT+02:00, alexei на taf.ru <alexei на taf.ru>:
>>>
>>>> Хм... Я не понял что вас еще надо от u32 помимо того, что уже есть в
>>>> указанной доке.
>>>>
>>>
>>> Конкретно интересует именно содержимое раздела 12.1.3:
>>>
>>> http://lartc.org/howto/lartc.adv-filter.html#AEN1327
>>>
>>> Именно в этом разделе описаны те самые специфичные селекторы, которые
>>> меня интересует. Увы, раздел по большей части состоит из
>>> процитированных мной FIXME. То есть, такая таблица есть, но вынесена в
>>> отдельный файл, ссылки на который в тексте не дается. Хотя я очень
>>> хотел бы увидеть именно эту таблицу, даже если она на польском языке.
>>>
>>> Отдельные примеры дают только общее представление. Меня, например,
>>> интересует, можно ли понятным образом проанализировать метки пакета
>>> после прохождения iptables? Я не силен в RFC и боюсь наделать ошибки,
>>> вычисляя смещения и двоичные значения полей.
>>>
>>> Ну и вообще, как мне кажется, документация должна быть полной, не так ли?
>>>
>>
>> Нет желание рассказать конечную цель, которую вы пытаетесь достигнуть
>> чтением документации ?
>>
>> Я для u32 пользуюсь такой штукой как shapercontrol - всё просто и понятно.
>>
>> Да, на последних ядрах u32 сломан для i586. Имейте это ввиду.
>>
>>
>>
>>
>> _______________________________________________
>> community mailing list
>> community на lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/community
>>
>
>
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/community/attachments/20141118/e3a75c20/attachment.html>