Comments 50
Шаг 2. Маркировка пакетов
После этого перейдем во вкладку «Mangle» и добавим правила маркировки пакетов. Для этого жмем на «плюс» и указываем следующие параметры:
- chain — forward.
- Out. Interface — интерфейс, на котором висит Инет. В моем случае это «eth1-Wi-Fi».
- Dst. Address List — mega.nz — это имя того самого набора адресных листов с прошлого шага.
- Action — mark connection.
- New Connection Mark — MEGA.
- Passthrought — true.
- Comment — Traffic to Mega.nz.
Где соединение помеченное меткой MEGA в дальнейшем используется?
Решение хоть и рабочее, но в корне не верно. PCQ используется не для того чтобы ограничить общую скорость к/от одному хосту, а для того, чтобы равномерно распределить скорость между потоками по заданному критерию.
Соединение, помеченное данной меткой, используется в правилах с экшеном «mark packet» в разделе «mangle». Ниже эти блоки расписаны, как раз под тем, к которому ты замечание оставил.
Ясно, не заметил. Маркировка пакетов нагружает процессор маршрутизатора. Для данного примера это не существенно, а в больших сетях — да.
Совет
В RouterOS есть возможность экспорта конфигураций. Это текстовая «читабельная» информация которая показывает конфигурацию устройства. Если ты хочешь показать выполненную настройку, то можешь сделать это следующим образом. Куст /queue из моего устройства, для примера:
Совет
В RouterOS есть возможность экспорта конфигураций. Это текстовая «читабельная» информация которая показывает конфигурацию устройства. Если ты хочешь показать выполненную настройку, то можешь сделать это следующим образом. Куст /queue из моего устройства, для примера:
/queue type
add kind=pcq name=pcq_download pcq-classifier=dst-address pcq-limit=40KiB pcq-rate=4M pcq-total-limit=1600KiB
add kind=pcq name=pcq_upload pcq-classifier=src-address pcq-limit=40KiB pcq-rate=4M pcq-total-limit=1600KiB
/queue tree
add name=download packet-mark=mark_download parent=global queue=pcq_download
add name=upload packet-mark=mark_upload parent=global queue=pcq_upload
Про экспорт конфига знаю. В указанной в разделе «pps» статье есть все необходимые команды для терминала, поэтому и делал скриншоты — вдруг кому-то проще через гуй реализовать процесс.
Маркировка да, нагружает. Из практики, Mikrotik RB450G с 94 компами в онлайн успешно маркировал пакеты торрент-трафика и дропал их. При этом, нагрузка на ЦП устройства не превышала 60%.
Конкретно эта статья писалась с устройства Mikrotik RB950G-2HnD на котором висит 2 компа и телефон. Во время синхронизации маркировка пакетов поднимает используемый объем ПЦ примерно до 9-13% от общего объема в то время, как без маркировки этот показатель прыгает в пределах 5-10% при просмотре того же видео онлайн с ютуба.
Конкретно эта статья писалась с устройства Mikrotik RB950G-2HnD на котором висит 2 компа и телефон. Во время синхронизации маркировка пакетов поднимает используемый объем ПЦ примерно до 9-13% от общего объема в то время, как без маркировки этот показатель прыгает в пределах 5-10% при просмотре того же видео онлайн с ютуба.
Суть в том, что ты пытаешься «забивать гвозди плоскогубцами». Разве это нельзя сделать на простой очереди simple queue?
Конечно, может быть я что-то не так делал, на «simple queue» удавалось лишь ограничить скорость на конкретный IP-адрес, а у сервиса используется их пул.
Да, возможно, нужно использовать /queue tree. Но, для поставленной задачи не нужно использовать PCQ. Попробуй на PFIFO сделать (/queue type).
pfifo позволяет лишь размер пакетов в очереди указывать. Сомневаюсь что это есть ограничение по скорости.
Кстати, в Simple Queues во вкладке Advanced есть параметр Queue Type. Пробовал в нем выбрать существующие типы и отключить записи с вкладки Queue Type — не сработало правило. Прога выжала весь канал для синхронизации. А как только активировал обратно Queue Tree — трафик моментально стал ограничиваться.
Кстати, в Simple Queues во вкладке Advanced есть параметр Queue Type. Пробовал в нем выбрать существующие типы и отключить записи с вкладки Queue Type — не сработало правило. Прога выжала весь канал для синхронизации. А как только активировал обратно Queue Tree — трафик моментально стал ограничиваться.
Попробовал в queue tree заменить значение пункта queue с PCQ-MEGA-download на default-small — скорость также режется. У правила default-small значение kind равно pfifo.
В связи с этим удалил лишние правила из вкладки типов.
Комментарием выше писал что с типом pfifo не сработало — как оказалось, каким-то образом умудрился в правиле queue tree заменить значение поля packet marks на no-mark. Вот и не срабатывало правило, ибо не было ограничений.
Еще раз проверил нагрузку на ЦП: прыгает в пределах 18-27%.
В связи с этим удалил лишние правила из вкладки типов.
Комментарием выше писал что с типом pfifo не сработало — как оказалось, каким-то образом умудрился в правиле queue tree заменить значение поля packet marks на no-mark. Вот и не срабатывало правило, ибо не было ограничений.
Еще раз проверил нагрузку на ЦП: прыгает в пределах 18-27%.
Ну то есть получилось на PFIFO? Тогда идём дальше. Попробуй в правилах очередей указать использование не маркировки пакета, а маркировку соединения. Потести ограничение на приём и отдачу. Нужно будет добавить ещё одну маркировку для connection, а маркировки для пакетов можешь поудалять или временно выключить.
В правилах очередей можно выбрать лишь значение «Packet Marks». Настройки для маркированных пакетов не нашел. Весь раздел облазил.
Статью обновил. В предыдущей версии на выгрузку норм срабатывало, а на вход — нет. Исправил. Сколько тестил, это самый минимальный конфиг. Меньше не получилось.
Нагрузка на ЦП ~15-25% в одну сторону и ~30-42% при трафике в обе стороны на канале в 90 Мбит/с (ночью провайдер до 100 разрешает юзать) с ограничением по 25 Мбит/с в каждую сторону для выбранного пула адресов.
Нагрузка на ЦП ~15-25% в одну сторону и ~30-42% при трафике в обе стороны на канале в 90 Мбит/с (ночью провайдер до 100 разрешает юзать) с ограничением по 25 Мбит/с в каждую сторону для выбранного пула адресов.
Корректировка: модель устройства Mikrotik RB951G-2HnD
Скриншоты в jpeg… :facepalm:
Про Habrastorage в курсе?
Он вполне себе неплохо хранит PNG: https://habrastorage.org/webt/rw/dm/rq/rwdmrqfimciqkxwgku_kij96wug.png
Проблема не в Habrastorage, а в прокладке между монитором и стулом.
Проблема не в Habrastorage, а в прокладке между монитором и стулом.
Ого, грубость пошла? :)
На компе скриншоты сохранены в формате jpg. При перетаскивании drag'n'drop'ом они автоматом загружаются на ресурс, который в ответ выдает ссылку на изображение. Эта ссылка и была вставлена в тело статьи. Или тебе придраться больше не к чему, кроме как к расширению файла загруженного в облако?..
На компе скриншоты сохранены в формате jpg. При перетаскивании drag'n'drop'ом они автоматом загружаются на ресурс, который в ответ выдает ссылку на изображение. Эта ссылка и была вставлена в тело статьи. Или тебе придраться больше не к чему, кроме как к расширению файла загруженного в облако?..
Ого, грубость пошла? :)Вы первый начали грубить, перейдя неожиданно на «ты», и указывая на мою глупость, что это habrastorage себя так ведёт (якобы он сконвертировал нормальные скриншоты из PNG в JPEG):
Про Habrastorage в курсе?
При этом дальше пишете:
На компе скриншоты сохранены в формате jpgНу и причем тут тогда habrastorage, если вы скриншоты налепили в JPEG? И к чему ваш первый комментарий про habrastorage? Изначально скриншоты интерфейсов надо делать в PNG. Эх, зря вам карму плюсанул, поторопился… (upd: хотя нет, статья действительно полезная, и лично мне пригодится)
Идея хорошая, но есть ряд замечаний:
1. Оптимально для решения поставленной задачи тупо создать 4 simple queues к аггрегированным подсеткам в качестве dst-address:
31.216.144.0/23
31.216.147.0/24
89.44.168.0/24
154.53.224.0/23
Никаких деревьев не надо. Простые очереди работают быстрее.
2. Маркировать пакеты. Не так оптимально для текущей задачи, но если сильно хочется маркировать, то лучше сначала маркировать соединения, а уж потом маркировать пакеты, к ним относящиеся.
1. Оптимально для решения поставленной задачи тупо создать 4 simple queues к аггрегированным подсеткам в качестве dst-address:
31.216.144.0/23
31.216.147.0/24
89.44.168.0/24
154.53.224.0/23
Никаких деревьев не надо. Простые очереди работают быстрее.
2. Маркировать пакеты. Не так оптимально для текущей задачи, но если сильно хочется маркировать, то лучше сначала маркировать соединения, а уж потом маркировать пакеты, к ним относящиеся.
Для домашней сети с 3-мя устройствами вариант, описанный в статье, значительно лучше подходит, т.к. новые диапазоны адресов можно просто в именованный список добавить и не париться.
Количество устройств не имеет значения, равно как и место куда добавлять подсети (или, как вы говорите, диапазоны). Что в адрес-лист, что в адрес очереди.
Но спорить не буду. Задача очень простая, и решить ее можно массой способов, которые в конце все равно упираются в queue. Поэтому, оптимальнее всего писать сразу в queue.
Если есть желание новых диапазонов — сделайте автоматическое их определение по адресу хоста ;-)
Но спорить не буду. Задача очень простая, и решить ее можно массой способов, которые в конце все равно упираются в queue. Поэтому, оптимальнее всего писать сразу в queue.
Если есть желание новых диапазонов — сделайте автоматическое их определение по адресу хоста ;-)
Что касается автоматического определения IP-адресов, уже много лет юзаю скрипт с работы, где соцсети таким образом банили.
Чуть переименовав у себя скрипты с «mega.nz» на «cloud», получил такой функционал:
Таким образом, сейчас в списке находится 33 IP-адреса и микротик в состоянии «покоя» (брожу по просторам без скачивания файлов) дает нагрузку в 2-4%.
Чуть переименовав у себя скрипты с «mega.nz» на «cloud», получил такой функционал:
Скрипт автодобавления IP-адресов в список
:log info "STARTING SCAN TO CLOUD"
:put [:resolve mega.nz]
:put [:resolve mega.co.nz]
:put [:resolve eu.static.mega.co.nz]
:put [:resolve dropbox.com]
:put [:resolve d.dropbox.com]
:put [:resolve bolt.dropbox.com]
:put [:resolve dl-debug.dropbox.com]
:put [:resolve api.disk.yandex.net]
:foreach i in=[/ip dns cache all find where (name~"mega.nz" || name~"mega.co" || name~"dropbox" || name~"disk.yandex") && (type="A") ] do={
:local tmpAddress [/ip dns cache get $i address];
delay delay-time=10ms
#prevent script from using all cpu time
:if ( [/ip firewall address-list find where address=$tmpAddress] = "") do={
:local cacheName [/ip dns cache get $i name] ;
:log info ("added entry: $cacheName $tmpAddress");
/ip firewall address-list add address=$tmpAddress list=clouds comment=$cacheName;
}
}
:log info "CLOUD SCAN COMPLETE"Таким образом, сейчас в списке находится 33 IP-адреса и микротик в состоянии «покоя» (брожу по просторам без скачивания файлов) дает нагрузку в 2-4%.
Ага. И про коннекты-пакеты. Как-то так делают, чтобы роутер не ковырял каждый пакет в цепочке на соответствие правилу:
То есть, сначала соответственно правилу маркируем соединение, а потом помечаем пакеты внутри маркированного соединения. Остальной трафик идет свободно
add action=mark-connection chain=prerouting dst-address-list=mega.nz \
new-connection-mark=upload-conn passthrough=yes
add action=mark-packet chain=prerouting connection-mark=upload new-packet-mark=\
upload-pk passthrough=yes tcp-flags=""То есть, сначала соответственно правилу маркируем соединение, а потом помечаем пакеты внутри маркированного соединения. Остальной трафик идет свободно
Кстати, коль скоро лимит очень большой 25М — можно просто ограничить любые «тяжелые» соединения. Например, так: wiki.mikrotik.com/wiki/Manual:Connection_Rate
Для справки. Попробовал ограничивать скорость через `simple queue`, натравив его на маркированные пакеты и указав просматриваемый интерфейс — eth1.
Нагрузка на ЦП что при `Queue Tree`, что при `Simple Queue` одинакова от слова «совсем».
Так что разницы особой нет чем ограничивать. Единственное отличие между них в том, что в `Queue Tree` можно задать приоритет трафику.
Нагрузка на ЦП что при `Queue Tree`, что при `Simple Queue` одинакова от слова «совсем».
Так что разницы особой нет чем ограничивать. Единственное отличие между них в том, что в `Queue Tree` можно задать приоритет трафику.
В simple тоже можно и приоритет и иеррархию. Я сам скорость не измерял, т.к. разница будет ощутима либо на большом количестве правил qos, но помню, на MTCRE говорили о том, что mikrotik в новых версиях ros делает упор на механизме simple queue. Типа: «Камрады, не будьте дубами, не парьтесь с деревьями». Или как-то так.
Тем более, есть живые примеры в энторнетах, когда переводили деревья на simple queue forum.mikrotik.by/viewtopic.php?t=109
Тем более, есть живые примеры в энторнетах, когда переводили деревья на simple queue forum.mikrotik.by/viewtopic.php?t=109
А какая объективная причина использовать 2 Queue Tree, вместо 1 Simple?
Как писал выше в комментариях, во-первых, simple queue не позволяет ограничивать трафик по имени маркированных пакетов. Во-вторых, он не позволяет ограничивать трафик по диапазону из нескольких IP-адресов, а создавать новое правило для каждого диапазона с маской — глупо (у того же Mega.nz 6 диапазонов IP-адресов замечал, а облачными хранилищами несколькими пользуюсь). Вот и выйдет что у тебя выйдет не 1 Simple Queue, а 6 как минимум для каждого диапазона с выбранной маской.
Как писал выше в комментариях, во-первых, simple queue не позволяет ограничивать трафик по имени маркированных пакетов. Во-вторых, он не позволяет ограничивать трафик по диапазону из нескольких IP-адресов
Во-первых, simple queue вполне позволяет ограничивать трафик по имени маркированых пакетов. Смотрите параметр «packet-marks=». В winbox вкладка «advanced». Если у Вас не сработало, вероятно или Вы что-то сделали не так или набрели на некий баг.
Во-вторых, прямо по диапазону ограничить не даёт и tree. Для диапазонов используется маркировка пакета в firewall-mangle.
В simple queue можно легко ввести ограничение по IP или подсети. Их нужно указать в «target=» сколько угодно, через запятую в консоли. Либо в winbox кликнув справа от поля ввода на символ «стрелка вниз».
И, да, для simple queue нужно обязательно указывать target. Относительно target считается направление upload/download.
Вот и выйдет что у тебя выйдет не 1 Simple Queue, а 6 как минимум для каждого диапазона с выбранной маской.
Ничего подобного. Диапазон IP-адресов заносится единожды в address-list и по нему проводятся дальнейшие действия с маркировкой пакетов.
Метод описанный Louie с предварительным использованием «action=mark-connection» и последующей маркировкой по критерию «connection-mark=upload» более эффективен и, вот почему: все транзитные пакеты проверяются на принадлежность ранее помеченному соединению (1 критерий), а не списку IP-адресов. Хотя address-list, это аналог линуксового ipset, но проверка принадлежности к connection должна быть быстрее, чем проверка по хэшу IP-адреса и сверка со списком. Особенно, когда этих проверок две (два правила), одно для SRC-IP, другое для DST-IP.
Далее, simple queue позволяет в одном правиле ограничить сразу и upload и download (если нужно), а не расползаться по двум веткам дерева — правила в дереве не учитывают направление трафика.
Что у вас за провайдер? У меня проблем с облаками нет, провайдер ничего не ограничивает в этом плане. Даже несколько часов может держаться ~ гигабит. Не удивлюсь, если бы и больше суток держался, но я не рискую, так как для провайдера это будет аномальный трафик. А вот несколько часов (например, 2-3) ~ гигабита иногда бывает (например, заливка бэкапов).
Где ты был 9 лет назад, когда я статью писал :)
Ростелеком был в то время.
У меня тоже РТ тогда был (и сейчас он). Проблем нет. Может, ему не нравился трафик именно с Меги, так как он зарубежный. Трафик для провайдера/оператора не везде бесплатный. Где-то договариваются на безлимит, где-то на пакеты трафика с погигабайтной оплатой после лимита, где-то бесплатно обмениваются трафиком, а где-то только на погигабайтную оплату (например, 50 копеек за гигабайт). Или изначально канал последней мили был не очень большой, потому провайдер и вводил ограничения для тех, кто потребляет много трафика. А может, это была политика Меги.
В текущих реалиях уже нет этой проблемы? Не приходится "танцевать с бубном"?
>>> «до 50 Мбит/с», имеющее «фичу» разгоняться до 100 если канал свободен.
Не видел таких тарифов у РТ. Может, до 50 Мбит/с на внешку и до 100 Мбит/с по локалке? Или до 100 Мбит/с в ночное время и тоже по локалке. В 2017 у меня был тариф 200 Мбит/с и 1 Гбит/с по локалке.
Чел. На дворе вторая половина 2026-го, а ты докапываешься до статьи 2017-го года. Акстись.
К тому же, статья вообще о другом.
Просто интересно, что был за тариф. Никто не докапывается, включите голову. Нужно было сделать больше тестов с разными ресурсами, а не катить сразу бочку на провайдера. Что-то мне подсказывает, что дело было не в Ростелекоме. Как будто ему делать нечего, как отслеживать скачки и резать скорость под ноль. Я работал и с шейперми, и с балансировщиками нагрузки, и много с чем.
>>> Провайдер отслеживает все «скачки» скорости и количество обращений к ресурсам, выдавая ограничение на превышающие их показатели предел. Узнать его не получится — это закрытая информация провайдера.
Это ваши домыслы.
Sign up to leave a comment.
Mikrotik: Ограничение скорости скачивания для определенных IP-адресов