[firstcalled]

Добрый! Сразу расставлю точки над 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? Правда ли это такие костыли, которых лучше избегать?

[disappointed]

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

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

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

 

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

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

[firstcalled]

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

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

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

 

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

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

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

[Ivan_83]

QoS немного из другой оперы.

[evil-man]

его хочется: чтобы он динамически делился, между всеми пользователями и чтобы все получали поровну. Прочитав мануалы с этих сайтов 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-фильтр с хешированием по адресу источника (на интерфейсе который смотрит в интернет) и адресу назначения (на интерфейсе, который смотрит в сторону клиентской сети).

Изменено 8 сентября, 2015 пользователем evil-man

[disappointed]

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

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

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

 

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

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

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

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

 

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

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

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

[vop]

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

[kayot]

vop

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

 

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

[disappointed]

там 10 строк получится(HTB+SFQ и настройка rate/ceil).

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

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

[vop]

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

 

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