Mikrotik: Load Balance & QoS (Балансировка в КПСС и соблюдение скоростного режима)

В этой статье я хочу поделится своим решением балансировки с применением Классификатора по Сетевым Соединениям (Per Connection Classificator) и маркировкой трафика для QoS.

Предисловие

Ну и кроме всего, связать это с QoS не является тривиальной задачей.

Введение в Policy Base Routing

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

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

Для генерации маршрутов нам поможет такой скрипт:

Данный скрипт может быть использован совместно с DHCP, если закоментить переменные в разделе «use then static ip»

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

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

Идея тут довольно простая: новое соединение пришедшее из интернета, сразу маркируется меткой провайдера, через которого пришло, а то что собирается уйти в сторону интернета балансируется с помощью PPC или направляется к «прибитому» (Nailed) провайдеру в соответствии с критерием.

Далее я приложу скрипты, которые генерируют определенную часть конфигурации. Прикладывать конфигурацию содержащую все сразу будет избыточным, скрипты покажут отдельные, не дублирующиеся фрагменты. А для понимания скриптов помогут эти схемы:

Принципиальная (обобщенная) схема прохождения пакетов в таблице PreRoute:

Функциональная схема, каждая колонка олицетворяет отдельную цепочку правил:

Схема таблицы Forward принципиальная:

И собственно самый большой монстр, схема таблицы Forward функциональная:

Такие извращения нужны в частности из-за того, что нет условия вроде «ELSE», а еще, на соединении может быть только одна метка (которая есть целое число, для удобства, отображенная как понятное человеку название). Из-за наличия кучи QoS классов, да еще и маршрутов до разных провайдеров, пришлось реализовывать «вызовы функций с переменными в стеке» тем языком, который есть в пакетном фильтре RoS (который почти ничем не отличается от Linux и просто обернут немного в другую командную обертку). Если реализуют битовые операции с метками, то почти все извращения выше станут не нужны!

Если вы ищите универсальное решение: его нет. Каждый планирует политику исходя из потребностей своей сети. Я полагался на вот эту статью: Borderless Campus 1.0 Design Guide от Cisco, и тоже перенес её не 1 в 1.

Самый первый, и самый не сложный (хоть и большой), скрипт классификации трафика (бесполезен без остальных, нет своей точки входа для трафика):

Этот классификатор назначает метку класса для различных видов трафика, основной набор я взял из Shorewall, если вам столько не надо, смело урезайте. Тут есть два простых правила, весь трафик сначала помечается как DF (Default), а затем, весь UDP помечается как CS1 (Scavenger, «мусорный» трафик, которым мы заполняем остатки полосы пропускания). И уже после, весь трафик переразмечается в другие классы.

Таким образом, torrent автоматически становится либо CS1, либо DF (если TCP), и куча другого трафика так-же может получить такие классы, если вы их сами не выделите.

Важно заметить, что Web трафик, соединения которого «длинные», потом перемаркируется в AF12 (для различных закачек и т.п.). Таким образом, серфинг проходит шустро (у DF приоритет 7), а когда начинается закачка, она автоматически попадает в AF12 (с приоритетом 8), тем самым, забить канал закачкой не удается.

Отдельно стоят всякие YouTube. Их трафик ловим с помощью Layer7 (не самый надежный вариант, но вполне рабочий).

Далее идет скрипт ответственный за маршрутизацию:

Можем задать число провайдеров (у меня их 6-ть), указать домены, DNS резолвинг которых надо делать на особом DNS сервере, указать классы пользователей (первыми указываем все «особые» категории, в конце все «остальные»). Указываем на необходимость классификации трафика в локальной сети, а не только до интернета и задаем необходимость балансировки, с указанием относительного веса провайдеров.

Обязательно заполните список адресов LAN-IP. Он необходим для определения направления трафика и должен содержать адреса вашей внутренней сети.

Далее, скрипт для раскладывания трафика по очередям:

Тут опций поменьше, из еще «неизвестных»: требовать установки DSCP у пакетов и постановки в очереди трафика сгенерированного самим маршрутизатором (если у вас есть туннели, то их трафик в таком случае будет учтен два раза, включайте только если знаете зачем вам оно надо, мне вот не надо).

Обратите внимание на списки интерфейсов TUN<номер>, в эти списки помещайте туннельные интерфейсы, которые ходят через соответствующего провайдера. Тогда туннельный трафик тоже пройдет QoS, но не внешний (по отношению к туннелю), а внутренний.

Список интерфейсов WiFi нужен для расстановки приоритетов WiFi трафика (технология WMM) с использованием меток DSCP.

В заключении, скрип генерирующий дерево очередей:

Обратите внимание, типы пользователей указанны в обратном порядке, точнее, в порядке приоритета. Задаем число VoIP каналов, и максимальную скорость провайдеров (подразумевая симметричную скорость). Параметр Reserv задает сколько зарезервировать под «колебания и вылеты» скорости за приделы заданных значений (для маленьких каналов в процентах, для больших в 500Кбит\с). genOnly задает номер провайдера, очереди которого надо перегенерить (-1 для всех, отсчет с 0).

Немного о производительности: Классификация как таковая не требует много ресурсов, так-как затрагивает в основном только новые пакеты, которых обычно мало. Однако, перемаркировка DSCP меток пакета, установка обычных и маршрутных меток пакета производится с каждым пакетом. Использование костылинга вместо нормальных битовых операций совсем не улучшает производительность. Там где можно вытащить класс трафика или интерфейс, через который он пойдет, буквально одним правилом, приходится делать монстра из десятков правил! Как бы то ни было, RB951G способен прожевать около 52 Мбит\с в одну сторону с установкой DSCP. RB1100x4 не напрягается более чем на 8%, при трафике в 60 Мбит\с (локалку я у себя не классифицирую).

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