Приоритеты для входящего трафика

[Nvc]

Есть 3 компьютера - роутер под Linux и 2 рабочих. Есть канал в интернет (11,5 Кбайт/с) на роутере. Т.к. канал анлим, на том же роутере круглосуточно работает wget, edonkey и другие нужные вещи - не платить же деньги даром :).

Интернет на интерфейсе ppp0, 1 компьютер включен в eth0 (usb wireless), другй - в eth2 (обычная сетевая плата). Задача в том, чтобы закачка на роутере не мешала работе на 2-х компьютерах.

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

[Roman Ivanov]

Есть 3 компьютера - роутер под Linux и 2 рабочих. Есть канал в интернет (11,5 Кбайт/с) на роутере. Т.к. канал анлим, на том же роутере круглосуточно работает wget, edonkey и другие нужные вещи - не платить же деньги даром :).

Интернет на интерфейсе ppp0, 1 компьютер включен в eth0 (usb wireless),  другй - в eth2 (обычная сетевая плата). Задача в том, чтобы закачка на роутере не мешала работе на 2-х компьютерах.

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

 

Задача решается только выше, у прова.

Ибо шейпится ВЫХОДЯЩИЙ траффик.

Это как-бы правило ;)

[Nvc]

Roman Ivanov, де нет, не решается. Откуда провайдеру знать, что траффик идет на 192.168.0.1, а не на 10.10.19.1? Для провайдера весь траффик идет на 195.5.52.*, а приоритеты надо ставить локально.

Вот если бы создать какой-то виртуальный интерфейс int0, чтобы траффик шел по пути провайдер -> ppp0 -> int0 -> (eth0/eth2), тогда на int0 можно было бы шейпить исходящий траффик. Только как это сделать? Ибо покупать еще один компьютер только в роли шейпера как-то неправильно.

[Roman Ivanov]

Речь о ВХОДЯЩЕМ траффике.

Т.е. после того, как он зайдет в ваше соеденение (11.5) - делать шейпинг Вам на него поздно. Вот Upload шейпить - да. Но не download.

 

В данном случае - можно просить сделать приоритеты.

В большинстве случаев wget и edonkey это не порт 80,22,25,110,143.

А для работы - нужны они.

[Nvc]

А как же тогда провайдер может разделять канал между несколькими пользователями?

[zASSAz]

Речь о ВХОДЯЩЕМ траффике.

Т.е. после того, как он зайдет в ваше соеденение (11.5) - делать шейпинг Вам на него поздно. Вот Upload шейпить - да. Но не download.

 

И upload и download ... по приоритетам. HTB под линуx подойдет.

Уже более двух лет все работает и не шуршит. 2 скрипта один вешается на исходящий интервейс второй на входящий. так как эта штука умеет шейпить только траффик уxодящий с интейфейса. Пакеты метим iptables по меткам загоняем в HTB. одна проблема iptables не умеет метить траффик типа p2p но есть патч 'patch-o-matic-ng' ;)

Вот и все воощем Удачи.

[Shiva]

Nvc, а толку-то, надо у горлышка шейпить, а не наоборот, подумайте сами.

[Nvc]

Shiva, на столько я понял, принцип работы шейпинга - удаление части пакетов до тех пор, пока скорость их передачи не достигнет нужной. Соответственно не должно быть разницы, где их удалять. Главное, чтобы пакеты не добрались к получателю и не было отправлено подтверждение о получении.

[Guest]

Nvc, а толку-то, надо у горлышка шейпить, а не наоборот, подумайте сами.

Shtob gorlyshko propuskalo to shto bolee nuzhno.

[Shiva]

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

[Roman Ivanov]

Shiva, на столько я понял, принцип работы шейпинга - удаление части пакетов до тех пор, пока скорость их передачи не достигнет нужной. Соответственно не должно быть разницы, где их удалять. Главное, чтобы пакеты не добрались к получателю и не было отправлено подтверждение о получении.

 

Нет не прав.

Shaping - это задержка пакета перед его отправкой.

Если задержка большая - DROP.

 

Представь это как длинную, трубу. Если с одной стороны (провайдер) туда залили дерьма, то с другой что-либо делать поздно.

 

На саом деле, большинство программ не посылают следующий запрос, порка не получили предыдущий. Поэтому, на нормальных каналах (5Mbit и более) можно шейпить клиентов на выходе из твоего рутера - и это поможет.

 

Но на канале 11.5 - лучше просить провайдера.

[Fog]

неморочте человеку голову - провайдера просить. а если это укртелеком или связинвест от которого просить толку мало. человек хочет у СЕБЯ шейпить трафик.

 

начнем с того что РОУТЕР ЗНАЕТ адрес источника и ПОЛУЧАТЕЛЯ. в тотм же самом CBQ или HTB есть пример как шейпить в обе стороны. трудно почитать и поставить одну единственную !!!ЗАПЯТУЮ!!!.

 

в принципе все сводится к ограничаниям для качки роутера. хотя если чесно мне непонятко как ограничить качку на САМ роутер. получается это повлияет на всех.

как выход выделить отдельную машину под линукс (типа пенек1) и шейпить трафик в CBQ для этой машины. стоимость пенка1 мало что значит а вот зато как удобно будет.

[Nvc]

хотя если чесно мне непонятко как ограничить качку на САМ роутер

В том то и дело. Надо промежуточный интерфейс. Только еще один компьютер ставить не очень хочется.

[qoute]провайдера просить. а если это укртелеком

Именно Укртелеком. И ничого они делать точно не будут. Да и не смогут, т.к. они не знают, что мне ограничивать...

[Fog]

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

 

второй вариант создать соединение типа мост. там создается интерфейс ВИРТУАЛЬНЫЙ ну и само собой присуствует езернет. тока как это тебе поможет еще непонял.

 

тоесть создать интерфейс както непроблема ifconfig add тока как завернуть на него трафик тока КОНКРЕТНЫХ прог (wget emule) нетрогая остальной трафик (ppp0 eth0 eth1) мне неочень понятно. вот если решиш эту задачу то обязательно напиши.

[Roman Ivanov]

> начнем с того что РОУТЕР ЗНАЕТ адрес источника и ПОЛУЧАТЕЛЯ. в тотм

> же самом CBQ или HTB есть пример как шейпить в обе стороны. трудно

> почитать и поставить одну единственную !!!ЗАПЯТУЮ!!!.

Принципы шейпинга вам чужды ;)

В том что шейпится ВЫХОДЯЩИЙ траффик есть логика.

Допустим я ограничиваю клиенту траффик на 1Mbit. Сам рутер при этом может (и получает) для этого клиента БОЛЬШЕ. Просто часть - дропается. Но то, что дропается УЖЕ пришло, и заняло входной канал. Так как большинство трафика - tcp, а не udp, то получается более менее прилично. Однако, при этом сопоставимость MTU, размера tcp пакета и скорости канала должна отличатся в разы.

Так как MTU ~ 1500, то адекватный шейпинг будет при 1Mbit канале.

Качественный - при 2+Mbit канале. При этом желательно ВСЕГДА иметь свободным не менее 10% (при небольших (2-10Mbit)) скоростях.

Для канала в 115Kbit нужно уменьшат MTU. И то может не помочь.

Накладные расходы на packet overhead сожрут половину.

 

К примеру, если я сделаю png flood, то шейпить его у получателя - глупо. он ВСЕ РАВНО ЗАБЬЕТ ВЕСЬ ВХОДНОЙ КАНАЛ у него.

 

> в принципе все сводится к ограничаниям для качки роутера. хотя

> если чесно мне непонятко как ограничить качку на САМ роутер.

> получается это повлияет на всех.

linux & IMQ. Но год назад у меня такое висло. От IMQ в результате отказался.

 

> как выход выделить отдельную машину под линукс (типа пенек1) и

> шейпить трафик в CBQ для этой машины. стоимость пенка1 мало что

> значит а вот зато как удобно будет.

Шумелка под боком + электро + пожаробезопасность + доп звено.

[Nvc]

Спасибо, пока что информации достаточно. Надо пробывать настраивать ограничение с помощю IMQ.

Roman Ivanov, дело в том, что мне не нужно какое-то advanced ограничение. Единственная задача - распределение канала для комфортной работы. А т.к. интернет для работы пользуется явно не круглосуточно, а в худшем случае 10% суток, то пропажа 5% пропускной способности канала не есть критичной.

[Fog]

Roman Ivanov начнем с того что принципы шейпинга я знаю и сам пользую. то что шейпится выходящий трафик я тоже знаю.

Вы лучше человеку скажите что делать по существу вопроса а не доказывать то чего сами незнаете (использовать не означает что знаеш, водить мащину совершенно не означает что знать как она устроена.).

могу даже спецально для ВАС пояснить что пакеты при шейпинге НЕ ДРОПАЮТСЯ. могу еще расказать что при шейпинге замеряется время между пакетами и соотвественно коректируется их подтверждение. а пингом канал незабьеш просто время ответа будет измерятся секундами. на любой входящий пакет нужно подтверждение (не считая атаки и злонамерения) что и делает CBQ отправляя пакет подтверждения с задержкой.

человеку ненадо шейпить сам канал 115кбит. ему надо шейпить трафик на проги.

что разве трудно подумать что для интерфейса ppp0 (на котором сидит модем) интерфейс eth0 будет уже ПОЛУЧАТЕЛЕМ. вот пример из CBQ дла тех кто непонял:

<code>

#

# +---------+ 192.168.1.1

# BACKBONE -----eth0-| linux |-eth1------*-[client]

# +---------+

#

# Imagine you want to shape traffic from backbone to the client to 28Kbit

# and traffic in the opposite direction to 128Kbit. You need to setup CBQ

# on both eth0 and eth1 interfaces, thus you need two config files:

#

# cbq-028.backbone-client

# --------------------------------------------------------------------------

# DEVICE=eth1,10Mbit,1Mbit

# RATE=28Kbit

# WEIGHT=2Kbit

# PRIO=5

# RULE=192.168.1.1

# --------------------------------------------------------------------------

#

# cbq-128.client-backbone

# --------------------------------------------------------------------------

# DEVICE=eth0,10Mbit,1Mbit

# RATE=128Kbit

# WEIGHT=10Kbit

# PRIO=5

# RULE=192.168.1.1,

# --------------------------------------------------------------------------

#

# Pay attention to comma "," in the RULE field - it denotes source address!

 

</code>

[Roman Ivanov]

> начнем с того что принципы шейпинга я знаю и сам пользую. то что

> шейпится выходящий трафик я тоже знаю.

Я рад за Вас.

 

> могу даже спецально для ВАС пояснить что пакеты при шейпинге НЕ

> ДРОПАЮТСЯ.

Ась? хммм...

Уверен?

 

> а пингом канал незабьеш просто время ответа будет измерятся

> секундами.

ping -f -s 3000 xx.xxx.xxx

 

валит большинство.

[Shiva]

Roman Ivanov, хаватит, раз люди не поняли, не надо.

 

Fog, так помоги человеку, что ты с Романом припераешься?

[repa]

Все в чем-то, да правы.

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

 

Шейпер с минимальным набором функций, конечно не поможет. Нужно смотреть конкретный инструмент.

 

В варианте приоритизации и шейпинга прекрасно работает ALTQ на FreeBSD.

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

 

В итоге: используйте приоритизацию.

[Shiva]

repa,

В итоге: используйте приоритизацию.

Её точно также надо настраивать у прова :) У клиента нету никакого толка.

[Shiva]

Ну или ставить своё оборудование до сужения канала, т.е. у прова на колокатион.

[Fog]

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

Roman Ivanov я же написал что если неиспользовать злонамеренные методы забития канала то все работает. тоесть на езернете например без проблем можно отдавать трафик в 1кб или 3кб. даже при МТУ 1500. просто на графике закачки сам график будет пилой. тоесть принял пакет а потом долго ждет.

[repa]

Еще раз перечитал, задачу.

Более точно нужно сделать следующее.

1. Измерить средний трафик в сторону провайдера когда идут закачки с роутера и ничего более.

2. Поставить шейпер для всего исходящего трафика на скорость полученую в п.1.

3. Выставить приоритет на трафик в сторону провайдера с простых тачек.

В этой схеме запросный канал принудительно заужается. Увеличение времени отправление роутером подтверждения при закачках, когда пошел трафик с клиентских тачек, позволит уменьшить скорость отправления с ftp серверов.

 

В этой схеме есть минусы.

1. Канал в сторону оператора будет заужен для всего трафика. И в случае когда качают с клиентских машин будет не совсем хорошо.

2. Эта схема не настолько эффективна как применение приоритизации на стороне оператора. FTP сервера будут освобождать канал для трафика в сторону клиентских тачек не сразу. Точно сказать не могу, но думаю где-то это будет приблизительно 20 сек.

 

Можно будет почесать еще за левым ухом, и что-нибудь сделать первым минусом, но только после того как опробуете в деле этот вариант.

[Shiva]

Fog,

я же написал что если неиспользовать злонамеренные методы забития канала

А edonkey и FTP это что?