1. 150 клиентов - я взял в среднем, так как количество их увеличиваеться, тоесть есть вероятность, что через пол-года уже будет 250 клиентов. Вопрос: как быть с распределением параметра RATE для всех подклассов, если общий канал останеться тем же, прийдетсья вручную править значение RATE в файле каждого клиента... уменьшая его, или есть альтернатива?
Можно просто поставить его заранее очень низким и всё. Ведь в задаче (договоре) не говорится о гарантированной скорости. Можно хоть
1Kbit поставить.
При свободном канале скорость будет подниматься вплоть до
CEIL.
2. Создавать eth0-2:2001, eth0-2:2002, eth0-2:2003, eth0-2:2004, eth0-2:2005, eth0-2:2006 .... eth0-2:2150 как-то неудобно, есть ли возможность генерирования автоматически нужного количество файлов, с задаными подклассами, айпишками и всеми нужными параметрами, или все таки надо будет вручную добавлять n-нное количество файликов?
Автоматически - возможно и есть, но я такого решения не знаю. Всегда можно написать специализированный скрипт. Причем скрипт может работать как с
htb.init, так и напрямую с
tc.
3. Можно ли для файла, к примеру, eth0-2:2001 задать следующие:
...
RULE=192.168.0.1 192.168.0.2 192.168.0.3 192.168.0.4 192.168.0.5
Тоесть, чтоб в RULE одного из под-классов основного под-класса попали данные айпишки, чтобы не создавать на каждую ip пять файлов eth0-x:xyyy. Я так понимаю, 1Мбит будет распределяться между теми айпишками в произвольном порядке.
Нет, такой синтаксис неверен. Можно писать несколько правил:
...
CEIL=1Mbit
LEAF=sfq
....
RULE=192.168.0.1
RULE=192.168.0.2
RULE=192.168.1.0/24
- в класс будут попадать пакеты, идущие к хостам
192.168.0.1,
192.168.0.2 и всей подсети
192.168.1.1-254.
Однако ты прав в том, что при этом 1МБит будет
равномерно (а не произвольно - спасибо
LEAF=sfq) распределяться между
всеми этими хостами, а не для каждого в отдельности.
приметка: классовость начинаетсья с двойки? почему нельзя задать первый класс eth0-1:2001? и обязательно ли идентификатор подклассовости должен начинаться с :2001, тоесть вариант для первого клиента eth0-1:1 будет совершенно неверным?... (я так понимаю, что eth0-1:2001 - это как бы рут-класс, потому и с eth0-2:2001 начинаеться)
Зри в хелп внутри скрипта
htb.init - там описан принцип именования файлов. В кратце формат таков:
<device>-<parent_class_id>:<class_id>.<comment>
<device> - имя интерфейса;
<class_id> - числовой идентификатор того класса, который описывается этим файлом;
<parent_class_id> - числовой идентификатор класса-предка;
<comment> - комментарий.
Числовые идентификаторы задаются в шестнадцатиричной системе исчисления, но без ведущего спецификатора этой системы (например 45AE вместо 0x45AE). Идентификаторы двухбайтовые (4 шестнадцатиричных цифры). В htb.init говорится, что идентификаторы могут быть в диапазоне от 0x2 до 0xFFFF.
Вариант
eth0-1 будет неверным потому что идентфикатор 1 не разрешен.
Вариант
eth0-2:3 будет вполне нормальным.
В примерах выше я выбрал
eth0-2:2001 исходя из следующих соображений:
1. 2 - наименьший разрешенный идентификатор
2. пользователей 150 - значит нам нужно как минимум 3 цифры, чтобы красиво их именовать. (можно использовать
eth-2:YYY)
3. а вдруг потом еще где-то понадобиться по-другому ограничить тех же пользователей? а эти красивые идентификаторы (YYY) уже будут заняты. Поэтому я решил добавить еще ведущую цифру, совпадающую с идентификатором корневого класса (получилось
eth-2:2YYY).
То есть это просто конвенция именования и более ничего. Можно было именовать последовательно без привязки идентификаторов классов к IPшникам.
Каково действие параметра BURST, что-то по аналогии МТУ ?
и актуально ли использовать параметр peakrate?
[/size]
BURST - это уже тонкая настройка, определяет максимальное количество данных, которое может передать один класс до того, как htb попытается обслужить другой класс. При использовании
htb.init можно не задавать - вычисляется автоматически.
Про peakrate ничего не могу сказать - не пользовался... (сделал cat htb.init | grep peakrate - пусто)... ты вообще о чем?
<----pong<----pong<----pong<----pong<----pong<----pong<----pong<----pong<----pong<----pong<----pong<----pong<----pong<----pong<----pong<----pong