Сеть

archy · Отправлено: **17:20, 03-03-2005** | #2

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

oxide · Отправлено: **17:38, 03-03-2005** | #3

iptables это хорошо конечно, но реально ли разобратся в нём новечку. Хотя ладно разберусь

а как насчёт железа? Или хватит 1 компа под сервер и пару трой ку хабов?

oxide · Отправлено: **19:34, 03-03-2005** | #4

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

ihc · Отправлено: **20:46, 03-03-2005** | #5

в двух словах: 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 · Отправлено: **11:16, 04-03-2005** | #6

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

lcat · Отправлено: **14:19, 04-03-2005** | #7

Вот тебе как должно быть полность с использованием 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 · Отправлено: **15:50, 04-03-2005** | #8

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

lcat · Отправлено: **16:00, 04-03-2005** | #9

ihc я перепутал, sfq с чем то другим уже не всмомню

, поэтому так и написал
http://linux-ip.net/articles/Traffic...ss-qdiscs.html тут об этом все написано, в картинках

ihc · Отправлено: **16:10, 04-03-2005** | #10

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

lcat · Отправлено: **20:22, 05-03-2005** | #11

Да ты прав, перепутал с cbq

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

Mozgoved · Отправлено: **05:02, 09-03-2005** | #12

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

ihc · Отправлено: **13:44, 09-03-2005** | #13

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 · Отправлено: **13:53, 09-03-2005** | #14

Отставить баян (

) Заработало 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 · Отправлено: **20:28, 09-03-2005** | #15

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

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

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

ihc · Отправлено: **21:05, 09-03-2005** | #16

Похоже, не так страшен чёрт, как его малютки. Скорее всего, придётся использовать WRR -- Weighted Round Robin. Единственное, что мне что-то никак не разобраться с документацией на него (

) Если интересно: ссылка на WRR

Mozgoved · Отправлено: **22:07, 09-03-2005** | #17

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

ihc · Отправлено: **23:21, 09-03-2005** | #18

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

Сорри, тогда или 2.4 юзать, или смотреть аналог WRR для 2.6

Mozgoved · Отправлено: **23:26, 10-03-2005** | #19

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

lcat · Отправлено: **02:41, 11-03-2005** | #20

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

Цитата:

тема на самом деле весьма актуальна! :-)

АГА