Ни для кого не секрет, что MikroTik производит Software-Baser роутеры и большую часть по обработке трафика берет на себя CPU. У данного подхода есть преимущество, т.к. можно напрограмировать практически любой функционал и поддерживать относительно единую систему для всех устройств. Но по скорости они всегда будут отставать от маршрутизаторов со специализированными чипами.
Программная обработка пакетов имеет ряд недостатков:
- Отсутствие wire speed — процессор (особенно одноядерный) не может работать быстрее, чем специализированные чипы.
- Блокировки. При реально больших объемах трафика (например DoS/DDoS) у вас может не быть возможности подключиться к роутеру даже через консольный интерфейс, т.к. все процессорное время будет занимать обработка трафика.
- Сложность масштабирования. Нельзя добавить модуль увеличивающий скорость обработки пакетов аппаратно.
Разработчики идут на различные аппаратные и програмные решения для улучшения ситуации:
- Switch-чип на недорогих моделях, позволяет обрабатывать Layer2 трафик минуя CPU.
- SoC с хорошим сетевым чипом (линейка CCR).
- Использование аппаратного шифрования
- Различные технологии снижающие число программных обработок для пакетов (FastPath и FastTrack), о них и пойдет речь.
SlowPath vs FastPath
SlowPath — это базовый путь трафика по внутренним подсистемам MikroTik, он может быть давольно разнообразным и, чем длинее путь, тем выше нагрузка на CPU и больше падает скорость.
FastPath — алгоритмы позволяющие передавать трафик, минуя достаточно большие блоки обработки.
Условия работы и поддержка на устройствах
Большинство современных роутеров и плат от MikroTik поддерживают FastPath, но на wiki есть подробный список:
Модель | Поддержка на ethernet интерфейсах |
---|---|
RB6xx series | ether1,2 |
Most of the RB7xx series | all Ethernet ports |
RB800 | ether1,2 |
RB9xx series | all Ethernet ports |
RB1000 | all Ethernet ports |
RB1100 series | ether1-11 |
RB2011 series | all Ethernet ports |
RB3011 series | all Ethernet ports |
CRS series routers | all Ethernet ports |
CCR series routers | all Ethernet ports |
Other devices | Not supported |
И отдельный список для интерфейсов отличных от ethernet:
Интерфейс | Поддержка fastpath | Примечание |
---|---|---|
Wireless | Да | |
Bridge | Да | Начиная с 6.29 |
VLAN, VRRP | Да | Начиная с 6.30 |
Bonding | Да | Только RX трафик, начиная с 6.30 |
EoIP, GRE, IPIP | Да | Начиная с 6.33. При включении опции не весь туннельный трафик пойдет по FastPath |
L2TP, PPPoE | Да | Начиная с 6.35 |
MPLS | Да | Currently MPLS fast-path applies only to MPLS switched traffic. MPLS ingress and egress will operate as before. |
Прочие | Нет |
Для полноценной работы FastPath необходима поддержка как со стороны входящего, так и со стороны исходящего интерфейсов. На интерфейсах должны быть включены только аппаратные очереди.
И последнее, FastPath очень не любит фрагментированный трафик. Если пакет зафрагментирован — он однозначно застрянет на CPU.
FastPath и Bridge
Bridge — это програмный интерфейс используемый для создания Layer2 связи между несколькими аппаратными (или програмными) интерфейсами. Если объеденить на роутере 4 ethernet интерфейса в bridge (и включить hw=yes
) и один wireless, то трафик между ethernet интерфейсами будет ходить минуя программный интерфейс, а трафик между ethernet и wireless будет задействовать программный bridge. На роутерах с несколькими чипами (например RB2011) трафик между интерфейсами с разных чипов будет задействовать возможности програмного bridge (иногда для снижения нагрузки интерфейсы просто объединяют патч-кордом и в целом это работает).
FatsPath — относится только к трафику приходящему через CPU (програмный bridge), обычно это трафик между интерфесов с разных чипов, либо отключена опция hw=yes
.
На Packet Flow трафик проходящий через Bridge выглядит следующим образом:
И подробнее:
Включается в настройки bridge (настройка едина для всех bridge интерфейсов) [Bridge]->[Settings]->[Allow FastPath], там-же можно увидеть счетчики.
Для работы FastPath в Bridge необходимо соблюдать следующие условия:
- Нет конфигурации vlan на bridge интерфейсах (думаю это не актуально для CRS серии, где vlan настраиваются на аппаратном уровне, но могу ошибаться)
- Нет правил в
/interface bridge filter
и/interface bridge nat
, это те самые блоки из второй схемы, которые проходит фрейм. - Не включен ip firewall (
use-ip-firwall=no
). Хорошая функция для захвата трафика и отладки сети, но на постоянной основе включается редко. - Не использовать mesh и metarouter
- На интерфейсе не запущены: sniffer, torch и traffic generator.
FastPath и Tunnel
Если двумя словами: туннельный интерфейс — это инкапсуляция одних пакетов в нагрузочную часть других пакетов. Если идти по PacketFlow, то красными линиями отмечен оригинальный пакет, синими — оригинальный пакет инкапсулированный в пакет туннельного протокола (например ipip или gre; eoip попадает(и приходит из) в bridging decision; с туннельным ipsec все еще интереснее, но не имеет отношение к fastpath).
Туннельный трафик в FastPath не будет виден в: firewall, queues, hotspot, vrf, ip accounting. Но часть пакетов продолжит передаваться по SlowPath, это надо учитывать при конфигурации Firewall.
Для работы FastPath в туннельных интерфейсах необходимо соблюдать следующие условия:
- Не использовать ipsec шифрование
- Избегать фрагментацию пакетов (правильно настраивать mtu)
- Включить
allow-fast-path=yes
на туннельном интерфейсе
FastPath и Layer3
Layer3 — это передача пакетов между подсетями, маршрутизатор строит таблицы маршрутизации и исходя из них направляет пакет следующему хопу.
На Packet Flow транзитный трафик сетевого уровня выглядит так:
идем вглубь
и еще глубже
Для работы FastPath на Layer3 необходимо соблюдать следующие условия:
- Не добавлять правила в firewall (совсем, даже nat).
- Не добавлять записи в Address Lists.
- Не настраивать Simple Queues и Queues Tree для
parent=global
, либо интерфейсов на которых планируется получить рабочий FastPath . - Не использовать mesh и metarouter.
- Отключать Connection tracker. Опция auto была введена именно для работы FastPath при отсуствии правил в firewall.
- Не использовать
/ip accounting
. - Не использовать
/ip route vrf
. - Не конфигурировать
/ip hotspot
. - Не добавлять политики ipsec.
- Route Cache должен быть включен.
- Не использовать активно:
/tool mac-scan
и/tool ip-scan
. - Запущенные sniffer, torch и traffic generator мешают работе FastPath.
Включается в настройках ip: [IP]->[Settings], там-же можно увидеть счетчики успешно обработанных пакетов.
Скриншот с домашнего роутера. У меня достаточно нагруженный firewall, несколько постоянно включенных L2TP/IPSec соединений и очереди. Про FastPath можно и не мечтать.
FastTrack
Технология маркировки ip пакетов для быстрого прохождения через Packet Flow.
Для работы FastTrack необходимо соблюдать следующие условия:
- Route Cache и FastPath должены быть включены и активны.
- Правильная конфигурация маркировки трафика.
- Работает только для UDP и TCP трафика.
- Не использовать mesh и metarouter.
- Не использовать активно:
/tool mac-scan
и/tool ip-scan
. - Запущенные sniffer, torch и traffic generator мешают работе FastTrack.
Трафик помеченный как fasttrack не будет обработан в:
- Firewall filter (хотя это спорно, в примере покажу почему);
- Firewall mangle;
- IPSec;
- Queues с parrent=global;
- Hotspot;
- VRF.
Если что-то будет мешать прохождению пакета по fasttrack, он будет передан как и все оставшиеся пакеты по медленному пути.
Включается путем добавления правила (см. ниже) в Firewall. FastTrack маркируются только пакеты из установленного соединения (можно и new замаркировать, но тогда будут проблемы с NAT). Используется таблица filter, т.к. при маркировке fasttrack в prerouting опять-же возникнут проблемы с NAT.
Синтетический тест
FastPath | Connection Tracker | NAT | FastTrack | Speed | CPU |
---|---|---|---|---|---|
- | - | - | - | ~932Mb/sec | 100%(networking, ethernet) |
+ | - | - | - | ~923Mb/sec | 65-75%(networking, ethernet, unclassified) |
+ | + | - | - | ~680Mb/sec | 100%(networking, firewall, ethernet) |
+ | + | + | - | ~393Mb/sec | 100%(networking, firewall, ethernet) |
+ | + | + | + | ~911Mb/sec | 60-80%(networking, ethernet, unclassified) |
И (для последнего теста) что было настроено и как оно работало:
Правила фильтрации продолжали обрабатывать трафик (если отключить разрешающее для established, related трафик уходил в drop), в postrouting+mangle отлавливались пакеты, которые не попали в FastTrack.
В Connection Tracker можно отслеживать FastTrack соедиения по одноименному флагу.
В Счетчиках [IP]->[Settings] видно, что FastTrack активен и работает, а FastPath нет.
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related
add action=accept chain=forward connection-state=established,related
add action=accept chain=forward connection-state=new
add action=drop chain=forward
/ip firewall mangle
add action=mark-packet chain=postrouting connection-state=established,related new-packet-mark=q1 passthrough=no src-address=20.20.20.0/24
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
Вместо заключения
Использовать или нет?
- FastPath для Bridge — Однозначно да. По крайней мере снижает нагрузку на CPU.
- FastPath для Туннелей — Нет. Работает мутно, отключается при наличии шифрования.
- FastPath для Layer3 — Спорно, теряется большая часть возможностей роутера. В большой, закрытой от дикого интернета, сети может иметь свой (небольшой) выйгрыш.
- FastPath для MPLS/VLAN/Bonding/VRRP — Включается автоматически, если есть возможноть. Отдельной опции для управления нет.
- FastTrack — Для домашних и SOHO конфигураций без очередей и параноидального firewall подойдет. Синтетические тесты с одним клиентом выглядят хорошо, на практике требуется очень внимательно следить за трафиком который просочился мимо FastTrack и выискивать причину.
Ссылки в дополнение
https://wiki.mikrotik.com/wiki/Manual:Fast_Path
https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack
http://mum.mikrotik.com/presentations/UA15/presentation_3077_1449654925.pdf
Комментарии (9)
leon_3
08.01.2019 03:47«который просочился мимо FastTrack» — как я понял, трафик который пошел по стандартному «медленному» пути, т.е. проанализировать, почему он не пошел по быстрому маршруту.
Chupaka
08.01.2019 10:18В разделе про FastTrack вы не перепутали, когда приписали FastPath? Или там всё же FastTrack имеется в виду?
И "Trafic Flow" замените, пожалуйста, на Packet Flow — у MiktoTik это всё же разные термины :)
Bulroh Автор
08.01.2019 11:04Может и перепутал, сейчас перечитаю поправлю)
Спасибо за наблюдательность, поправилChupaka
09.01.2019 15:48> Запущенные sniffer, torch и traffic generator мешают работе FastPath.
Тут тоже, пожалуйста, поправьте :) Про FastPath это было выше, и хоть оно является следствием и для FastTrack, но там-то речь уже про последнего.Bulroh Автор
10.01.2019 12:12Все, больше про похожие термины писать не буду) путаю когда пишу. Поправил.
eri
08.01.2019 12:27Побольше б внутреннего устройства. Какие блоки и обходятся? Есть ли табличка соединений как у куалкома? Понимание как это работает внутри важно потому как если экономим процессор — возрастает потребление памяти.
Bulroh Автор
08.01.2019 15:21Побольше б внутреннего устройства. Какие блоки и обходятся?
Часть firewall, очереди, accounting, vrf, hotspot. В остальном информации на эту тему реально очень мало, на mum подходил спрашивал про fastpath для туннелей, мне толком ничего не сказали.
Есть ли табличка соединений как у куалкома?
А кау у куалкома? Я-бы почитал. Вообще находил утверждение, что FastPath изначально появился в ядрпе linux, но не нашел достаточно число пруфов.
XanKraegor
Спасибо за статью! Можете, пожалуйста, пояснить последний абзац про «без параноидального firewall» и трафик, «который просочился мимо FastTrack»? Не понимаю модель угрозы. Сделать TCP SYN, а потом под видом established кидать левые пакеты?
Bulroh Автор
У меня бывают конфигурации, когда жестко режу established,related трафик(например для ограничения по времени).
Тут все тяжко, т.к. сложно отследить что просочилось. Обычно это фрагментированный трафик.
тут не угроза, а сам факт того что fasttrack включен но работает неправильно из-за того чо маркируется не весь трафик