Сеть

[ihc]

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

[lcat]

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

[Mozgoved]

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

[ihc]

Единственное, зачем данной ситуации нужны 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 в дистриб, потому мозг не про то думает :)) Доутопчу, добавлю и такую задачку, а скрипт кину сюда.

[lcat]

ihc :)

[oxide]

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

[oxide]

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

[Mozgoved]

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

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

[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, причём вполне корректно. Вот дочешу, сделаю пакет, чтоб можно было и отдельно юзать, и сяду подумаю :) Не обещаю, но сегодня-завтра за это примусь. Просто один, а дел много

[lcat]

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

[ihc]

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

[ihc]

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

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

Итого. Создаём очередь:
tc qdisc add dev eth0 handle 1:0 root cbq avpkt 500 bandwidth 100Mbit

Далее, вешаем корневой класс (так рекомендуют)
tc class add dev eth0 parent 1:0 classid 1:1 cbq rate 100Mbit allot 1500 prio 5 bounded isolated

Канал описали, теперь вешаем "лимитчиков":
tc class add dev eth0 parent 1:1 classid 1:11 cbq rate 100Mbit allot 1500 prio 5 bounded

Так мы определили класс, который отъедает весь канал (100Mbit) с приоритетом (prio) 5 и может делиться своей полосой с другими классами, не забирая себе от них (bounded). Дальше "пацаны":
tc class add dev eth0 parent 1:1 classid 1:12 cbq rate 80Mbit allot 1500 prio 1 isolated

Т.е. отдали 80Мбит, но с приоритетом 1, сказали забирать полосу у других, не отдавая самому (isolated). Как навесить фильтры, чтобы раскидывать траффик -- см. выше. Надо не забывать, что очереди вешаются на исходящий траффик, т.е. должны быть на интерфейсе к клиенту.

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

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

[lcat]

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

[ihc]

Из man:/tc-cbq In the round-robin process, classes with the lowest priority field are tried for packets first. То есть, таки да.