Сеть
 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот тебе как должно быть полность с использованием 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/.

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

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

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

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

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

1) на эту тему есть такая очередь, называется SFQ -- Stohastic Fairness Queue. Её задача состоит как раз таки в том, чтобы делить канал поровну, не допуская его "забивания" каким-нибудь одним сеансом.
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/ . У меня периодически возникают мысли заняться переводом, потом забиваю -- свою документацию никак не хватает времени перевести на русский (:))

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

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

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

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

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

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

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

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

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

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

lcat Уже не :) Изначально -- потому что WRR активно и очень удобно юзается на кошках. Аналог в линухе был, да вот уже не используется, как я понял. Пока что есть верианты htb/cbq, но у меня -- только у меня пока что -- они не дают нужного результата. Как закончу тесты, скину результаты.

У меня сетьвот как работает, есть несколько ip которым можно лазить в некоторой городской сети со скоростью 16-128Kb/s.
Есть еще и несколько ip которые могут лазить как в городской сети так и в инете (скорость 4-8Kb/s).
Все это дело функционирует с помошью iptables и htb, хотья я когда анализировал как все это работает выходило так что iptables както не так пакеты маркирует, но всеже
работает все, как я и задумывал.
Вроде ситуация похожа на ту что нужно Mozgoved.

HTB нашел, уже изучаю. А вот как с помощью iptables это сделать пока найти не могу. Может пару примеров дадите?

Единственное, зачем данной ситуации нужны iptables -- это маркировать пакеты (-j MARK) или менять поле приоритета (-j TOS, -j DSCP). Маркированные пакеты можно заворачивать либо через ip rule, либо через tc filter -- смотря что надо. В случае TOS || DSCP ты определяешь приоритет обслуживания пакетов. Я предпочитаю обходиться без iptables (лишний cs, на мой взгляд, если фильтрация не нужна) и явно через tc filter .. u32 закидывать в нужные классы. Т.о. проблемой остаётся лишь взаимодействие классов -- какую queue discipline выбрать и с какими параметрами использовать. Тут можно сказать два слова про queue disciplines.

На интерфейсах в линухе висят т.н. очереди. Очередь -- это нечто, куда приходят и откуда уходят пакеты. По умолчанию на всех интерфейсах висят очереди pfifo_fast. Как и следует из названия, FIFO -- первым пришёл, первым ушёл. Просто, без изысков.

Далее, очередей есть больше, чем один тип. Есть очереди бесклассовые и классовые. Первые (как pfifo_fast) просто висят на интерфейсе и занимаются приёмом/отправкой (enqueueing/dequeueing). Вторые -- классовые -- могут нести от нуля до k дочерних классов, формирующих дерево. В качестве листьев на таком дереве можно подвешивать также бесклассовые очереди.

Классы занимаются тем же, что и бесклассовые очереди -- принимают (в данном случае -- от родительского узла), отдают (дочерним узлам, если есть), по пути оперируя пропускной способностью, очерёдностью пакетов (больных и ветеранов -- без очереди) а также _взаимодействуя_ с соседними классами (bounded/isolated в классах CBQ -- идти строем или по одному). По классам траффик раскидывается родительскими узлами с помощью фильтров (tc filter). Эти фильтры могут работать как на основании полей ip-хидера (откуда куда как и т.п.), так и на основании другой информации (например, -j MARK от iptables).

Итого, задача твоя сводится к построению:

1. корень -- классовая очередь, CBQ или HTB
2. корневой класс -- который будет рулить дочерними, изображая из себя весь канал
3а. класс беспредельщиков -- те, кто будут жрать без очереди до 80% канала
3б. класс лимиты -- те, кто будут жрать, пока не придут беспредельщики и не завинтят лимите гайки
4. листья на классах -- SFQ, как обычно

+ механизм, как раскидывать по классам, т.е. фильтры, например, по адресам источников или их макам.

Дальше надо подумать, какие параметры какой очереди подойдут. В данном случае явно напрашивается CBQ с её bounded для 3а и 3б, и нужно сформулировать условия приоритезации для них.

Как дойдут руки, напишу скрипт -- просто сейчас утаптываю SNMPd в дистриб, потому мозг не про то думает :)) Доутопчу, добавлю и такую задачку, а скрипт кину сюда.

ihc :)

Ну тут мега тема развернулась :)

Вот притяну домой второй комп с работы, поставлю пингвина и начну мучать htb и iptables.

Конечно Мега!!! Потому как решает мега задачи! :-))

ihc Время появилось скриптик набросать? :-)

Отвлёкся :)) Накидал скриптик, который отрисовывает графики скорости на интерфейсах, как какти или mrtg, но _без_ использования перла, пхп, rrdtools, snmp (вот не заживил пока) и так далее. Скоро туда же довешу графики скорости по realms, т.е., например, из такой-то сетки в такую-то (iproute2 рулит!). Вот только что снятый пример со вполне живого DSL-сервера на базе RAD:

http://rad.peet.spb.ru/files/horror21.png
http://rad.peet.spb.ru/files/horror22.png

Скорости маленькие, но не суть -- кстати, видна работа HTB, ограничивающая клиента в 64Kbit, причём вполне корректно. Вот дочешу, сделаю пакет, чтоб можно было и отдельно юзать, и сяду подумаю :) Не обещаю, но сегодня-завтра за это примусь. Просто один, а дел много

ihc
а чтож ты использовал? (как не скрипты)

скрипты на sh + awk требуют sh + awk; если сравнить с php или perl -- выгода в размере очевидна :) Как в смысле самих скриптов (хотя тут перл может поспорить), так и в смысле интерпретаторов (а тут все просто за бортом). А cgi пускается встроенным в busybox httpd.

Итак, некоторые размышления на тему поставленной выше задачи. Напомню вкратце: есть два класса юзеров, одни "лимитчики", которые до прихода "пацанов" берут весь канал, после чего только 20% его. Для приведённого решения надо заранее знать:

1) пропускную способность канала (bandwidth, стандартные единицы)
2) средний размер пакета (лучше сделать некую репрезентативную выборку) (avpkt, байты)

Итого. Создаём очередь:
Далее, вешаем корневой класс (так рекомендуют)
Канал описали, теперь вешаем "лимитчиков":
Так мы определили класс, который отъедает весь канал (100Mbit) с приоритетом (prio) 5 и может делиться своей полосой с другими классами, не забирая себе от них (bounded). Дальше "пацаны":
Т.е. отдали 80Мбит, но с приоритетом 1, сказали забирать полосу у других, не отдавая самому (isolated). Как навесить фильтры, чтобы раскидывать траффик -- см. выше. Надо не забывать, что очереди вешаются на исходящий траффик, т.е. должны быть на интерфейсе к клиенту.

Таким образом, при нагрузке от обоих классов получаем, что 80% отъедят "пацаны", а всё, что останется -- "лимитчики". Тут есть тонкость в том, что последние при отсутствии первых будут иметь весь канал, в то время как первые будут железно иметь 80Мбит в любых условиях -- это немного не то, что требовалось, но при наличии большего количества "лимитчиков" по сравнению с "пацанами" это покатит вполне.

Последнее -- это результат некоторых размышлений, ещё не тестировал, и не скажу, насколько хорошо сработает.

ihc
по поводу prio, хотел узнать, там они в порядке уменьшения действует? тоесть prio 1 выше по приоритету чем prio 2?

Из man:/tc-cbq То есть, таки да.