Главная » Хабрахабр » Пара слов про FastPath и FastTrack в MikroTik

Пара слов про 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 необходима поддержка как со стороны входящего, так и со стороны исходящего интерфейсов.

Если пакет зафрагментирован — он однозначно застрянет на CPU. И последнее, FastPath очень не любит фрагментированный трафик.

FastPath и Bridge

Если объеденить на роутере 4 ethernet интерфейса в bridge (и включить hw=yes) и один wireless, то трафик между ethernet интерфейсами будет ходить минуя программный интерфейс, а трафик между ethernet и wireless будет задействовать программный bridge. Bridge — это програмный интерфейс используемый для создания Layer2 связи между несколькими аппаратными (или програмными) интерфейсами. На роутерах с несколькими чипами (например 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). Если двумя словами: туннельный интерфейс — это инкапсуляция одних пакетов в нагрузочную часть других пакетов.

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

Для работы 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 мешают работе FastPath.

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

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

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

ниже) в Firewall. Включается путем добавления правила (см. Используется таблица filter, т.к. FastTrack маркируются только пакеты из установленного соединения (можно и new замаркировать, но тогда будут проблемы с NAT). при маркировке 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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Big data, deus ex machina

Источник Эту фразу на выступлении для PopTech произнёс несколько лет назад Джер Торп (Jer Thorp), художник и эксперт в вопросах анализа и визуализации данных, один из основателей «Бюро креативных исследований». «Данные — это новая нефть». Разбираемся, какие данные big, а ...

XXH3: новый рекордсмен по скорости хеширования

Бенчмарки сделаны в программе SMHasher на Core 2 Duo 3,0 ГГц Они применяются там, где важна скорость и нет смысла применять медленные MD5 или SHA1. На Хабре неоднократно рассказывали про некриптографические хеш-функции, которые на порядок быстрее криптографических. Например, для построения ...