Сеть

[oxide]

Допустим у меня есть сеть в которой 10 пользователей. Ещё у меня есть DSL подключение со скоростью 1 мег. Теперь главное :) Как мне каждому пользователи назначить определённую скорось, например, одному 256 кб, другому 128 кб, третьему 64 кб и тд. Что для этого нужно? Какой софт, какое железо.
P.S. на сервере у меня *nix.
Заранее спасибою

[archy]

Тебе нужен iptables, так что man его =)

[oxide]

iptables это хорошо конечно, но реально ли разобратся в нём новечку. Хотя ладно разберусь :) а как насчёт железа? Или хватит 1 компа под сервер и пару трой ку хабов?

[oxide]

Не непонял я пока в как это в iptables сделать. Покажите пожалуйста на конкретном примере, какой файл редактировать, если надо.

[ihc]

в двух словах: iptables пока оставь :)) В смысле, с его помощью можно сделать маскарад, но не зажать траффик.

про то, как надо: допустим, надо пользователю 10.0.0.10 зажать траффик до 64Kbit

1) делаем корневую очередь на девайсе к пользователю, советую HTB

tc qdisc add dev eth0 root handle 1:0 htb

2) создаём класс, котoрый будет жать траффик

tc class add dev eth0 parent 1:0 classid 1:1 htb rate 64Kbit

3) вешаем очередь SFQ за классом, чтобы зажатый траффик был более-менее равномерен

tc qdisc add dev eth0 parent 1:1 sfq perturb 10

4) создаём фильтр, который будет кидать траффик в класс

tc filter add dev eth0 parent 1:0 protocol ip prio 16 u32 match ip dst 10.0.0.10 flowid 1:1

всё. Смотрим статистику.


tc -s qdisc show
tc -s class show dev eth0
tc filter show dev eth0


кстати, в том дистре, который я сегодня объявлял это бы выглядело так:


!
shaper rule test
address 10.0.0.10
bound 64Kbit
!
ip shaper ethernet 0
shaper rule test
!


а вообще http://lartc.org

[oxide]

Ну ihc огромное тебе мегаспасибо. Будем пробовать. :)

[lcat]

Вот тебе как должно быть полность с использованием htb, sfq ( отдыхает :), не обижайтесь )
#!/bin/bash
# Describe env
TC=/sbin/tc
# use bandwidth 1mbps
# ROOT rule
$TC qdisc add dev eth0 root handle 1:0 htb default 2
# sub class of root
$TC class add dev eth0 parent 1:0 classid 1:1 htb rate 1mbps ceil 1mbps

$TC class add dev eth0 parent 1:1 classid 1:12 htb rate 256kbps ceil 512kbps
$TC class add dev eth0 parent 1:1 classid 1:13 htb rate 128kbps ceil 512kbps
$TC class add dev eth0 parent 1:1 classid 1:14 htb rate 64kbps ceil 512kbps


$TC filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.2 flowid 1:12
$TC filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.3 flowid 1:13
$TC filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.4 flowid 1:14

# это для создание pfifo каналов вместо по умолчание fast_fifo, если память не изменяет :)
$TC qdisc add dev eth0 parent 1:12 handle 50:0 pfifo limit 5
$TC qdisc add dev eth0 parent 1:13 handle 51:0 pfifo limit 5
$TC qdisc add dev eth0 parent 1:14 handle 52:0 pfifo limit 5

# default param for htb, сюда весь трафик который не фильтруеться
$TC class add dev eth0 parent 1:1 classid 1:2 htb rate 1kbps ceil 1kbps
$TC qdisc add dev eth0 parent 1:2 handle 100:0 pfifo limit 5

rate и ceil очень удобные параментры, в данной конфигурации к примеру если никто не сидит в сети то чел
у которого rate 64kbps ceil 512kbps, скорость подымиться до 512килобит :). Вообщем сам решай тут и читай доки само собой.
Вот еще хороший сайт по THB http://www.docum.org/docum.org/docs/.

[ihc]

Хм, вопрос, что вешать на конец класса -- sfq или pfifo -- довольно спорный. Для себя я решил остановиться на sfq, т.к. при маленьком выходе (очереди <128Kbit) уже становится заметно забивание канала, например, толстым ftp. В остaльном, такая же схема, нет? ;)

[lcat]

ihc я перепутал, sfq с чем то другим уже не всмомню :), поэтому так и написал
http://linux-ip.net/articles/Traffic-Control-HOWTO/classless-qdiscs.html тут об этом все написано, в картинках

[ihc]

Перепутал с cbq, скорее всего. Клинических испытаний эта очередь у нас, кстати, не прошла: несмотря на хорошие показатели на низких скоростях, она неспособна обрабатывать большие потоки. Да и загрузка системы с htb поменьше.

[lcat]

Да ты прав, перепутал с cbq :)
На сайте разработчика CBQ, он сам написал что htb превосходит его алгоритм. Так что про cbq можно забыть :)

[Mozgoved]

А вот такой вопрос, скажем нужно трафик раздавать по приоритетам!? Имеется введу следуещее:
1) Если у пользователей приоритет одинаковый, значить они делят трафик поровну.
2) Если приоритет высокий, значит пользователи забирают, скажем 80% от общего трафика и делят его между собой поровну.
3) И последнее, как сделать балансировку.

[ihc]

1) на эту тему есть такая очередь, называется SFQ -- Stohastic Fairness Queue. Её задача состоит как раз таки в том, чтобы делить канал поровну, не допуская его "забивания" каким-нибудь одним сеансом.

tc qdisc add dev eth0 root sfq

2) не понял, если честно (:)) Но можно посмотреть там же (см. ссылку внизу)
3) на LARTC описан способ с применением очередей типа teql (см. load sharing over multiple links), но, если честно, у меня это не заработало. Как варианты:
3.1) Сделать два маршрута с одинаковыми метриками через разные интерфейсы. Честно скажу, ни разу не пробовал
3.2) modprobe eql, а дальше как в документации к ядру: ip addr add X.X.X.X mtu YYYY dev eql и используй eql_enslave для добавления слэйвов к eql.

Так вот, почти всё описанное есть на http://lartc.org/ . У меня периодически возникают мысли заняться переводом, потом забиваю -- свою документацию никак не хватает времени перевести на русский (:))

[ihc]

Отставить баян (:)) Заработало teql. Предположим, что надо шарить линк между eth0 и eth1


modprobe sch_teql
tc qdisc add dev eth0 root teql0
tc qdisc add dev eth1 root teql0
ip link set dev teql0 up


И далее по LARTC. Не уверен, правда, что это будет лучшим выходом, чем eql, но попробовать можно.

[Mozgoved]

За ответ спасибо, есть над чем подумать! :-)

Что касается второго. Имелось введу следующее: есть обыкновенные пользователи которые делят трафик между собой поровну, в какой то момент появляется превелегированный пользователь которому должно быть выделенно 80% от общего трафика, значить остальным отанется всего 20%. При этом есть вероятность появления второго превелегированного пользователя и они делят 80% поровну между собой... То есть существуют две очереди одна для всех, другая для превелегированных пользователей. немного муторно, но уж как смог :-))

Если интересно, то есть область расматривающая СМО, то что я описывал немного похоже на "Окрашенные сети Петри". :-)

[ihc]

Похоже, не так страшен чёрт, как его малютки. Скорее всего, придётся использовать WRR -- Weighted Round Robin. Единственное, что мне что-то никак не разобраться с документацией на него (:)) Если интересно: ссылка на WRR (http://wipl-wrr.sourceforge.net/wrr.html)

[Mozgoved]

Ну что ж, почитаю. Может и разберусь, только смущает версия ядра 2.4, у меня 2.6

[ihc]

Только что проверил -- не тот WRR идёт в 2.6, а для virtual servers, это немного другое. :shuffle: Сорри, тогда или 2.4 юзать, или смотреть аналог WRR для 2.6

[Mozgoved]

Все равно спасибо! :-)
если что то нарою, отстучу. Ну и других прошу не терять активность, тема на самом деле весьма актуальна! :-)

[lcat]

Mozgoved
Я так и не понял почему ihc посоветова тебе использовать WRR(о нем первый раз слышу),
все это делаеться настроками htb, или я не прав?
Там куча параметров (prio или можно iptables ом трафик метить чтоб ему приоритет отдавать).
тема на самом деле весьма актуальна! :-)
АГА :)