Mikrotik Qos В Распределенных Системах Или Умных Шейперах

LAN - с подсетью 192.168.0.0/24 Задача - урезать входящую скорость в различных комбинациях (Скачать) для подсети 192.168.0.0/24. Исходящую скорость (Upload) мы пока трогать не будем, но отметим, что ее реализация почти ничем не отличается от реализации входящей скорости.

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

Для этого нам понадобится /ip firewall mangle. Mangle можно представить как своеобразный фильтр, способный выделять пакеты и соединения из общего потока по определенным критериям и совершать с ними определенные действия.

Единственный наш критерий известен: из общего потока нам нужны только пакеты, идущие в подсеть 192.168.0.0/24. В качестве действия с этими пакетами мы выберем присвоение пакету метки; впоследствии на основе этой маркировки пакеты можно будет обрабатывать в дереве очередей.

Чтобы правильно разметить посылку, нужно знать, через какие цепочки она проходит в Mangle. Для этого вам необходимо знать диаграммы потока пакетов (Packet Flow), причем не какие-нибудь диаграммы, а самые последние диаграммы, потому что в шестой версии ROS схема немного изменилась.

И естественно, когда вы впервые посмотрите на эти схемы, у вас на устах не будет ничего, кроме матерных слов.

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

Исходя из этой диаграммы, мы можем понять, что интересующий нас трафик идет по следующему пути: Входной интерфейс > PREROUTING -> FORWARD -> POSTROUTING -> Выходной интерфейс Схема с включенным NAT будет немного толще: Входной интерфейс > PREROUTING > DST-NAT > FORWARD > POSTROUTING > SRC-NAT > Выходной интерфейс Какую цепь выбрать? В пятых версиях ROS помимо того, где находится NAT, нужно было еще знать, где находится обработка глобальных входящих, глобальных очередей и глобальных общих очередей.

В шестой версии все стало проще, потому что.

вышеуказанные обработки были отменены и заменены одной глобальной.

И этот глобал находится в самом конце POSTROUTING, после него обрабатываются очереди SimleQueue и пакет выпускается на свободу.

Исходя из этого, нам не важно, где он сейчас находится, потому что.

вся обработка разметки осуществляется до этого.

А раз так, то единственным ограничением для нас является NAT и выбор будет зависеть от направления трафика, который мы хотим разметить.

По этому поводу я сделал свою собственную диаграмму:



Как видно из схемы, для маркировки полученных пакетов нам нужны цепочки, в которых доступны серые адреса подсети 192.168.0.0/24 (dst-адрес).

И они видны только в FORWARD и POSTROUTING. Для того, чтобы пометить пакеты Upload, нужны цепочки из второй половины схемы, в которой доступны серые адреса подсети 192.168.0.0/24 (src-адрес).

И они доступны во всех трёх цепочках PREROUTING, FORWARD, POSTROUTING. Я рада, что не поленилась и написала столько дополнительных книг.

И все для того, чтобы донести до вас информацию о том, что независимо от направления, которое мы хотим обозначить, в обоих случаях мы можем выбрать цепочку FORWARD. Но в пятых версиях ROS этого сделать нельзя.

С цепочкой определились, теперь нужно решить, как мы будем маркировать посылки.

Сначала отмечать соединения, а уж потом отмечать в них нужные пакеты? Или просто отметим пакеты и всё взлетит? Когда-то, во время первых версий шестой линии, мне написал один хороший человек (за что ему огромное спасибо!) и сказал, что у него в системе интересный глюк.

Он дал мне подключение в TeamViewer и показал, как обычная маркировка пакетов маркирует на треть (треть! Карл!) больше пакетов, чем маркировка теми же параметрами, но внутри соединений.

Соответственно, скорости в дереве были нормальные, а вот на интерфейсах были на треть выше.

Я долго рылся и ничего не нашел.

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

Все это записывается в журнал.

Обычные обычные пакеты, я так и не понял, почему они не попали в соединение.

Я установил на свой тестовый стенд такую же версию (один WAN, один LAN и все под двойным NAT), настроил правила и словил тот же глюк.

На протяжении четырех или пяти (не помню) версий я ловил этот глюк.

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

С тех пор я отказался от маркировки пакетов в соединениях.

Как только попаду в руки, проверю, а пока буду маркировать упаковки вот так.

/ip firewall mangle add action=mark-packet chain=forward comment=LAN disabled=no dst-address-list=LAN new-packet-mark=LAN passthrough=yes;

Добавим также сам адресный лист:

/ip firewall address-list add address=192.168.0.0/24 disabled=no list=LAN;

На этом маркировка в одном направлении завершена; для маркировки исходящего трафика нам понадобится копия правила, где dst-address-list=LAN заменяется на src-address-list=LAN Но как я уже писал, для примера мы будем брать только входящий трафик.

Но я создам два правила, чтобы на одном примере показать, как ведет себя очередь в том или ином случае при установке лимитов.

Родительская очередь

/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=30M name=DOWNLOAD parent=global priority=8

Здесь стоит уточнить несколько моментов: родительский = глобальный — В этом параметре вы можете указать либо «глобальный», либо имя интерфейса.

Имя интерфейса здесь играет роль конкретного фильтра направления трафика и используется в сложных конфигурациях для исключения всех направлений, кроме указанного интерфейса, и допустимо только для этой очереди и ее потомков.

Всегда указывайте в этом параметре «глобальный»; эффект будет тот же, но проблем будет меньше.

максимальный предел = 30M — в условии задачи указано, что наш канал обеспечивает 32 метра, но вам необходимо прописать скорость чуть меньше доступной.

В противном случае у вас возникнут проблемы с шейпером вашего провайдера, и ваш просто не будет работать.

всплеск-предел = 0 всплеск-порог = 0 всплеск-время = 0 с — отключено, поскольку их использование мало что добавляет к PCQ, но в профиле они имеют достаточную релевантность для использования.

приоритет=8 — приоритет очереди, 1 — высший приоритет, 8 — низший приоритет. НЕ РАБОТАЕТ, если в очереди есть дочерние элементы.

Приоритеты работают только для потомков, и они конкурируют друг с другом не только внутри своего родителя, но и с потомками других родителей, и только в случае общего дедушки, ограничивающего скорость этих паразитов.

С одинаковыми приоритетами они распределят между собой всю доступную дедушке скорость.

У разных сначала едят из общей дедушкиной миски те, у кого приоритет выше, потом едят те, у кого приоритет ниже, и то только если что-то осталось, или родители обманули дедушку в Лимит-ат. Хотя родители могут устроить битву титанов среди своих отпрысков, если у них установлен не только Лимит-ат, но и Макс-лимит. Это будет в стиле: «не жри всё, у деда есть другие дети и внуки от первого брака!» Ну давайте пошутим и хватит! Более подробно о лимитах и приоритетах я расскажу чуть позже.

По сути, мы создали родителя, теперь ему нужен дочерний элемент. Но чтобы добавить дочернюю (листовую очередь), необходимо сначала добавить профиль.

Давайте добавим.

/queue type add kind=pcq name= PCQ_DOWNLOAD_LAN pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=0 pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;

вид=pcq — Указываем, что очередь, использующая этот профиль, является инициатором подочередей PCQ pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10с — Настройки Burst Speed, об этом позже.

pcq-classifier=dst-адрес — Этот параметр указывает, какой классификатор будет использоваться для создания очередей PCQ. В данном случае по адресу назначения (входящий трафик) pcq-dst-address-mask=32 и pcq-src-address-mask=32 — задайте количество адресов в одной очереди.

(32=одна очередь на IP-адрес) процентная ставка=0 — Устанавливает верхний предел скорости для одной очереди PCQ (в нашем случае для одного IP-адреса).

Если указан ноль, скорость не ограничивается и будет делиться поровну между очередями (IP-адресами).

В нашем случае 30 мегабит будут разделены поровну между активными очередями (ip-адресами).

pcq-limit=50 — ограничение на размер одной очереди (для одного IP-адреса).

Все данные в этой очереди при достижении лимитов задерживаются, все, что в нее не помещается, уничтожается.

pcq-total-limit=2000 — ограничение на размер всех очередей.

Теперь, когда у нас есть родительская очередь и профиль для дочернего элемента, мы добавим сам дочерний элемент:

/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=LAN packet-mark=LAN parent=DOWNLOAD priority=8 queue=PCQ_DOWNLOAD_LAN;

package-mark=LAN — здесь мы ставим в очередь поток пакетов, отмеченных в мангле.

родитель=DOWNLOAD — указал родителя, который ограничил нашу скорость.

очередь=PCQ_DOWNLOAD_LAN — обратитесь к профилю с настройками в Типе очереди.

Ну вот мы и закончили с правилами.

Давайте посмотрим на визуальную схему.

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

И вот здесь начинается веселье.

Допустим, в настоящее время в подсети работают три машины: 192.168.0.1, 192.168.0.2 и 192.168.0.3. В связи с тем, что ребенок привязан к профилю с именем «PCQ_DOWNLOAD_LAN», профиль сообщил ему, что нужно создать отдельную очередь PCQ для каждого адреса dst-ip, встреченного в размеченном потоке.

У нас будет три очереди PCQ (потока), созданные внутри очереди дерева очередей с одинаковыми параметрами pcq-rate, pcq-limit и Burst Speed. В этом случае очередь работала как своего рода сортировщик пакетов.

И я создал индивидуальную очередь для каждого пользователя.

Каждая очередь проходит через pcq-rate, именно эта штука задерживает пакеты в отдельных очередях.

Далее пакеты смешиваются и заносятся во вторую часть очереди Дерева очередей с именем «LAN», где проверяются их общая скорость по Макс-Лимиту, если он существует и исчерпан, то этот Макс-Лимит есть.

лимит будет разделен поровну между очередями (потоками) PCQ, задержка производится на уровне pcq-rate, одни очереди ускоряются, другие замедляются.

Все, что не укладывается в pcq-лимит, уничтожается.

Но у нас в очереди «LAN» этот параметр не установлен и поэтому трафик ползет в родительскую очередь (DOWNLOAD).

Там все происходит по аналогии, проверяется Max-Limit и при его достижении родительская очередь пинает pcq-rate, чтобы закрыть drawbar. Скорости потока выравниваются, и все приходит в норму.

Давайте на секунду представим, что мы не установили Max-Limit для родительской очереди.

Итак, если значение Max-Limit не было обнаружено нигде на пути трафика при pcq-rate=0, то вся очередь работать не будет, весь трафик пройдет через шейпер без задержек, т.к.

некому сообщить pcq- оцените, что канал не резиновый.

Многих мучает вопрос: если в данном случае pcq-rate = 0, то пользователей три, двое спят, а один скачивает. Съедает все 30 мегабит? - Да! Что будет, если другой проснется и тоже начнет сцеживаться? — Полоса поменяется, скорости выровняются.

Они поделят 30 мегабит поровну.

Единственное предостережение: это требует времени; второй пользователь будет набирать скорость немного медленнее, чем обычно.

Суть механизма заключается в задержке и уничтожении пакетов, не укладывающихся в лимит. Протокол TCP разработан таким образом, что в рамках соединения сервер, отправляющий данные клиенту, проверяет, как они дошли до них; если пакеты имеют повышенную задержку или пакет потерян (нарушение последовательности), сервер снижает скорость отправки для повышения стабильности.

pcq-limit и pcq-total-limit устанавливаются экспериментально; чем больше предел, тем больше задержка и тем больше оперативной памяти использует маршрутизатор.

Чем ниже предел, тем больше пакетов будет уничтожено.

Что произойдет, если вы установите pcq-rate=5M? Каждый пользователь получит не более 5 мегабит. 3 активных пользователя * 5 мегабит = 15 мегабит. Три активных пользователя, все скачивают на полную катушку, pcq-rate=11M? Скорость будет ограничена максимальным лимитом родительской очереди (30M), и эта скорость будет разделена поровну между пользователями по 10 мегабит. Если один из них прекратит загрузку или снизит скорость хотя бы до 8 мегабит, два других ускорятся до 11 мегабит. Очень надеюсь, что в этом примере все понятно, если не понятно, читайте еще и еще, будет сложнее.

Данную функцию желательно использовать на низкоскоростных тарифах для ускорения веб-серфинга или быстрой загрузки данных в приложения.

Эта функция работает только в том случае, если скорость pcq не равна нулю.

Не буду утомлять вас графиками и расчетными формулами до посинения; Я лучше приведу вам пример.

Pcq-ставка=2M pcq-burst-rate=4M pcq-burst-threshold=1M pcq-burst-time=10 с Максимальная пользовательская скорость составляет 2 мегабита.

Если его текущая скорость меньше 1 мегабита (pcq-burst-threshold), он будет иметь доступ к скорости 4 мегабита (pcq-burst-rate) в течение 10 секунд (на практике меньше) — это pcq-burst-time .

Счетчик начинает тикать с момента превышения порога в 1 мегабит (pcq-burst-threshold), по истечении времени скорость упадет до pcq-rate, чтобы Burst снова стал доступен - скорость пользователя должна упасть ниже 1 мегабита и оставайтесь там не менее 10 секунд (pcq-burst-time) Понятно, что это очень грубое объяснение; на самом деле время доступности пакета рассчитывается по сложному алгоритму – время разбивается на 16 сегментов и с учетом практически всех скоростных переменных и ограничений рассчитывается время действия.

Эта функция потребляет значительное количество ресурсов, используйте ее с умом.

Справочно: При внесении любых изменений, в любую очередь и в любом ее проявлении (Дерево или Простое), все счетчики обнуляются, в т.ч.

и счетчики взрывов.

Этот параметр можно изменить от 0,1 до 10, и он используется для установки емкости корзины с токенами.

Вместимость ковша рассчитывается по формуле: Емкость в МЕГАБАЙТАХ = размер сегмента * максимальный предел Над каждой очередью висит ведро с тоннами токенов, пока трафик в данной очереди не превысит лимит (max-limit), токены накапливаются в этом ведре.

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

На что тратятся токены?

/queue tree add name=download parent=global packet-mark=PC1-traffic max-limit=10M bucket-size=10;

В этом примере емкость корзины будет равна: (max-limit=10M) * (bucket-size=10) = 100 мегабайт. Если пользователь или пользователи потока пакетов с пометкой «PC1-трафик» до недавнего времени ничего не скачивали на полной скорости, ведро с токенами в этой очереди будет заполнено, а это целых сто мегабайт трафика.

И вот они вместе решили что-то скачать, так вот, первые 100 мегабайт трафика они получат без ограничения скорости по макс-лимиту, когда будет скачано 100 мегабайт очередь начнет ограничивать скорость по заданному максимальный лимит = 10M. Кроме того, если у очереди есть родительский элемент с более толстым max-limit, то после того, как дочерний элемент израсходует все свои токены из своего сегмента, он начнет брать токены из родительской очереди.

Для чего это? Bucket-size — это своего рода Burst, только не по скорости, а по объёму трафика.

Использование его совместно с очередями PCQ даст лишь сомнительные преимущества.

В одиночных сеялках, таких как pfifo, red и sfq, это может быть чрезвычайно полезно.

Для очередей PCQ единственное, что приходит на ум, это то, что мы ограничиваем скорость родительских очередей, которая немного ниже реальной скорости канала.

Правильное использование этой функции позволяет в краткосрочной перспективе более полно использовать всю доступную скорость канала и сгладить пики активности пользователей.

Мы пометили трафик на эти адреса одним правилом в мангле и одним списком адресов.

На всякий случай скажу, что для мангла нет разницы, как мы ему будем скармливать адреса для разметки — они будут обработаны одинаково.

Вся подсеть:

/ip firewall address-list add address=192.168.0.0/24 disabled=no list=LAN;

Диапазон адресов:

/ip firewall address-list add address=192.168.0.1-192.168.0.3 disabled=no list=LAN;

Индивидуальные адреса:

/ip firewall address-list add address=192.168.0.1 disabled=no list=LAN; /ip firewall address-list add address=192.168.0.2 disabled=no list=LAN; /ip firewall address-list add address=192.168.0.3 disabled=no list=LAN;

Аналогичная ситуация и с очередями PCQ. Очередь PCQ легко разбирает один поток пакетов, размеченных одним правилом, состоящий из адресов разных подсетей в подочереди.

Допустим, мы подключили еще трех пользователей из другой подсети (192.168.1.1, 192.168.1.2, 192.168.1.3).

Просто добавьте необходимые записи в список адресов.

Тогда мы получим следующую картину:



На основании всего вышесказанного можно сделать вывод, что мы оперируем не подсетями, а группами IP-адресов, которые создаем с помощью списков адресов.

В этом случае нет смысла отдельно размечать трафик, создавать два профиля и две очереди.

Такой подход необходим только в следующих случаях: Когда вам нужно установить индивидуальный Макс-Лимит для выбранной группы адресов.

Когда для групп адресов или типа трафика требуется разный приоритет. Когда необходимо реализовать разные тарифные планы для группы адресов.

(ставка за штуку) И во всех возможных сочетаниях вышеперечисленных случаев.

Имеем исходные данные: WAN-интерфейс с белым адресом (1.1.1.1) и входящей скоростью 32 мегабита в секунду.

LAN - с подсетью 192.168.0.0/24 (Рабочие места директоров) LAN2 - с подсетью 192.168.1.0/24 (рабочие станции менеджеров) В этом примере у нас есть один канал и две группы потребителей с разными приоритетами.

Где директора имеют приоритет над менеджерами.

Именно в этом случае реализация данной схемы потребует отдельной маркировки пакетов и отдельных очередей для групп пользователей.

Правила маркировки:

/ip firewall mangle add action=mark-packet chain=forward comment=GROUP-A_DW disabled=no dst-address-list= GROUP-A new-packet-mark= GROUP-A_DW passthrough=yes; /ip firewall mangle add action=mark-packet chain=forward comment=GROUP-B_DW disabled=no dst-address-list= GROUP-B new-packet-mark= GROUP-B_DW passthrough=yes;

Два правила маркировки трафика разными пакетными метками и два списка для назначения адресов группам.

/ip firewall address-list add address=192.168.0.0/24 disabled=no list=GROUP-A; /ip firewall address-list add address=192.168.1.0/24 disabled=no list=GROUP-B;

Пришло время создать профили PCQ для очередей.

Сколько профилей вам нужно? По идее для загрузки достаточно одного профиля, но я всегда создаю отдельный профиль для каждой группы и для каждого направления.

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

/queue type add kind=pcq name= GROUP-A_DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=0 pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000; /queue type add kind=pcq name= GROUP-B_DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=0 pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;

Создайте дерево очередей: Родительская очередь:

/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=30M name=DOWNLOAD parent=global priority=8;

Потомки:

/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name= GROUP-A_DW packet-mark= GROUP-A_DW parent=DOWNLOAD priority=7 queue= GROUP-A_DW; /queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name= GROUP-B_DW packet-mark= GROUP-B_DW parent=DOWNLOAD priority=8 queue= GROUP-B_DW;

В этом примере нет ничего сложного; разница между очередями только в разной маркировке пакетов и разных приоритетах.

На низких скоростях эта схема будет прозрачно пропускать через себя трафик и любой из потребителей сможет получить все 30М, указанные в родительской очереди.

При недостатке скорости в родительской очереди скорость начнет перераспределяться между потребителями по следующей схеме: Группа с адресами GROUP-A_DW имеет более высокий приоритет (приоритет=7), ей будет предоставлена вся скорость родительской очереди (30M) и поровну поделена между активными потребителями внутри этой очереди.

Если эта группа не израсходовала весь доступный лимит скорости (30М), остаток этого лимита будет перенесен в очередь с более низким приоритетом GROUP-B_DW (приоритет=8), где эти остатки будут поровну поделены между активными потребителями внутри эта очередь.

Если GROUP-A_DW израсходовал весь доступный лимит в 30 мегабит, GROUP-B_DW вообще не получит скорости и не сможет отправлять и получать пакеты из сети.

Для того, чтобы у группы с низким приоритетом осталась хоть какая-то скорость, в очереди можно установить параметр limit-at=5M. Но этот параметр можно установить только совместно с параметром Max-Limit; нам не нужно ограничивать максимальную скорость группы — поэтому просто скопируем ее из родительской очереди.

А вторая очередь после правок будет выглядеть так:

/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=5M max-limit=30M name=GROUP-B_DW packet-mark=GROUP-B_DW parent=DOWNLOAD priority=8 queue=GROUP-B_DW;

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

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

У нас узкий интернет-канал, пара тарифных планов и две категории абонентов (физические и юридические лица).

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

При этом мы предоставляем юридическим лицам некоторые дополнительные гарантии в виде гарантированной скорости и более быстрой технической поддержки.

Ну и как это часто бывает, мы немного увлеклись и подключили чуть больше абонентов, чем может обработать наш интернет-канал.

Правильный вариант — расширить канал или подключить дополнительный с последующей балансировкой нагрузки.

Но, как уже говорилось, это пока невозможно.

Но скорости в прайм-тайм не хватает, начинают звонить юридические лица и жаловаться на скорость, не соответствующую тарифному плану, задержки пакетов, заикания телефонии и т.д. Частично облегчить эту ситуацию поможет шейпер с приоритетами, как во втором примере; Отличия лишь в том, что в данном примере скорость на одного абонента строго ограничена и имеется несколько тарифных планов.

Как и в предыдущих примерах, мы будем учитывать только входящую скорость.

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

Сокращения: СИЗ является физическим лицом.

УР является юридическим лицом.