System administration
Network hardware
January 8

Пара слов про FastPath и FastTrack в MikroTik

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


Программная обработка пакетов имеет ряд недостатков:


  1. Отсутствие wire speed — процессор (особенно одноядерный) не может работать быстрее, чем специализированные чипы.
  2. Блокировки. При реально больших объемах трафика (например DoS/DDoS) у вас может не быть возможности подключиться к роутеру даже через консольный интерфейс, т.к. все процессорное время будет занимать обработка трафика.
  3. Сложность масштабирования. Нельзя добавить модуль увеличивающий скорость обработки пакетов аппаратно.

Разработчики идут на различные аппаратные и програмные решения для улучшения ситуации:


  1. Switch-чип на недорогих моделях, позволяет обрабатывать Layer2 трафик минуя CPU.
  2. SoC с хорошим сетевым чипом (линейка CCR).
  3. Использование аппаратного шифрования
  4. Различные технологии снижающие число программных обработок для пакетов (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 необходимо соблюдать следующие условия:


  1. Нет конфигурации vlan на bridge интерфейсах (думаю это не актуально для CRS серии, где vlan настраиваются на аппаратном уровне, но могу ошибаться)
  2. Нет правил в /interface bridge filter и /interface bridge nat, это те самые блоки из второй схемы, которые проходит фрейм.
  3. Не включен ip firewall (use-ip-firwall=no). Хорошая функция для захвата трафика и отладки сети, но на постоянной основе включается редко.
  4. Не использовать mesh и metarouter
  5. На интерфейсе не запущены: sniffer, torch и traffic generator.

FastPath и Tunnel


Если двумя словами: туннельный интерфейс — это инкапсуляция одних пакетов в нагрузочную часть других пакетов. Если идти по PacketFlow, то красными линиями отмечен оригинальный пакет, синими — оригинальный пакет инкапсулированный в пакет туннельного протокола (например ipip или gre; eoip попадает(и приходит из) в bridging decision; с туннельным ipsec все еще интереснее, но не имеет отношение к fastpath).



Туннельный трафик в FastPath не будет виден в: firewall, queues, hotspot, vrf, ip accounting. Но часть пакетов продолжит передаваться по SlowPath, это надо учитывать при конфигурации Firewall.


Для работы FastPath в туннельных интерфейсах необходимо соблюдать следующие условия:


  1. Не использовать ipsec шифрование
  2. Избегать фрагментацию пакетов (правильно настраивать mtu)
  3. Включить allow-fast-path=yes на туннельном интерфейсе

FastPath и Layer3


Layer3 — это передача пакетов между подсетями, маршрутизатор строит таблицы маршрутизации и исходя из них направляет пакет следующему хопу.


На Packet Flow транзитный трафик сетевого уровня выглядит так:



идем вглубь



и еще глубже



Для работы FastPath на Layer3 необходимо соблюдать следующие условия:


  1. Не добавлять правила в firewall (совсем, даже nat).
  2. Не добавлять записи в Address Lists.
  3. Не настраивать Simple Queues и Queues Tree для parent=global, либо интерфейсов на которых планируется получить рабочий FastPath .
  4. Не использовать mesh и metarouter.
  5. Отключать Connection tracker. Опция auto была введена именно для работы FastPath при отсуствии правил в firewall.
  6. Не использовать /ip accounting.
  7. Не использовать /ip route vrf.
  8. Не конфигурировать /ip hotspot.
  9. Не добавлять политики ipsec.
  10. Route Cache должен быть включен.
  11. Не использовать активно: /tool mac-scan и /tool ip-scan.
  12. Запущенные sniffer, torch и traffic generator мешают работе FastPath.

Включается в настройках ip: [IP]->[Settings], там-же можно увидеть счетчики успешно обработанных пакетов.



Скриншот с домашнего роутера. У меня достаточно нагруженный firewall, несколько постоянно включенных L2TP/IPSec соединений и очереди. Про FastPath можно и не мечтать.


FastTrack


Технология маркировки ip пакетов для быстрого прохождения через Packet Flow.


Для работы FastTrack необходимо соблюдать следующие условия:


  1. Route Cache и FastPath должены быть включены и активны.
  2. Правильная конфигурация маркировки трафика.
  3. Работает только для UDP и TCP трафика.
  4. Не использовать mesh и metarouter.
  5. Не использовать активно: /tool mac-scan и /tool ip-scan.
  6. Запущенные sniffer, torch и traffic generator мешают работе FastTrack.

Трафик помеченный как fasttrack не будет обработан в:


  1. Firewall filter (хотя это спорно, в примере покажу почему);
  2. Firewall mangle;
  3. IPSec;
  4. Queues с parrent=global;
  5. Hotspot;
  6. 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

+19
23k 169
Comments 9
Top of the day