Пара слов про 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
    • 21,5k
    • 9
    Поделиться публикацией

    Комментарии 9

      0

      Спасибо за статью! Можете, пожалуйста, пояснить последний абзац про «без параноидального firewall» и трафик, «который просочился мимо FastTrack»? Не понимаю модель угрозы. Сделать TCP SYN, а потом под видом established кидать левые пакеты?

        0
        без параноидального firewall

        У меня бывают конфигурации, когда жестко режу established,related трафик(например для ограничения по времени).

        который просочился мимо FastTrack

        Тут все тяжко, т.к. сложно отследить что просочилось. Обычно это фрагментированный трафик.

        Не понимаю модель угрозы.

        тут не угроза, а сам факт того что fasttrack включен но работает неправильно из-за того чо маркируется не весь трафик
        0
        «который просочился мимо FastTrack» — как я понял, трафик который пошел по стандартному «медленному» пути, т.е. проанализировать, почему он не пошел по быстрому маршруту.
          +1

          В разделе про FastTrack вы не перепутали, когда приписали FastPath? Или там всё же FastTrack имеется в виду?


          И "Trafic Flow" замените, пожалуйста, на Packet Flow — у MiktoTik это всё же разные термины :)

            0
            Может и перепутал, сейчас перечитаю поправлю)

            Спасибо за наблюдательность, поправил
              0
              > Запущенные sniffer, torch и traffic generator мешают работе FastPath.

              Тут тоже, пожалуйста, поправьте :) Про FastPath это было выше, и хоть оно является следствием и для FastTrack, но там-то речь уже про последнего.
                0
                Все, больше про похожие термины писать не буду) путаю когда пишу. Поправил.
            0

            Побольше б внутреннего устройства. Какие блоки и обходятся? Есть ли табличка соединений как у куалкома? Понимание как это работает внутри важно потому как если экономим процессор — возрастает потребление памяти.

              0
              Побольше б внутреннего устройства. Какие блоки и обходятся?

              Часть firewall, очереди, accounting, vrf, hotspot. В остальном информации на эту тему реально очень мало, на mum подходил спрашивал про fastpath для туннелей, мне толком ничего не сказали.

              Есть ли табличка соединений как у куалкома?

              А кау у куалкома? Я-бы почитал. Вообще находил утверждение, что FastPath изначально появился в ядрпе linux, но не нашел достаточно число пруфов.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое