HTB и шейпинг инета

tc qdisc add dev eth0 root handle 1: htb

#class for local net
tc class add dev eth0 parent 1: classid 1:1 htb prio 10 rate 1000mbit burst 200k

#class for inet traffic
tc class add dev eth0 parent 1: classid 1:2 htb prio 5 rate 980kbit burst 1500b

#assign local traffic to class 1:1
tc f add dev eth0 protocol ip parent 1: prio 1 u32 match ip src 192.168.0.0/16 flowid 1:1


#assign net 192.168.1.0/24 to class 1:11
tc f add dev eth0 protocol ip parent 1: prio 5 u32 match ip dst 192.168.1.0/24 flowid 1:11

и т.д. в том же духе
с параметром default у меня не получилось :( потому что мне непонятно как сделать обратный match на сеть. но этот вариант выглядит лучше, потому что локальный трафик которого может быть в разы больше чем инет трафика, поэтому его лучше классифицировать первым.

tc class add dev eth0 parent 1:2 classid 1:11 htb prio 5 rate 128kbit ceil 900kbit

вот еще, забыл :)

А вот параметр burst обязательно таким указывать, оно его само адекватно не подстроит?

А вот у инет класса rate 980kbit, а у дочернего ceil 900kbit, специально сделано поменьше, мне тож так делать?

А у меня с интерфейса eth0 исходят в локалку пакеты с src ip из, как минимум, 4х подсетей, это навскидку, а так даже плюс несколько отдельных хостов, и выборка локал покетов становится неприятным занятием. А в чем техническая трудность дефолтного класса, кроме производительности? Потому как, судя по htb мануалу, все, что не удовлетворилось на фильтрах, идет по дефолту без проблем.

И да, на класс 100Мбит нужно навешивать дисциплину обработки очереди?
Аля:
tc class add dev eth0 parent 1: classid 1:1 htb prio 10 rate 1000mbit burst 200k
tc qdisc add dev eth0 parent 1:1 handle 10: sfq perturb 10

Сумма rate дочерних классов не должна превышать rate родителя.
Если вы хотите сделать из своей машины роутер, тогда не вижу смысла ставить 100 мбит в корне(хотя если у вас такой жирный канал...).
Если вы будете использовать роутер и как "домашний" комп, то тогда ставьте 100 мбит и размечайте трафик.
Насчет параметра burst и сburst - незнаю, в одних доках говорится что оно само расчитывается, в других что нужно ручками для лучшей интерактивности.
Насчет дефолтного класса - все что неразметилось в него, нормально работает. В нем постоянно какой-то траф сидит, ну думаю это от binda или еще какого-то трафика для роутера.

> И да, на класс 100Мбит нужно навешивать дисциплину обработки очереди?

Ну это по желанию. по хорошему конечно надо бы заменить дефолтный pfifo на sfq или что-то подобное. в моем примере класс на гигабит, у меня гигабитная карточка стоит.

> Сумма rate дочерних классов не должна превышать rate родителя.

на сколько я помню из доков - это не обязательное условие.

> А в чем техническая трудность дефолтного класса, кроме производительности?

а производительность не в счет? пакеты туда попадут, конечно, если не будут отфильтрованы ранее. смотрите сами, куда у вас больше трафика идет, по сети или в инет. один раз прописать пусть даже пару десятков фильтров - не такая уж и большая работа, не так ли?

> А вот у инет класса rate 980kbit, а у дочернего ceil 900kbit, специально сделано поменьше, мне тож так делать?

у меня дочерних классов несколько, этот приведен для примера. выставляйте параметры согласно вашим пожеланиям. у меня был ceil 900kbit из-за нежелания отдавать даже весь свободный канал какому либо классу. я жадный :)

Насчет суммы rate дочерних классов давайте уточним. У меня например с этим небольшая проблема. Я на каждого пользователя выделяю клас. Затем к этому классу цепляю еще 4 под-класса(1-мелкие пакеты,2-HTTP,3-все что неотмаркировалось,4-торенты). Так-вот райты у меня доходят до 8000бит, приходится высчитывать квантум. Все это дело конечно скриптом высчитывается, но мне хотелось что бы ставить r2q на корень и хай htb сам все считает. Просто если сумма rate превысит ceil(когда большое кол-во людей будет в онлайне) будет свистопляска с делением трафика. Или может я что-то не так понял в htb?

Вот тут
http://www.opennet.ru/base/net/htb_saga.txt.html
я только что прочитал, что-то есть по rate vs ceil (но чувствую этот мануал для вас - баян).

В любом случае моя голова сейчас занята осмысливанием inet_rate vs 100Mbit ))

Во, вопрос про фильтры. Там написано, что фильтры прикручиваются к 1:0 и просматриваются в порядке до совпадения. Означает ли это, что я не смогу реализовать например такую фишку:
- сначала выбираем по tc filter route from internet все что с инета
- а потом, то что выбрано, расщепляем более мелко по tc filter u32 ...
или придется юзать fwmark ?

Кстати, если ip ro ad 0.0.0.0 dev ppp0 realm X, то под правило tc filter route from X будут отобраны пакеты, пришедшие с ppp0 либо вообще все пакеты (т.к. 0.0.0.0)?

> From: Andy Gorev <gorev@mail333.com> > Date: Mon, 13 Mar 2003 13:01:37 +0000 (UTC) > Subject: Сага по ограничению трафика в Linux при помощи htb.

вероятно, это не имеет (почти) никакого отношения к текущему коду htb в ядре. 2003 год, епт. чтобы понять как этот код поменялся надо либо качать старые сорцы ядра и самому делать диффы и смотреть, либо отследить списки рассылки kernel developers на предмет изменений в htb.

> Во, вопрос про фильтры. Там написано, что фильтры прикручиваются к 1:0 и просматриваются в порядке до совпадения. Означает ли это, что я не смогу реализовать например такую фишку: - сначала выбираем по tc filter route from internet все что с инета - а потом, то что выбрано, расщепляем более мелко по tc filter u32 ... или придется юзать fwmark ?

Я бы тоже хотел, чтоб так могло реализовываться, но так просто не получается.

<IMHO>Как я понял, фильтр может быть вызван только дисциплиной, но не классом. Т.е. если пакет в классе htb был отфильтрован либо по дефолту попал в какой-то класс, то дальше уже нельзя прикрутить фильтр. Но ничто не мешает к классу подцепить ДИСЦИПЛИНУ htb и к ней уже прицепить фильтры и классы, осуществляющие более тонкую нарезку трафика</IMHO>

Просто если сумма rate превысит ceil(когда большое кол-во людей будет в онлайне) будет свистопляска с делением трафика. Или может я что-то не так понял в htb?

http://luxik.cdi.cz/~devik/qos/htb/htbfaq.htm

What if sum of child rates is greater than parent rate ?

Then interesting things can happen. Total rate delivered by children can be higher that parent's rate (thus its rate is not respected). However when sum of actual child rates are under parent's rate then borrowing will occur like in regular case.

Так, я тут сомневаюсь. Я правильно понял что проблема с локальным трафиком заключается в том, что вот допустим его очень много, и если первыми идут фильтры на инет трафик, то пока локальный трафик проходит эти фильтры какбы все тормозится?

> если первыми идут фильтры на инет трафик, то пока локальный трафик проходит эти фильтры какбы все тормозится

да

>>я только что прочитал, что-то есть по rate vs ceil (но чувствую этот мануал для вас - баян).

Нет не баян, я тоже как и вы хочу нормально разобраться с трафиком. Просто от того как я могу делить трафик зависит моя должность и моя работа. Я вот пришел к такому выводу, что всем докам по которым мы делим трафик больше 5 лет, ведь к этому времени в tc произошли разные модификации, поэтому происходят разногласия. Отслеживать выпуск изменений на английском языке, невижу смысла - я просто незнаю его и изучать его пока нет времени. Поэтому все что говорил - основано только на личном опыте.

Судя по
http://lartc.org/
http://luxik.cdi.cz/~devik/qos/htb/
можно сильно сомневаться, что в tc с тех пор произошли сильные модификации)) Даже ман по tc-filter все еще не написали.

Вобщем, демо версия моего шейпера работает не совсем так, как того хотелось бы.(((
Если на одном компе идет закачка и канал полностью забит, на другом включить торрент, то скорость вроде как делиться пополам, но на 1ом компе все равно почему-то побольше, и к тому же скорость пляшет не слабо.
А самое главное что серфинг парализовался (по крайней мере в случае когда кто-то качает), странички в этом на других компах открываются архи долго.
Буду думать дальше...

>А самое главное что серфинг парализовался (по крайней мере в случае когда кто-то качает), странички в этом на других компах открываются

И вам советую http://ipp2p.org. Все нормально метит.