Jump to content
Калькуляторы

Шейпер на хеш таблицах в Mikrotik

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

Вариант:

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

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

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

Share this post


Link to post
Share on other sites

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

Edited by goonman

Share this post


Link to post
Share on other sites

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, а затем оптимизируйте по приведенной выше схеме.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this