goonman Опубликовано 5 октября, 2011 Подскажите, возможно ли на Mikrotik настроить шепинг трафика на основе хешей как в Linux. Особо плотно не курил всякие варианты у микротика, так как не было серьезных задач. Поставили задачу реализовать подобное на микротике для шейпинга 15-20 сетей с маской /24. Вот и думаю как что-то подобное сделать, дабы минимизировать кол-во правил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 5 октября, 2011 PCQ делается в несколько команд. Канал делится поровну между всеми, кто качает в данный момент. Как показывает опыт, у такой схемы минимум недовольных :) Если нужны неодинаковые скорости, тогда сложнее. Придётся сначала маркировать трафик по ip-адресам, потом распихивать по разным очередям для тарифных скоростей, потом сводить в одну очередь для интерфейса. Тут и утилизация суммарной полосы будет хуже, и загрузка процессора выше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
goonman Опубликовано 6 октября, 2011 PCQ не подходит, мне не нужно делить канал поровну. В этом нет смысла. Маркировать пакеты для каждого апи... хм, мне кажется что там будет нагрузка не меньше чем цепочка правил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 6 октября, 2011 Маркировать пакеты для каждого апи... хм, мне кажется что там будет нагрузка не меньше чем цепочка правил. Естественно, для маркировки первых пакетов надо использовать address-lists, для остальных - connection-marks. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mnemoid Опубликовано 10 октября, 2011 Маркировать пакеты для каждого апи... хм, мне кажется что там будет нагрузка не меньше чем цепочка правил. Естественно, для маркировки первых пакетов надо использовать address-lists, для остальных - connection-marks. Вариант: 1. Использовать Queue Tree на входящем и исходящем интерфейсе. (не Simple Queue) 2. Пакеты маркировать в IP/Firewall/Mangle 3. Для уменьшения количества просматриваемых правил в Mangle, желательно сгруппировать подсети на несколько блоков. К примеру, сначала просматривается chain со списоком подсетей /24, а затем jump на chain соотвествующей подсети. Там уже просматривается каждый ip или подсеть соответствующей очереди. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
goonman Опубликовано 12 октября, 2011 (изменено) 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mnemoid Опубликовано 23 октября, 2011 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, а затем оптимизируйте по приведенной выше схеме. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...