Jump to content
Калькуляторы

tc, imq vs ifb и все-такое

Добрый! Сразу расставлю точки над i: в linux новичок, поэтому большая просьба выражаться яснее и если вы используете спец. лексику, то используйте ее английские аналоги, чтобы я всегда мог загуглить и понять, о чем идет речь вообще. А теперь по существу вопроса.

Что есть: системный блок с debian, 2 сетевых интерфейса, на этом деле настроена базовая маршрутизация и nat. Внешний интрефейс - eth0 - пусть будет 10.30.139.2/24, внутренний интерфейс - eth1 - пусть будет 192.168.1.2/24. Есть канал, равный 10мб в сек. Есть 10 пользователей.

Чего хочется: чтобы он динамически делился, между всеми пользователями и чтобы все получали поровну. Прочитав мануалы с этих сайтов tldp.org/HOWTO/Traffic-Control-HOWTO/index.html и www.lartc.org/lartc.html и www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html и еще парочку, я примерно понял, как решение выглядит, но потом появился ряд вопросов:

Во-первых, вся мощь tc утилины под linux используется только для исходящего трафика, входящий трафик мы не можем шейпить(shaping), все, что мы можем делать с ним - это откидывать(policing, согласно http://www.lartc.org), но я-то хочу не просто, чтобы 10 пользователей получали по 1мб. А чтобы, если канал используется двумя пользователями, то каждый бы получал по 5мб в среднем, если используется тремя, то по 3.3 и тд. Я думаю, вы поняли идею. А достичь этого просто при помощи отбрасывания пакетов мы не сможем. Начал искать и нашел такие вещи, как IMQ и IFB, но читая статьи про них и споры людей, понял, что это вроде бы как работает, но не является правильным использование этих "костылей". Тогда мне в голову пришла простая идея, ради которой и пишется сей опус, а что если шейпить входящий трафик(Internet -> eth0 -> внутренние процессы NAT и routing -> eth1 -> внутренняя сеть), но не на eth0, а на eth1?! Ведь для tc он будет считаться исходящим, ведь приходит он из внутренних процессов и отправляется в сеть, хотя для нас это, по факту, входяший трафик, верно? Или мои рассуждения неверны на корню?

Во-вторых, насколько все-таки неверно использование IMQ и IFB? Правда ли это такие костыли, которых лучше избегать?

Share this post


Link to post
Share on other sites

Без разницы, что на eth1 шейпить, что отзеркаленный на ifb с eth0 - суть не меняет,

это трафик который пришёл от удалённой стороны, с ним можно только что-то сделать в надежде, что удалённый

хост приостановит передачу.

 

В принципе то, что описано приемлемо работает, но нужно запас оставлять в корневом классе,

процентов 10-15 от реальной полосы, чтобы не упираться в шейпер/полисер вышестоящего оператора.

Share this post


Link to post
Share on other sites

Без разницы, что на eth1 шейпить, что отзеркаленный на ifb с eth0 - суть не меняет,

это трафик который пришёл от удалённой стороны, с ним можно только что-то сделать в надежде, что удалённый

хост приостановит передачу.

 

В принципе то, что описано приемлемо работает, но нужно запас оставлять в корневом классе,

процентов 10-15 от реальной полосы, чтобы не упираться в шейпер/полисер вышестоящего оператора.

Спасибо за ответ! Насколько я помню и исходя из того, что я понял из QoS, если передающая сторона видит, что нет подтверждения от принимающей стороны того, что пакеты были доставлены, она, передающая сторона, должна уменьшить скорость передачи и повторить передачу недошедших пакетов. В squid это прекрасно работает. Должно работать и в tc. Есть, например, youtube и человек качает фильм, при этом полностью вычерпывает весь свой трафик, если мы настроим все правильно, то входящие пакеты, из-за отсутсвия места в очереди, будут отбрасываться, youtube будет снижать скорость и мы получаем то, что нужно. Верно же?

Share this post


Link to post
Share on other sites

его хочется: чтобы он динамически делился, между всеми пользователями и чтобы все получали поровну. Прочитав мануалы с этих сайтов tldp.org/HOWTO/Traffic-Control-HOWTO/index.html и www.lartc.org/lartc.html и www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html и еще парочку, я примерно понял, как решение выглядит, но потом появился ряд вопросов:

 

Добрый день! Того, что Вы описали, можно достигнуть, используя дисциплины очереди SFQ/FQ/QFQ и иже с ними, то есть любую Fair Queue дисциплину, которая распределяет ресурсы примерно равными частями между потоками. Так как вы отталкиваетесь от адреса источника (клиентский адрес), то надо будет повесить flow-фильтр с хешированием по адресу источника (на интерфейсе который смотрит в интернет) и адресу назначения (на интерфейсе, который смотрит в сторону клиентской сети).

Edited by evil-man

Share this post


Link to post
Share on other sites
если передающая сторона видит, что нет подтверждения от принимающей стороны того, что пакеты были доставлены, она, передающая сторона, должна уменьшить скорость передачи и повторить передачу недошедших пакетов.

Да, работает неплохо. Я в пору введения безлимов, когда цена каждого метра была поистине конской

таким образом удерживал приемлемый интернет в условиях почти круглосуточной "полки".

 

Самым критичным была именно подушка - запас по полосе, подбиралось экспереминтально,

и ещё было важно чтобы вышестоящий оператор ни в коем случае не шейпил, а полисил,

с большим бёрстом. Чтобы у него не образовывалась неподконтрольная очередь входящих пакетов.

Тогда вообще на ура работать будет.

 

Если применять сейчас то возможно будет проблема с торрентами по UDP,

они довольно агрессивно работают. Можно попытаться дропать такой трафик по сигнатурам, там было за что зацепится

на этапе установки соединения, но как с этим протоколом сейчас дела обстоят не знаю, возможно его уже обфусцировали.

Share this post


Link to post
Share on other sites

Если я правильно понял суть вопроса - старая проблема скрещивания NAT и shaper. Для того и используются либо псевдо-устройства, типа ifb, либо маркировка трафика до NATа для шейпера индивидуально для каждого абонента.

Share this post


Link to post
Share on other sites

vop

Нет, у человека нет тоннелей или любых других виртуальных интерфейсов. Ему ничто не мешает шейпить на физических eth0 и eth1.

 

Нужные примеры для реализации честного деления между абонентами есть в lartc, там 10 строк получится(HTB+SFQ и настройка rate/ceil).

Share this post


Link to post
Share on other sites
там 10 строк получится(HTB+SFQ и настройка rate/ceil).

На полосах в сотни мегабит SFQ плохо придерживала торренты,

я использовал bfifo с большим буфером.

Share this post


Link to post
Share on other sites

vopНет, у человека нет тоннелей или любых других виртуальных интерфейсов. Ему ничто не мешает шейпить на физических eth0 и eth1.

 

У него есть NAT, и внешний интерфейс, на котором после ната трафик по абонентам не разделить. Или нет?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this