[goonman]

Подскажите, возможно ли на Mikrotik настроить шепинг трафика на основе хешей как в Linux. Особо плотно не курил всякие варианты у микротика, так как не было серьезных задач. Поставили задачу реализовать подобное на микротике для шейпинга 15-20 сетей с маской /24. Вот и думаю как что-то подобное сделать, дабы минимизировать кол-во правил.

[Ilya Evseev]

PCQ делается в несколько команд.

Канал делится поровну между всеми, кто качает в данный момент.

Как показывает опыт, у такой схемы минимум недовольных :)

 

Если нужны неодинаковые скорости, тогда сложнее.

Придётся сначала маркировать трафик по ip-адресам,

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

потом сводить в одну очередь для интерфейса.

Тут и утилизация суммарной полосы будет хуже, и загрузка процессора выше.

[goonman]

PCQ не подходит, мне не нужно делить канал поровну. В этом нет смысла. Маркировать пакеты для каждого апи... хм, мне кажется что там будет нагрузка не меньше чем цепочка правил.

[Ilya Evseev]

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

Естественно, для маркировки первых пакетов надо использовать address-lists,

для остальных - connection-marks.

[Mnemoid]

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

Естественно, для маркировки первых пакетов надо использовать address-lists,

для остальных - connection-marks.

 

Вариант:

1. Использовать Queue Tree на входящем и исходящем интерфейсе. (не Simple Queue)

2. Пакеты маркировать в IP/Firewall/Mangle

3. Для уменьшения количества просматриваемых правил в Mangle, желательно сгруппировать подсети на несколько блоков. К примеру, сначала просматривается chain со списоком подсетей /24, а затем jump на chain соотвествующей подсети. Там уже просматривается каждый ip или подсеть соответствующей очереди.

[goonman]

Mnemoid, а можно пример реализации на примере трех подсетей 10.0.1.0/24, 10.0.2.0/24 и 172.17.1.0/24. Клиентам доступно три тарифа 10М, 50М, 100М. А то мне немного неясно относительно "jump на chain" и еще некоторых нюансов, или ткнуть на рабочий пример. Смотрел на wiki там много вариантов, но нечто похожего на ваше предложение я не нашел. Буду признателен за разъяснение.

Изменено 12 октября, 2011 пользователем goonman

[Mnemoid]

Mnemoid, а можно пример реализации на примере трех подсетей 10.0.1.0/24, 10.0.2.0/24 и 172.17.1.0/24. Клиентам доступно три тарифа 10М, 50М, 100М. А то мне немного неясно относительно "jump на chain" и еще некоторых нюансов, или ткнуть на рабочий пример. Смотрел на wiki там много вариантов, но нечто похожего на ваше предложение я не нашел. Буду признателен за разъяснение.

 

А вы попробуйте сами сделать свой вариант, а мы, если что - поправим. Для начала сделайте queue tree для входящего трафика на внутреннем интерфейсе. Создайте корневую очередь с общим ограничением на канал, потом создайте для каждого абонента очередь, которая в качестве родительской будет использовать корневую очередь. В абонентской очереди режете нужную скорость в зависимости от пакета.

Чтобы нужный пакет попал в нужную очередь, помечаете его в mangle. Это описывается в множестве мест в той же wiki это есть. Фишка заключается в том, что если клиентов много, в mangle приходится просматривать большое количество правил, прежде чем найдется подходящее. Так вот чтобы этого не делать, процесс просмотра разбивается на две части. Сначала просматриваются chain с правилами для определения подсети (например /24) в которой находится искомый IP. Когда нужное правило найдено, в нем выполняется действие jump на цепочку, соответствующую данной подсети. В этой цепочке уже находятся правила, которые проверяют IP только из выбранной подсети.

Таким образом, этот алгоритм является модификацией стандартного способа работы с queue tree. Реализуйте сначала рабочий queue tree, а затем оптимизируйте по приведенной выше схеме.