A couple of words about FastPath and FastTrack in MikroTik
It is not a secret for anyone that MikroTik produces Software-Baser routers and CPU takes over most of the traffic processing. This approach has an advantage, since You can program almost any functionality and maintain a relatively unified system for all devices. But in speed they will always lag behind routers with specialized chips.
Software processing packages has several disadvantages:
- The lack of wire speed — the processor (especially single-core) can not work faster than specialized chips.
- Locks With really large amounts of traffic (for example, DoS / DDoS) you may not be able to connect to the router even through the console interface, since all processor time will be occupied by traffic processing.
- The difficulty of scaling. You cannot add a module that increases packet processing speed by hardware.
Developers go to various hardware and software solutions to improve the situation:
-
on inexpensive models, allows processing Layer2 traffic bypassing the CPU.
- SoC with a good network chip (CCR line).
- Using hardware encryption
- Various technologies reduce the number of software processing packages (FastPath and FastTrack), and they will be discussed.
SlowPath vs FastPath
SlowPath is the basic traffic path through the internal MikroTik subsystems, it can be quite diverse and, the longer the path, the higher the CPU load and the more the speed drops.
FastPath — algorithms for transmitting traffic bypassing rather large processing blocks.
Operating conditions and support on devices
Most modern routers and motherboards from MikroTik support FastPath, but the wiki has a detailed list:
Model | Ethernet support |
---|---|
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 |
And a separate list for interfaces other than ethernet:
Interface | Fastpath support | Note |
---|---|---|
Wireless | Yes | |
Bridge | Yes | Starting at 6.29 |
VLAN, VRRP | Yes | Starting at 6.30 |
Bonding | Yes | Only RX traffic from 6.30 |
EoIP, GRE, IPIP | Yes | Starting at 6.33. When this option is enabled, not all tunnel traffic will go via FastPath |
L2TP, PPPoE | Yes | Starting at 6.35 |
MPLS | Yes | Currently MPLS fast-path applies only to MPLS switched traffic. MPLS ingress and egress will operate as before. |
Other | Not |
For the full-fledged operation of FastPath, support is needed from both the incoming and the outgoing interfaces. Interfaces should only include hardware queues.
Last but not least, FastPath doesn’t like fragmented traffic. If a packet is framed, it will definitely get stuck on the CPU.
FastPath and Bridge
Bridge is a software interface used to create a Layer2 connection between multiple hardware (or software) interfaces. If you integrate 4 ethernet interfaces on the bridge (and enable hw=yes ) and one wireless on the router , the traffic between the ethernet interfaces will go past the software interface, and the traffic between ethernet and wireless will use the software bridge. On routers with several chips (for example, RB2011), the traffic between interfaces from different chips will use the capabilities of the software bridge (sometimes, to reduce the load, interfaces simply join the patch cord and, in general, it works).
FatsPath — refers only to traffic coming through the CPU (software bridge), usually this is traffic between interfaces from different chips, or the option is disabled hw=yes .
On Packet Flow, the traffic passing through Bridge looks like this:
It is included in the bridge settings (the setting is the same for all bridge interfaces) [Bridge] -> [Settings] -> [Allow FastPath], there you can also see the counters.
For FastPath to work in Bridge, the following conditions must be met:
- There is no vlan configuration on the bridge interfaces (I think this is not relevant for the CRS series, where the vlan are configured at the hardware level, but I could be wrong)
- There are no rules in /interface bridge filter and /interface bridge nat , these are the same blocks from the second scheme that the frame goes through.
- Ip firewall ( use-ip-firwall=no ) is not enabled . A good feature for capturing traffic and debugging the network, but on an ongoing basis is rarely included.
- Do not use mesh and metarouter
- The interface is not running: sniffer, torch and traffic generator.
FastPath and Tunnel
If in two words: a tunnel interface is the encapsulation of some packets into the load part of other packets. If you go along PacketFlow, then the red lines mark the original packet, the blue ones — the original packet encapsulated in the tunnel protocol packet (for example, ipip or gre; eoip gets (and comes from) in bridging decision; with tunnel ipsec is still more interesting, but not related to fastpath).
FastPath tunnel traffic will not be visible in: firewall, queues, hotspot, vrf, ip accounting. But some packets will continue to be transmitted over SlowPath, this must be taken into account when configuring the Firewall.
For FastPath to work in tunnel interfaces, the following conditions must be met:
- Do not use ipsec encryption
- Avoid packet fragmentation (properly configure mtu)
- Enable allow-fast-path=yes on tunnel interface
FastPath and Layer3
Layer3 is the transfer of packets between subnets, the router builds routing tables and proceeds from them forwards the packet to the next hop.
On Packet Flow, the transit traffic on the network layer looks like this:
and even deeper
For FastPath to work on Layer3, the following conditions must be met:
- Do not add rules to the firewall (at all, even nat).
- Do not add entries to Address Lists.
- Do not configure Simple Queues and Queues Tree for parent=global , or interfaces on which you plan to get a working FastPath.
- Do not use mesh and metarouter.
- Disable Connection tracker. The auto option was introduced specifically for the operation of FastPath in the absence of rules in the firewall.
- Do not use /ip accounting .
- Do not use /ip route vrf .
- Do not configure /ip hotspot .
- Do not add ipsec policies.
- Route Cache must be enabled.
- Do not use active: /tool mac-scan and /tool ip-scan .
- Launched sniffer, torch and traffic generator interfere with the operation of FastPath.
It is enabled in the ip settings: [IP] -> [Settings], there you can also see the counters of successfully processed packets.
Screenshot from home router. I have a fairly heavy firewall, several constantly enabled L2TP / IPSec connections and queues. About FastPath you can not even dream.
Fasttrack
Technology marking ip packages for quick passage through Packet Flow.
For FastTrack to work, you must comply with the following conditions:
- Route Cache and FastPath must be enabled and active.
- Correct configuration of traffic marking.
- Works only for UDP and TCP traffic.
- Do not use mesh and metarouter.
- Do not use active: /tool mac-scan and /tool ip-scan .
- Launched sniffer, torch and traffic generator interfere with the operation of FastTrack.
Traffic marked as fasttrack will not be processed in:
- Firewall filter (although this is debatable, in the example I will show why);
- Firewall mangle;
- IPSec;
- Queues with parrent = global;
- Hotspot;
- VRF.
If something interferes with the fasttrack packet, it will be transmitted like all the remaining packets along a slow path.
Enabled by adding a rule (see below) to the Firewall. FastTrack only marks packets from the established connection (you can also mark new, but then there will be problems with NAT). The filter table is used because When marking fasttrack in prerouting, again there will be problems with NAT.
Synthetic test
And (for the last test) what was configured and how it worked:
The filtering rules continued to process traffic (if you disable allowing for established, related traffic went to drop), postrouting + mangle was trapped for packets that did not fall into FastTrack.
In Connection Tracker you can track FastTrack connections by the flag of the same name.
In the [IP] -> [Settings] counters, you can see that FastTrack is active and working, but FastPath is not.
Настройка L2TP сервера в MikroTik
В этом уроке научимся включать и настраивать L2TP сервер.
Для этого перейдем в настройки L2TP сервера PPP > Interface > L2TP Server.
И поставить галочку Enable.
На этом настройка L2TP сервера закончена, но есть нюансы.
Выбор необходимого профиля.
Если мы оставляем профили по умолчанию, то все настройки связанные, например, с IP-адресами будут браться из настроек клиента. В нашем случае есть уже настроенный ранее ppp профиль. Видео про PPP профили.
Или создаем pool адресов:
Создаем профиль vpn-profile:
В этом случае все настройки будут взяты из данного профиля.
Следующая настройка позволяем нам указать максимальное количество сессий на VPN сервере. То есть сколько клиентов может быть одновременно подключено к L2TP серверу. Данное число можно указать произвольно или выяснить эмпирическим путем. Чем более мощное оборудование у нас есть, тем больше клиентов мы сможем подключить.
Дальше нужно отключить старые методы аутентификации и оставить наиболее безопасный mschap2.
Следующая опция Use IPsec позволяем нам зашифровать наш L2TP трафик. Для этого выбираем Use IPsec: required и в графе IPsec Secret указываем пароль для нашего подключения.
В опции Caller ID Type есть 2 варианта — ip address и number. В 90% случаев нам понадобится ip address и в 10% number. Number позволяет различить клиентов, подключенных из-под одного внешнего IP адреса. И остаются две опции, это One Session Per Host. Она позволяет подключаться с одного IP адреса только одному клиенту. И Allow Fast Path. Она позволяет обработать трафик от L2TP сервера по быстрому пути, избегая серьезной обработки через Firewall, но это противоречит работе IPsec, поэтому Allow Fast Path с IPsec несовместимы.
Все это можно сделать следующей командой:
Что касается MTU, можно оставить значение по умолчанию или указать меньший размер, потому что есть заголовки IPsec, которые уменьшают эффективность стандартного MTU.
Записки IT специалиста
Правильное использование Fast Path и FastTrack в Mikrotik
- Автор: Уваров А.С.
- 05.09.2021
С самого основания данного ресурса мы не перестаем придерживаться мнения, что практика всегда должна опираться на необходимый теоретический минимум, давая в своих статьях порой обширные теоретические отступления. Без теории практика превращается в подобие шаманских камланий с бубном, когда вроде сделал все тоже самое, но ничего не работает. В этом плане технология FastTrack в Mikrotik, несмотря на всю свою простоту, держит пальму первенства по количеству возникающих с ней проблем, которые, в большинстве своем, возникают именно от незнания и непонимания работы этой технологии.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Что такое Fast Path
Основной проблемой роутеров Mikrotik, особенно недорогих моделей, является достаточно слабая вычислительная мощность процессора, являющаяся сдерживающим фактором для реализации многих сложных сетевых сценариев. Причина этого кроется в достаточно сложном процессе обработки трафика роутером, в чем можно убедиться подробно изучив диаграммы Packet Flow, показывающие порядок прохождения пакетов через устройство. Если вы собираетесь серьезно работать с устройствами Mikrotik, то данный раздел документации рекомендуется знать хотя бы на твердую четверку, так как именно здесь находятся ответы на многочисленные вопросы типа: «я все сделал по инструкции, но ничего не работает» или «работает, но как-то не так».
Более подробное рассмотрение данного вопроса выходит за рамки нашей статьи, поэтому вернемся к нагрузке на процессор. Очевидно, что причина этого — сложный путь обработки трафика, который полностью ложится на плечи CPU. Можно ли этого как-либо избежать? Можно, в RouterOS v6 для этого появилась новая технология — Fast Path (быстрый путь), которая позволяет направить трафик по быстрому пути, без обработки ядром ОС, что позволяет существенно снизить нагрузку на систему.
Основная мысль, положенная в основу этой технологии такова, что пакеты уже установленных соединений, а также тех участков передачи трафика, где не требуется фильтрация и контроль, можно отправить по быстрому пути, тем самым разгружая процессор и ускоряя передачу данных. Fast Path — это расширение драйвера интерфейса, которое позволяет ему напрямую взаимодействовать с некоторыми подсистемами RouterOS и пропускать остальные.
В настоящий момент Fast Path можно использовать для:
- Трафика IPv4
- Транзитного трафика IPv4 (FastTrack)
- Traffic Generator
- MPLS
- Мосты (Bridge)
Однако использование данной технологии имеет ряд ограничений, так для IPv4 FastPath требуется среди прочего:
- Отсутствие правил брандмауэра
- Отсутствие списков адресов
- Отсутствие политик IPsec
- Отсутствие очередей
- Отсутствие отслеживания соединений
Для мостов требуется:
- Отсутствие правил брандмауэра
- Отсутствие фильтрации VLAN
Это не полный список, с полным списком ограничений вы можете ознакомиться в официальной документации. Но уже этого достаточно, чтобы понять, с Fast Path не все так просто и за производительность приходится расплачиваться возможностями. Если мы хотим использовать быстрый путь, то нам следует отказаться практически от любого контроля и фильтрации трафика.
Также помним, что Fast Path — это расширение драйвера интерфейса и оно может поддерживаться не для всех портов и типов интерфейсов. Так в современных моделях серии RB9xx и RB2011/3011/4011 Fast Path поддерживается для всех портов, а вот более старые модели могут иметь ограничения, поэтому советуем снова обратиться к документации. Также Fast Path можно использовать для PPPoE, L2TP, IP-IP, GRE и EoIP, мостов, VLAN и беспроводных интерфейсов .
При этом может возникнуть ситуация, когда один из интерфейсов поддерживает Fast Path, а другой нет. В этом случае возможны два варианта: если входящий интерфейс поддерживает Fast Path, то часть пути (насколько это возможно) пакеты пройдут через него, а затем перейдут на Slow Path (медленный путь) с полной обработкой трафика на CPU. Если интерфейс входа не поддерживает Fast Path, то трафик проделает весь путь по Slow Path, вне зависимости от того, поддерживает Fast Path интерфейс выхода или нет.
Еще один важный момент: Fast Path можно использовать только для IPv4 TCP или UDP соединений. Однако в правилах нет необходимости указывать протокол, для всего неподдерживаемого трафика Fast Path будет игнорироваться.
Практическое применение Fast Path
Прежде всего перейдем в IP — Settings и убедимся, что флаги Allow Fast Path и Route Cache установлены. В современных моделях это настройки по умолчанию, поэтому данная рекомендация носит чисто академический характер. В данной конфигурации IPv4 TCP и UDP-трафик, удовлетворяющий перечисленным выше условиям, будет автоматически отправлен по быстрому пути.
Для мостов по умолчанию активируется опция Fast Forward, включающая для передаваемых пакетов быстрый путь, но при этом помним, что DHCP-snooping не должен быть включен, а также отсутствовать любая фильтрация трафика или VLAN внутри моста.
А вот дальше уже становится интереснее. Туннельные соединения и L2TP поддерживают Fast Path, но это лишает нас возможности использовать IPsec, поэтому от Fast Path для данных видов соединений придется отказаться. Тем более что система не даст нам создать интерфейс, сочетающий Fast Path и IPsec.
Правда для L2TP-соединений вы можете одновременно установить обе опции, но при включённом IPsec Fast Path будет игнорироваться. Тем не менее мы категорически не рекомендуем использовать такие неоднозначные варианты настройки, потому как при обновлении RouterOS поведение системы может измениться, что способно привести к неожиданным и непредсказуемым результатам.
Коротко подведем итоги. RouterOS по умолчанию сама будет использовать Fast Path там, где это возможно, наша задача — понимать, что влияет на возможность использования данной технологии и делать правильный выбор между Fast Path или возможностями дополнительного контроля и защиты трафика.
Практическое использование Fasttrack
Fasttrack можно без преувеличения назвать самой неправильно настраиваемой опцией. Если выполнить поиск в сети интернет, то можно увидеть множество материалов про то, как решить те или иные проблемы с Fasttrack. Но большинство этих проблем также связаны с непониманием работы данной технологии. Давайте разберемся, что же такое Fasttrack, это сочетание Fast Path + Connection Tracking, проще говоря мы можем отправить все уже установленные и связанные с ними соединения по быстрому пути.
При этом нам окажутся недоступны брандмауэр, очереди, IPsec и многое другое. По сути, пакеты, попадающие в Fasttrack проскакивают роутер без обработки, что значительно снижает нагрузку на процессор, но лишает нас возможности гибко управлять трафиком. Насколько это оправдано? Нужно смотреть по задачам, скажем если это выход внутренних устройств в интернет, то Fasttrack тут вполне к месту, позволяя существенно разгрузить роутер. Насколько это безопасно? Безопасность в данном случае не пострадает, так как по быстрому пути идут уже установленные соединения, новый пакет обязательно пройдет по медленному пути с полной обработкой брандмауэром.
Для включения Fasttrack перейдем в IP — Firewall — Filter Rules и добавим следующее правило: Chain — forward, Connection State: established, related, на закладке Action установим действие fasttrack connection. Это отправит все установленные и связанные соединения по короткому пути, но лишит нас возможности обработки и контроля такого трафика.
Еще один важный момент, вы обязательно должны указать Connection State для этого правила, если вы этого не сделаете, то получите огромную дыру в безопасности, так как мимо брандмауэра по короткому пути пойдут все пакеты. Мы бы не стали заострять на этом внимание, но в нашей практике были случаи, когда администраторы включали Fasttrack для всего транзитного трафика.
Сразу после него добавим еще одно правило: Chain — forward, Connection State: established, related, на закладку Action можно не переходить, так как accept — действие по умолчанию. Для чего это нужно? Как мы помним, Fast Path работает только для TCP и UDP соединений, остальной трафик пойдет по этому правилу, кроме того, некоторая часть пакетов попадающих под действие Fasttrack направляется по медленному пути и без этого правила они бы были отброшены.
Это самая простая реализация Fasttrack, которая приведена в большинстве инструкций, и она же вызывает большинство проблем. Почему так? Да потому, что приведенное выше правило отправляет по быстрому пути все установленные и связанные соединения, без учета их направления и назначения. При этом становятся недоступны фильтрация и маркировка трафика брандмауэром, очереди и политики IPsec. Стоит ли удивляться, что все завязанные на данные технологии настройки перестают работать.
Как быть? Нужно конкретизировать правила, основная наша цель — снизить нагрузку на устройство, поэтому мы хотим использовать Fasttrack для обычного интернет трафика, но исключим оттуда все остальные соединения. Поэтому вместо одного правила используем два:
Где bridge1 — внутренний мост, а ether10 — внешний интерфейс, смотрящий в интернет.
Что изменилось? Теперь по быстрому пути идут пакеты только из локальной сети в интернет и обратно. Все остальные соединения полноценно обрабатываются ядром RouterOS и могут полностью использовать все ее возможности.
Если направлений трафика, который мы хотим направить по быстрому пути несколько, скажем, несколько каналов в интернет, либо межсетевой трафик, то создаем для каждого направления свою пару правил, с указанием входящего и исходящего интерфейсов.
Для IPsec в самое начало цепочки forward (т.е. обязательно выше правил с fasttrack) следует добавить еще два правила:
Важно! Обратите внимание, так как Fast Path — это расширение драйвера интерфейса, то и в качестве критериев в правилах мы должны использовать именно интерфейсы, что позволит максимально корректно обрабатывать потоки трафика и избежать логических ошибок.
Также обратите внимание, что Fasttrack применяется именно для транзитных соединений, не влияя на входящие и исходящие соединения самого роутера. Мы бы не заостряли на этом внимание, но в сети нам попадались инструкции, когда пакеты маркировались в цепочках INPUT и OUTPUT, а затем эти метки соединений пытались использовать в цепочке FORWARD, надо ли говорить, что подобные конструкции работать не будут.
Ну и логическое завершение нашей статьи — практическая польза от Fasttrack. Мы провели простой тест, запустили на одном из узлов сети Speedtest от Ookla используя для выхода в интернет RB2011. С включенным Fasttrack роутер прокачал все 100 Мбит/с тарифа при нагрузке на CPU в пределах 30-32%:
А теперь выключаем Fasttrack и видим, что роутер полностью лег, но при этом даже не смог прокачать тариф, упершись в планку 80 Мбит/с:
Становится очевидно, что Fast Path и FastTrack — важные технологии, позволяющие существенно увеличить производительность Mikrotik, но применять их следует обдуманно, учитывая все плюсы и минусы данного решения. Надеемся, что данная статья окажется вам полезна и вы теперь будете использовать все возможности Fast Path без каких-либо затруднений и будете понимать как именно это работает.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.