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...