Есть такой момент в жизни каждого MikroTik-администратора: роутер стоит, всё работает, но загрузка CPU неприятно высокая. Торрент на 100 Мбит/с, пара десятков активных пользователей — и процессор уже думает о своей нелёгкой судьбе. Именно здесь на сцену выходит FastTrack — механизм аппаратного ускорения соединений в MikroTik, который позволяет «быстрым» пакетам обходить полную обработку в firewall и летать на максимальной скорости с минимальной нагрузкой на CPU.
В этой статье разберём: что такое MikroTik FastTrack, как он работает изнутри, как включить и отключить его через CLI и WinBox, что такое special dummy rule to show FastTrack counters и зачем она нужна, как FastTrack настроен в дефолтной конфигурации defconf — и три практических кейса. Всё с реальными командами.
Что такое FastTrack и зачем он нужен
FastTrack — это механизм ускоренной маршрутизации в RouterOS, который переводит установленные соединения в специальный «быстрый» режим обработки. Пакеты, попавшие в FastTrack, минуют большую часть стандартного pipeline обработки в ядре RouterOS — они не проходят через Mangle, не обрабатываются правилами Connection Tracking повторно, не тратят время на полный цикл firewall-фильтрации.
Результат: пропускная способность растёт, задержки падают, CPU вздыхает с облегчением.
Сколько это даёт в цифрах
На типичном RouterBOARD без аппаратного offload (hAP ac², RB4011, CCR1009) разница между обычной маршрутизацией и FastTrack может быть весьма существенной:
- Без FastTrack: CPU 60–80% при 300–400 Мбит/с
- С FastTrack: CPU 20–30% при той же нагрузке
На старших платформах с аппаратным offload (CRS3xx, CCR2xxx) разница менее заметна — там есть другие механизмы ускорения. Но для большинства офисных и домашних роутеров на RouterBOARD FastTrack — самый простой способ существенно снизить нагрузку на процессор.
Как работает FastTrack: механика на уровне пакетов
Чтобы понять FastTrack, нужно понять, как RouterOS обрабатывает трафик в обычном режиме. Каждый пакет проходит через цепочку: Prerouting → Routing Decision → Forward → Postrouting. На каждом этапе — Connection Tracking, NAT, Mangle, Filter. Это правильно и гибко, но требует ресурсов.
FastTrack работает иначе. Когда соединение помечается как FastTrack, RouterOS запоминает всю необходимую информацию для маршрутизации этого соединения (интерфейс, MAC назначения, очередь) и при получении следующих пакетов этого соединения — пропускает их по «быстрому» пути, минуя полную обработку.
Когда FastTrack применяется
- Соединение в состоянии established или related — то есть уже установленное, не новое
- Соединение прошло через правило с action=fasttrack-connection
- Нет активных правил Mangle, которые должны обработать эти пакеты
- Нет queue tree, которая зависит от Mangle-маркировок этого соединения
Когда FastTrack НЕ применяется
- MPLS-трафик — не поддерживается
- IPsec-трафик — пакеты с шифрованием не фасттрекаются
- Трафик с активными Mangle-правилами — если пакет должен пройти через mark-connection или mark-routing — FastTrack его не возьмёт
- Мосты (Bridge) — в старых версиях RouterOS (до 6.47) FastTrack не работал на bridge-интерфейсах. С 6.47+ появился Bridge FastTrack, но настраивается отдельно
- Новые соединения — первые пакеты нового соединения всегда идут через полный pipeline
FastTrack и NAT
Важный момент: FastTrack работает совместно с NAT, но с нюансом. NAT-правила обрабатываются при установке соединения (для первых пакетов). Когда соединение попадает в FastTrack, RouterOS уже знает NAT-преобразование и применяет его на быстром пути. Так что masquerade + FastTrack — стандартная и рабочая комбинация для интернет-шлюза.
Defconf и FastTrack: что включено по умолчанию
Defconf (default configuration) — стандартная конфигурация MikroTik, которая загружается при первом запуске или после сброса устройства командой /system reset-configuration. Она включает базовые правила firewall, NAT и — что важно для нас — FastTrack.
В defconf FastTrack включён по умолчанию для established и related соединений. Посмотреть текущие firewall-правила после загрузки defconf:
/ip firewall filter print
В списке вы увидите правило примерно такого вида:
chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"
Это и есть FastTrack в действии. Всё что нужно для базового ускорения — уже настроено в дефолтной конфигурации. Вопрос в том, понимаете ли вы что происходит и как это контролировать.
Включение FastTrack: пошаговая инструкция
Если FastTrack не включён или вы настраиваете роутер с нуля — добавляем правило вручную.
Через CLI (Terminal)
/ip firewall filter add \ chain=forward \ action=fasttrack-connection \ connection-state=established,related \ comment="FastTrack established/related" \ place-before=0
Параметр place-before=0 ставит правило первым в цепочке forward. Это критично: FastTrack должен стоять до правил drop и reject, иначе установленные соединения будут проверяться всеми правилами по порядку — и весь смысл ускорения теряется.
Через WinBox
- Открываем IP → Firewall → Filter Rules
- Нажимаем + для добавления нового правила
- Chain: forward
- Connection State: отмечаем established и related
- Action: fasttrack connection
- Comment: FastTrack established/related
- OK → перетаскиваем правило на первую позицию в списке
Проверка что FastTrack активен
/ip firewall filter print stats
После нескольких минут работы счётчик пакетов и байт на FastTrack-правиле должен расти. Если счётчик стоит на нуле — что-то не так: либо нет трафика, либо правило стоит не там.
# Посмотреть только правило FastTrack /ip firewall filter print stats where comment="FastTrack established/related"
Отключение FastTrack: когда и зачем
Звучит парадоксально — зачем отключать то, что ускоряет? Но ситуации бывают разные.
Когда FastTrack нужно отключить
- Детальный мониторинг трафика — FastTrack-пакеты не видны в torch, не подсчитываются в очередях и не маркируются через Mangle. Если вам нужно «увидеть» весь трафик — FastTrack мешает.
- Настройка QoS и очередей — если вы расставляете приоритеты через queue tree и Mangle — FastTrack нужно временно отключить, иначе часть трафика просто обойдёт ваши правила.
- Отладка firewall-правил — при разборе проблем удобно видеть все пакеты в полном pipeline.
- Использование Mangle для маркировки — если активны Mangle-правила mark-connection или mark-routing для этих соединений, FastTrack всё равно не возьмёт их. Но явное отключение убирает путаницу.
Отключение через CLI
# Отключить правило по comment /ip firewall filter disable [find comment="FastTrack established/related"] # Или отключить все правила FastTrack /ip firewall filter disable [find action=fasttrack-connection]
Удаление правила FastTrack
# Удалить правило FastTrack полностью /ip firewall filter remove [find action=fasttrack-connection]
Последствия для производительности
После отключения FastTrack весь трафик идёт через полный pipeline RouterOS. На слабых платформах (hAP lite, RB750) это означает немедленный рост CPU при высокой нагрузке. На мощных (RB4011, CCR) — менее заметно, но всё равно ощутимо при гигабитных потоках.
Правило: отключаем для диагностики, включаем обратно сразу после завершения отладки.
Special Dummy Rule: как смотреть счётчики FastTrack соединений
Вот тут начинается интересное. Когда пакет обрабатывается FastTrack — он не учитывается в счётчиках обычных firewall-правил, стоящих ниже. FastTrack перехватывает его раньше. Это означает, что если у вас стоит правило connection-state=established,related action=accept после FastTrack — его счётчик будет показывать только пакеты, которые не попали в FastTrack.
Как тогда понять, сколько трафика идёт через FastTrack? Через special dummy rule — специальное «пустое» правило, которое стоит перед FastTrack-правилом и считает пакеты, которые потенциально станут FastTrack-соединениями.
Создание dummy rule для подсчёта FastTrack-трафика
# Добавляем dummy rule ПЕРЕД FastTrack правилом /ip firewall filter add \ chain=forward \ action=passthrough \ connection-state=established,related \ comment="!!! special dummy rule to show fasttrack counters" \ place-before=0
Ключевой момент: action=passthrough — это действие, которое не останавливает обработку пакета. Правило считает пакеты и пропускает их дальше. Никакого влияния на трафик — только счётчики.
После добавления порядок правил в chain=forward должен быть таким:
0 chain=forward action=passthrough connection-state=established,related comment="!!! special dummy rule to show fasttrack counters" 1 chain=forward action=fasttrack-connection connection-state=established,related comment="FastTrack established/related" 2 chain=forward action=accept connection-state=established,related comment="accept established,related" ...остальные правила...
Просмотр счётчиков
# Все правила со счётчиками /ip firewall filter print stats # Только наши правила /ip firewall filter print stats where comment~"fasttrack" # Динамическое обновление каждые 2 секунды /ip firewall filter print interval=2 stats where comment~"fasttrack"
Пример вывода:
0 ;;; !!! special dummy rule to show fasttrack counters
chain=forward action=passthrough connection-state=established,related
packets=1523847 bytes=1873452198
1 ;;; FastTrack established/related
chain=forward action=fasttrack-connection connection-state=established,related
packets=1498231 bytes=1841209344
Смотрим на разницу между счётчиком dummy rule и FastTrack-правила. Если числа близкие — FastTrack берёт почти все established/related пакеты. Если разница большая — часть пакетов по каким-то причинам не фасттрекается (проверьте Mangle-правила и активные очереди).
Почему dummy rule стоит перед FastTrack
Логика такая: FastTrack перехватывает пакет и выдаёт его в быстрый путь. Правила после FastTrack эти пакеты уже не видят. Поэтому dummy rule должна стоять до FastTrack — тогда она успевает посчитать пакет до того, как FastTrack его «похитит».
FastTrack и производительность: разбор деталей
FastTrack vs обычный firewall: сравнение
| Параметр | Без FastTrack | С FastTrack |
|---|---|---|
| Обработка пакетов | Полный pipeline RouterOS | Быстрый путь, минуя Mangle/Filter |
| Нагрузка на CPU | Высокая при нагрузке | Значительно ниже |
| Пропускная способность | Ограничена CPU | Близко к аппаратному максимуму |
| Видимость в torch | Полная | FastTrack-пакеты не видны |
| QoS и очереди | Полная поддержка | Ограниченная |
| Mangle-маркировка | Работает | Не работает на FastTrack-пакетах |
| IPsec | Работает | Не фасттрекается |
Лайфхаки для оптимизации CPU с FastTrack
- FastTrack как первое правило в chain=forward — иначе пакеты прогоняются через предыдущие правила, прежде чем попасть в ускоренный путь. Даже одно правило до FastTrack — лишняя работа для CPU на каждом пакете.
- Минимизируйте Mangle-правила — каждое активное Mangle-правило потенциально мешает FastTrack. Если Mangle не нужен — не добавляйте.
- Connection tracking tuning — FastTrack работает на базе connection tracking. Если таблица соединений переполнена — FastTrack деградирует. Проверяйте:
/ip firewall connection print count-only # Если близко к лимиту — увеличивайте: /ip firewall connection tracking set max-entries=1000000
- Проверяйте версию RouterOS — FastTrack активно развивается. В RouterOS 7.x появился улучшенный FastTrack с поддержкой Bridge. Обновление может дать дополнительный прирост.
FastTrack в RouterOS 7: что изменилось
В RouterOS 7 FastTrack получил существенное развитие:
- Bridge FastTrack — теперь работает на мостовых интерфейсах. Для CRS3xx/CRS5xx с bridge это важно.
- IPv6 FastTrack — поддержка IPv6 в ускоренном режиме.
- Улучшенная интеграция с hardware offload — на платформах с поддержкой offload FastTrack работает совместно с аппаратным ускорением.
Проверить версию RouterOS и включить Bridge FastTrack (RouterOS 7):
/system routerboard print /interface bridge set bridge1 fast-forward=yes
Три практических кейса
Кейс 1: Ускорение интернет-шлюза для офиса на 50 пользователей
Ситуация: RB4011, 50 пользователей, симметричный канал 500 Мбит/с. Без FastTrack CPU держится на 45–55% в пиковые часы. Периодически лагает VoIP.
Исходное состояние firewall:
/ip firewall filter print # Правило FastTrack отсутствует или отключено
Решение: добавляем FastTrack и dummy rule:
# Шаг 1: dummy rule для мониторинга (первой!) /ip firewall filter add \ chain=forward \ action=passthrough \ connection-state=established,related \ comment="!!! special dummy rule to show fasttrack counters" \ place-before=0 # Шаг 2: FastTrack правило (второй!) /ip firewall filter add \ chain=forward \ action=fasttrack-connection \ connection-state=established,related \ comment="FastTrack established/related" \ place-before=1
Результат через 5 минут:
/ip firewall filter print stats where comment~"fasttrack" # Счётчики растут — FastTrack работает # Смотрим CPU /system resource print # cpu-load: 18% ← было 50%
CPU упал с 50% до 18%. VoIP-звонки стали стабильными. Делаем это на всех шлюзах в сети.
Кейс 2: Отладка firewall-правил через отключение FastTrack и dummy rule
Ситуация: Жалобы что определённые соединения блокируются, но в firewall-логах ничего нет. Нужно понять что происходит с трафиком.
Проблема: FastTrack включён, пакеты established-соединений не проходят через обычные правила — их не видно в логах и torch.
Решение: временно отключаем FastTrack:
# Отключаем FastTrack /ip firewall filter disable [find action=fasttrack-connection] # Включаем логирование для подозрительных соединений /ip firewall filter add \ chain=forward \ action=log \ log-prefix="DEBUG_FW:" \ src-address=192.168.10.0/24 \ place-before=0 # Смотрим логи /log print follow where topics~"firewall"
Видим полную картину трафика, находим проблему, исправляем правило. После отладки:
# Удаляем debug-правило /ip firewall filter remove [find log-prefix="DEBUG_FW:"] # Включаем FastTrack обратно /ip firewall filter enable [find action=fasttrack-connection]
Правило: FastTrack — выключить для отладки, включить сразу после. На боевом шлюзе долго держать FastTrack выключенным — плохая идея.
Кейс 3: FastTrack в дефолтной конфигурации для удалённого офиса
Ситуация: Нужно быстро поднять MikroTik в удалённом офисе. Используем defconf как базу и убеждаемся что FastTrack настроен корректно.
После загрузки defconf проверяем:
# Смотрим firewall-правила /ip firewall filter print # Ищем FastTrack /ip firewall filter print where action=fasttrack-connection # Должно быть одно правило: # chain=forward action=fasttrack-connection connection-state=established,related
Добавляем dummy rule для мониторинга (в defconf её нет):
# Находим номер FastTrack правила /ip firewall filter print # Допустим FastTrack стоит на позиции 1 # Добавляем dummy rule перед ним /ip firewall filter add \ chain=forward \ action=passthrough \ connection-state=established,related \ comment="!!! special dummy rule to show fasttrack counters" \ place-before=1
Настраиваем автоматический мониторинг через скрипт:
# Скрипт для логирования FastTrack-статистики каждые 5 минут
/system scheduler add \
name="FastTrack-Stats" \
interval=5m \
on-event={
:local ftRule [/ip firewall filter find comment="!!! special dummy rule to show fasttrack counters"];
:local ftBytes [/ip firewall filter get $ftRule bytes];
:log info "FastTrack bytes: $ftBytes";
}
Частые ошибки при настройке FastTrack
Ошибка 1: FastTrack стоит не первым в цепочке
Симптом: FastTrack включён, счётчики растут, но CPU всё равно высокий.
Причина: Перед FastTrack стоят другие правила, которые обрабатывают каждый пакет. FastTrack ускоряет только ту часть обработки, которая идёт после него.
# Проверяем порядок правил /ip firewall filter print # Перемещаем FastTrack на первую позицию /ip firewall filter move [find action=fasttrack-connection] destination=0
Ошибка 2: Конфликт FastTrack с Mangle-правилами
Симптом: После включения FastTrack перестала работать приоритизация трафика (QoS). Некоторые соединения не попадают в нужные очереди.
Причина: FastTrack-пакеты не проходят через Mangle. Если соединение ушло в FastTrack раньше, чем Mangle успел поставить метку — метки на этих пакетах не будет.
Решение: Для трафика, который нужно маркировать через Mangle, FastTrack нужно исключить. Добавляем условие, которое исключает уже помеченные соединения:
# FastTrack только для соединений БЕЗ меток /ip firewall filter add \ chain=forward \ action=fasttrack-connection \ connection-state=established,related \ connection-mark=no-mark \ comment="FastTrack unmarked connections"
Ошибка 3: FastTrack и connection tracking
Симптом: FastTrack включён, но эффекта нет. CPU не снижается.
Причина: Connection tracking отключён или работает в режиме loose. FastTrack требует полноценного connection tracking.
# Проверяем статус connection tracking /ip firewall connection tracking print # Должно быть: # enabled: yes # Или auto (рекомендуется) /ip firewall connection tracking set enabled=yes
Ошибка 4: FastTrack не работает на bridge в старых RouterOS
Симптом: Устройство работает как bridge/switch, FastTrack включён, но нагрузка не снижается.
Причина: До RouterOS 6.47 FastTrack не поддерживался на bridge-интерфейсах.
# Проверяем версию /system package print # Если RouterOS 7.x — включаем Bridge FastTrack /interface bridge set [find name=bridge1] fast-forward=yes
Контроль FastTrack: итоговый чеклист
# 1. Проверить что FastTrack включён /ip firewall filter print where action=fasttrack-connection # 2. Проверить порядок правил (FastTrack должен быть первым в forward) /ip firewall filter print # 3. Проверить счётчики /ip firewall filter print stats where action=fasttrack-connection # 4. Проверить наличие dummy rule /ip firewall filter print where comment~"dummy" # 5. Проверить CPU до и после /system resource print # 6. Проверить таблицу соединений /ip firewall connection print count-only # 7. Проверить что connection tracking включён /ip firewall connection tracking print
Заключение
FastTrack — один из самых эффективных и при этом малозатратных способов снизить нагрузку на CPU MikroTik и поднять пропускную способность. Одно правило в firewall — и роутер начинает обрабатывать вдвое больше трафика при той же загрузке процессора.
Главные выводы:
- Включайте FastTrack на всех шлюзах, где нет активного QoS с Mangle-маркировками. Это должно быть по умолчанию.
- Добавляйте dummy rule перед FastTrack — иначе вы слепы: не видите сколько трафика реально идёт через ускоренный путь.
- Отключайте FastTrack временно при отладке firewall-правил — иначе часть трафика просто не видна в логах и torch.
- Следите за порядком правил — FastTrack должен стоять первым в chain=forward, иначе эффект минимальный.
- В defconf FastTrack уже включён — но dummy rule нет. Добавьте её вручную для нормального мониторинга.
Настроили FastTrack и получили неожиданный результат? Столкнулись с конфликтом с QoS или IPsec? Пишите в комментарии — разберём. А в следующей статье поговорим про оптимизацию очередей в MikroTik: Queue Tree vs Simple Queues.
Author: Георгий Креативный
Оставайтесь на связи
Рецепты от IT-боли. Без воды, без рекламы, без маркетинговой шелухи.
Подписаться на IT-Аптеку →
